Interested in the latest container technologies?

Great, here is what the openSUSE community has been working on lately.

Many of our users are interested in trying out alternatives to the Docker open-source engine, so we started having look at what the larger community has to offer and, in fact, there is quite some choice. In the context of Kubernetes, there are cri-containerd and CRI-O. Both projects have a vivid community and are ultimately aiming at serving the Kubelet in a more specialized and less heavy-weight way than running a feature-rich yet fat dockerd. Alternatives for a standalone container engine are, for instance, rkt and Podman. As you can see, there is a lot to talk about but in this article, I want to focus on Podman.

Introduction to Podman

Podman, formerly known as kpod, is a comparatively young project that was introduced in mid 2017. Podman can be described in very simple terms by comparing it to the client of the Docker open-source engine. If you are familiar with the Docker command-line interface (CLI), then playing around with Podman should be a breeze as Podman’s CLI is a nearly verbatim copy of Docker’s CLI. In fact, there are rumors about some users aliasing it.

Although there are some familiarities with the Docker open-source engine, Podman’s architecture is quite different. The architecture of the Docker open-source engine follows a strict client-server paradigm, which means that each command passed to the client gets translated into a remote procedure call, which is finally passed to the dockerd daemon, which in turn is talking to another daemon, containerd, which is responsible for the run-time and low-level management of containers.

In contrast to the client-server paradigm, Podman follows a more lightweight approach by not requiring any heavy-weight daemon at all, but only a tiny layer taking care of monitoring tasks, such as logging. All container processes, in fact, are direct descendants of Podman. The more traditional fork/exec model of Podman reduces some complexity in terms of the steps required to get a container running. It can be used as any other standalone binary and thereby opens doors to some interesting use-cases, for instance, to integrate Podman directly into systemd unit files. Pretty exciting, isn’t it?

Podman on openSUSE

If you’re using openSUSE and want to try out Podman, you don’t need to bother building it on your own, you can simply install the package via zypper install podman. It’s part of the official repositories of openSUSE Tumbleweed. If you want to try out Podman on other versions of openSUSE, feel free to install it from software.opensuse.org.

As soon as Podman is installed, we are ready to go. As I’ve mentioned before, Podman is a nearly 1:1 copy of the command-line interface of the Docker open-source engine. In my opinion, this is a wise decision as Docker’s CLI is the defacto standard; users are accustomed to this CLI and do not need to learn another workflow to achieve the very same thing. In the following, I will go through a few common commands and explain how we can use Podman and also how we can do some minor tweaks to make using it a little bit more convenient.

Pulling an Image

The ones familiar with the Docker CLI will not be surprised that pulling images can be done via podman pull. However, Podman does not default to using the official Docker registry for unqualified images, but I am going to show how we can work around that. First, we can always use the full reference if we want to pull an image, for instance podman pull docker.io/library/opensuse:42.3. But this can be annoying at times or might even break existing automation as we might just want to pull opensuse:42.3. However, we can work around that by adding “docker.io/library” to the search registries in the /etc/containers/registries.conf configuration file. With this tweak, Podman will first search in the specified registry namespace when pulling an image and we can use it as we are used to from using the Docker open-source engine. Search registries are a pretty cool feature and enable users to solve common issues when automation uses unqualified references on specific images or when the desired images reside in a specific namespace on a registry.

Running a Container

Again, there should be no surprise as a simple podman run --rm -it opensuse:tumbleweed sh will run an openSUSE Tumbleweed image, give us a shell and will finally remove the container as soon as we exit from it. Initially, DNS resolution did not work inside Podman containers on openSUSE as IP forwarding for network bridges was blocked by default by the firewall and had to be manually enabled by adding a specific forwarding rule to iptables. The issue was already known to Podman’s upstream community and they were already working on fixing the root cause in the CNI networking plugins. Nonetheless, the Podman maintainers kindly accepted and implemented the proposal to add a workaround to Podman to make it usable by default on openSUSE without manually adding iptables rules. Due to the weekly Podman releases and the instant feedback of the Podman maintainers, it took two days until the DNS issue was resolved for openSUSE users. Thanks to everybody involved for making this such a pleasant experience!

Mounting a Container’s RootFS

While at the time of writing not at all Docker commands are yet implemented (e.g., container restart), Podman offers some interesting additions. I am particularly excited about the ability to mount and unmount a container’s root filesystem via podman mount ID and podman unmount ID respectively. This is a really great feature for automation scenarios to quickly alter the filesystem. Another scenario we are currently working on is a zypper-less and RPM-less version of openSUSE images, where packages can be installed by mounting the container’s rootFS and use the host’s package manager (i.e., zypper) to perform the packaging tasks; similar to dnf’s –installroot flag. The outcome would be an even slimmer version of openSUSE images, usable to perform specialized utility functions.

If you are interested in Podman, please check it out and let us and the upstream community know about your experience. Currently, we are evaluating ways to extend the concept of rootless containers (see https://rootlesscontaine.rs) to Podman and related tools and libraries, which would enable unprivileged users to build, run and modify containers and thereby cover more use-cases. There is plenty of fun ahead!