Containers are increasingly making inroads into home networks. If you use Flatpaks or Snaps, you already use containers in everyday life. Future distributions will shed weight to a minimum, with required services running as containers of some kind. This development has been heralded by Fedora's Silverblue and Kinoite, Endless OS, MicroOS, and Intel's Clear Linux. It definitely makes sense for home users to consider the various container solutions.

Containers isolate applications through virtualization while providing a runtime environment. They make use of the filesystem and the resources of the operating system on which they run. This gives containerization the advantage of lower resource consumption compared with the traditional server approach or conventional virtualization. Where a virtual machine requires its own operating system, including a kernel, containers only store the actual applications plus any files and functions (microservices) required for execution.

Docker has long been synonymous with containers since its inception in 2013, but the advent of the Kubernetes container orchestration software has slowly started to change this perception. Recently, Podman [1] has been gaining momentum in the container sector, reaching version 4.0. After disputes between Docker and Red Hat over ongoing development, Red Hat began investing in Podman in 2017 as an application for managing containers and pods and has since cancelled support for Docker.

Podman (short for Pod Manager) has adopted the pod model introduced by Kubernetes. Pods are containers, each with individual applications running on the same server. If you want to set up Nextcloud, for example, you also need a server application, a database, and, if you want to access the service from the outside world, a reverse proxy. All of these applications run in separate containers in a pod. This offers benefits such as the ability to bind to the pod's localhost address, which means that all the containers in the pod can connect to it because of the shared network namespace.

In this article, I'll discuss the benefits of Podman and then show you a practical example by setting up Nextcloud with Podman.

Podman Benefits

While Docker is centrally controlled by a daemon, Podman does without such an instance and runs without root privileges. The containers run in the context of a normal user thanks to the use of the kernel's user namespaces based on Cgroups 2 [2]. In the container itself, however, the processes themselves run with root privileges. Inside a namespace, processes thus have different rights and user IDs than outside it. Because they are not controlled by a daemon, Podman containers can be included as systemd services [3] or controlled in a GUI using the Cockpit admin tool (Figure 1) [4].

Figure 1: Cockpit, a web-based graphical user interface for servers, takes the pain out of managing local or remote computers in many ways. It recently added the ability to manage Podman.

Unlike Docker, where individual components of an application run in different containers, Podman combines multiple containers in a single pod; this, in turn, avoids network problems. At the command line, Podman's behavior is almost identical to that of Docker, whose commands the software implements in the background. In addition, Podman can be used to create images of the Docker Registry repository service.

To make containers as resource-efficient as possible, you can use Buildah [5], which lets you build containers from scratch. In particular, Buildah proves helpful in environments where you want the images to be as small as possible.

As you can see, Red Hat has elegantly solved its dependency on Docker with Podman, while providing additional functionality. For instance, Podman 4 comes with the new podman image scp command, which lets you copy images locally and to remote servers without detouring via a registry.

Installation

To set up a simple Nextcloud installation with Podman, I used both Fedora 36 with Podman 4.0.2 and Debian "Sid" (Siduction) with Podman 3.4.4. Apart from the Podman installation steps, the instructions are identical.

During testing, I ran Fedora 36 in a Proxmox container, whereas Siduction was installed on a laptop. To install Podman on Fedora, type:

sudo dnf install podman cockpit-podman

For Debian, use:

sudo apt install podman cockpit-podman

The Debian instructions should work on Debian Stable and its derivatives. Using older versions of Podman sometimes results in deviations in the behavior.

For even better integration between the containers and the host, you need to additionally install the toolbox utility [6]. After doing so, packages can be installed in the container using DNF, USB devices can be passed through, and the host's home directory can be integrated (Figure 2).

Figure 2: A handy little helper, toolbox has its origins in Fedora's immutable filesystems.

Configuration

First, you need to create three volumes for the Nextcloud installation you want to create in the Podman container (Listing 1). A volume [7] in this context acts as a storage device that Podman creates and manages, providing the ability to move and edit data between the container and the host. You can create volumes up front with the podman volume command or directly when setting up the containers (Figure 3).

$ podman volume create nextcloud-app
$ podman volume create nextcloud-data
$ podman volume create nextcloud-db

Figure 3: My example Nextcloud project consists of three volumes that can be created quickly with simple commands. The volumes enhance the containers' flexibility by allowing data to be moved and edited between the containers and the host.

Next, create a new network by typing

podman network create nextcloud-net

and check its properties with

podman network inspect nextcloud-net

Now it's time to create the containers, starting with the MariaDB database. As an alternative, you could integrate PostgreSQL, whereas SQLite is not a good choice for Nextcloud. The commands and specifications for setting up the database container are specified in Listing 2.

podman run --detach \
  --env MYSQL_DATABASE=nextcloud \
  --env MYSQL_USER=nextcloud \
  --env MYSQL_PASSWORD=<DB-User-Password> \
  --env MYSQL_ROOT_PASSWORD=<DB-Root-Password> \
  --volume nextcloud-db:/var/lib/mysql \
  --network nextcloud-net \
  --restart on-failure \
  --name nextcloud-db \
  docker.io/library/mariadb:10

The podman run \ command pops up an interactive shell where you can define the database properties [8]. Make sure you select and remember the <DB-User-Password> and the <DB-Root-Password>; you will need these later on. You can check whether this all worked by typing podman container ls, which shows you the running container.

The next step is to roll out Nextcloud. The same principle applies as shown in Listing 3. Again, make sure you run the <DB-User-Password> from the DB container and replace the <NC-Admin> and the <NC-Password> variables.

podman run --detach \
  --env MYSQL_HOST=nextcloud-db.dns.podman \
  --env MYSQL_DATABASE=nextcloud \
  --env MYSQL_USER=nextcloud \
  --env MYSQL_PASSWORD=DB-User-Password \
  --env NEXTCLOUD_ADMIN_USER=<NC-Admin> \
  --env NEXTCLOUD_ADMIN_PASSWORD=<NC-Password> \
  --volume nextcloud-app:/var/www/html \
  --volume nextcloud-data:/var/www/html/data \
  --network nextcloud-net \
  --restart on-failure \
  --name nextcloud \
  --publish 8080:80 \
  docker.io/library/nextcloud:latest

After setting up the framework, call localhost:8080 in your web browser. Nextcloud 23 will say hello, and you can then continue the installation in the GUI. You can also write the env parameters to a file and then include it by typing:

--env-file /<path>/<to>/<file>