Red Hat blog
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 andSIGKILL
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 topodman create
,podman pod create
,podman run
, andpodman play kube
can now, when specifying a network name, also specify advanced network options such asalias
,ip
,mac
, andinterface_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
, andpodman 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 thenetwork_backend
field. Please note that it is not recommended to switch backends while containers exist, and a system reboot is recommended after doing so.
About the author
Red Hatter since 2018, tech historian, founder of themade.org, serial non-profiteer.