1

I setup 2 Docker containers a and b that both expose HTTP services. They should be publicly accessbile through their virtual host names a.domain.com and b.domain.com. Furthermore a should be able to access b on it's public virtual host name, i.e. it should be able to access b on b.domain.com.

The setup of the 2 containers is done using a docker-compose v2 file

version: '2'
services:
  a:
    container_name: container-a
    build:
      context: ../
      dockerfile: Containers/A.Dockerfile
    ports:
      - 5001:80
    environment:
      VIRTUAL_HOST: a.domain.com
    depends_on:
      - b
    networks:
      - my-net

  b:
    container_name: container-b
    build:
      context: ../
      dockerfile: Containers/B.Dockerfile
    ports:
      - 5000:80
    environment:
      VIRTUAL_HOST: b.domain.com
    networks:
      - my-net

networks:
  my-net:
    driver: bridge

I setup the jwilder/nginx-proxy docker container to automatically create reverse proxy nginx configurations. My two containers a and b are connected through their user-defined bridge network but also attached to the default bridge network on which the nginx-proxy is running (docker network connect bridge container-(a|b))

The nginx configuration generated by the nginx-proxy looks quite fine.

upstream a.domain.com {
            # a
            server 172.17.0.14:80;
}
server {
    server_name a.domain.com;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    location / {
        proxy_pass http://a.domain.com;
    }
}        
upstream b.domain.com {
            # a
            server 172.17.0.15:80;
}
server {
    server_name b.domain.com;
    listen 80 ;
    access_log /var/log/nginx/access.log vhost;
    location / {
        proxy_pass http://b.domain.com;
    }
}

Both containers can be reached from my client machine through their public virtual host names. The problem is that my container A cannot reach container B on it's virtual host name b.domain.com. It can access it through container-b, this is not an option for me however. Any ideas or hints on what I'm doing wrong?

cmonsqpr
  • 583
  • 6
  • 13
  • Does DNS otherwise work? If you `docker run busybox nslookup a.domain.com` does it return a valid IP address for the host? – David Maze Sep 04 '18 at 10:07
  • No, it does not work either: `Non-authoritative answer: *** Can't find b.domain.com: No answer` – cmonsqpr Sep 04 '18 at 10:11

1 Answers1

3

The solution is to add an alias to container b, so that when container a tries to resolve b.domain.com won't be redirected to the host but will find container b directly.

Simply add an alias in the docker compose file for container b: instead of

networks:
  - my-net

add

networks:
  my-net:
    aliases:
      - b.domain.com
cmonsqpr
  • 583
  • 6
  • 13
  • Not quite correct. More info [about aliases](https://docs.docker.com/compose/compose-file/compose-file-v2/#aliases). Since aliases is network-wide scoped, so it could be shared by multiple containers and **even multiple services.** Which means, the aimed request to container-b might be routed to container-a, since they are in the same network(my-net). Above all, i think we’d better use a separated network for container-b and add b.domain.com as alias to it, which should be easy to deploy in compose yaml. – Light.G Sep 10 '18 at 10:48
  • @light-g You're right in that network aliases have their flaws. However, if your containers don't share a common network docker will install a UFW rule that will ultimately prevent your container A from connecting to container B. So putting them in separate networks is no solution as far as I can tell. I'd be happy if you prove me wrong on this... – cmonsqpr Sep 11 '18 at 12:32
  • yes, i almost forget you have ufw enabled. Here is another question([what’s the best practice on docker + ufw?](https://stackoverflow.com/questions/30383845/what-is-the-best-practice-of-docker-ufw-under-ubuntu)) asked in different way. You should do extra moves on iptables. May the answers help you more. – Light.G Sep 11 '18 at 15:42