I’m setting up some docker containers and want to use service discovery. A challenge is that most services do not explicitly support it, so there needs to be a way to make them, easily.

This is just me, thinking it through as a newb.

• There are two roles, registering services, and consuming services.
• These roles are entirely separate concerns; a service might heartbeat with service discovery, but we still could do consumption in such a way that the host controller sets a static environment variable (w/ a value service discovery) and has to restart the WordPress container when the MySQL container changes IP.
• The controller managing dependencies and restarting dependent services isn’t acceptable though. Dependencies may be known during deployment of containers, but once they are running, we don’t want to require a central instance to keep it all going.

Registration

• For service registry, docker containers can either expose themselves internally either a) via an internal LAN interface or b) by mapping to a host port.
• In both cases, it is the controller’s responsibility to know and decide on the address with which to register. In a) it is the only one knowing what the LAN is, in b) it is the one to pick the host port mappings.
• (In (a), a container may be able to know/guess the LAN on its own, but only because conceptually, it it would still the controller setting up the container interfaces.)
• In a docker setup specifically, the container may do the registration, but again it would be the host telling it the ip:port to register with. This can be easiest because LAN IPs are assigned via DHCP, so the controller would only know the IP post-start. A container can just wrap its binary in something like (sdutil)[https://github.com/flynn/sdutil] and take advantage of docker’s daemonization.
• (So if a container registers itself on its eth0 ip on a port chosen on its own, I am arguing this is still conceptionally the controller telling the container: feel free to register on any port on this interface you can assume to be the LAN.).

Consumption

• On the consuming side, if the service interacts with service discovery, we don’t have a problem.
• Again, this must work without the controller being involved to do dependency-related restarts.
• Instead, the service must use an external helper like (sdutil)[https://github.com/flynn/sdutil] to restart itself. I.e. we are pushing it to the edge.
• A tool like (synapse)[https://github.com/airbnb/synapse] or the proposed (CoreOS jumpers)[https://coreos.com/blog/jumpers-and-the-software-defined-localhost/] would move the service discovery consuming the host (and provide a transparently redirect port to the container). This is acceptable, because we are not per se centralizing on the host. Instead, it would be more accurate to say that services get a secondary, sibling service to do discovery consumption.
• In fact, the jumper may be a superior solution because it does not require restarts.

Available Tools

• (skydock)[https://github.com/crosbymichael/skydock] – uses DNS, with short timeouts consumption and docker-events for automatic registration.
• etcd
• serf