Chapter 5. Running Skopeo and Buildah in a container

With Skopeo, you can inspect images on a remote registry without having to download the entire image with all its layers. You can also use Skopeo for copying images, signing images, syncing images, and converting images across different formats and layer compressions.

Buildah facilitates building OCI container images. With Buildah, you can create a working container, either from scratch or using an image as a starting point. You can create an image either from a working container or via the instructions in a Dockerfile. You can mount and unmount a working container’s root filesystem.

Reasons to run Buildah and Skopeo in a container:

  • Skopeo: You can run a CI/CD system inside of Kubernetes or use OpenShift to build your container images, and possibly distribute those images across different container registries. To integrate Skopeo into a Kubernetes workflow, you need to run it in a container.
  • Buildah: You want to build OCI/container images within a Kubernetes or OpenShift CI/CD systems that are constantly building images. Previously, people used a Docker socket to connect to the container engine and perform a docker build command. This was the equivalent of giving root access to the system without requiring a password which is not secure. For this reason, Red Hat recommends using Buildah in a container.
  • Both: You are running an older OS on the host but you want to run the latest version of Skopeo, Buildah, or both. The solution is to run Buildah in a container. For example, this is useful for running the latest version of Skopeo, Buildah, or both provided in RHEL 8 on a RHEL 7 container host which does not have access to the newest versions natively.
  • Both: A common restriction in HPC environments is that non-root users are not allowed to install packages on the host. When you run Skopeo, Buildah, or both in a container, you can perform these specific tasks as a non-root user.

5.1. Running Skopeo in a container

This procedure demonstrates how to inspect a remote container image using Skopeo. Running Skopeo in a container means that the container root filesystem is isolated from the host root filesystem. To share or copy files between the host and container, you have to mount files and directories.

Procedure

  1. Log in to the registry.redhat.io registry:

    $ podman login registry.redhat.io
    Username: myuser@mycompany.com
    Password: ***********
    Login Succeeded!
  2. Get the registry.redhat.io/rhel8/skopeo container image:

    $ podman pull registry.redhat.io/rhel8/skopeo
  3. Inspect a remote container image registry.access.redhat.com/ubi8/ubi using Skopeo:

    $ podman run --rm registry.redhat.io/rhel8/skopeo skopeo inspect docker://registry.access.redhat.com/ubi8/ubi
    {
        "Name": "registry.access.redhat.com/ubi8/ubi",
        ...
        "Labels": {
            "architecture": "x86_64",
            ...
            "name": "ubi8",
            ...
            "summary": "Provides the latest release of Red Hat Universal Base Image 8.",
            "url": "https://access.redhat.com/containers/#/registry.access.redhat.com/ubi8/images/8.2-347",
            ...
        },
        "Architecture": "amd64",
        "Os": "linux",
        "Layers": [
        ...
        ],
        "Env": [
            "PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
            "container=oci"
        ]
    }

    The --rm option removes the registry.redhat.io/rhel8/skopeo image after the container exits.

Additional resources

5.2. Running Skopeo in a container using credentials

Working with container registries requires an authentication to access and alter data. Skopeo supports various ways to specify credentials.

With this approach you can specify credentials on the command line using the --cred USERNAME[:PASSWORD] option.

Procedure

  • Inspect a remote container image using Skopeo against a locked registry:

    $ podman run --rm registry.redhat.io/rhel8/skopeo inspect --creds $USER:$PASSWORD docker://$IMAGE

Additional resources

5.3. Running Skopeo in a container using authfiles

You can use an authentication file (authfile) to specify credentials. The skopeo login command logs into the specific registry and stores the authentication token in the authfile. The advantage of using authfiles is preventing the need to repeatedly enter credentials.

When running on the same host, all container tools such as Skopeo, Buildah, and Podman share the same authfile. When running Skopeo in a container, you have to either share the authfile on the host by volume-mounting the authfile in the container, or you have to reauthenticate within the container.

Procedure

  • Inspect a remote container image using Skopeo against a locked registry:

    $ podman run --rm -v $AUTHFILE:/auth.json registry.redhat.io/rhel8/skopeo inspect docker://$IMAGE

    The -v $AUTHFILE:/auth.json option volume-mounts an authfile at /auth.json within the container. Skopeo can now access the authentication tokens in the authfile on the host and get secure access to the registry.

