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:

try-app1:
  image: 'dockercloud/hello-world:latest'
  tags:
    - internal
try-app2:
  image: 'dockercloud/hello-world:latest'
  tags:
    - internal
web:
  image: 'mssio/nginx:1.9.11'
  environment:
    - APP_COUNT=2
    - APP_DOMAIN_1=web1.mss.io.dev
    - APP_DOMAIN_2=web2.mss.io.dev
    - APP_PORT_1=80
    - APP_PORT_2=80
  links:
    - 'try-app1:app_1'
    - 'try-app2:app_2'
  ports:
    - '80:80'
  tags:
    - 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.


(Vidsy.co (Charlie)) #2

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

proxy:
  ...
  links:
    - platform
platform:
  ...

@revett


(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.


(Vidsy.co (Charlie)) #4

Yep, underscores are not allowed.

@revett


(Ivannikov Kirill) #5

I have same problem, but I use dots

example:

frontend:
image: frontrend
links:
- backend:backend.service

backend:
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

THANK YOU!

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

FROM alpine

ADD run.sh /
ENV AUTHORIZED_KEYS **None**
VOLUME /user
CMD ["/run.sh"]

(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 docker.algotrader.ch --datapath datapath --ipalloc-range 10.128.0.0/10 --dns-effective-listen-address 172.17.0.1 --no-dns --http-addr 127.0.0.1:6784 --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 f2d94355-582b-4ad1-97e3-3cd73ff2a20b.local.dockerapp.io nameserver 10.0.0.1

10.0.0.1 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 (8.8.8.8, 8.8.4.4) 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:

nameserver 10.0.0.1

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