Red Hat Rethinks the Linux Distro for the Container Age
DENVER — Just as you use containers to quickly launch applications, Red Hat wants to make it just as easy to boot up entire Linux-based operating systems.
The company has made its flagship Linux distribution Red Hat Enterprise Linux (RHEL) bootable as a container image. In other words, all the operating code typically left out of a container, such as kernel-firmware, will be included in this image.
The company announced these initiatives during its annual user conference, Red Hat Summit, being held this week in Denver.
“This is something the entire industry needs,” explained Colin Walters, a Red Hat senior principal software engineer, in a session at the summit. “The more you’re using cloud native tooling, instead of building a unique bin for infrastructure, the [more] you’re leveraging that open source maintainership and shared ownership.”
The approach is different from the company’s typical package mode, where the final copy of a new RHEL release is issued as a stand-alone package to be installed on a server or virtual machine, which then is modified by the admin through customization for specific workloads.
This package mode, long a tradition in the Linux distribution community, is increasingly different from how applications are managed these days, through containers.
The idea is that “lessons learned on the container side that we can bring over to the OS world so that these two worlds aren’t managed completely separately,” said Ben Breard, a Red Hat senior principal marketing manager, in a Red Hat press conference
Goals for a container-based Linux OS, from Colin Walters’ presentation.
A Wider Workload
The move is one to make RHEL more flexible for a wider variety of workloads. The RHEL gold image is only applicable in some environments. Many environments, such as those at the edge or virtual desktop environments, end up needing to customize different bits.
Containerization would help streamline updates to these custom environments in a major way. And make testing and rollback far easier, the Red Hats claim.
Instead of making changes to the operating system after it has already been installed, the admin can configure the operating system at build time. GitOps or continuous integration/continuous deployment workflows already familiar to developers can be standard procedures for maintaining a fleet of Linux servers running across different environments.
All the cloud native tools, in fact, are put into service for maintaining operating systems.
Not Just for Ephemeral Workloads
This is not the first attempt at building an operating system in a container: RancherOS, Flatcar Linux, Talos, and CoreOS (purchased by Red Hat in 2018), among others, have all tackled this approach.
New to this release is a new bit of software called boot.c, which layers components of a bootable host system using the same Open Container Initiative (OCI) standards that Docker builds an application container through multiple layers.
The release “includes a kernel-firmware and all the things that historically you’re supposed to leave out of containers,” Breard said. As a result, “we can now manage version and deploy the full operating system using the standard container tools that pretty much everybody has in-house.”
The work actually came out of the CoreOS features that were merged in OpenShift. In 2020, Red Hat renamed the CoreOS Container Linux OS as, somewhat confusingly, Fedora CoreOS, “the container optimized OS.”
Unlike earlier container image-based systems, Red Hat’s will not be entirely ephemeral. Here the user data will be retained data in the /etc directory while updating other components as needed.
This approach would be most valuable for systems where some system and application data must be retained, which Walters explained in most cases.
Goals for a container-based Linux OS, from Colin Walters’ presentation.
Disclosure: Red Hat paid for travel expenses for the reporter to attend this conference.
