3 ms·
> Discovery looks interesting. Can it be used for a client to discover a cluster? It certainly could be extended for that. We haven't done anything with discov
by philips 13y ago
> Discovery looks interesting. Can it be used for a client to discover a cluster?
It certainly could be extended for that. We haven't done anything with discovery to help with that process yet though.
> Is there a way etcd can work better with Docker links?
There is a lot of room to explore here. Including:
- Automatically registering exposed ports from running containers into etcd for service discovery.
- Using information in etcd to manage a smart proxy that would proxy requests. This would be the "Link via an Ambassador" but etcd would help coordinate.
Both of these would be good things to build and see how they work and feel in practice.
There are also some interesting alternatives to doing the links thing such as using some network namespace tricks to avoid passing metadata around via environment variables and simply expose services directly into a container: https://coreos.com/blog/Jumpers-and-the-software-defined-localhost/ https://coreos.com/blog/Jumpers-and-the-software-defined-loc...
- nl 13y ago> Discovery looks interesting. Can it be used for a client to discover a cluster? >> It certainly could be extended for that. We haven't done anything with discovery to help with that process yet though. So what is the current best practice for etcd discovery? Environment variable? mDNS might be nice, too (Though I guess mDNS is kinda, almost an alternative for a subset of what etcd does). http://blogs.gnome.org/danni/2014/02/02/a-libnss-plugin-for-docker/ http://blogs.gnome.org/danni/2014/02/02/a-libnss-plugin-for-... looks interesting too. I read the Jumper post thing when it was HN. I need to think about that some more.