Beta 9 and localhost connection via net=host

Docker Desktop
8

@kolis @bsander @crowsnestjosh @mcgeeco @rpierce99 think the real blocker here, is the fact that some of the networking magic is not explained/missed.

Looking at the https://github.com/gliderlabs/registrator getting started guide, it becomes relevant that relying on the host to do anything instead of using a first-class network is simply WRONG (IMHO)

Doing this properly looks something like this.

Create a docker network for all your glider stuff

docker network create gliderlabs

Create consul and attach it to that network

docker run -d --name=consul -p 8500:8500 --net=gliderlabs gliderlabs/consul-server -bootstrap

Port mapping here -p 8500:8500 is only to allow the curl ‘test’ to work - it’s not needed for registrator to work, since they’ll talk over the docker network. Anyhow…

$ curl localhost:8500/v1/catalog/services
{"consul":[]}

Once that’s confirmed to be up and running get your registrator up with the proper network settings (not the host network but our gliderlabs network)

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

The magic here is that using the docker network and attaching the above containers to the same network, allows containers to talk to each other by name.

Remember how we used --name=consul when we created the consul container?
That’s why we’re using consul:8500 when we create the registrator container.

Finally checking it works:

$ docker logs registrator
2016/05/26 18:47:46 Starting registrator v7 ...
2016/05/26 18:47:46 Using consul adapter: consul://consul:8500
2016/05/26 18:47:46 Connecting to backend (0/0)
2016/05/26 18:47:46 consul: current leader  172.19.0.2:8300
2016/05/26 18:47:46 Listening for Docker events ...
2016/05/26 18:47:46 Syncing services on 2 containers