The stack it is a-changin’: Podman 4.0 features rewritten network stack in prep of things to come

Podman 4.0

Red Hat’s open source tool for pod management, Podman, has received an extensive network stack overhaul, prompting the team behind the Docker alternative to bump the version number to 4.0.

The rewrite of the network stack was tackled to be prepared for the completion of Netavark – a still in development, Rust-based container network stack especially designed for Podman. It is supposed to become the default for configuring containers, taking over from the regular CNI stack “as soon as it is available”.

Until then, administrators can specify the network that will be attached via the new options --ip, --ip6, and --mac-adress of the podman network connect command, and create dual-stack networks with user-specified subnets by setting some network create options more than once. Containers and pods can be connected to multiple networks by specifying the --net option in play kube multiple times, and there’s a new ipvlan network driver available.

Commands podman create and podman run have meanwhile been fitted with a couple of additional options, such as --passwd for using /etc/passwd and /etc/groups files from the image in the created container, and --hostuser for creating users in the container based on the host users. Admins looking to clear default environmental variables can add --unsetenv and --unsetenv-all starting with the release. There’s also a --depend option for podman rm, to remove a container and all the ones depending on it.

More enhancements can be found in the podman pod create command. It now sports a --volume and a --device option to let users specify volumes and devices that should automatically be mounted into all containers in a pod, while --security-opt and --sysctl can be used to let Podman configure security settings and sysctls for those containers. Other additions are a --volumes-from and a --share-parent option, which should facilitate mounting the volumes present in a specified container to all other containers in a pod and specifying whether the containers in a pod should share a cgroup parent.

Regular podman machine users should give the release notes a proper read, as it will now automatically mount the Podman API socket to the host and certificates from the host’s keychain into the VM, as well as propagate proxy environment variables from the host. It also learned to support new virtual machine type wsl, offers options to start a VM right after it was created, mount contents from the host, and specify the username to connect to the VM with when using SSH.

Users who find the Podman output to be a bit much or want to suppress it for security reasons can now do so with the --noout option added in the 4.0 release or cut things down by using regular expressions when filtering labels. 

As usual, caution is advised before updating to the latest major version. When upgrading to 4.0 the process for instance, includes some schema migrations in the Podman database which make jumping back without losses not exactly an option. Behavioural changes also mean that more components will be removed when forcing the tool to rm something, so a quick glance into the docs helps to prevent damage.