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