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

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

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

Procedure

  1. 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.podman

    The Podman system role in the Ansible Playbook configures the system with registries and a Quadlet application.

  2. Validate the playbook syntax:

    $ ansible-playbook --syntax-check ./setup.yml

    This command only validates the syntax and does not protect against a wrong but valid configuration.

  3. Create a quadlet.container file to configures the container application, for example:

    [Install]
    WantedBy=default.target
    
    [Container]
    Image=quay.io/my_org/my_image:20260326
    ContainerName=my-quadlet
  4. Create a Containerfile file 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.yml

    You 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.

    Note

    The images must be copied over before any container or service (e.g., Quadlet) depending on such an image is started.

  5. Build the bootc image, for example:

    $ podman build -t quay.io/<namespace>/<image>:<tag> .
Red Hat logoGithubredditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez le Blog Red Hat.

À propos de la documentation Red Hat

Legal Notice

Theme

© 2026 Red Hat
Retour au début