Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 4. Building and managing physically bound images
Physically bound images embed all necessary application containers, configurations, and Quadlet files directly into the root filesystem during the bootc build process. This ensures the entire system is all integrated, enabling disconnected and offline deployment, and applications are immediately available on boot.
4.1. Introduction to physically bound images Copier lienLien copié sur presse-papiers!
RHEL bootc physically binds images to the base operating system image, directly embedding containerized applications. This creates a fully self-contained, and immutable system. The underlying mechanism resembles that of logically-bound images because physically-bound images can be pre-pulled during image build time and made available at runtime.
Physically bound images contain the data in the final tar of the image, while logically bound images only reference the image and pull it during a bootc upgrade. Physically bound images offer strict offline reliability, while logically bound images accelerate development by avoiding an update to the entire base image for a small application change.
The key benefits of physically bound images include:
- Because the base operating system and all required application containers ship as one artifact, you have pre-installed application availability right at boot.
- You gain resilience against registry downtime, simplify your offline deployments, and secure atomic updates for both the operating system and applications.
4.2. Creating physically bound images by using system roles Copier lienLien copié sur presse-papiers!
You can use system roles to create physically bound images to detect the non-booted environment and adjust their behavior. The images must not, for example, try to start systemd units or talk to network services; instead, they must defer all of that to the first boot.
Prerequisites
- You have prepared the control node and the managed nodes.
-
The account you use to connect to the managed nodes has
sudopermissions for these nodes. - You are logged in to the control node as a user who can run playbooks on the managed nodes.
Procedure
Create a playbook file, for example
./setup.yml, with the following content:--- - name: Configure physically bound images with RHEL system roles hosts: all vars: podman_registries_conf: unqualified-search-registries: - "registry.access.redhat.com" - "docker.io" - "my-company-registry.com" registry: - location: "my-company-registry.com" - location: "my-local-registry:5000" insecure: true podman_quadlet_specs: - file_src: my-quadlet.container state: started tasks: - name: Run the podman role include_role: name: redhat.rhel_system_roles.podmanThe Podman system role in the Ansible Playbook configures the system with registries and a Quadlet application.
Validate the playbook syntax:
$ ansible-playbook --syntax-check ./setup.ymlThis command only validates the syntax and does not protect against a wrong but valid configuration.
Create a
quadlet.containerfile to configures the container application, for example:[Install] WantedBy=default.target [Container] Image=quay.io/my_org/my_image:20260326 ContainerName=my-quadletCreate a
Containerfilefile with the following content:FROM quay.io/centos-bootc/centos-bootc:stream10 RUN dnf -y install ansible-core rhel-system-roles COPY ./setup.yml . COPY ./quadlet.container . RUN ansible-playbook -c local setup.ymlYou perform every action inside the image build, running the playbooks against localhost. You can use a multi-stage build to keep Ansible and the roles out of your final image. Because this process is entirely self-contained, it works well in your automatic container build pipelines.
NoteThe images must be copied over before any container or service (e.g., Quadlet) depending on such an image is started.
Build the
bootcimage, for example:$ podman build -t quay.io/<namespace>/<image>:<tag> .