Hostname resolution via between different user defined networks

Docker Engine General
1

Good evening,

I would like to accomplish the following scenario: 3 networks - net_access, net_backend, net_data

net_access will house a loadbalancer (nginx) - container lb
net_backend will house an application - container app
net_data will house a database - container db

I was not able to resolve “app.backend” from “lb.access” nor “db.data” from “app.backend”.

I was able to access the relevant services via the ip addresses, the containers have been assigned, but I’d like to avoid hardcoding IP addresses as the internal DNS should be able to perform dns resolution “for me”.

Any advise on how to tackle this issue?

Version Info

$ docker info
Client:
 Debug Mode: false

Server:
 Containers: 28
  Running: 28
  Paused: 0
  Stopped: 0
 Images: 145
 Server Version: 19.03.13
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
 Logging Driver: json-file
 Cgroup Driver: cgroupfs
 Plugins:
  Volume: local
  Network: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inactive
 Runtimes: runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 8fba4e9a7d01810a393d5d25a3621dc101981175
 runc version: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 init version: fec3683
 Security Options:
  seccomp
   Profile: default
 Kernel Version: 4.9.0-13-amd64
 Operating System: Debian GNU/Linux 9 (stretch)
 OSType: linux
 Architecture: x86_64
 CPUs: 8
 Total Memory: 31.29GiB
 Name: basalt
 ID: T4QE:6GL2:4DFL:6P33:LSWQ:NCKF:CIL4:H3MP:JI5A:R224:BG7L:IT3C
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Username: adurias
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: true

Thanks in advance.

2

Please share your docker-compose.yml files.

3 
version: '3'
services:
  loadbalancer:
    image: debian:buster
    hostname: lb
    entrypoint: sleep 7200
    restart: on-failure:5
    volumes:
      - /etc/localtime:/etc/localtime:ro
    networks:
      access:

  app:
    image: debian:buster
    hostname: app
    restart: on-failure:5
    entrypoint: sleep 7200
    volumes:
      - /etc/localtime:/etc/localtime:ro
    networks:
      backend:

networks:
  access:
    external:
      name: access
  backend:
    external:
      name: backend
4

If is not sufficient to only add its own network to a service, you need to add the networks of services it needs to interact with as well. Thus, simply add the “access” network to the app service as well. Then use app (or app.access) to access it from the loadbalancer.

Note: it is possible to assign aliases per network.

5

Dual homing the containers works of course - but this comes at the cost of not being able to limit the traffic between the two containers as it will not traverse the iptables ruleset.

6

True. Even if you create dedicated transit-networks between application services and your loadbalancerservice, the problem will remain that both will be able to access all ports of the other party.

It’s a pitty that Swarm has no counterpart for Kubernetes Network Policies.

7

Workarounded the issue by deploying a small DNS server that collects the hostnames from the relevant network(s).