Out of the box, Consul has no visibility or knowledge of your containers, so we have to find a way of making an HTTP request to Consul each time a container launches. There is a service called Registrator by Glider Labs (http://gliderlabs.com/registrator/) which does exactly this, so let's look at launching a container running Registrator:

$ docker container run -d 
  --name=registrator --network=consul 
  --volume=/var/run/docker.sock:/tmp/docker.sock 
  gliderlabs/registrator:latest consul://consul:8500

As you can see from the preceding command, our Registrator container has our Docker Engine's socket file mounted. This means that it has direct access to the Docker Engine running on our host and that it will be aware of all changes, such as launching new containers. The other thing you may notice is that Registrator was executed with the following: consul://consul:8500. This is all of the configuration we have to do. It tells Registrator to use Consul and also the URL that Consul can be accessed on. In our case, as we launched our Registrator container on the same network as the Consul container, all requests will be routed through to the name and port of target container, which in this case is Consul and port 8500.

Going back to our browser, you should be able to see that two additional services are now being displayed:

Because we called our Consul container consul and we exposed ports 8500 and 8600, Registrator has added these to Consul. Now that our new containers are being registered with Consul, we can launch a test container. Like other chapters, we will use the Cluster application, though this time we won't be too worried about being able to access the application itself.