Podman

is [[Article description::a daemonless container engine for developing, managing, and running OCI Containers on linux.]]

aims to be a drop-in replacement for docker for most user applications running docker images, setting  should be enough for most pipelines to switch to. and are other tools which provide the other parts of the docker stack not provided by podman, such as building and distributing images.

Kernel
As of podman 1.3.2 and runc 1.0.0_rc8, there is no built-in kernel config check included. However, the upstream provides a method of listing its required kernel configuration via check-config.sh script

Configure the kernel
user namespaces have to be enabled in order to use the rootless mode. Many images make use of fuse and overlayfs, which also need to be enabled. The  kernel module also needs to be available and loaded for allowing rootless mode to access networking.

Load required modules
If the  module is not built into the kernel, it needs to be loaded manually:

Configure subuid/gid
requires the user to have a range of UIDs listed in and  files. These UIDs are used for mapping the container UIDs to the host UIDs via user namespaces.

An overview for the recommended configuration of subuid/subgids is given in the wiki - Subuid subgid.

Emerge
It is recommended to use as the OCI runtime provider,.

Files

 * - Specifies which container registries should be searched for images.
 * - Defines policies for image validation.

Defaults are provided as and.

Usage
The tool aims to be a drop-in replacement for  client provided by Docker. For example, becomes  and  becomes.

All Container Pod-related actions are accessible via command.

Exposing containers to local network
By default, works in bridge mode with a separate cni-podman0 bridge, and then requests are translated to local network via NAT. It is possible, only for root, to give pods/containers real ips on the local network using macvlan mode.

First enable and start the cni-dhcp daemon:

Add a new network config for to support macvlan networks.

Here it is assumed that there is an externally configured bridge already in existence. An example of such a configuration is available in the wiki - Network_bridge. It is also possible to use an existing ethernet device, such as and attach to it.

Now it is possible to create a pod with this network:

To validate that the pod has the proper configuration, an alpine test container can be run inside this pod:

Not enough namespaces
When running a container an error appears: error creating libpod runtime: there might not be enough IDs available in the namespace.

In this case, increase the number of user namespaces permanently via a kernel setting: