Offline/disconnected container images
cri-o via the
What are offline container images
Offline containers are containers which are stored in the operating, or
the operating system image for an ostree based system,
and made available to
cri-o via the
Those container images are accesible for
cri-o to create containers. Those images
cannot be deleted, but newer versions of those containers can be downloaded normally,
cri-o will store in the general R/W container storage of the system.
When to use offline container images
Offline containers are useful when the edge device will have restricted connectivity,
or no connectivity at all. Those containers are also helpful to improve general MicroShift
and application startup on first boot, since no images need to be downloaded from the
network and the applications are readily available to
RPM packaging of container images
RPM packaging of container images into read-only container storage is offered via the
as an experimental method to allow users to create ostree images containing the desired containers.
RPM was not designed for storing files with numeric uids/gids, or containing extended attributes,
although several workarounds allow this we are looking for better ways to provide this.
Offline MicroShift containers images
MicroShift uses a set of containers for the minimal components which can be installed
on the operating system image, those are published here, and can also be manually built using:
To install the MicroShift container images you can use:
curl -L -o /etc/yum.repos.d/microshift-containers.repo \
rpm-ostree install microshift-containers
Or simply include this package when using image-builder.
How package your application and manifests as rpms for offline container storage
To package workload application container images we provide
This tool accepts a yaml definition, for which an example can be found
The tool can produce an srpm, rpm, or push a build to a copr repository.
Some example usages:
./paack.py rpm example-user-containers.yaml centos-stream-9-aarch64
The target OS is not important (
centos-stream-9) but we need one os target
compatible with the destination architecture.
./paack.py srpm example-user-containers.yaml
srpm format contains the repository binaries and manifests for each architecture,
then the build system unpacks the specific architecture for the build. The post install step
of rpm configures the
./paack.py copr example-user-containers.yaml mangelajo/my-app-containers