Docker Compose V2 does not provide name resolving for service names

[hron84]

Description

Given the following config:

version: '3.9'

services:
  php: 
    image: php:7.3-fpm
    network_mode: bridge
    restart: always
  web:
    image: nginx:latest
    network_mode: bridge
    restart: always
    links:
      - php

I start the containers correctly with docker compose up -d and I see no errors.
However, when I enter to the web container and try to connect to the PHP container by telnet or ping or whatever, I get resolving issues:

root@482d3315c663:/# telnet php 9000
telnet: could not resolve php/9000: Name or service not known
root@482d3315c663:/# ping php
ping: unknown host

If I start the containers with the older docker-compose command:

root@ebb109efd6f8:/# ping -qc1 php
PING php (198.18.0.5): 56 data bytes
--- php ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.183/0.183/0.183/0.000 ms
root@ebb109efd6f8:/# telnet php 9000
Trying 198.18.0.5...
Connected to php.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

Output of docker compose version:

root@testmachine:~/test# docker compose version
Docker Compose version v2.5.0
root@testmachine:~/test# docker-compose --version
docker-compose version 1.29.2, build unknown
root@testmachine:~/test# 

Output of docker info:

Client:
 Context:    default
 Debug Mode: false
 Plugins:
  app: Docker App (Docker Inc., v0.9.1-beta3)
  buildx: Docker Buildx (Docker Inc., v0.8.2-docker)
  compose: Docker Compose (Docker Inc., v2.5.0)
  scan: Docker Scan (Docker Inc., v0.17.0)

Server:
 Containers: 5
  Running: 5
  Paused: 0
  Stopped: 0
 Images: 5
 Server Version: 20.10.16
 Storage Driver: overlay2
  Backing Filesystem: extfs
  Supports d_type: true
  Native Overlay Diff: true
  userxattr: false
 Logging Driver: json-file
 Cgroup Driver: systemd
 Cgroup Version: 2
 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: io.containerd.runc.v2 io.containerd.runtime.v1.linux runc
 Default Runtime: runc
 Init Binary: docker-init
 containerd version: 212e8b6fa2f44b9c21b2798135fc6fb7c53efc16
 runc version: v1.1.1-0-g52de29d
 init version: de40ad0
 Security Options:
  apparmor
  seccomp
   Profile: default
  cgroupns
 Kernel Version: 5.10.0-14-amd64
 Operating System: Debian GNU/Linux 11 (bullseye)
 OSType: linux
 Architecture: x86_64
 CPUs: 4
 Total Memory: 3.839GiB
 Name: testmachine
 ID: M56T:WBEV:W3PY:5LP5:LTZO:WHCV:36X4:JRNO:QSI6:C4FV:UOJJ:WEPY
 Docker Root Dir: /var/lib/docker
 Debug Mode: false
 Registry: https://index.docker.io/v1/
 Labels:
 Experimental: false
 Insecure Registries:
  127.0.0.0/8
 Live Restore Enabled: false
 Default Address Pools:
   Base: 198.18.0.0/16, Size: 24

Additional environment details:

I tried container ID, docker container names too, but neither worked. Also I tried with or without network_mode: bridge and with shared network, they also not work.

(Note: nginx image does not contain nor ping or telnet utilities, I installed them manually just for the demonstration. Both command output comes from same image, the only modification in the container is installing the two utilities).

[treibholzhq]

This happens with Compose V1 as well.

[laurazard]

Hi @hron84, thanks for the report! After investigating a bit, it does seem like there is a regression and V2 is not respecting the links: option. We'll investigate further.

In the meantime, you can solve this by not using the default bridge network which does not provide name resolution -- just this works as expected for me:

version: '3.9'

services:
  php:
    image: php:7.3-fpm
    restart: always
  web:
    image: nginx:latest
    restart: always

since it by default creates a user defined network which does provide name resolution for these containers.

Adding to this, the --link option, as per the documentation, is deprecated and should not be relied on.

The --link flag is a legacy feature of Docker. It may eventually be removed. Unless you absolutely need to continue using it, we recommend that you use user-defined networks to facilitate communication between two containers instead of using --link.

[glours]

Hey @hron84

We were to fast proposing to PR to fix your issue 😅
So If want to be able to connect from your web service to your php service by using network_bridge you can do it like with the service notation of the network_bridge property:

services:
  php: 
    image: php:7.3-fpm
    network_mode: bridge
    restart: always
  web:
    image: nginx:latest
    network_mode: "service:php"
    restart: always
    links:
      - php

But I imagine, and correct me if I'm wrong, that you just want to be sure that your services can connect and discuss to each others. So the simplest solution to do that is to define a network that will be used by all your services like that:

services:
  php:
    image: php:7.3-fpm
    restart: always
    networks:
      - backend
  web:
    image: nginx:latest
    restart: always
    links:
      - php
    networks:
      - backend

networks:
  backend: {}

That way your 2 services are in the same network and Compose internal dns knows how to resolve network communication by service names.

And maybe you don't need a custom network at all and you can just let compose create a default one like that:

services:
  php:
    image: php:7.3-fpm
    restart: always
  web:
    image: nginx:latest
    restart: always
    links:
      - php