Developers must distinguish between the following port configuration:

If the port that you assign to the container in the port mapping configuration does not match the application port, then the containerized application fails to communicate with the host.

You can use the podman port CONTAINER command to list the current container port mapping.

[user@host ~]$ podman port CONTAINER
8000/tcp -> 0.0.0.0:8080

In the preceding example, a container exposes the 8000 container port to the host machine on the 8080 host port at all the host network interfaces.

Applications might listen on a different port than you expect. Because Podman commands do not interact with the application, you cannot use Podman commands to verify the port that the application uses.

To verify the application ports in use, list the open network ports in the running container. Use Linux commands such as the socket statistics (ss) command to list open ports. A socket is the combination of a port and an IP address. The ss command lists the open sockets in a system. You can provide the ss command with options to filter and produce the desired output:

[user@host ~]$ podman exec -it CONTAINER ss -pant
Netid State  ... Local Address:Port   Peer Address:Port   Process
tcp   LISTEN ...       0.0.0.0:9091        0.0.0.0:*      users:("python",pid=...)
...output omitted...

Use the output of the ss command to verify that your port mapping matches the application ports in use. You can use values such as the local address and port, the peer address and port, and the process. In the preceding example, a Python service is listening on port 9091. Therefore, to expose this service to the host machine, make sure that a port mapping exists for this port.

To reduce the container attack surface, containers usually lack many commands. You can run the host system commands within the container network namespace by using the nsenter command. A container namespace is how the Linux kernel isolates a system resource view from the container perspective. For example, a container network namespace shows the system's networking stack to the container as if the container was the only process using the stack. There are other types of namespaces, but this material is out of scope for the course.

You can target a container namespace by using the nsenter -n -t command with the container process ID (PID).

To get the container PID you can use the following podman inspect command:

[user@host ~]$ podman inspect CONTAINER --format '{{.State.Pid}}'
CONTAINER_PID

After getting the container PID, you can run the nsenter command. Run the command with elevated privileges by using sudo, as follows:

[user@host ~]$ sudo nsenter -n -t CONTAINER_PID ss -pant
Netid State  ... Local Address:Port   Peer Address:Port   Process
tcp   LISTEN ...       0.0.0.0:9091        0.0.0.0:*      ...
...output omitted...

Developers commonly use Podman networks to isolate container network traffic from the host. If a container does not attach to a Podman network, then it cannot communicate with other containers on that network.

You can use the podman inspect command to verify that every container is using a specific network.

[user@host ~]$ podman inspect CONTAINER --format='{{.NetworkSettings.Networks}}'
map[network_name:0xc000a825a0]

When containers communicate by using Podman networks, there is no port mapping involved.

Podman networks provide connectivity for container-to-container network traffic by using IP addresses. However, because IP addresses might change, developers use hostnames to address these containers in a predictable way. The Domain Name System (DNS) service translates container names to IP addresses for network communication. If the network in use does not have DNS enabled, then containers cannot resolve the container hostnames and cannot communicate.

To ensure that DNS is enabled for a Podman network use the podman network inspect command.

[user@host ~]$ podman network inspect NETWORK
...output omitted...
  "dns_enabled": true,
...output omitted...