Containers are workloads which embed all necessary files to make the workload independent of the running host OS. This includes (but is not limited to) libraries, executables and shared resource files.
A container that is providing its own kernel is commonly called a virtual machine and will be referred to as such in this book. The Open Build Service (OBS) supports container builds either by supporting the native build format or as side product of a different format. This ranges is from very simple chroot containers over server (for example, Docker) or desktop formats (for example, AppImages, Snaps or Flatpaks) up to full VM builds (such as for OpenStack, KVM, or as a Live CD via KIWI).
SimpleImage is a special format which uses the rpm spec file syntax and
just packages the resulting install root as tar ball or squashfs image.
The format is just using the BuildRequires tags from a file called
simpleimage
, it supports also rpm macro handling to
allow for exceptions depending on the build environment.
Docker images can be built either via the KIWI tool or from Dockerfiles.
The desktop-oriented AppImage format is currently only created as a side
effect of an RPM build. Open Build Service (OBS) supports signing and
publishing the .AppImage files, the rest is handled via wrapper packages
which converts an RPM (or DEB package) into an AppImage file. Own build
rules can provided via a Recipe
file, fallback code
will be used if no Recipe
file is available.
The Snap format is supported natively. However, external resources are only supported via source services and therefore not all build types are supported. Snapcraft only works with Ubuntu-based base systems. (Code to support RPM-based distributions exists as well but has not been merged upstream yet.)
Flatpak packages can be built in the Open Build Service, see Section 2.8, “Flatpak” for further details.
Livebuild is the Debian livebuild support for ISO images.
Mkosi allows building images for rpm, arch, deb, and gentoo based distributions, see Section 2.9, “mkosi” for further details.
Container Registries are repositories that container images are published and can be automatically pulled from using tools like podman or docker.
The Open Build Service will automatically publish container images in a
OCI-compatible registry, with the URLs to the images constructed as follows:
$BASE/$PROJECT/$REPOSITORY/$IMAGE_NAME:$TAG
with the
following components:
$BASE
: URL/IP under which the Open Build Service
instance is reachable
$PROJECT
: The name of the project where the image is
build, with all colons replaced with forward slashes.
$REPOSITORY
: The name of the repository where the
containers are published.
$IMAGE_NAME
: The name of this container image. It
defaults to the name of the package from which the container is build.
Alternatively, a different image name can be specified in the build
recipe, e.g. via the containerconfig
element in a
KIWI file (see
the
kiwi documentation for further details).
$TAG
: The image tag. This defaults to
latest
with alternatives being provided in a similar
fashion as the image's name.
The cooverview project provides a simple user-facing webpage to search for containers published by the Open Build Service and can be used to conveniently obtain the correct registry URLs. It is used to power registry.opensuse.org
The Open Build Service automatically signs every package that has been build and publishes the cryptographic signature alongside with it. Container images are no exception to this and the detached signatures can be used by podman to verify every image that is pulled from the registry.
Podman has to be configured first as outlined in the following steps.
Create a yaml
file under
/etc/containers/registries.d/
with an appropriate name
for your instance and the following contents:
--- docker: REGISTRY_URL: sigstore: REGISTRY_URL/sigstore
Replace REGISTRY_URL with the appropriate URL
to your instance of Open Build Service (for example,
registry.opensuse.org
).
Add the following object into the key transports
in the
file /etc/containers/policy.json
:
"docker": { "REGISTRY_URL": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "PATH_TO_PUBLIC_KEY" } ] }
The complete /etc/containers/policy.json
can then
look like this:
{ "default": [ { "type": "insecureAcceptAnything" } ], "transports": { "docker-daemon": { "": [ { "type": "insecureAcceptAnything" } ] }, "docker": { "REGISTRY_URL": [ { "type": "signedBy", "keyType": "GPGKeys", "keyPath": "PATH_TO_PUBLIC_KEY" } ] } } }
Save the public key of the project where your image is build under
PATH_TO_PUBLIC_KEY (you can choose any location
to which you have read access, only ensure that you specify it in
/etc/containers/policy.json
as well).
Podman will from now on automatically fetch the published signatures from the backend and verify them before storing the images locally.