Podman-Container mit Quadlet als systemd-Dienste betreiben

Ziel

Einen von Podman verwalteten Container mithilfe einer Quadlet-Unit-Datei vom Typ .container als nativen systemd-Dienst definieren, statt den älteren Ansatz mit generierten Units zu verwenden.

Voraussetzungen

Podman 4.4 oder neuer (die erste Upstream-Version mit dem Quadlet-Generator; mit podman --version prüfen, da ältere Enterprise-Releases ihn möglicherweise nicht enthalten oder weniger Schlüssel unterstützen); systemd auf dem Host. Root für einen systemweiten Dienst, für einen Rootless-Dienst ein gewöhnliches Benutzerkonto (plus Lingering, falls der Dienst ohne Login-Sitzung laufen soll).

Schritte

1. Zuerst den Mechanismus verstehen: podman-systemd.unit(5) beschreibt Quadlet als systemd-Generator, der deklarative .container-Dateien (sowie .volume, .network, .pod, .kube, .image, .build) beim Booten oder bei daemon-reload in reguläre .service-Units umwandelt. Eine separat gepflegte, generierte Unit-Datei ist dadurch nicht mehr nötig.
2. podman generate systemd nicht für neue Dienste verwenden: Die zugehörige Manpage kennzeichnet den Befehl als veraltet (deprecated) und empfiehlt Quadlet.
3. Eine systemweite Unit unter /etc/containers/systemd/myapp.container ablegen, eine benutzerspezifische unter ~/.config/containers/systemd/myapp.container (weitere Suchpfade sind im Manual aufgeführt). Ein minimales Beispiel:

[Unit]
Description=My application container

[Container]
Image=docker.io/library/nginx:stable
PublishPort=8080:80
AutoUpdate=registry

[Service]
Restart=on-failure

[Install]
WantedBy=multi-user.target

Für eine Rootless-Unit (Benutzer-Unit) WantedBy=default.target verwenden; der Benutzer-Manager kennt kein multi-user.target. 4. systemd veranlassen, die Units aus der neuen Datei neu zu generieren: sudo systemctl daemon-reload (System) bzw. systemctl --user daemon-reload (rootless). Laut systemctl-Manual lädt daemon-reload die Unit-Dateien neu und führt dabei auch die Generatoren erneut aus. 5. Den Dienst starten: sudo systemctl start myapp.service (bzw. systemctl --user start myapp.service). Kein systemctl enable ausführen: Generierte Units lassen sich nicht aktivieren. Der Start beim Booten ergibt sich aus dem Abschnitt [Install], den der Generator bei jedem Lauf selbst anwendet. Der Container heisst systemd-myapp, sofern nicht ContainerName= gesetzt ist. 6. AutoUpdate=registry versieht den Container mit dem Label für podman auto-update, das ein neueres Image abruft und die Unit neu startet. Der Befehl läuft nur, wenn er aufgerufen wird oder podman-auto-update.timer aktiviert ist (sudo systemctl enable --now podman-auto-update.timer, bzw. mit --user); eine Vorschau liefert podman auto-update --dry-run. Das Image muss als vollständig qualifizierte Referenz angegeben sein. Das Label lässt sich mit podman inspect --format '{{ index .Config.Labels "io.containers.autoupdate" }}' systemd-myapp prüfen.

Erwartetes Ergebnis

systemctl status myapp.service --no-pager zeigt die generierte Unit als aktiv an; Stoppen und Starten der Unit stoppt bzw. startet den Container mit der üblichen systemd-Abhängigkeitsreihenfolge, den Restart-Richtlinien und dem Logging (journalctl -u myapp.service). Zum Rückgängigmachen den Dienst stoppen, die .container-Datei löschen und erneut daemon-reload ausführen.

Grenzen und Prüfbasis

Syntax und verfügbare Schlüssel der Quadlet-Dateien sind generatorspezifisch und an die Podman-Version gebunden. Vor der Verwendung eines hier nicht gezeigten Schlüssels in man podman-systemd.unit der installierten Version nachsehen, ob er unterstützt wird. Ein Syntaxfehler oder ein nicht unterstützter Schlüssel führt dazu, dass der Generator die Datei überspringt; systemctl meldet dann später Unit myapp.service not found. Die generierte Ausgabe und Fehler zeigt /usr/lib/systemd/system-generators/podman-system-generator --dryrun an (für Rootless-Units --user ergänzen).