Demonstrating Docker 1.12 Service Discovery with Docker Compose

Estimated Reading Time: 4 minutes

CofvQBxUAAE1UpT

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.

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:

Docker_11

The collabapp contains a very simple Dockerfile which pulls nginx running alpine image from Dockerhub.

Docker_12

 

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.

Docker_13

A quick look at docker-compose.yml file:

Docker_19

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:

Docker_14

Let’s bring up both the containers:

Docker_15

There are two services running – test_collabapp_1 and test_collabproxy_1. You can view the services running in a single shot as shown:

Docker_16

Let’s try to reach out to collabapp from within collabproxy using hostname and see if internal DNS resolves that or not.

Docker_16

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:

Docker_17

Also, the mount command too shows how the /etc/resolv.conf, /etc/hostname and related files are created for service discovery to be enabled.

Docker_18

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.

Docker_20

Now, the docker-compose ps shows scaled value of 5.

Docker_21

If you enter into collabproxy container and try to check the nslookup output:

Docker_23

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.

 

Clap