Power Up

Podman since version 4.4 has a native mechanism to start containers automatically by systemd unit files: Podman Quadlet. In this article, I guide you through preparing your system and configuring it to use Quadlets (as the container unit files are called) for your rootless Podman containers. As an example, I'll show you how to set up a reverse proxy in one container and some web services behind the proxy in other containers.

Docker and Podman

If you want to configure which Docker containers should start automatically on your Linux server, Docker Compose [1] is a widely recognized solution. However, within enterprise Linux distributions, Podman [2] has been the preferred container engine for a while. Both Red Hat Enterprise Linux and SUSE Linux Enterprise have adopted Podman, as have their associated community distributions, Fedora and openSUSE.

In contrast to Docker, Podman operates without a continuously running daemon. As a result, Podman is somewhat more lightweight and allows containers to start up faster. Moreover, Podman defaults to running rootless containers, with ordinary user instead of root privileges. SELinux integration is also standard in distributions that support it. Overall, a server running Podman is easier to secure by default than one using Docker.

Podman's compatibility with the Docker API makes it relatively straightforward to use in combination with tools developed for Docker. If you're accustomed to Docker commands, you'll find you can generally substitute the docker command with podman. For example, podman ps lists all running containers, podman images shows all downloaded container images, and podman pull nginx:alpine downloads the nginx:alpine image from one of the registered container repositories.

A Podman Compose [3] solution also processes docker-compose.yml files to start your containers with Podman. Another popular solution is configuring systemd services with the appropriate podman start commands to manage them. However, the Podman Quadlet [4] alternative simplifies the creation and management of systemd unit files for containers.

Preparing the Container Host

You can choose from various Linux distributions for hosting Podman containers, because many include Podman in their standard repositories. In immutable Linux distributions like Fedora CoreOS [5] and openSUSE MicroOS [6] (Figure 1), Podman comes pre-installed. Both Linux distributions offer a minimal operating system (OS) that automatically updates and provides a stable foundation for running containers.

Figure 1: An immutable operating system such as openSUSE MicroOS is an ideal base OS for running Podman containers.

In this article, I operate Podman on an openSUSE MicroOS server installed with the Base System + Container Runtime Environment package set. If you've only installed the base system, you can still install Podman with:

# transactional-update pkg install podman
# reboot

A reboot is necessary because, as an immutable Linux distribution, openSUSE MicroOS doesn't allow live changes. On a traditional Linux distribution this reboot isn't required.

Additionally, you should create a user to run all containers:

$ sudo useradd -m user

The -m option instructs useradd to create a home directory for the user, where all container data will be stored. To set a password for the newly created user, enter,

$ sudo passwd user

and log in as this user. Throughout this article, all containers are operated by this user without the need for root privileges.

Configuring Container Registries

When pulling a container image, you often do not need to specify the container registry because Podman automatically searches a few trusted registries that are configured in the /etc/containers/registries.conf file. On an openSUSE MicroOS system, for example, this file includes:

unqualified-search-registries = ["registry.opensuse.org", "registry.suse.com", "docker.io"]

This sequence implies Podman first searches registry.opensuse.org, followed by registry.suse.com, and finally docker.io. If this configuration file exists at ~/.config/containers/registries.conf, it takes precedence for that user over the system-wide configuration file in /etc/containers/registries.conf.