Use container hostname resolution with network=host

Use container hostname resolution with network=host

I have two docker container. One is the "backend", the other "connector"..

The connector needs to have its network type set to "host" (To receive udp multicast: ssdp/mdns packets).

But it also needs to be able to use docker dns system so i can resolve container names to their ip addresses.

How can i do this?

docker-compose.yml:

version: "3"
services:

  database:
    image: mongo
    container_name: database
    hostname: database
    ports:
      - "27017:27017"

  backend:
    image: "project/backend:latest"
    container_name: backend
    hostname: backend
    environment:
      - NODE_ENV=production
      - DATABASE_HOST=database
    ports:
      - "8080:8080"
    depends_on:
      - database
    tty: true

  connector:
    image: "project/connector:latest"
    container_name: connector
    hostname: connector
    ports:
      - "1900:1900/udp"
    environment:
      - NODE_ENV=production
      - BACKEND_HOST=backend
    depends_on:
      - backend
    network_mode: host
    tty: true

When i run it with docker compose up, my connector container throws a "EAI_AGAIN" error:

connector  | Error: getaddrinfo EAI_AGAIN backend
connector  |     at GetAddrInfoReqWrap.onlookup [as oncomplete] (node:dns:109:26) {
connector  |   errno: -3001,
connector  |   code: 'EAI_AGAIN',
connector  |   syscall: 'getaddrinfo',
connector  |   hostname: 'backend'
connector  | }

Which means the node.js app cant resolve the hostname "backend". Which is not a surprise since the network is set to "host".

How can have the "connector" container have its network set to "host" but is still able to resolve other container names?

답변1

Docker macvlan sets up a software switch(bridge) on a host network interface of your choosing. This could be the same interface as the host, or a different interface or sub-interface with a different network.

Assigning a container to this macvlan docker network will create a unique layer 2 address for the container and allow it to use any layer 3 ip address that has a route on the parent interface of the macvlan. This will also give your container host network functionality, ie. mdns network discovery.

A container assigned to the macvlan network can concurrently be assigned to other docker networks in your compose file and communicate with the other containers within docker's networking. Use the macvlan interface as nothing more than ingress for whatever data the rest of your stack is consuming.

Disadvantages and considerations to doing it like this:

  • Macvlan configuration needs to be pointed at a physical named interface. It also needs to be connected to the actual layer 2 network you are bridging it to. Introducing macvlan into your docker environment will make it less portable.

  • There's no proper way for macvlan interfaces to participate in DHCP. Docker can be given a range to automatically assign to containers to the macvlan network, or you can individually assign a static ip to each container. Be sure to remove those ip(s) from your DHCP scope to avoid conflicts.

관련 정보