How does one service resolve the address of another service using docker compose, link hostname, and ports?
I have read several SO questions revolving the same question, but due to insufficient points, I cannot comment on existing questions. Therefore, I must spawn my own question thread regarding docker-compose and links.
I was under the impression that having the following in a docker-compose file would add ‘db’ to my container’s hostfile
web: links: - db
I was thinking that my web code could establish a db connection with something along the lines of
db := sql.Open("postgres", "user=foo dbname=baz host=db")
where hostname db exists in my web container’s /etc/hostfile and therefore resolves to some address that reaches the db container.
My web application does not resolve to the address where my db is running, instead it resolves to an address (172.19.0.3) and I cannot figure out where it has come from or how to fix.
docker exec $WEB_CONTAINER_ID cat /etc/hosts 127.0.0.1 localhost ::1 localhost ip6-localhost ip6-loopback fe00::0 ip6-localnet ff00::0 ip6-mcastprefix ff02::1 ip6-allnodes ff02::2 ip6-allrouters 172.19.0.2 6f52f9e78f00
I was expecting to see an entry for db. Furthermore:
docker exec $WEB_CONTAINER_ID nslookup db Name: db Address 1: 172.19.0.3 apiserver_postgres_1.apiserver_default
What am I misunderstanding? How do I enable my web code to resolve my db address?
One Solution collect form web for “How does one service resolve the address of another service using docker compose, link hostname, and ports?”
This is no longer your classic docker 1.8 or less “link”, especially if you are using version 2 of
As mentioned in issue 3002:
version:”2″ creates a bridge network by default for your project. If you run
docker network lsyou’ll see a new bridged network where your project containers will be created. (which makes totally sense)
Docker itself has removed these variables from links on any network except for the old bridge network.
There is now an embedded DNS.