Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 2. Building and testing RHEL bootc images

You can build and test RHEL container images using Podman and Containerfiles to create, customize, and share bootable RHEL system images across environments efficiently. You can also use other tools, for example, OpenShift Container Platform. For more examples of configuring RHEL systems by using containers, see the rhel-bootc-examples repository.

2.1. Building and configuring bootc-based images from a Containerfile
Link kopieren

You can use a Containerfile to build and customize your own bootc-based image with the tools, configurations, and applications you need. While most standard instructions work, some are ignored when the image is installed on a system.

Figure 2.1. Building an image by using instructions from a Containerfile, testing the container, pushing an image to a registry, and sharing it with others

639 RHEL Bootable Container Bifrost 0524 2
View larger image
639 RHEL Bootable Container Bifrost 0524 2

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]
Copy to Clipboard Toggle word wrap

The available commands that are usable inside a Containerfile and a Dockerfile are equivalent.

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

  • ENTRYPOINT and CMD (OCI: Entrypoint/Cmd): you can set CMD /sbin/init instead.
  • ENV (OCI: Env): change the systemd configuration to configure the global system environment.
  • EXPOSE (OCI: exposedPorts): it is independent of how the system firewall and network function at runtime.
  • USER (OCI: User): configure individual services inside the RHEL bootc to run as unprivileged users instead.

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

  • The rhel-10-bootc container image ignores the container config section (Config) when it is installed to a system.
  • The rhel-10-bootc container image does not ignore the container config section (Config) when you run this image by using container runtimes such as podman or docker.

2.2. Building reproducible container images with container tools
Link kopieren

Red Hat Enterprise Linux (RHEL) now supports reproducible container builds using Podman and Buildah, reducing image changes with consistent inputs over time. This new feature decreases data pulled from registries when updating images, which is crucial for supply chain security, reliable software deployment, and effective debugging. Reproducible builds for RHEL containers reduce registry storage, create smaller update payloads, and enable faster downloads by ensuring image layers remain consistent. Previously, challenges with tarball 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 like rhel-bootc and RHEL AI.

2.3. Building a container image
Link kopieren

To build an image by using instructions from a Containerfile, use the podman build command.

Prerequisites

  • The container-tools meta-package is installed.

Procedure

  1. Create a Containerfile: 

    $ cat Containerfile
FROM registry.redhat.io/rhel10/rhel-bootc:latest
RUN dnf -y install cloud-init && \
    ln -s ../cloud-init.target /usr/lib/systemd/system/default.target.wants && \
    dnf clean all
    Copy to Clipboard Toggle word wrap

    This Containerfile example adds the cloud-init tool, so it automatically fetches SSH keys and can run scripts from the infrastructure and also gather configuration and secrets from the instance metadata. For example, you can use this container image for pre-generated AWS or KVM guest systems.

  2. Build the <image> image by using Containerfile in the current directory: 

    $ podman build -t quay.io/<namespace>/<image>:<tag> .
    Copy to Clipboard Toggle word wrap

Verification

  • List all images: 

    $ podman images
REPOSITORY                                  TAG      IMAGE ID       CREATED              SIZE
localhost/<image>                           latest   b28cd00741b3   About a minute ago   2.1 GB
    Copy to Clipboard Toggle word wrap

2.4. Running a container image
Link kopieren

To run and test your container, use the podman run command.

Prerequisites

  • The container-tools meta-package is installed.

Procedure

  • Run the container by using the podman run command with the appropriate options. For example, to run the container named mybootc based on the quay.io/<namespace>/<image>:<tag> container image: 

    $ podman run -it --rm --name mybootc quay.io/<namespace>/<image>:<tag> /bin/bash
    Copy to Clipboard Toggle word wrap
    • The -i option creates an interactive session. Without the -i option, the shell opens and then exits.
    • The -t option opens a terminal session. Without the -t option, the shell stays open, but you cannot type anything to the shell.
    • The --rm option removes the quay.io/<namespace>/<image>:<tag> container image after the container exits.

Verification

  • List all running containers: 

    $ podman ps
CONTAINER ID  IMAGE                                    COMMAND          CREATED        STATUS            PORTS   NAMES
7ccd6001166e  quay.io/<namespace>/<image>:<tag>  /sbin/init  6 seconds ago  Up 5 seconds ago          mybootc
    Copy to Clipboard Toggle word wrap

2.5. Benefits of custom bootable images with multi-stage builds
Link kopieren

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 each of them begins 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:

Smaller image size
By separating the build environment from the runtime environment, only the necessary files and dependencies are included in the final image, significantly reducing its size.
Improved security
Since build tools and unnecessary libraries are excluded from the final image, the attack surface is reduced, leading to a more secure container.
Optimized performance
A smaller image size means faster download, deployment, and startup times, improving the overall efficiency of the containerized application.
Simplified maintenance
With the build and runtime environments separated, the final image is cleaner and easier to maintain, containing only what is needed to run the application.
Cleaner builds
Multi-stage builds help avoid clutter from intermediate files, which could accumulate during the build process, ensuring that only essential artifacts make it into the final image.
Resource efficiency
The ability to build in one stage and discard unnecessary parts minimizes the use of storage and bandwidth during deployment.
Better layer caching
With clearly defined stages, Podman can efficiently cache the results of previous stages, potentially speeding up future builds.

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"]
Copy to Clipboard Toggle word wrap

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:

Stopping at a specific build stage
When you build your image, you can stop at a specified build stage. For example: 
$ podman build --target build -t hello .
Copy to Clipboard Toggle word wrap

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

Using an external image as a stage
You can use the COPY --from instruction to copy from a separate image either using the local image name, a tag available locally or on a container registry, or a tag ID. For example: 
COPY --from=<image> <source_path> <destination_path>
Copy to Clipboard Toggle word wrap
Using a previous stage as a new stage
You can continue where a previous stage ended by using the FROM instruction. From example: 
FROM ubi10 AS stage1
[...]

FROM stage1 AS stage2
[...]

FROM ubi10 AS final-stage
[...]
Copy to Clipboard Toggle word wrap

2.6. Pushing a container image to the registry
Link kopieren

To push an image to your own registry, or a third party registry, and share it with others, use the podman push command. The following procedure uses the Red Hat Quay registry as an example.

Prerequisites

  • The container-tools meta-package is installed.
  • An image is built and available on the local system.
  • You have created the Red Hat Quay registry. For more information, see Proof of Concept - Deploying Red Hat Quay.

Procedure

  • Push the quay.io/<namespace>/<image>:<tag> container image from your local storage to the registry: 

    $ podman push quay.io/<namespace>/<image>:<tag>
    Copy to Clipboard Toggle word wrap
Nach oben
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2025 Red Hat