Other Skopeo commands work similarly, for example:

  • Use the skopeo-copy command to specify credentials on the command line for the source and destination image using the --source-creds and --dest-creds options. It also reads the /auth.json authfile.
  • If you want to specify separate authfiles for the source and destination image, use the --source-authfile and --dest-authfile options and volume-mount those authfiles from the host into the container.

Additional resources

5.4. Copying container images to or from the host

Skopeo, Buildah, and Podman share the same local container-image storage. If you want to copy containers to or from the host container storage, you need to mount it into the Skopeo container.

Note

The path to the host container storage differs between root (/var/lib/containers/storage) and non-root users ($HOME/.local/share/containers/storage).

Procedure

  1. Copy the registry.access.redhat.com/ubi8/ubi image into your local container storage:

    $ podman run --privileged --rm -v $HOME/.local/share/containers/storage:/var/lib/containers/storage registry.redhat.io/rhel8/skopeo skopeo copy docker://registry.access.redhat.com/ubi8/ubi containers-storage:registry.access.redhat.com/ubi8/ubi
    • The --privileged option disables all security mechanisms. Red Hat recommends only using this option in trusted environments.
    • To avoid disabling security mechanisms, export the images to a tarball or any other path-based image transport and mount them in the Skopeo container:

      • $ podman save --format oci-archive -o oci.tar $IMAGE
      • $ podman run --rm -v oci.tar:/oci.tar registry.redhat.io/rhel8/skopeo copy oci-archive:/oci.tar $DESTINATION
  2. To list images in local storage:

    $ podman images
    REPOSITORY                               TAG     IMAGE ID      CREATED       SIZE
    registry.access.redhat.com/ubi8/ubi      latest  ecbc6f53bba0  8 weeks ago   211 MB

Additional resources

5.5. Running Buildah in a container

The procedure demonstrates how to run Buildah in a container and create a working container based on an image.

Procedure

  1. Log in to the registry.redhat.io registry:

    $ podman login registry.redhat.io
    Username: myuser@mycompany.com
    Password: ***********
    Login Succeeded!
  2. Pull and run the registry.redhat.io/rhel8/buildah image:

    # podman run --rm --device /dev/fuse -it registry.redhat.io/rhel8/buildah  /bin/bash
    • The --rm option removes the registry.redhat.io/rhel8/buildah image after the container exits.
    • The --device option adds a host device to the container.
  3. Create a new container using a registry.access.redhat.com/ubi8 image:

    # buildah --storage-opt=overlay.mount_program=/usr/bin/fuse-overlayfs from registry.access.redhat.com/ubi8
    ...
    ubi8-working-container
    • The --storage-opt option sets the storage driver. This option overrides all options configured in /etc/containers/storage.conf and STORAGE_OPTS environment variable.
    • The /usr/bin/fuse-overlayfs is an implementation of FUSE (Filesystem in Userspace) and enables non-root users to create their file systems without modifying kernel code.
  4. Run the ls / command inside the ubi8-working-container container:

    # buildah --storage-opt=overlay.mount_program=/usr/bin/fuse-overlayfs run  --isolation=chroot ubi8-working-container ls /
    bin  boot  dev  etc  home  lib  lib64  lost+found  media  mnt  opt  proc  root  run  sbin  srv
  5. To list all images in a local storage, enter:

    # buildah images
    REPOSITORY                        TAG      IMAGE ID       CREATED       SIZE
    registry.access.redhat.com/ubi8   latest   ecbc6f53bba0   5 weeks ago   211 MB
  6. To list the working containers and their base images, enter:

    # buildah containers
    CONTAINER ID  BUILDER  IMAGE ID     IMAGE NAME                       CONTAINER NAME
    0aaba7192762     *     ecbc6f53bba0 registry.access.redhat.com/ub... ubi8-working-container
  7. To push the registry.access.redhat.com/ubi8 image to the a local registry located on registry.example.com:

    # buildah push ecbc6f53bba0 registry.example.com:5000/ubi8/ubi

Additional resources