In this chapter, we will understand how Microservices work with Consul. We will also learn how the following components affect Consul.

• Using docker
• Building Registrator for Service Discovery
• Using rkt and Nomad

Let us now discuss each of these in detail.

Using Docker

Before starting, please do not use this setup in production as it is used for demo purposes only. Docker is a container based service using which we can easily deploy our applications. For using Consul, we are going to use the image at the following link –0

https://hub.docker.com/r/progrium/consul/.

It is being assumed that your system has Docker installed and properly configured. Let us try pulling down the image from the Docker hub, by running the following command −

$ docker pull progrium/consul

The output would be as shown in the following screenshot.

We are going to publish some interfaces with their ports (using -p option on Docker) in the following manner.

• 8400 (RPC)
• 8500 (HTTP)
• 8600 (DNS)

Also as per the pull made, we are going to set the name of the hostname as node1.You can change it to anything you want by using the -h flag with some hostname of your own as shown below.

$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul
-server -bootstrap

The output would be as shown in the following screenshot.

You can also enable the UI mode for the Consul using −

$ docker run -p 8400:8400 -p 8500:8500 -p 8600:53/udp -h node1 progrium/consul
-server -bootstrap -ui-dir /ui

You can check the UI based output on http://localhost:8500. The following screenshot gives you a better idea regarding the UI based output.

For using consul over various docker containers on different nodes, we can run the following commands on different nodes −

On Node1

$ docker run -d --name node1 -h node1 progrium/consul -server -bootstrap-expect 3

Where, -bootstrap-expect 3 means that the consul server will wait until there are 3 peers connected before self-bootstrapping and becoming a working cluster.

Before going any further, we need to get the container”s internal IP by inspecting the container. For our use, case purpose, we are going to declare the $ JOIN_IP.

$ JOIN_IP = "$(docker inspect -f ''{{.NetworkSettings.IPAddress}}'' node1)"

On Node2

So, let us start Node2 and tell it to join Node1 using the variable declared in the program given above.

$docker run -d --name node2 -h node2 progrium/consul -server -join $JOIN_IP

On Node3

$ docker run -d --name node3 -h node3 progrium/consul -server -join $JOIN_IP

Building Registrator for Service Discovery

Registrator automatically registers and deregisters services for any Docker container by inspecting containers as they come online. The Registrator we are about to use currently supports pluggable service registries, which currently includes Consul, Etcd and SkyDNS2. The usage of Registrator is highly recommended when we are interacting with different services over the network.

$ docker pull gliderlabs/registrator:latest

The output would be as shown in the following screenshot.

$ docker run -d 
--name = registrator 
--net = host 
--volume = /var/run/docker.sock:/tmp/docker.sock 
gliderlabs/registrator:latest 
 consul://localhost:8500

The output would be as shown in the following screenshot.

The output you have received is the ID of the Docker Container that you have just started. You can check whether the container is running or not by using the command −

$ docker ps -a

he output would be as shown in the following screenshot.

You can also view the logs of Registrator by using the following command.

$ docker logs registrator

Using rkt and Nomad

The rkt is another container-based service, which you can use in your environment. It is built by CoreOS. The main reason for building rkt was to improve the security that was one of the crisis issues for Docker back when it was still in development in 2013-14.

As for Consul, we can use the Rkt Registrator for working on service discovery with Consul. This particular Registrator project, which is covered for rkt is under development and is not recommended for production level use.

You can check if rkt is installed or not, by going to its path and running the following command.

$ ./rkt

You can check the output to check, if it is correctly installed or not as shown in the following screenshot.

For trying out rkt and Consul please check out − https://github.com/r3boot/rkt-registrator.

Nomad Tool

One of the most commonly used and a favorite option is the Nomad tool. Nomad is a tool for managing a cluster of machines and running applications on them. It is similar to Mesos or Kubernetes. By default, Nomad covers the Docker and rkt driver within itself. So, if you are looking for a large-scale deployment of containers with Consul. Nomad might be a good solution to it. Check out − https://www.nomadproject.io/docs/drivers/rkt.html for further information on Nomad.