An OCI container workflow using Podman, Buildah, and Skopeo

The action to run a container from Linux, either on a local machine or cloud service, usually involves some steps:

• Push a validated base image to a container image registry.
• Fetch a base image by pulling it from the registry to your local machine.
• Inspect the base image.
• Create a Container file or a Dockerfile and use it to build a custom image on top of the base image.
• Use the created custom image to start one or more containers.

To implement these steps, containers, images, and image registries need to be able to interact with each other.

Running a containerized application (running an application inside a container) requires a container image and a file system bundle that provides all the application files, libraries, and dependencies the application needs to run.

Container images are available from container image registries that allow users to search and retrieve base images.

So, we must be able to build images; put them into image registries; retrieve an image from the image registry; build a container from that image; run the container.

We can use three complementary and open-source tools for this task: Podman, Buildah, and Skopeo.

These tools can be directly accessed from the public repositories of their respective projects:

https://github.com/dankohn/libpod

https://github.com/containers/buildah

https://github.com/containers/skopeo

These tools are also available natively in the Red Hat Enterprise Linux 9. The RHEL9 has two native runtimes for perfect integration, especially with Podman and Buildah: runc and crun.

For more information, refer to the following link:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/building_running_and_managing_containers/index

Summarizing Podman, Buildah, and Skopeo characteristics:

Podman:

This tool can manage containers and images, volumes mounted into those containers, and pods made from groups of containers.

Podman is a CLI tool based on libpod, that enables users to run standalone OCI containers, similar to the Docker CLI. The libpod library provides APIs for managing containers, pods, container images, and volumes.

Users can invoke Podman from the command line to pull containers from a repository and run them. Podman calls the configured container runtime to create the running container. Podman also directly interacts with the image registry, the container, image storage, and the Linux kernel through runc container runtime process, all with no daemons involved like in Docker.

Podman is also capable of integrating with the Linux systemd. There are two use cases for combining systemd and containers:  running systemd inside a container and using systemd to run containerized applications.

At a high level, the scope of Podman and libpod is the following:

• Support for multiple container image formats, including OCI and Docker images.
• Full management of those images, including pulling from various sources, creating, and pushing to registries and other storage backends.
• Full container lifecycle management, including creation, running, checkpointing, restoring (via CRIU), and removal.
• Full management of container networking using Netavark.
• Support for pods, groups of containers that share resources and are managed together.
• Support for running containers and pods without root or other elevated privileges.
• Resource isolation of containers and pods.
• Support a Docker-compatible CLI interface, which can run containers locally and on remote systems.
• No manager daemon.
• Support for a REST API providing both a Docker-compatible interface and an improved interface exposing advanced Podman functionality.
• Support for running on Windows and Mac via virtual machine.

Buildah:

It facilitates building OCI container images. Buildah’s goal is also to provide a lower-level interface to build container images without requiring a Dockerfile.

Buildah’s other goal is to allow you to use other scripting languages to build container images without requiring a daemon. And Buildah’s commands replicate all of the commands that are found in a Dockerfile.

With Buildah, we can create a working container from scratch or use an image as a starting point. We can create an image from a working container. Or we can use the instructions in a Containerfile, and mount/unmount a working container’s root filesystem.

Both Podman and Buildah can be used to build container images.

While Podman makes it possible to build images using Dockerfiles, Buildah offers an expanded range of image-building options and capabilities.

So, in short, Buildah is an efficient way to create OCI images. At the same time, Podman allows us to manage and maintain those images and containers in a production environment using a familiar container command line.

Skopeo:

It is specialized in inspecting images. With Skopeo, we can inspect images on a remote registry without having to download the entire image with all its layers. Before Skopeo, we had to extract the entire image to inspect it, even if we only wanted to inspect some metadata.

We can also use Skopeo for copying, signing, syncing, and converting images across different formats and layer compressions.

Skopeo also allows you to delete an image from a repository and sync an external image repository to an internal registry for more secure disconnected network (also known as air-gapped) deployments. Skopeo can pass the appropriate credentials and certificates for authentication when required by the repository.

Let´s verify a simple workflow using Podman, Buildah, and Skopeo:

Here is a simple workflow to create, run and inspect containers:

1. Use “podman push registry” to pushes a base image to a container image registry
2. You can use “skopeo inspect” to verify the base image on container image registry.
3. Use “buildah from registry.xxx/xx/xx” to create a working container from the base image. The working container is just a temporary container.
4. Use the “build bud” command to build an image using instructions from the Containerfile or Dockerfile you created.
5. Once the packages are installed in the working container, save the working container as the target application image using “buildah commit”.
6. Use “podman run” to start the customized container. Podman and Buildah use the exact local image storage locations, which lets you immediately run your new image without specifying the container’s location or system on which the container will run.
7. You can use “podman ps” to inspect container and verify the application if the container is running and accessible
8. You can use “podman images” to list all local images.
9. The “skopeo inspect” allows you to inspect any local image.

Please, refer to this step-by-step exercise which is very similar to the proposed pipeline:

https://redhatgov.io/workshops/rhel_8/exercise1.8/

That is all for now. I hope this post can be helpful!

References:

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html-single/building_running_and_managing_containers/index

https://developers.redhat.com/cheat-sheets/podman-cheat-sheet

https://developers.redhat.com/cheat-sheets/buildah-cheat-sheet

https://github.com/containers/skopeo