With the new “swarm mode”, you can use docker services to create clustered services in multiple swarm nodes. You can then access the same load-balanced services using the service name, not the node name in your requests.
This only applies to swarm overlay network nodes. If your client systems are part of the same swarm, then the discovery should work without any external solutions.
On the other hand, if you want to be able to discover services from systems outside the swarm, you have several options:
- For stateless services, you can use the docker routing grid , which will make the service port available to all swarm nodes. That way, you can simply point to any node in the swarm, and the docker will direct your request to the node that starts the service (regardless of whether your node has a service or not).
- Use the actual load balancer in front of your swarm services if you need to control routing or deal with different states. It can be either another docker service (i.e. Haproxy, nginx) launched with the
--mode global option to ensure that it works on all nodes, or a separate load balancer, such as citrix netscaler. You will need your service containers to reconfigure LB through their startup scripts or through provisioning tools (or add them manually). - Use something like a consul to discover external services. Perhaps in conjunction with registrator to automatically add services. In this scenario, you simply configure external clients to use the consul server / cluster to resolve DNS (or use the API).
Of course, you can simply move your service consumers to a swarm. If you separate clients from services in different physical VLANs (or VPCs, etc.), you will need to run client containers on separate overlay networks to ensure that you cannot effectively destroy any physical network segregation already in place.