Podman 4.0 Arrives

If you like big updates, Podman 4.0 is for you! Just to get you up to speed:

Podman (the POD MANager) is a tool for managing containers and images, volumes mounted into those containers, and pods made from groups of containers. Podman is based on libpod, a library for container lifecycle management that is also contained in this repository. The libpod library provides APIs for managing containers, pods, container images, and volumes. Source.

This release has a boatload of new features, including an extensive rewrite of the networking stack. This new work is based around Netavark, a new tool built to manage container networks. That means there are a lot of new capabilities in the Podman bag of tricks for configuring networks of containers.

This version does contain a handful of breaking changes, the biggest of which would occur if a user upgrades to Podman 4.0, then downgrades to Podman 3.x. This is due to some changes in the Podman database schema. That's an unlikely scenario though, but you've now been warned.

Here's just a taste of the release notes, which go on quite extensively:

• Podman containers will now automatically add the container's short ID as a network alias when connected to a supporting network (#11748).
• The podman machine stop command will now log when machines are successfully stopped (#11542).
• The podman machine stop command now waits until the VM has stopped to return; previously, it returned immediately after the shutdown command was sent, without waiting for the VM to shut down.
• VMs created by podman machine now delegate more cgroup controllers to the rootless user used to run containers, allowing for additional resource limits to be used (#13054).
• The podman stop command will now log a warning to the console if the stop timeout expires and SIGKILL must be used to stop the container (#11854).
• Several performance optimizations have been implemented that should speed up container and pod creation, and running containers and pods that forward large ranges of ports.
• Podman has seen an extensive rewrite of its network stack to add support for Netavark, a new tool for configuring container networks, in addition to the existing CNI stack. Netavark will be default on new installations when it is available.
• The podman network connect command now supports three new options, --ip, --ip6, and --mac-address, to specify configuration for the new network that will be attached.
• The podman network create command now allows the --subnet, --gateway, and --ip-range options to be specified multiple times, to allow for the creation of dual-stack IPv4 and IPv6 networks with user-specified subnets.
• The --network option to podman create, podman pod create, podman run, and podman play kube can now, when specifying a network name, also specify advanced network options such as alias, ip, mac, and interface_name, allowing advanced configuration of networks when creating containers connected to more than one network.
• The podman play kube command can now specify the --net option multiple times, to connect created containers and pods to multiple networks.
• The podman create, podman pod create, and podman run commands now support a new option, --ip6, to specify a static IPv6 address for the created container or pod to use.
• Macvlan networks can now configure the mode of the network via the -o mode= option.
• When using the CNI network stack, a new network driver, ipvlan, is now available.
• The podman info command will now print the network backend in use (Netavark or CNI).
• The network backend to use can be now be specified in containers.conf via the network_backend field. Please note that it is not recommended to switch backends while containers exist, and a system reboot is recommended after doing so.