Build Containers

User Guide › Reference › Build Containers

User Guide

Navigation←→

24 Build Containers #

Abstract#

24.1 Supported Container Formats
24.2 Container Registry
24.3 Container Image Signatures

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.

24.1 Supported Container Formats #

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: 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: Docker images can be built either via the KIWI tool or from Dockerfile build descriptions.
AppImage: 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.
Snap: 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: Flatpak packages can be built in the Open Build Service, see Section 2.8, “Flatpak” for further details.
Livebuild: Livebuild is the Debian livebuild support for ISO images.
Mkosi: Mkosi allows building images for rpm, arch, deb, and gentoo based distributions, see Section 2.9, “mkosi” for further details.

24.2 Container Registry #

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

24.3 Container Image Signatures #

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:
Example 24.1: registry.yaml #
```
---
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:

Example 24.2: 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:

Example 24.3: policy.json #

{
  "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.

Print this page