Podman #2 - Rootless - Feeling the Pain

In the first post we created a rootful container that survives a reboot.

Now it’s time to look at what everyone is talking about: rootless containers.

In this example we’ll use the default Debian user named debian with user ID 1000.

Step 1: Enable Linger

For containers to keep running when we’re not logged in, we need to allow the user to linger:

sudo loginctl enable-linger $UID

A reboot at this point helps clear up some warnings and errors from Podman. After rebooting, create the folder for the Quadlet file:

mkdir -p ~/.config/containers/systemd/

Step 2: Create the Quadlet

Next, create the Quadlet file:

nano ~/.config/containers/systemd/alpine.container

With the following content:

[Unit]
Description=Alpine test container

[Container]
Image=docker.io/library/alpine:latest
Exec=sleep infinity

[Service]
Restart=always

[Install]
WantedBy=default.target

Notice the use of default.target. This differs from the multi-user.target we used for the rootful container. In user mode, default.target is analogous to multi-user.target in system mode.

Step 3: Generate the Service File

Now let’s tell systemd to generate the service file:

systemctl --user daemon-reload

The generated file will be in:

ls /run/user/$UID/systemd/generator/

If alpine.service is missing, troubleshoot the Quadlet with:

/usr/lib/systemd/user-generators/podman-user-generator -dryrun

Step 4: Start the Container

Once the service file is created, start it with:

systemctl --user start alpine.service

At this point, the rootless container is running—and it will survive a reboot.

https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html

Podman #1 - Everyone is talking about podman

I’ve been using Docker forever, and everything was fine until the licensing changed and suddenly you couldn’t use it at work anymore. So, it’s time to pivot to Podman. Great. Everyone’s talking about it, so you figure, why not give it a try? But then you realize development is moving so fast that most of the documentation is already outdated before you even get started. Now, with the release of Debian Trixie, it’s finally time to sort this out.

In this series, I want to figure out how to use Podman as a replacement for Docker. For example, starting containers at boot using Quadlets. I work with Kubernetes quite a bit, so learning how pods work in Podman is a nice bonus. Network control and policies are also important, so we’ll take a look at those too.

Using Debian Trixie, we get a fairly recent version of Podman to work with, which makes experimenting a lot easier.

sudo apt install podman

podman --version
podman version 5.4.2

Step 1: Create a Quadlet

Let’s begin with a simple container. We’ll create a Quadlet in the default location for a root container:

nano /etc/containers/systemd/alpine.container
[Unit]
Description=Alpine test container

[Container]
Image=docker.io/library/alpine:latest
Exec=sleep infinity

[Service]
Restart=always

[Install]
WantedBy=multi-user.target

Save and close the file. At this point, nothing happens yet — no container is running.

Step 2: Reload systemd

Podman relies on systemd to manage services behind the scenes. To get systemd to notice our new Quadlet, reload it:

systemctl daemon-reload

This triggers "/usr/lib/systemd/system-generators/podman-quadlet", which generates the actual service file in "/etc/containers/systemd/".

Step 3: Troubleshoot if needed

If you run "systemctl daemon-reload" and no .service file appears in "/etc/containers/systemd/", try this command:

/usr/lib/systemd/system-generators/podman-quadlet -dryrun

It will tell you what went wrong in the Quadlet file ("/etc/containers/systemd/alpine.container" in our case).

Step 4: Start the container

If everything worked, you should see a file called alpine.service:

ls /etc/containers/systemd/

Now you can start it just like any other systemd service:

systemctl start alpine.service

And just like that, the container is up and running.

Step 5: Startup on boot

You might notice that the container already comes back after a reboot, even without manually enabling the service. That’s because Podman includes a helper service:

podman-restart.service

On boot, this service regenerates the systemd unit files in the documented locations and automatically starts them if the policy is set in your Quadlet. In other words, as long as you’ve configured "Restart=" or similar policies, Podman takes care of the boot startup for you.

https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html