In Red Hat Enterprise Linux 8.1, we added new container features including full support for rootless Podman, Podman Play/generate Kube, and container images for the Golang toolset (“A minor release with major new container capabilities“). Red Hat Enterprise Linux 8.2 hits the ground with an even bigger set of features. 

Here’s a quick summary:

• Update to the container-tools:rhel8 fast moving stream
• Continued support for container-tools:1.0 stable stream
• New container-tools:2.0 stable stream
• CRIU added to container-tools:rhel8 stream
• Udica added to container-tools:rhel8 stream
• OpenJDK images released as part of Red Hat Universal Base Image
• Source container images produced for all Red Hat Universal Base Images
• Container images for Buildah and Skopeo
• Extension to Red Hat Universal Base Image EULA for partners

We have a lot to cover, so let’s explain each of these features in a little more detail.

Container Tools

Container Tools RHEL 8 Fast Stream (container-tools:rhel8)

The container-tools:rhel8 stream with RHEL 8.2 remains with the following stable versions: Podman 1.6.4, Buildah 1.11.6, and Skopeo 0.1.40. These versions were specifically chosen to be in line with the versions released in RHEL 7.8, making it easier to move to RHEL 8.

Here’s a short list of some interesting new features since RHEL 8.1:

• Support for Message Passing Interface (MPI) in a High Performance Computing (HPC) environment. This is part of a larger initiative to support HPC workloads with podman. See product documentation for more details: Building, running, and managing containers – Using podman with MPI.
• Initial support for the Container Network Interface (CNI) DNS plugin, which allows containers to resolve the IPs of other containers via DNS name, has been added.
• Podman now supports anonymous named volumes, created by specifying only a destination to the -v flag to the podman create and podman run commands
• The podman info command, when run without root, now shows information on UID and GID mappings in the rootless user namespace.
• Added podman build --squash-all flag, which squashes all layers (including those of the base image) into one layer.
• The podman network create, podman network rm, podman network inspect, and podman network ls commands have been added to manage CNI networks used by Podman.
• The podman volume create command can now create and mount volumes with options, allowing volumes backed by NFS, tmpfs, and many other filesystems.
• Rootless Podman can experimentally squash all UIDs and GIDs in an image to a single UID and GID (which does not require use of the newuidmap and newgidmap executables) by passing --storage-opt ignore_chown_errors.
• Rootless Podman containers with --privileged set will now mount in all host devices that the user can access.
• Rootless Podman now supports health checks (#3523).

For a deeper dive, please see the man pages, product documentation, and release notes.

Container Tools 1.0 Stable Stream (container-tools:1.0)

Many of our users want access to the latest versions of Podman, Buildah, and Skopeo, but some are seeking something more stable. These users want access to releasesstable versions of Podman, Buildah and Skopeo which don’t change versions, but do receive security updates. 

If this describes your use case, then this is the stream for you. This stream will continue to receive security updates until RHEL 8.4. That means you can continue to use this version for another year, eventually migrating to the container-tools:2.0 stream or container-tools:3.0 (planned for RHEL 8.4).

The container-tools:1.0 stream remains with Podman 1.0, Buildah 1.5 and Skopeo 0.1.32 until the planned end of life when RHEL 8.4 is released with the container-tools:3.0 stable stream.

Container Tools 2.0 Stable Stream (container-tools:2.0)

The container tools 2.0 stream has been added with the same versions of the Podman, Buildah and Skopeo from the container-tools:rhel8 stream released with RHEL 8.2. This gives users a stable offramp. 

Checkpoint/Restore in Userspace (CRIU)

When a container is stopped (podman stop), the contents of the copy-on-write layer dedicated to the container are left in the overlay file system (unless you run podman rm), but the contents in memory are discarded. 

For most ephemeral workloads like an Apache or Nginx server, this is fine. But, for Java workloads (JVMs can take a while to start), or databases which have large caches (which could take hours to warm up), this is sub-optimal. To solve this problem, Podman and CRIU work together to save the contents of the memory of a container. This can be used to restart a containerized workload, while avoiding start up or cache warming time. 

With the release of RHEL 8.2, Checkpoint/Restore In Userspace, often called CRIU is released as part of the container-tools:rhel8 and container-tools:2.0 module streams. This provides users with a stable version of CRIU which tracks with Podman, providing compatibility for the separate life cycles of each module stream.

For more information, see our product documentation: Building, running, and managing Linux containers on Red Hat Enterprise Linux 8 – creating and restoring container checkpoints.

Udica

The standard SELinux policies provide good general protection by dynamically separating running containers using auto-generated Multi Category Security (MCS) label for each container (see also: What Is SVirt And How Does It Isolate Linux Containers?). 

This protects containers from attacking each other, as well as attacking the host. But, what happens when you want to limit exactly what ports, files, sockets, etc that a container can use? Say, you want to allow that container only the most minimal of security capabilities – that’s where Udica (pronounced yu-dee-tsa) comes in.

Udica allows admins and container developers to create security policies which only allow the exact capabilities needed, by analyzing a container, and generating extra controls which work with the default policy. Think of this as an overlay layer of protection. 

Like CRIU, there is a version of Udica included in the container-tools:rhel8 and container-tools:2.0 module streams to ensure compatibility over the life cycles of each. For more information, see the product documentation: Using SELinuxChapter – Creating SELinux policies for containers.

OpenJDK Images Added to Red Hat Universal Base Image

Red Hat Universal Base Images allow users to build and distribute their own applications, on top of enterprise quality bits which are supportable on OpenShift and RHEL. With the release of RHEL 8.2, we are announcing the General Availability of the OpenJDK 8 and OpenJDK 11 Red Hat Universal Base Images, which brings all the benefits of UBI plus setting the baseline for anyone who want to develop Java Applications running inside containers in a secure, stable and tested manner backed by the Red Hat Build of OpenJDK.

The Red Hat Build of OpenJDK is based on the upstream OpenJDK 8u and 11u projects. Red Hat maintains these projects upstream and adds additional future features into our builds. It offers support and maintenance over stated time periods for the major versions of OpenJDK. 

Long Term Supported versions until June 2026 and October 2024 for 8 and 11 respectively (see also: OpenJDK Life Cycle and Support Policy). Lastly these are some of the latest features in OpenJDK:

• Includes the Shenandoah ultra-low pause time Garbage Collector.
• Planned updates at least once a quarter for security and other bug fixes and  enhancements.

For more information, check out the new imaged in the Red Hat Ecosystem Catalog:

• OpenJDK 8 UBI8 Image
• OpenJDK 11 UBI8 Image

Source Container Images

Container images make it extremely convenient to consume software. Consumers can focus on the software they want to run, and container image builders can automate the construction of that software with all of the necessary dependencies. Using a shipping analogy, container images enable us to load at the factory, in a reproducible environment,  instead of at the dock with numerous bags, barrels, crates and boxes affected by unpredictable weather.

This convenience also comes with some challenges. Before container images, most software in Linux was distributed using package management (RPMs or DEBs) which mostly focused on the  distribution of a single upstream project. These package builders/maintainers have deep subject matter expertise, including open source licensing requirements of the software they package. Furthermore, tooling like Source RPMs made it even easier to pull the source code for a particular package as well as all of the build instructions for that source code. 

Containers compound these open source licensing requirements by including many packages in a single container image, including a variety of different open source licenses. For a deeper understanding of the legal challenges with open source and containers, see What’s in a container image: Meeting the legal challenges by Scott K Peterson.

With the release of Red Hat Enterprise Linux 8.2, we’re making it easier for partners, customers, and community to meet these open source legal requirements and guidelines by distributing source container images corresponding to binary container images which are part of Red Hat Universal Base Image (UBI). This technology allows UBI users to offload the factory work to Red Hat.

Container Images for Buildah and Skopeo

Packaging software as container images enables fellow creators to start their work with a bias toward consumption (Life in The Container – When it comes to code, be a consumer). This is true of application dependencies as well as the tools that we use to create our applications. To reduce friction and enable OCI compliant tools in every use case possible, Red Hat is working on working on containerized versions of container tools like Buildah, Skopeo, and eventually Podman (targeted for RHEL 8.3).

With the release of RHEL 8.2, we now offer Technology Preview container images for Buildah and Skopeo. We invite you to come use these images and give us feedback on them. The goal is to provide a set of containerized applications which can be used to build other applications anywhere you already run containers.

Extension to UBI EULA

Application developers in the Red Hat Partner Connect program can now build their container apps from the full set of Red Hat Enterprise Linux (RHEL) user space packages (non-kernel) and redistribute through the container registry of their choice. This nearly triples the number of packages over UBI only.

When we introduced Red Hat Universal Base Images (UBI) in May 2019, we provided Red Hat partners the ability to freely use and redistribute a substantial number of RHEL packages that can be deployed on both Red Hat and non-Red Hat platforms. This gave developers the ability to build container-based software on the foundation of Red Hat Enterprise Linux that could then be deployed anywhere. 

The feedback on this has been overwhelmingly positive and we thank you for it, but we learned that you needed more, so we’re expanding the package set for Red Hat partners. See also:  Red Hat simplifies container development and redistribution of Red Hat Enterprise Linux packages.

• 
• 
• 
•