Registrator Deployment

Registrator is a host-level service that can be run as a Docker container. It watches for new containers, inspects them for service information, and registers them with Consul. It also deregisters them when the container dies. Once our Consul cluster is up and running we can start the Registrator container.

We'll take an example where we deploy a dummy microservice in a container. Registrator needs to be deployed on the same machine (bare metal or virtual) where the microservices are going to be run.

If Registrator needs to run on a separate machine rather than where the Consul container is running then we need to do the following

$export CONSUL_IP=172.16.20.132

$docker run -d -v /var/run/docker.sock:/tmp/docker.sock --name registrator -h $HOSTNAME  gliderlabs/registrator:latest consul://$CONSUL_IP:8500

If Registrator is on the same machine as where the Consul container is, then we need to do the following:

$docker run -d -v /var/run/docker.sock:/tmp/docker.sock --name registrator -h $HOSTNAME  gliderlabs/registrator:latest consul://$HOST_IP:8500

Here we are mounting our “/var/run/docker.sock” file to the container. This file is a Unix socket where the docker daemon listens for events. This is actually how the docker client and the docker daemon communicate, through a REST API accessible from this socket. The important thing to know is that by listening on the same port as Docker, Registrator is able to know everything that happens with Docker on that host.

If you check the logs of the “registrator” container you’ll see a bunch of stuff and a message in the end indicating that it is waiting for new events. You should run the same commands on the other 2 nodes(VM) to start Registrator on those.

$docker logs registrator
2016/05/13 14:35:15 Starting registrator v7 ...
2016/05/13 14:35:15 Using consul adapter: consul://172.16.20.132:8500
2016/05/13 14:35:15 Connecting to backend (0/0)
2016/05/13 14:35:15 consul: current leader  172.16.20.132:8300
2016/05/13 14:35:15 Listening for Docker events ...

To summarize what we have done so far, we have 3 different hosts running a Consul agent and a Registrator container each. The Registrator instance on each host watches for changes in docker containers on that host and talks to the local or remote Consul agent as the case may be.

results matching ""

    No results matching ""