Docker Community Forums

Share and learn in the Docker community.

[Resolved] Container Link Problem In Docker Cloud

(Mssio) #1

Hello, I have a problem linking my containers in Docker cloud.

Here is how my stackfile looks like:

  image: 'dockercloud/hello-world:latest'
    - internal
  image: 'dockercloud/hello-world:latest'
    - internal
  image: 'mssio/nginx:1.9.11'
    - APP_COUNT=2
    - APP_PORT_1=80
    - APP_PORT_2=80
    - 'try-app1:app_1'
    - 'try-app2:app_2'
    - '80:80'
    - internal

This Stackfile works prefrectly if I change it to docker-compose.yml but in Docker Cloud somehow the link between web container and try-app1 / try-app2 container is not working so this error message is shown:

web-1 | 2016-02-18T09:54:48.182025377Z 2016/02/18 09:54:46 [emerg] 20#20: host not found in upstream “app_1:80” in /etc/nginx/conf.d/app_1.conf:2

Any idea if it is a bug in Docker Cloud or any mistakes in my deployment strategy?

Thank you for your help.

( (Charlie)) #2

Try using just the service name instead of an alias, this is what works for me. Example:

    - platform


(Mssio) #3

I think the problem is in Docker Cloud naming.
I can’t link container with number and/or underscore in it’s name.
If I name container app_1 or app_2, it will be renamed automatically to app-1 or app-2.
I need to have it named as app_1 because my nginx will connect to host app_1, but somehow it is not working in Docker Cloud.

( (Charlie)) #4

Yep, underscores are not allowed.


(Ivannikov Kirill) #5

I have same problem, but I use dots


image: frontrend
- backend:backend.service

image: backend

(Ivannikov Kirill) #6

Hmm… now I see links works not like a docker-compose.
In docker-compose I can see linked aliases in /etc/hosts.

How I can do the same in docker cloud?

(Fernando Mayo) #7

In Docker Cloud, links are resolved via DNS and not via /etc/hosts. Why do you need them there?

(Ivannikov Kirill) #8

I use consul for service discovery and after start docker container I overwrite resolv.conf to using consul dns.

(Fernando Mayo) #9

If you are using Consul for service discovery, what do you exactly need in /etc/hosts?

(Ivannikov Kirill) #10

Good question, but use “hard links” (in docker-compose file) useful for fast start up and integration test.

(Tai Lee) #11

Same problem here. I have a service that links to another service (no aliases). I am unable to resolve the linked services, when they are running on the same or different nodes. If Docker Compose made this work with /etc/hosts but Docker Cloud uses DNS, how is Docker Cloud configuring the container to use your DNS? It just doesn’t seem to work at all.

(Fernando Mayo) #12

There’s no configuration needed, links should resolve automatically. The only known issue is that alpine images apart from “alpine:edge” do not support DNS search and our service discovery system does not work on them.

(Tai Lee) #13

That explains it. I’m using alpine (not edge). I emailed Docker Cloud support about this problem, including my stack file that clearly shows this, and didn’t get much help. It would be good to have that as a note in the service discovery docs.

(Dlsysadmin) #14


And here I was assuming that Docker Cloud supported regular alpine because their own images are built on it, specifically dockercloud/authorizedkeys:

FROM alpine

VOLUME /user
CMD ["/"]

(Fernando Mayo) #15

That specific image does not use alpine:edge because will never be linked to anything else. But I get your point, it can lead to confusion.

(Algotrader) #16

I have the same problem. I’m also using container links without aliases.

Interesting enough links work an an Amazon AWS host. I can execute a “ping mysql”. But links fail to work an a BYO (bring-your-own) CentOS host. Here ping returns “unknown host”

I did a bit of research and apparently docker cloud (formerly tutum) uses weave for dynamic dns resolution of docker cloud containers

@fermayo I believe you were involved in the creation of weave originally (nice stuff btw!)

When I compare “weave status” on my BYO host to the Amazon AWS
host I notice that the BYO host does not specify “”–trusted-subnets"
whereas the Amazon AWS does.

This is what I see when I run “docker top weave” on my BYO host:
/home/weave/weaver --port 6783 --name 16:24:f1:e6:dd:33 --nickname --datapath datapath --ipalloc-range --dns-effective-listen-address --no-dns --http-addr --conn-limit=0 --trusted-subnets= --no-dns --no-discovery --init-peer-count=1

I assume that this causes the issue. Unfortunately i have no idea how to set the “–trusted-subnets” correctly.

Also I’m not sure my containers are actually using the weave DNS, my containers /etc/resolv.conf show:
search nameserver is the local DNS on my physical network

Any idea how to get container links to work on a BYO host?

No Service Discovery
(Fernando Mayo) #17

In your case @algotrader the fact that your CentOS-based BYON cannot resolve links doesn’t seem related to the overlay network. Not having “–trusted-subnets” in BYON is normal - we only use it on AWS VPCs where we don’t need to encrypt the overlay network. May I ask which DNS resolvers are you using on your BYON? Can you try to use Google’s (, and check if the issue is solved?

(Algotrader) #18

Thanks Fernando. This solved the problem

My /etc/resolv.conf had the following DNS server which is running on our local network:


Is there a reason why “local” DNS servers do not work? Maybe this is something that should be added to the docker cloud documentation.

(Evan Prodromou) #19

Is there a recommended workaround for this?

(Kevintruck) #20

After I saw this it’s a bit curious that Alpine isn’t working with dockercloud