When running applications deployed as a docker “service” within Docker Swarm (post 1.12 swarm mode), often those application’s have the need to discover their peer containers for purposes such as forming a cluster. Similar to “service discovery”, I’ll just use the term “peer discovery” for this use-case.
The simple example is as follows: You create a swarm service bound to a docker network “N” and launch/scale X containers over it. How do those container instances find one another on the docker network?
As it stands today, simple dynamic discovery of peer container instances within a named swarm “service” residing on a particular docker network is not trivial. The Docker engine’s service API, can provide the information you need to figure this out, however this still puts a lot of work on you, the container developer who needs to collect this info and then act upon it in order to form a higher level cluster between your containers.
I had this specific challenge for a Java based service that needed to form a peer cluster dynamically. Out of that use case I came up with a generic library that you can drop into your Java container application called docker-discovery-swarm-service which is available at: https://github.com/bitsofinfo/docker-discovery-swarm-service
The purpose of this library is for “self-discovery” from within your JVM based Docker service application where you need to discover what your accessible docker service network bound IP is, as well as that of your peers within the same named docker service. As noted above this is critical if your container has to do further peer discovery for other services it provides or clustering groups it must form.
You can read all the details of how it works and how to use it here: https://github.com/bitsofinfo/docker-discovery-swarm-service
Hopefully it will be of use to you as well.
After going through a lot of R&D of deploying Hazelcast enabled apps as Docker Containers, first starting on pre-Docker 1.12 (legacy swarm, w/ mgrs/agents etc), with Registrator and Consul, ended up creating the hazelcast-consul-discovery-spi (available on GitHub).
This served its purpose well, but as Docker evolved and post 1.12 “swarm mode” came out with the entire concept of Docker “services”, coupled with the questionable future of the Registrator project itself; it was time to migrate our apps to “swarm mode” services….. however again we ran into issues w/ Hazelcast and peer discovery.
Out of this challenge I ended up creating the hazelcast-docker-swarm-discovery-spi
This works with Hazelcast 3.6-EA+ and Docker Swarm services (manager nodes) to provide automatic peer discovery of the Hazelcast cluster. This is done by interrogating the swarm manager api’s to locate peers based on shared information such as network info, service names and service labels (that are specified by you when you launch your services)
I hope others find this helpful, and please leave your feedback, pull-requests or issues on the project!
Do you use Docker?
Does your containerized app have the need to discover both its own IP and one or more mapped ports?
How can another container access my exposed ports and how can I do the same of my peers?
As it stands today, simple self discovery of your container’s accessible IP and one or more of its mapped ports is not exposed to your Docker container process as a native feature of the engine itself.
If you’ve attempted to containerize an app that attempts to discover its peers in order to form its own peer-level cluster etc, you’ve likely run into this challenge.
That said there are several tools out there with can help you with this issue. One of which is Registrator which is a special container that listens for events from a Docker host and acts as service discovery bridge that relays this info into other tooling such as Consul and etcd etc. In short, when your container is launched, the Registrator container collects all the info about the docker host it is running on and its exposed ports and registers this under a named service in one of the aforementioned backends.
This is all fine and great, however this still puts a lot of work on you, the container developer who needs to collect this info and then act upon it in order to form a higher level cluster between your containers.
I had this exact same problem for a Java based service that needed to form a Hazelcast cluster dynamically. Out of that use case I came up with a generic library that you can drop into your Java container application called docker-discovery-registrator-consul which is available at: https://github.com/bitsofinfo/docker-discovery-registrator-consul
The purpose of this library is for “self-discovery” from within your JVM based Docker application where you need to discover what your accessible docker-host bound IP and mapped port(s) are, as well as your peers within the same service. As noted above this is critical if your container has to do further peer discovery for other services it provides or clustering groups it must form.
You can read all the details of how it works and how to use it here: https://github.com/bitsofinfo/docker-discovery-registrator-consul
Hopefully it will be of use to you as well.