About physically bound bootc image building
When a bootc image is fully self-contained, everything you need to run workloads is embedded with the bootc image, including MicroShift and application container images. The underlying mechanism is to pre-pull physically-bound images during image build and then make them available at runtime.
Because embedded images might change with each system update, you cannot pull the images directly to the default container storage. Additional image stores do not work in this case because of current implementation limits. These limits do not allow bootc image updates for those container images.
The manifest, layer tarballs, and signatures are exported as individual files into the directory. The dir transport type preserves the digest of the image, which is crucial for the original digest to reference the image.
Technical details to understand include the following items:
-
Each image goes into the same top-level directory, but a separate subdirectory.
-
Subdirectories are named after the image reference string
SHA. -
An image list file maps image references to their name
SHA. -
You must install the
microshift-release-infoRPM to get the image references required by MicroShift. -
You must have image references for your workloads. Apply the same methods to workload image references that you use for MicroShift image references.
-
When you build the container, you must install the
microshift-release-infoRPM. Therelease-x86_64.jsonandrelease-aarch64.jsonfiles from this RPM reside in the/usr/share/microshift/release/directory. These files contain image references required by MicroShift.
|
|
You must keep track of the name of the image. A tag, digest, or a mix of both can reference images. Choosing the best way to reference the images you need can impact the quality and robustness of workloads. |