Last updated on 13th December 2017
Docker 1.12 is GA now. Thanks to Docker Inc. core Team and community support for releasing it on time as promised during DockerCon 2016.In my earlier post, I briefed around Service Discovery concept and how does it work in terms of Swarm Mode. As we are well aware, Swarm Mode is an optional mode which can be ON and OFF based on your choice and requirement. Under this blog post, I am going to demonstrate service discovery while playing around with docker-compose.
I have a Ubuntu 16.04 machine upgraded with Docker 1.12 GA version. I have docker-compose 1.8.0 running on the same machine. To demonstrate how one service discover others through hostname, I am going to build a very simple Nginx application and a proxy which redirects to the default Nginx web application through the following structure:
The collabapp contains a very simple Dockerfile which pulls nginx running alpine image from Dockerhub.
The collabproxy contains Dockerfile to use the same nginx image with the customized proxy.conf. All it does is whenever there is any request coming to port: 80 will be redirected to http://collabapp which is nothing but a container running web application.
A quick look at docker-compose.yml file:
One thing which you would notice here is that we are NOT providing any “link:” parameter for linking both the services. Docker 1.12 handles this service name aspect internally through the in-built service discovery concept.
Let’s build up the containers using docker-compose as shown below:
Let’s bring up both the containers:
There are two services running – test_collabapp_1 and test_collabproxy_1. You can view the services running in a single shot as shown:
Let’s try to reach out to collabapp from within collabproxy using hostname and see if internal DNS resolves that or not.
As shown above, we are able to ping web application from proxy container using hostname.
To see how does it resolve that hostname, let us look up few interesting files inside the container:
Also, the mount command too shows how the /etc/resolv.conf, /etc/hostname and related files are created for service discovery to be enabled.
The 127.0.0.11 is an embedded DNS server which enables the service discovery functionality.The embedded DNS server is really a light weight server only interested in responding to container name/alias queries and for everything else it just acts as the proxy to any other DNS server.There is a socket created in the container namespace and which listens on it in the daemon itself and respond queries using that. The socket acts as the demux identifier to identify the network in case of unqualified name queries.
Let’s look at an interesting aspect of Service Discovery while we scale the service to run multiple containers across the same machine.
Now, the docker-compose ps shows scaled value of 5.
If you enter into collabproxy container and try to check the nslookup output:
Wow ! The command returned five different IP addresses from in-built DNS and all it does is round-robin DNS to load-balance across those 5 different containers.