Image mode for Red Hat Enterprise Linux (RHEL) is a simple, consistent approach to build, deploy, and manage the operating system using container technologies. Similar to building any container, image mode begins with a base image and users can layer components and applications on top of it.
The fundamental difference lies in the base image's inclusion of critical lower-level OS components, notably the kernel, bootloader, and bootc. Bootc is the core technology that lies at the heart of image mode. This article focuses on the specifics of creating bootc images from scratch, addressing the reasons for and against this approach.
Do you need base images from scratch?
The goal is not to need this base image from scratch feature in most use cases. This feature, designed to be the "20" in the 80/20 rule, addresses specific and important use cases that block bootc adoption without the need to fork the code.
However, the increased control is not free. Choosing this route means that you will carry all of the responsibilities associated with maintaining the base image. Nonetheless, if you come from the package world, you may be comfortable with this responsibility and helping bootc fit more seamlessly into your existing workflow.
It's always a good idea to evaluate whether your environment truly needs this feature or if a suitable alternative is available that requires less work in the long run. We will talk about the alternative methods later on.
The benefits of bootc images from scratch
Bootc images made from scratch provide developers and image maintainers with full control over the underlying image content, enabling them to tailor their environment to suit specific needs and workflows. This level of customization addresses several key use cases we have heard from users embarking on their bootc journey.
The bootc-base-imagectl command allows developers to create customized base images from scratch with greater control over the OS content included in the build process.
2 reasons to create base images from scratch
Let's explore the two primary reasons for creating base images from scratch and their drawbacks:
Building with specific pinned content offers version control.
Building up from a minimal base image can improve security.
Version control with pinned content
An organization deploying a bootc system may need to ensure the base image version carries a set of packages at specific versions. This is a particularly common issue for larger enterprise customers in highly regulated environments.
The bootc images from scratch feature allows you to configure and override package information in source RPM repositories, enabling you to reference mirrored, pinned, or snapshotted repository content and a content view from Satellite. This provides fine-grained control over package versions and their dependencies.
Typical scenarios where this level of precision is necessary in an enterprise workflow include the following:
- A specific package version is required due to strict certification and compliance requirements.
- Providing specific software versions known to work for middleware and app teams within the company, such as support for critical dependencies.
While it's possible to add pinned packages to a default build by removing the source and adding the pinned packages in separate layers during customization, this approach leads to image bloat because all the content would be included in the image, making it less suitable for production.
Minimal base images improve security
An organization may want to start from a minimal base image, adding only the packages that are absolutely necessary. This approach is commonly adopted in practice to reduce the attack surface of their systems, improve their overall security posture, and minimize overall size for network efficiency.
When building a bootc image from scratch, you can generate a new minimal image from the standard image, which only includes bootc, kernel, and dnf. This minimal image can be built up further in a multi-stage build process, creating a final image with a constrained and targeted package set.
We see the nuance between the full customization of the base packages and an image with a Universal Base Image (UBI)-like setup. Even if the output appears the same, building on your own adds more steps and complexity. Currently, the minimal image is not shipped pre-built in the registry, but it may be available in the future. While this may not be an ideal solution for those seeking a UBI-like starting point, it represents an incremental improvement for those who desire this experience.
Using a minimal image doesn’t come without costs. It requires more planning, experience, and knowledge of the specific environments and applications that you are running. Starting with a minimal image may lead to more issues with getting various systems to boot. We will explore this more in the next section.
4 reasons not to use bootc images from scratch
A core premise of the bootc model is accomplishing rich control over Linux system customization with a default container built on the provided base image without any of the overhead associated with maintaining a base image. We believe the content of the standard bootc image will deliver the best experience that works in any environment.
We want to earn your trust, and we know it must be earned. But consider the following alternatives before taking on the extra responsibility of maintaining your own base image.
The following are four scenarios with viable alternatives to using the bootc images from scratch feature, which save time and effort in the long run.
Security concerns
If your motivation to build a minimal image from scratch is to reduce the potential number of CVEs by removing packages from the base image, be aware that reducing the number of packages to reduce the number of CVEs does not work on the base image. The packages are there for a reason, and more than ~90% of CVEs are in components that cannot be removed. Are you sure you are getting enough juice from the squeeze by creating a minimal image?
Update concerns
If you are considering using an image from scratch to control the update cadence to the base image, be aware that while we make new images available, you still have control when you take them.
Size issues
If the primary concern is image size, the bootc-base-imagectl tool provides a
rechunksubcommand to interact with rpm-ostree and perform this rechunking. This process will optimize the ordering and grouping of installed packages in the layers of the final image, providing better network efficiency and a smaller footprint.You can run the
rechunksubcommand on any bootc container image, not just bootc images from scratch. Compare a rechunked version of your image built from scratch to a standard base image and assess if the gains are worth the additional effort.Kernel swapping
Creating bootc images from scratch is not required for kernel management. If your use case requires a particular kernel version and the content included in the base image is not a concern, you can do that with a standard bootc’s image and retain all the benefits and support.
Beyond the default
In this article, we introduced bootc images created from scratch, the use cases they target, and alternative approaches. By creating bootc images from scratch, developers and maintainers can gain complete control over the underlying image content, allowing them to tailor their environment to meet specific needs and workflows. This level of customization addresses several common pain points associated with using pre-configured images, providing a tailored solution for users on their bootc journey.
