Einführung in Podman

Docker braucht einen Daemon mit Root-Rechten, der im Hintergrund läuft. Podman nicht. Jeder Container ist ein eigenständiger Prozess unter Ihrem normalen Benutzerkonto. In diesem Block verstehen Sie diese daemonless Architektur, den OCI-Standard hinter Podman und warum das Konzept von Anfang an auf Kubernetes ausgelegt ist.

Seit 2022 verlangt Docker Desktop ein kostenpflichtiges Abo für Unternehmen mit mehr als 250 Mitarbeitern oder über 10 Mio. USD Jahresumsatz sowie für Behörden (je nach Plan 9 bis 24 USD pro Entwickler und Monat, Stand: Juli 2026). Podman und Podman Desktop sind Apache 2.0 lizenziert und ohne Lizenzgebühren nutzbar. Aber Lizenzkosten sind nur ein Grund: Sie sehen, warum RHEL, Fedora und SUSE Podman als Standard ausliefern und was das Ökosystem aus Buildah, Skopeo und Quadlet für Ihren Alltag bedeutet.

Podman läuft auf Linux direkt, während macOS und Windows über Podman Machine eine VM benötigen; Podman Desktop ergänzt eine grafische Oberfläche. Sie richten die passende Laufzeit ein und untersuchen anschließend containers.conf, registries.conf sowie storage.conf, bevor Sie ausgewählte Defaults und Registry-Regeln ändern. Durch einen Testlauf erkennen Sie, welche Datei Container-Verhalten, Registry-Auswahl und Storage beeinflusst.

Docker Hub, Quay.io, GitHub Container Registry: Sie arbeiten mit mehreren Registries gleichzeitig und sehen, wie Podman über Shortnames und die registries.conf automatisch die richtige Quelle findet. Mit Skopeo kopieren Sie Images direkt zwischen Registries, ohne sie lokal herunterzuladen. Das spart Bandbreite und ist in CI/CD-Pipelines Gold wert.

Die Podman-CLI ist zu über 95 % identisch mit Docker. Sie testen das am lebenden Objekt und merken schnell, wo die Grenzen der Kompatibilität liegen. Im Rootless-Modus verhält sich einiges anders als gewohnt. Beim Debugging entdecken Sie Podman-eigene Werkzeuge, über die die meisten Tutorials schweigen.

Seit Podman 4.0 läuft das Netzwerk über Netavark statt dem älteren CNI-Stack. Der Vorteil: alles in einem Tool, spürbar schneller, und die DNS-Auflösung funktioniert jetzt zuverlässig über mehrere Netzwerke hinweg. Sie erstellen Bridge-Netzwerke, verbinden Container und verstehen, wann Host- oder None-Modus die bessere Wahl ist.

Container sind kurzlebig, Ihre Daten nicht. Sie arbeiten mit Named Volumes und Bind Mounts und prüfen, ob Daten einen Container-Neustart überleben. Im Rootless-Modus treffen Sie dann auf das häufigste Podman-Problem überhaupt: Dateiberechtigungen, die sich plötzlich anders verhalten als erwartet. Sie verstehen die Ursache (UID/GID-Mapping) und lernen den sauberen Umgang damit.

Images beschreiben Sie deklarativ: Jede Zeile im Containerfile definiert exakt einen Schritt, reproduzierbar und versionierbar. Sie schreiben Ihr erstes Image von Grund auf und lernen dabei den Unterschied zwischen Containerfile und Dockerfile (technisch identisch, Podman bevorzugt Containerfile). Im Hintergrund nutzt Podman Buildah als Build-Engine.

FROM, COPY, RUN, ENTRYPOINT, CMD und die weiteren Befehle lernen Sie nicht als Aufzählung, sondern an einem durchgehenden Beispiel. Der Fokus liegt auf dem deklarativen Ansatz und Best Practices, die heute funktionieren und in 20 Jahren noch gelten: Wie strukturieren Sie ein Containerfile, das wartbar bleibt? Wann ENTRYPOINT statt CMD? Warum gehört COPY vor RUN?

