Following on from my previous blog article, Deploying Xwiki using Podman Pod, this blog article explains how to configure Podman containers to use hostnames in inter-container communication.
Podman offers a sub-command for managing container networks, which can be do through rootfull or rootless networking. I will stick to rootfull networking for the time being, but I will go into more detail about rootless networking a bit later.
Let’s verify what networks are available out-of-the-box after installing Podman:
[root@test system]# podman network ls NETWORK ID NAME DRIVER 2f259bab93aa podman bridge [root@test system]# podman network inspect podman [ { "name": "podman", "id": "2f259bab93aaaaa2542ba43ef33eb990d0999ee1b9924b557b7be53c0b7a1bb9", "driver": "bridge", "network_interface": "cni-podman0", "created": "2022-06-30T06:33:42.39196519+10:00", "subnets": [ { "subnet": "10.88.0.0/16", "gateway": "10.88.0.1" } ], "ipv6_enabled": false, "internal": false, "dns_enabled": false, "ipam_options": { "driver": "host-local" } } ] As demonstrated in the excerpt above, the network is already in place. This example shows us this default network has a name, id, driver and subnets.
- See what happens when you create a new network:
[root@test system]# podman network create lab-test lab-test [root@test system]# podman network inspect lab-test [ { "name": "lab-test", "id": "4cafce838a4754e4d444fd8b84c19ca2e5e66b8c529d53be8b9ce072f6797c82", "driver": "bridge", "network_interface": "cni-podman2", "created": "2022-06-30T06:36:45.074773593+10:00", "subnets": [ { "subnet": "10.89.1.0/24", "gateway": "10.89.1.1" } ], "ipv6_enabled": false, "internal": false, "dns_enabled": true, "ipam_options": { "driver": "host-local" } } ] - The very first difference is the option “dns_enabled”: true – this implies the dnsname plugin which is used for external networks has been used while creating this network.
- The “dnsname” plugin allows addressing containers in this network by their container names. The —disable-dns option can be used to override this behaviour.
- There is one crucial step to enable dnsname plugin. You need to install podman-plugins:
dnf install podman-plugins -yThe command above will install all the necessary Podman plugins alongside the dnsmasq package.
The following example will present how you can use the dnsname plugin for inter-container communication.
You will create two containers. Each container will use a specific name (container name), specified by the —name parameter. For the sake of this exercise, you will also set the hostname for each container so it looks pretty when you attach to it.
- First container:
[root@test system]# podman run -dti --rm --name=web.example.net -h web.example.net --network=lab-test fedora 36185a9269a66045cd5870f53482c09dc7bba71135355cc05c6317b47fdc0ff1 [root@test system]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 36185a9269a6 registry.fedoraproject.org/fedora:latest /bin/bash 12 seconds ago Up 13 seconds ago web.example.net - Second container:
[root@test system]# podman run -dti --rm --name=ptr.example.net -h ptr.example.net --network=lab-test fedora 36185a9269a66045cd5870f53482c09dc7bba71135355cc05c6317b47cdc0aa1 [root@test system]# podman ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 36185a9269a6 registry.fedoraproject.org/fedora:latest /bin/bash 12 seconds ago Up 13 seconds ago web.example.net - Connect to the ptr.example.net container, install ping and try to ping the web.example.net container:
[root@test system]# podman exec -it ptr.example.net /bin/bash [root@ptr /]# dnf install iputils -y - Inspect /etc/resolv.conf
[root@ptr /]# cat /etc/resolv.conf search dns.podman example.net nameserver 10.89.1.1 nameserver 192.168.100.1 As you can see, an additional nameserver has been added, including ‘search dns.podman’.
- Verify if you can communicate with your web.example.net container using the container’s name:
[root@ptr /]# ping web.example.net PING web.example.net (10.89.1.2) 56(84) bytes of data. 64 bytes from web.example.net (10.89.1.2): icmp_seq=1 ttl=64 time=0.055 ms 64 bytes from web.example.net (10.89.1.2): icmp_seq=2 ttl=64 time=0.062 ms 64 bytes from web.example.net (10.89.1.2): icmp_seq=3 ttl=64 time=0.080 ms As indicated above – you can.
- Verify if 10.89.1.2 is definitely the IP address allocated to the web.example.net container. You will exit the ptr container to inspect the web container:
[root@test system]# podman inspect web.example.net | grep -i IPAddress "IPAddress": "", "IPAddress": "10.89.1.2", This implies the name of the container has been properly resolved to the IP address. Let us remove this container and start it again to ensure a new IP address is allocated.
[root@test system]# podman inspect web.example.net | grep -i IPAddress "IPAddress": "", "IPAddress": "10.89.1.4", - You can see in the excerpt above the container has been assigned a new IPAddress: 10.89.1.4. I would like to confirm the dnsname plugin can resolve the container name to this new IP address:
[root@test system]# podman exec -it ptr.example.net /bin/bash [root@ptr /]# ping web.example.net PING web.example.net (10.89.1.4) 56(84) bytes of data. 64 bytes from web.example.net (10.89.1.4): icmp_seq=1 ttl=64 time=0.236 ms 64 bytes from web.example.net (10.89.1.4): icmp_seq=2 ttl=64 time=0.090 ms 64 bytes from web.example.net (10.89.1.4): icmp_seq=3 ttl=64 time=0.077 ms And voila, it does!
I hope you found this brief step-by-step guide to be helpful in enabling DNS resolution for your internal container network.
You can check out our Professional Services for more insights on Insentra, or for an in-depth look at your internal container network by one of our expert consultants, please contact us.
