Eine Tutorialreihe zum Einsatz von Podman: Anwendung, Vorteile und Funktionsweise.
Inhaltsverzeichnis
- Teil: Einleitung und Installation
- Teil: Podman CLI
- Teil: Wie funktioniert die Restart-Policy? Oder: Podman hat keinen Daemon
- Teil: Quadlets
- Teil: Updates (Das ist dieser Artikel)
- Teil: Healthchecks
- Teil: Ports publishing – rootful & rootless
- Teil: Volumes & Mounts
- Teil: Netzwerk: Kommunikation zwischen Containern
- Teil: Capabilities
Einleitung
Im Quadlets-Kapitel haben wir AutoUpdate=registry schon gesehen, ohne ins Detail zu gehen. Das holen wir jetzt nach.
Der Auto-Update-Prozess
Eine Idee von OCI-Containern ist, dass der Update-Prozess einfach und standardisiert vonstattengeht: Wenn die Entwickler:innen einer Applikation, die du als Container am Laufen hast, eine neue Version als Image hochladen, kannst du das Image herunterladen, deinen Container zerstören (stoppen und löschen) und den Container vom neuen Image neu erstellen und starten.
Wäre es nicht super, wenn du für diesen Prozess nur einen einzigen Befehl bräuchtest? Podman bietet dir genau das:
podman auto-update
Der Befehl sucht sich alle Container mit dem Label io.containers.autoupdate. Dies musst du mittels --label setzen. Bei Quadlets setzt AutoUpdate=registry dieses Label automatisch für dich.
Bei der Policy registry vergleicht Podman den Digest des lokalen Images mit demjenigen in der Registry. Unterscheiden sich die beiden, gilt das lokale Image als veraltet. Wichtig: Dafür braucht es – genau wie beim docker.io-Thema ganz am Anfang – eine vollständig qualifizierte Image-Referenz.
Findet Podman ein neueres Image, passiert Folgendes:
- Das neue Image wird heruntergeladen.
- Der zugehörige Container bzw. bei Quadlets die zugehörige systemd-Unit wird neu gestartet. Der alte Container verschwindet, ein neuer mit dem neuen Image nimmt seinen Platz ein.
Noch besser als jedes Mal podman auto-update aufzurufen, wäre eine Automatisierung des Ganzen. Damit das regelmässig automatisch passiert, brauchst du den podman-auto-update.timer. Genau wie podman-restart.service muss auch dieser zuerst aktiviert werden. Einmal aktiviert, prüft er einmal täglich (kurz nach Mitternacht, leicht zufällig verzögert) auf neue Images.
# ROOTLESS:
systemctl --user enable --now podman-auto-update.timer
# ROOTFUL:
sudo systemctl enable --now podman-auto-update.timer
Der Rollback
Das Geniale an podman auto-update ist, dass Podman prüft, ob der Container das Update überlebt hat – und rollt bei Bedarf automatisch auf die alte Version zurück.
Wie erkennt Podman aber, ob der Neustart wirklich geklappt hat? Nicht über einen simplen Prozess-Exit-Code – ein Neustart des systemd-Service kann technisch "erfolgreich" sein, obwohl die Applikation im Container längst abgestürzt ist. Podman braucht dafür ein aktives Signal, dass der Container wirklich bereit ist. Zwei Wege dafür:
Notify=healthy(in der Quadlet-Datei) kombiniert mit einem Healthcheck: Podman meldet "bereit", sobald der Healthcheck zum ersten Mal erfolgreich durchläuft. Das ist der pragmatischste Weg für Images, die kein natives systemd-Wissen mitbringen (wie z.B. IT-Tools) – du musst nur einen Healthcheck definieren. Mehr dazu unter Healthchecks.Notify=true: Die Applikation im Container meldet sich selbst übersystemd-notify --ready, sobald sie bereit ist. Braucht native Unterstützung in der Applikation, ist dafür aber am präzisesten.
Ohne eine der beiden Optionen (Standard ist Notify=false) hat Podman keine zuverlässige Möglichkeit, einen fehlgeschlagenen Start zu erkennen – und der Rollback bleibt entsprechend aus. Für produktiv genutzte Container würde ich das also nicht dem Zufall überlassen.
Und bei Docker?
Bei Docker fehlt diese Update-Möglichkeit. Der Docker Daemon bringt keinen eingebauten Mechanismus mit, um Container automatisch zu aktualisieren. Die Docker-Welt behilft sich deshalb mit Drittanbieter-Tools, beispielsweise Watchtower.
Für mich ist das ein weiterer Punkt auf der Podman-Seite der Waage: Der ganze Update-Lebenszyklus – inklusiv Sicherheitsnetz – gehört von Haus aus dazu.
Fazit und Ausblick
Du weisst jetzt, wie Podman Container automatisch aktualisiert (podman auto-update plus podman-auto-update.timer) und wie der eingebaute Rollback funktioniert – sofern du Podman mitteilst, wann ein Container wirklich bereit ist. Genau das haben wir mit Notify=healthy nur gestreift.
Im nächsten Teil schauen wir uns Healthchecks im Detail an: wie du sie definierst, welche Optionen es gibt und wie du sie in unsere Quadlet-Datei einbaust.
TL;DR
Aktiviere automatische Updates:
# ROOTLESS:
systemctl --user enable --now podman-auto-update.timer
# ROOTFUL:
sudo systemctl enable --now podman-auto-update.timer
Damit der Rollback bei einem missglückten Update zuverlässig funktioniert, in der Quadlet-Datei kombiniert mit einem Healthcheck (mehr dazu im nächsten Teil):
[Container]
Notify=healthy
Quellen und Dokumentation
- Container mit podman-auto-update automatisch aktualisieren | My-IT-Brain. 28. August 2023. https://www.my-it-brain.de/wordpress/container-mit-podman-auto-update-automatisch-aktualisieren/.
- «How to Use Auto-Updates and Rollbacks in Podman». Zugegriffen 8. März 2025. https://www.redhat.com/en/blog/podman-auto-updates-rollbacks.
- Kastning, Joerg. «Automatically Update Containers with Podman-Auto-Update». Open Sourcerers, 4. September 2023. https://www.opensourcerers.org/2023/09/04/automatically-update-containers-with-podman-auto-update/.
- Rick. «Autostarting, Auto-Updating, Rootless Podman Containers». Nano’s Blog, 16. Januar 2022. https://www.nanosector.nl/posts/podman-rootless-autostart/.
