podman: Cannot resolve other containers names in internal network

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Containers in internal network are not able to see each other

Steps to reproduce the issue:

  1. As rootless user.

  2. ❯ podman network create --internal
    WARN[0000] dnsname and --internal networks are incompatible.  dnsname plugin not configured for network cni-podman0 
    /var/home/yajo/.config/cni/net.d/cni-podman0.conflist
    
    ❯ podman container run --rm -d --name a --net cni-podman0 docker.io/library/debian:10 sleep 5 && podman container run --rm -it --name b --net cni-podman0 docker.io/library/debian:10 ping a -c 1
    1e5526ee01a24161d6c135c15a8b2255383b771646338c38cb4790de98f5f66d
    ping: a: Temporary failure in name resolution
    

Describe the results you received:

Containers in same network cannot find each other.

Describe the results you expected:

Containers should see each other.

Additional information you deem important (e.g. issue happens only occasionally):

This works on docker:

❯ docker network create test --internal
09ca0528cc4ab395d64a1d73898c4ee7aa79605e0bb7abe9428e12b490c7a381

❯ docker container run --rm -d --name aaa --net test docker.io/library/debian:10 sleep 5 && docker container run --rm -it --name bbb --net test docker.io/library/debian:10 ping aaa -c 1
440c67d3482ffcba2477c8418b0fe450de5bfe973f2873cc68f2ca4de0460c19
PING aaa (172.23.0.2) 56(84) bytes of data.
64 bytes from aaa.test (172.23.0.2): icmp_seq=1 ttl=64 time=0.118 ms

--- aaa ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.118/0.118/0.118/0.000 ms

Output of podman version:

Version:      3.2.0
API Version:  3.2.0
Go Version:   go1.16.3
Built:        Wed Jun  9 15:24:16 2021
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.21.0
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.27-2.fc34.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.27, commit: '
  cpus: 12
  distribution:
    distribution: fedora
    version: "34"
  eventLogger: journald
  hostname: yajolap-tecnativa-com
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.12.9-300.fc34.x86_64
  linkmode: dynamic
  memFree: 731549696
  memTotal: 16613015552
  ociRuntime:
    name: crun
    package: crun-0.20.1-1.fc34.x86_64
    path: /usr/bin/crun
    version: |-
      crun version 0.20.1
      commit: 0d42f1109fd73548f44b01b3e84d04a279e99d2e
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.9-1.fc34.x86_64
    version: |-
      slirp4netns version 1.1.8+dev
      commit: 6dc0186e020232ae1a6fcc1f7afbc3ea02fd3876
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.0
  swapFree: 16959922176
  swapTotal: 16965951488
  uptime: 1h 25m 49.31s (Approximately 0.04 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.access.redhat.com
  - docker.io
  - quay.io
store:
  configFile: /var/home/yajo/.config/containers/storage.conf
  containerStore:
    number: 3
    paused: 0
    running: 0
    stopped: 3
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.5.0-1.fc34.x86_64
      Version: |-
        fusermount3 version: 3.10.3
        fuse-overlayfs: version 1.5
        FUSE library version 3.10.3
        using FUSE kernel interface version 7.31
  graphRoot: /var/home/yajo/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 18
  runRoot: /run/user/1000/containers
  volumePath: /var/home/yajo/.local/share/containers/storage/volumes
version:
  APIVersion: 3.2.0
  Built: 1623248656
  BuiltTime: Wed Jun  9 15:24:16 2021
  GitCommit: ""
  GoVersion: go1.16.3
  OsArch: linux/amd64
  Version: 3.2.0

Package info (e.g. output of rpm -q podman or apt list podman):

podman-3.2.0-5.fc34.x86_64

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/master/troubleshooting.md)

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):

Physical Fedora Silverblue 34. Trying to migrate from docker-compose project that needs internal network with discovery.

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Reactions: 4
  • Comments: 28 (10 by maintainers)

Most upvoted comments

This is a very old issue. Please file a new bug report.

@Luap99

services:
  server:
    image: nginx

  client:
    image: alpine
    depends_on:
      - server
    command: "sh -c 'apk add curl && curl -v server:80 && echo It works'"

docker-compose up does not work in this most basic compose file. ‘server’ cannot be resolved.

edit: not to derail this thread further, but for other travelers, installing https://github.com/containers/dnsname enabled container <-> container resolution for the sample above.

As you can see by the warning, dnsname is not supported with internal networks. For now you have to use external network if you want to use dnsname. I tag this as feature, the team wants to rework the network stack in the near future.

works with podman4

While this issue may be old… it remains completely unresolved.

Unfortunately like @megakoresh this doesn’t work for me either, on a fresh Fedora 36 install.

  • Use case: rootless containers, initialised using podman-compose up. I want to address another container using its docker-compose service name (e.g. http://postgres)
  • Networking backend: podman info output says networkBackend: netavark
  • Podman version: podman version 4.2.0

Is there a log or somewhere I can look to troubleshoot this?

For rootfull networks, you can enable the dnsname plugin at the system level https://podman.io/getting-started/network#using-dns-in-container-networks

For the rootless ones, this has not been documented afaik, and I don’t know if it’s implemented or feasible.

This can be easily reproduced with this example:

services:
  nginx:
    image: nginx
  client:
    image: alpine
    command: "sh -c 'apk add curl && curl -v nginx:80 && echo It works'"

And then:

docker-compose up nginx
docker-compose up client

Are there any known workarounds?