This series is dedicated to DNS-based service discovery, reverse-proxying and load balancing of dockerized microservices using etcd, SkyDNS, nginx and a simple service built with Node.js and node-docker-monitor module.

Part 1 – Setting up SkyDNS for service discovery of dockerized microservices
Part 2 – Automating SkyDNS service discovery with simple Node.js service
Part 3 – Setting up nginx as a reverse-proxy for dockerized microservices


Implementing automation service with TypeScript and Node.js

In our pervious article we’ve setup all components required for DNS-based service discovery and load balancing and demonstrated them in action. However, we had to manually create DNS entries for all our services (using etcdctl command). In this post we will remove that manual step by building a simple Node.js service – docker-skydns-adaptor for SkyDNS automation. This service will be listening for Docker events, maintaining DNS entries for running Docker containers.

Service discovery automation with Docker / SkyDNS adapter

Service discovery automation with Docker / SkyDNS adaptor

We are going to use TypeScript for service development. To find out why not JavaScript, please read this article. For more details on setting up simple TypeScript project with Intellij IDEA / Webstorm or Microsoft VS Code. To simplify Docker and etcd integration we will use node-docker-monitor and node-etcd npm modules respectively.

Our service will implement following logic:

  • when Docker container is started and has label skydns_host
    • get container IP
    • create entry for SkyDNS in etcd using container IP and skydns_host value
  • when container is stopped and has label skydns_host
    • remove entry in etcd


Full sources of the adaptor are available on GitHub – docker-skydns-adaptor.

Testing automated service discovery

Prebuilt Docker image of the adaptor is available DockerHub – docker-skydns-adaptor – we will use in our following tests.

I assume that dockerized versions of etcd and SkyDNS that we set up in Part 1 are up and running.

Now, we will start dockerized adaptor service. Note, that we need to map host’s docker unix socket path to make Docker API available inside the container. Also, we defining etcd connection parameters through ETCD_HOSTS environment variable.

At this stage we are ready to start a few of our test services and see how DNS automation service works

Note, that we defined skydns_host label to let our adaptor know what host name to map the container to.

Let’s check adaptor’s logs to see if it’s discovered our test services and properly updated DNS entries

As we can see, it’s created 2 entries for our containers.

Now we can see DNS service discovery in action. By referring service as http://service:3000 we are achieving load balancing, when client’s requests are evenly distributed between available containers

When we are using full host name like http://11.service:3000 we can address specific container

This behaviour can also be used to address different versions of the same service, referring them like http://v1.service and http://v2.service when we want a specific version of the service to serve the request or using http://service when we don’t care.

In the next article we will add nginx to our software stack and configure it to run as Reverse Proxy / API Gateway for our microservices.

If you have any questions or want further details regarding any of the aspects of this tutorial – please leave a comment below.

Share This

Share This

Share this post with your friends!