Build-Tools, Compiler, Test-Frameworks: all das gehört nicht ins Runtime-Image. Multi-Stage Builds trennen Build-Umgebung und Runtime sauber in einem Containerfile. Sie bauen ein konkretes Beispiel und sehen live, wie viel Ballast Sie loswerden. Mit Distroless Images gehen Sie ans Minimum: kein Paketmanager, keine Shell, nur Ihre Anwendung und deren Abhängigkeiten.

Gute Images sind klein, sicher und bauen schnell. Sie optimieren Layer-Caching für kürzere Build-Zeiten, nutzen .containerignore zum Ausschließen unnötiger Dateien und konfigurieren HEALTHCHECK und USER für den Produktionseinsatz. Mit podman secret verwalten Sie Zugangsdaten, ohne sie ins Image einzubacken. Am Ende bauen Sie ein Multi-Platform-Image für AMD64 und ARM64.

Bevor Sie mit Podman Compose arbeiten, brauchen Sie sicheres YAML: Einrückung, Listen, Maps, Anker und mehrzeilige Strings. Klingt trivial, sorgt aber in der Praxis für die häufigsten Fehler in compose.yaml-Dateien und Kubernetes-Manifesten. Sie schreiben bewusst fehlerhafte Dateien, debuggen die Fehlermeldungen und wissen danach, worauf es ankommt.

Ihre erste compose.yaml definiert mehrere Container als einen gemeinsamen Stack. Ab der Compose-v5-Syntax entfällt das veraltete version-Feld, Sie arbeiten direkt mit dem aktuellen Standard. Dabei sehen Sie den Unterschied zwischen den beiden Compose-Varianten: podman-compose als eigenständiges Tool und Docker Compose über den Podman-Socket. Beide funktionieren, aber nicht in jedem Szenario gleich gut.

Sie definieren Netzwerke und Volumes in der compose.yaml, steuern die Startreihenfolge über depends_on mit Healthchecks und binden Secrets ein, die nie im Image landen. Mit podman compose up --scale skalieren Sie einzelne Services und sehen, wie Podman die Lastverteilung handhabt.

Datenbank, Backend, Frontend, Reverse-Proxy: Sie setzen einen vollständigen Stack in Podman Compose auf und betreiben ihn mit Healthchecks, Secrets und persistenten Daten. Das Ergebnis nehmen Sie als funktionierende Vorlage für eigene Projekte mit.

Jetzt wird es konkret: Sie vergleichen Architektur, Sicherheit, Kompatibilität und Lizenzmodell Punkt für Punkt. Sie testen, welche Docker-Befehle in Podman identisch funktionieren, wo die 5 % Unterschiede liegen und was bei einer Migration tatsächlich bricht. Nach diesem Block können Sie in Ihrem Team fundiert argumentieren.

Das Podman-Ökosystem trennt Image-Build, Registry-Transport und systemd-Betrieb auf Buildah, Skopeo und Quadlet. Mit einem vorbereiteten Containerfile bauen Sie das Image praktisch mit Buildah und prüfen das Ergebnis. Anschließend vergleichen Sie bereitgestellte Skopeo-Ausgaben und eine Quadlet-Datei, um Registry-Transfer und dauerhaften Dienstbetrieb den beiden anderen Werkzeugen zuzuordnen.

podman kube generate erzeugt Kubernetes-YAML aus laufenden Containern und Pods. podman kube play startet Kubernetes-Manifeste lokal, ohne Cluster. Das heißt: Sie entwickeln lokal mit Podman und deployen dasselbe Manifest im Cluster. Für einzelne Server ohne Kubernetes bietet Quadlet mit .kube-Dateien eine leichtgewichtige Alternative.

In Docker gibt es kein Äquivalent zu Pods. In Podman schon: Container, die sich Netzwerk und PID-Namespace teilen, genau wie in Kubernetes. Sie erstellen Ihren ersten Pod, fügen Container hinzu, testen die Kommunikation über localhost innerhalb des Pods und generieren am Ende ein Kubernetes-Manifest, das direkt im Cluster läuft.