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:
-
As rootless user.
-
❯ 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)
This is a very old issue. Please file a new bug report.
@Luap99
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.
podman-compose up. I want to address another container using its docker-compose service name (e.g.http://postgres)podman infooutput saysnetworkBackend: netavarkpodman version 4.2.0Is 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:
And then:
Are there any known workarounds?