13 CLI, Engine, Conmon, runc/crun

13.1 Ein modularer Laufzeitstapel ohne verborgene Ebenen

Podman setzt auf einen geschichteten Laufzeitstapel, der im Gegensatz zu klassischen Containerlösungen wie Docker keine Monolithen, sondern klar voneinander abgegrenzte Werkzeuge und Bibliotheken nutzt. Diese Modularität ist das Ergebnis eines Architekturansatzes, der Debuggability, Sicherheit und Austauschbarkeit priorisiert. Jede Schicht lässt sich gezielt analysieren, ersetzen oder optimieren, ohne dass das Gesamtsystem instabil wird.

13.2 Die CLI: Frontend statt Kontrollinstanz

Die podman-CLI ist das sichtbare Element des Systems, besitzt jedoch keine dauerhafte Kontrolle über laufende Container. Sie liest Konfigurationen, interpretiert Argumente und erzeugt die notwendigen Strukturen – anschließend übergibt sie an die nachgelagerten Komponenten.

Die CLI:

• startet keine Container dauerhaft,
• überwacht keine Prozesse,
• betreibt keine langfristige Netzwerk- oder Storageverwaltung,
• verwendet keinen globalen privilegierten Socket.

Die CLI existiert nur für die Dauer des Befehlsaufrufs:

$ podman run -d python:3.11
# wenige Millisekunden später ist der CLI-Prozess verschwunden

Der Container läuft unabhängig weiter. Dieses Verhalten erleichtert Debugging, Skripting und Automatisierungsabläufe.

13.3 Die Podman-Engine: kein Daemon, sondern Bibliotheken und Tools

Podman umfasst keine dauerhaft laufende Engine im klassischen Sinn. Stattdessen besteht das System aus Bibliotheken wie containers/storage und containers/image sowie verschiedenen Hilfsprogrammen, die bei Bedarf zusammenarbeiten.

Die Engine übernimmt während der Containerinitialisierung:

• Aufbau der Konfigurationsstrukturen,
• Auswahl und Initialisierung der OCI-Runtime,
• Verwaltung des Storage-Backends,
• Erzeugung der isolierenden Namespaces,
• Start des Conmon-Prozesses.

Nach Abschluss dieser Schritte tritt die Engine zurück. Es bleiben keine globalen Zustände zurück, die später Probleme verursachen könnten.

13.4 Conmon: der unsichtbare Supervisor

Conmon ist ein kleines, in C geschriebenes Hilfsprogramm und übernimmt die Aufgabe eines stabilen Supervisors für jeden Container.

Conmon:

• startet die OCI-Runtime (runc oder crun),
• hält Standard-Ein- und -Ausgabe offen,
• sammelt Logs,
• speichert den Exit-Code,
• stellt sicher, dass der Container unabhängig von der CLI weiterläuft.

Prozessmodell:

Conmon ersetzt die Daemonfunktionalitäten klassischer Engines in einem minimalen, isolierten Umfang. Störungen betreffen nur den jeweiligen Container, nicht das gesamte System.

13.5 runc und crun: die eigentlichen Containerstarter

Die OCI-Runtime bringt den Container in den laufenden Zustand. Podman selbst startet keine Containerprozesse – dieser Schritt wird vollständig der Runtime überlassen.

13.5.1 runc

Die Referenzimplementierung der OCI Runtime Spec. Bewährt, stabil, breit unterstützt.

13.5.2 crun

Eine moderne, in C geschriebene Alternative. Schlanker, schneller initialisierend und besonders effizient im Rootless-Betrieb.

Beide sind vollständig OCI-konform und können je nach Systemvorgabe oder Präferenz verwendet werden.

13.5.3 Ablauf eines Containerstarts

Die einzelnen Schritte entsprechen exakt der OCI-Spezifikation und sind dadurch transparent und gut debugbar.

13.6 Das Zusammenspiel: lose gekoppelt, präzise abgestimmt

Die Architektur ist streng modular:

• Die CLI verschwindet unmittelbar nach dem Startvorgang.
• Die Engine tritt nur während der initialen Einrichtung auf.
• Conmon existiert nur für die Dauer des Containerprozesses.
• Die Runtime läuft nur für Bruchteile von Sekunden bis zum Start des Entry-Points.

Dieses Modell unterscheidet sich grundlegend von daemonbasierten Engines. Die einzelnen Bausteine arbeiten präzise zusammen, ohne sich gegenseitig dauerhaft zu binden. Dadurch bleibt das Gesamtsystem robust, übersichtlich und leicht wartbar.