Red Hat SummitChapter 6. Containers
The following chapter contains the most notable changes to containers between RHEL 8 and RHEL 9.
6.1. Notable changes to containers
The container-tools meta-package is now available
The container-tools RPM meta-package, which includes Podman, Buildah, Skopeo, CRIU, Udica, and all required libraries, is available in RHEL 9. The stable streams are not available on RHEL 9. To receive stable access to Podman, Buildah, Skopeo, and others, use the RHEL EUS subscription.
To install the container-tools meta-package:
Install the
container-toolsmeta-package:$ sudo dnf install container-tools
Improved control group performance
The previous version of control groups, cgroup version 1 (cgroup v1), caused performance problems with a variety of applications. The latest release of control groups, cgroup version 2 (cgroup v2) enables system administrators to limit resources for any application without causing performance problems.
In RHEL 9, the new version of control groups, cgroups v2, is enabled by default.
Podman now supports secure short names
Short-name aliases for images can now be configured in the registries.conf file in the [aliases] table. The short-names modes are:
-
Enforcing: If no matching alias is found during the image pull, Podman prompts the user to choose one of the unqualified-search registries. If the selected image is pulled successfully, Podman automatically records a new short-name alias in the
$HOME/.cache/containers/short-name-aliases.conffile (rootless user) and in the/var/cache/containers/short-name-aliases.conf(root user). If the user cannot be prompted (for example, stdin or stdout are not a TTY), Podman fails. Note that theshort-name-aliases.conffile has precedence overregistries.conffile if both specify the same alias. The enforcing mode is default in RHEL 9. - Permissive: Similar to enforcing mode, but Podman does not fail if the user cannot be prompted. Instead, Podman searches in all unqualified-search registries in the given order. Note that no alias is recorded. The permissive mode is default in RHEL 8.
Example:
unqualified-search-registries=["registry.fedoraproject.org", "quay.io"] [aliases] "fedora"="registry.fedoraproject.org/fedora"
Default container registries in registries.conf
You can find the list of container registries in the /etc/containers/registries.conf file as a root user and in $HOME/.config/containers/registries.conf as a non-root user. By changing the registries.conf file, you can change the default system-wide search settings.
For RHEL 8, the unqualified-search-registries is:
unqualified-search-registries = ["registry.access.redhat.com", "registry.redhat.io", "docker.io"] short-name-mode = "permissive"
For RHEL 9, the unqualified-search-registries is:
unqualified-search-registries = ["registry.access.redhat.com", "registry.redhat.io", "docker.io"] short-name-mode = "enforcing"
Default OCI runtime change
The crun OCI runtime is now available for the container-tools:rhel8 module. The crun container runtime supports an annotation that enables the container to access the rootless user’s additional groups. This is useful for container operations when volume mounting in a directory where setgid is set, or when the user only has group access.
-
The default container runtime in RHEL 8 is
runc. -
The default container runtime in RHEL 9 is
crun.
Running RHEL 9 containers on a RHEL 7 host is not supported
Running RHEL 9 containers on a RHEL 7 host is not supported.
For more information, see Red Hat Enterprise Linux Container Compatibility Matrix.
Default network stacks
Podman uses CNI as the default network stack in RHEL 8 and Netavark as the default network stack in fresh installs of RHEL 9.
If you perform an in-place upgrade from RHEL 8 to RHEL 9, Podman’s network stack is set as:
-
Netavark if the
network_backendparameter in the/etc/containers/containers.conffile is not set or if you manually upgraded Podman’s network stack in RHEL 8 to Netavark. - CNI if there are containers, images, pods, or networks presented when Podman is first run after an upgrade. You can then manually upgrade to the new Netavark network stack. For instructions on how to switch between the CNI and Netavark network stacks, see 8.6 Switching network stack from CNI to Netavark and 8.7 Switching the network stack from Netavark to CNI.
Red Hat recommends explicitly specifying the network_backend parameter to ensure that the correct backend is selected.
You cannot migrate the existing containers to a different network stack system using the podman container checkpoint and the podman container restore commands. If you want to switch from the CNI network stack to the Netavark network stack, recreate the container from the container image.
The Podman v5.0 deprecations
In RHEL 9.5, the following is deprecated in Podman v5.0:
-
The system connections and farm information stored in the
containers.conffile are now read-only. The system connections and farm information will now be stored in thepodman.connections.jsonfile, managed only by Podman. Podman continues to support the old configuration options such as[engine.service_destinations]and the[farms]section. You can still add connections or farms manually if needed; however, it is not possible to delete a connection from thecontainers.conffile with thepodman system connection rmcommand. -
The
slirp4netnsnetwork mode is deprecated and will be removed in a future major release of RHEL. Thepastanetwork mode is the default network mode for rootless containers. - The cgroups v1 for rootless containers is deprecated and will be removed in a future major release of RHEL.
The runc container runtime has been deprecated
The runc container runtime is deprecated and will be removed in a future major release of RHEL. The default container runtime is crun.
