Serie: Podman-Bausteine – Updates (Teil 5)

  indibart   Lesezeit: 4 Minuten Auf Mastodon ansehen

Der Artikel zeigt, wie `podman auto-update` Container anhand des Image-Digests automatisch aktualisiert und wie der eingebaute Rollback bei einem missglückten Update funktioniert.

serie: podman-bausteine – updates (teil 5)

Eine Tutorialreihe zum Einsatz von Podman: Anwendung, Vorteile und Funktionsweise.

Inhaltsverzeichnis

  1. Teil: Einleitung und Installation
  2. Teil: Podman CLI
  3. Teil: Wie funktioniert die Restart-Policy? Oder: Podman hat keinen Daemon
  4. Teil: Quadlets
  5. Teil: Updates (Das ist dieser Artikel)
  6. Teil: Healthchecks
  7. Teil: Ports publishing – rootful & rootless
  8. Teil: Volumes & Mounts
  9. Teil: Netzwerk: Kommunikation zwischen Containern
  10. 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:

  1. Das neue Image wird heruntergeladen.
  2. 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 über systemd-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

Tags

Podman, Auto-Update, Rollback, podman-auto-update.timer

Es wurden noch keine Kommentare verfasst, sei der erste!