Chapter 3. Building and managing logically bound images Logically bound images give you support for container images that are lifecycle bound to the base bootc image. This helps combine different operational processes for applications and operating systems, and the container application images are referenced from the base image as image files or an equivalent. Consequently, you can manage multiple container images for system installations. You can use containers for lifecycle-bound workloads, such as security agents and monitoring tools. You can also upgrade such workloads by using the bootc upgrade command. 3.1. Logically bound images Logically bound images enable an association of the container application images to a base bootc system image. The term logically bound is used to contrast with physically bound images. The logically bound images offer the following benefits: You can update the bootc system without re-downloading the application container images. You can update the application container images without modifying the bootc system image, which is especially useful for development work. The following are examples for lifecycle bound workloads, whose activities are usually not updated outside of the host: Logging, for example, journald->remote log forwarder container Monitoring, for example, Prometheus node_exporter Configuration management agents Security agents Another important property of the logically bound images is that they must be present and available on the host, possibly from a very early stage in the boot process. Differently from the default usage of tools like Podman or Docker, images might be pulled dynamically after the boot starts, which requires a functioning network. For example, if the remote registry is temporarily unavailable, the host system might run longer without log forwarding or monitoring, which is not desirable. Logically bound images enable you to reference container images similarly to you can with ExecStart= in a systemd unit. When using logically bound images, you must manage multiple container images for the system to install the logically bound images. This is an advantage and also a disadvantage. For example, for a disconnected or offline installation, you must mirror all the containers, not just one. The application images are only referenced from the base image as .image files or an equivalent. Logically bound images installation When you run bootc install , logically bound images must be present in the default /var/lib/containers container store. The images will be copied into the target system and present directly at boot, alongside the bootc base image. Logically bound images lifecycle Logically bound images are referenced by the bootable container and have guaranteed availability when the bootc based server starts. The image is always upgraded by using bootc upgrade and is available as read-only to other processes, such as Podman. Logically bound images management on upgrades, rollbacks, and garbage collection During upgrades, the logically bound images are managed exclusively by bootc. During rollbacks, the logically bound images corresponding to rollback deployments are retained. bootc performs garbage collection of unused bound images. 3.2. Using logically bound images Each logically bound image is defined in a Podman Quadlet .image or .container file . To use logically bound images, follow the steps: Prerequisites The container-tools meta-package is installed. Procedure Select the image that you want to logically bound. Create a Containerfile : In the .container definition, use: In the Containerfile example, the image is selected to be logically bound by creating a symlink in the /usr/lib/bootc/bound-images.d directory pointing to either an .image or a .container file. Run the bootc upgrade command. The bootc upgrade performs the following overall steps: Fetches the new base image from the image repository. See linkhttps://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/using_image_mode_for_rhel_to_build_deploy_and_manage_operating_systems/managing-users-groups-ssh-key-and-secrets-in-image-mode-for-rhel#configuring-container-pull-secrets_managing-users-groups-ssh-key-and-secrets-in-image-mode-for-rhel[Configuring container pull secrets]. Reads the new base image root file system to discover logically bound images. Automatically pulls any discovered logically bound images defined in the new bootc image into the bootc-owned /usr/lib/bootc/storage image storage. Make the bound images become available to container runtimes such as Podman. For that, you must explicitly configure bound images to point to the bootc storage as an "additional image store". For example: Important Do not attempt to globally enable the /usr/lib/bootc/storage image storage in /etc/containers/storage.conf . Only use the bootc storage for logically bound images. The bootc image store is owned by bootc . The logically bound images will be garbage collected when they are no longer referenced by a file in the /usr/lib/bootc/bound-images.d directory.

Commands:
cat Containerfile FROM quay.io/ <namespace> / <image> :latest COPY ./ <app_1> .image /usr/share/containers/systemd/ <app_1> .image COPY ./ <app_2> .container /usr/share/containers/systemd/ <app_2> .container RUN ln -s /usr/share/containers/systemd/ <app_1> .image /usr/lib/bootc/bound-images.d/ <app_1> .image && ln -s /usr/share/containers/systemd/ <app_2> .container /usr/lib/bootc/bound-images.d/ <app_2> .container
GlobalArgs=--storage-opt=additionalimagestore=/usr/lib/bootc/storage
bootc upgrade
--storage-opt=additionalimagestore=/usr/lib/bootc/storage run <image>