One of the questions we in the Podman world often are asked is “Why can’t my container resolve other containers by name?” In many of the cases, the answer is … because you are running on a network with name resolution disabled. In fact, you are likely running on the *default* network; which indeed does not have name resolution enabled. The next question then is “why is Podman doing that?” And the standard answer? “Because Docker does that and people want Docker compatibility as much as possible.”
Let’s take a closer look by example. I’ll be using containers created by a privileged user because that is sort of the Docker standard. In each example, I will launch two named containers on the same network and show name resolution success and failure.
In this first example, we confirm only the default Podman network exists. It is called podman and it cannot be removed. Remembering that the default network does not have name resolution enabled, any attempts to do so should and do fail. Notice that test2 is unable to resolve test1 by name.
$ sudo podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge $ sudo podman run --rm -dt --name test1 alpine top 3703d80740513421772db407972111ad6f535f5ca214f11ddb714a7d64ee140c $ sudo podman run --rm -it --name test2 alpine /bin/sh / # ping test1 ping: bad address 'test1' / # exit
One solution is to then create a new network which I called new. By default, all created networks do have name resolution enabled and must opt-out in order to disable it. Then I run two containers in the same way as before except that I cite a different network and name resolution works as expected.
$ sudo podman network create new new $ sudo podman network ls NETWORK ID NAME DRIVER d9376e135b46 new bridge 2f259bab93aa podman bridge $ sudo podman run --rm -dt --name test1 --network new alpine top f5a8d256f29221676dc7fca36bca0b680dd7de4a5aa20af2a9d9a02072b34fc7 $ sudo podman run --rm -it --name test2 --network new alpine /bin/sh / # ping test1 PING test1 (10.89.0.2): 56 data bytes 64 bytes from 10.89.0.2: seq=0 ttl=42 time=0.114 ms 64 bytes from 10.89.0.2: seq=1 ttl=42 time=0.107 ms ^C
I mentioned earlier that one of the reasons Podman behaves this way is because Docker does as well. Performing the same test with Docker’s default network, we can see name resolution does not work either. The solution is the same as Podman where you create a new network and run your containers there.
ubuntu@ubuntu:~$ sudo docker network ls NETWORK ID NAME DRIVER SCOPE cb0c4d38339a bridge bridge local 5d0fce56bcad host host local 18c31437e8d0 none null local ubuntu@ubuntu:~$ sudo docker run -dt --name test1 alpine top b23e15c969d253f33f99bd2cecb00b4b061e2a7605190eae683f546692ea34cc ubuntu@ubuntu:~$ sudo docker run -it --name test2 alpine /bin/sh / # ping test1 ping: bad address 'test1' / # exit
If you always want your containers to have name resolution but you do not want to have to cite the different network for each container, you can make any network the default network for containers. It requires a small change to /etc/containers/containers.conf (or simple addition if containers.conf does not exist).
$ sudo cat /etc/containers/containers.conf [network] default_network = "new" $ sudo podman run -dt --rm --name test1 alpine top 18d033aeec0640100bf8165c23b01e55c03fbd5bc320d874a3f4f01f755512c7 $ sudo podman run -it --rm --name test2 alpine /bin/sh / # ping test1 PING test1 (10.89.0.5): 56 data bytes 64 bytes from 10.89.0.5: seq=0 ttl=42 time=0.137 ms 64 bytes from 10.89.0.5: seq=1 ttl=42 time=0.106 ms ^C --- test1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max = 0.106/0.121/0.137 ms / # exit
Note here that new is the default network and name resolution works.
We have also been asked why does Podman mimic Docker on this behavior especially when a lot of people do want name resolution by default. My personal answer is two-fold. I do not know why Docker did it but I do not want to find out, and Podman users like to call us out when we are not bug for bug compatible with Docker. The second reason I would not want name resolution enabled by default is because it takes just a little longer for the container to run. Podman always has to use netavark to set up networking but when name resolution is enabled, netavark also has to call out to aardvark-dns. The amount of time might be nearly nothing, but in some cases this matters.
Brent Baude
Senior Principal Software Engineer, Podman Architect
Leave a Reply