Chapter 21. Containers

The following chapter contains the most notable changes to containers between RHEL 8 and RHEL 9.

21.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-tools meta-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.conf file (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 the short-name-aliases.conf file has precedence over registries.conf file 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_backend parameter in the /etc/containers/containers.conf file 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.

Warning

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.