Chapter 2. Building and testing RHEL bootc images

You can build and configure Red Hat Enterprise Linux bootc-based images by defining your system specifications in a Containerfile. You can generate customized, reproducible, and scalable container-native operating systems tailored to your specific deployment requirements.

A general Containerfile structure is the following:

FROM registry.redhat.io/rhel10/rhel-bootc:latest

RUN dnf -y install [software] [dependencies] && dnf clean all

ADD [application]
ADD [configuration files]
RUN [config scripts]

The following commands in a Containerfile are ignored when the rhel-10-bootc image is installed to a system:

The rhel-10-bootc container image reuses the OCI image format.

Red Hat Enterprise Linux supports reproducible container builds by using Podman and Buildah, reducing image changes with consistent inputs over time. This feature decreases data pulled from registries when updating images, which is crucial for supply chain security, reliable software deployment, and effective debugging.

Previously, challenges with tar file creation and escalating container image sizes led to increased storage burdens and unnecessary layer pulls, even when underlying data remained unchanged, hindering faster updates in environments, such as, rhel-bootc and RHEL AI. By using reproducible builds for RHEL containers reduces registry storage, creates smaller update payloads, and enables faster downloads by ensuring image layers remain consistent.

For more information, see Introduction to reproducible container builds

Build a Red Hat Enterprise Linux container image to encapsulate your operating system configuration and applications in a single artifact. By creating a custom image, you can manage your system lifecycle by using standard container tools and ensures consistent deployments across hybrid infrastructure.

You can run a Red Hat Enterprise Linux container image to run your application or validate your operating system build in an isolated environment. By launching the container, you can verify the system behavior and configurations without modifying the host infrastructure.

Red Hat Enterprise Linux (RHEL) base images, Universal Base Images (UBI), and rhel-bootc use version numbers that track only the major operating system version. To define a specific version number for a derived image, you can override this value by adding the version label to your Containerfile.

The deployment image must include only the application and its required runtime, without adding any build tools or unnecessary libraries. To achieve this, use a two-stage Containerfile: one stage for building the artifacts and another for hosting the application.

With multi-stage builds, you use multiple FROM instructions in your Containerfile. Each FROM instruction can use a different base and starts a new stage of the build. You can selectively copy artifacts from one stage to another and exclude everything you do not need in the final image.

Multi-stage builds offer several advantages:

The following Containerfile consists of two stages. The first stage is typically named builder and it compiles a golang binary. The second stage copies the binary from the first stage. The default working directory for the go-toolset builder is opt/ap-root/src.

FROM registry.access.redhat.com/ubi10/go-toolset:latest as builder
RUN echo 'package main; import "fmt"; func main() { fmt.Println("hello world") }' > helloworld.go
RUN go build helloworld.go

FROM registry.redhat.io/rhel10/rhel-bootc:latest
COPY --from=builder /opt/app-root/src/helloworld /
CMD ["/helloworld"]

As a result, the final container image includes the helloworld binary but no data from the previous stage.

You can also use multi-stage builds to perform the following scenarios:

$ podman build --target build -t hello .

For example, you can use this approach to debug a specific build stage.

COPY --from=<image> <source_path> <destination_path>

FROM ubi10 AS stage1
[...]

FROM stage1 AS stage2
[...]

FROM ubi10 AS final-stage
[...]

Push your Red Hat Enterprise Linux container image to a remote registry to make it accessible for deployment. By uploading the image, you can distribute your customized operating system across your infrastructure or share it with collaborators for testing.