Podman ist daemonlos. Es gibt keinen zentralen Hintergrundprozess, der Zustände speichert, Events orchestriert oder Lebenszyklen überwacht. Das wirkt sich auf jeden Schritt des Containerlebenszyklus aus – vom Erstellen über das Starten bis zum Aufräumen. Die Zustandsmaschine verteilt sich auf:
Der Lebenszyklus ist damit transparenter und unmittelbarer: Container sind Prozesse – keine Objekte eines Daemons. Dieses Modell erleichtert Debugging und erlaubt eine klare Sicht darauf, was zur Laufzeit tatsächlich passiert.
Der Containerlebenszyklus besteht in Podman aus klar getrennten Phasen:
podman create)podman start)podman stop /
podman kill)podman rm)Docker fasst viele dieser Schritte stillschweigend zusammen. Podman trennt sie, um die Kontrolle explizit dem Nutzer zu überlassen.
podman create --name myapp python:3.11Dieser Befehl erzeugt:
/var/lib/containers/...)Der Container ist in diesem Zustand vergleichbar mit einem vollständigen, aber noch nicht gestarteten Dienst. So lassen sich Konfiguration, Volumes, Netzwerke und Umgebungsvariablen prüfen, bevor etwas ausgeführt wird.
podman start myappBeim Start geschieht Folgendes:
Podman ruft conmon auf.
conmon ruft die Runtime (crun oder runc) auf.
Die Runtime erzeugt die isolierenden Namespaces:
Der definierte Prozess wird gestartet.
conmon bleibt bestehen und überwacht den Containerprozess.
Ein Überblick:
Ohne Daemon ist conmon das Bindeglied zwischen CLI und laufendem Prozess. Fällt die CLI aus, läuft der Container weiter.
Ein laufender Container ist technisch gesehen ein normaler Linux-Prozess in einem eigenen Namespace-Set.
Das bedeutet:
ps, top, htop
zeigen Containerprozesse wie reguläre Prozesse.Die Containerlaufzeit ist damit kein verborgenes Subsystem eines Daemons, sondern eine isolierte Prozessinstanz mit klaren Schnittstellen zur Außenwelt.
podman stopStop sendet:
SIGTERM (für einen geordneten Shutdown)SIGKILLNützlich für alle Prozesse, die noch aufräumen oder geordnet beenden sollen.
podman killSendet standardmäßig sofort SIGKILL.
Nützlich bei:
Beide Befehle sind reine Signaloperationen – Podman vermittelt lediglich die Signale.
Ein gestoppter Container kann inspiziert werden:
podman inspect myapp
podman logs myapp
podman mount myappDiese Werkzeuge eignen sich für Post-Mortem-Analysen, Debugging oder Zustandsprüfungen.
Entfernen:
podman rm myapplöscht:
Das Image bleibt erhalten.
Container können jederzeit neu instanziiert werden, solange das zugrunde liegende Image verfügbar ist. Dieser Mechanismus ermöglicht reproduzierbare Deployments: Der Container ist flüchtig, das Image persistent.
Daten, die über Container hinweg bestehen sollen, gehören in Volumes – nicht in den Containerlayer.
podman run -it ...für Shell-Sessions, Debugging und experimentelle Ausführung.
podman run -d ...für Dienste und Hintergrundprozesse.
Podman generiert native Units:
podman generate systemd --new --files --name myappSystemd übernimmt anschließend Restart-Verhalten und Prozessüberwachung – ohne dass ein Podman-Daemon benötigt wird.
Podman ist daemonlos, aber conmon stellt Ereignisse bereit:
podman eventsAuflistbare Events sind u. a.:
Die Events spiegeln reale Prozesszustände wider, nicht den Zustand eines Daemons.
Das explizite Modell – create → start → run → stop → rm – bietet präzise Kontrolle. Seitenkanalzustände wie bei daemonbasierten Engines existieren hier nicht.
Mehrstufige Anwendungen, Debugging, reproduzierbare Workflows und getrennte Build-/Run-Phasen profitieren davon.