Container & Kubernetes

Docker oder Podman: Daemon, rootless und Lizenzfragen

Für neue Projekte auf RHEL-Systemen ist Podman die naheliegende Wahl: rootless, ohne Daemon, ohne Lizenzfrage. Wo eine gewachsene Compose-Landschaft produktiv läuft, ist ein Wechsel dagegen selten den Aufwand wert.

6 Kapitel mit allen Befehlen
DevOps-Engineer erklärt einem Kollegen Container-Dashboards am Stehtisch
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt
Seit 1997 am Markt Präsenz & Live-Online 4,9 aus 503 Google-Bewertungen Auch Inhouse für dein Team
Worum es geht

Warum die Runtime-Frage gerade jetzt auf dem Tisch liegt

In vielen Teams ist Docker historisch gewachsen: Entwickler nutzen Docker Desktop, die Server laufen mit dockerd, und irgendwo existiert ein docker-compose.yml, das niemand mehr anfassen möchte. Parallel liefert Red Hat Enterprise Linux seit Version 8 Podman als Standardwerkzeug aus, und auch CentOS Stream, Rocky Linux und AlmaLinux führen Docker nicht in ihren offiziellen Paketquellen. Wer heute ein neues RHEL- oder Rocky-System aufsetzt, steht damit vor der Frage, ob Docker aus dem Herstellerrepository nachgerüstet wird oder Podman übernimmt.

Technisch geht es um mehr als einen anderen Befehlsnamen. Docker arbeitet mit einem zentralen Daemon, der als root läuft und Container über containerd verwaltet. Podman startet Container direkt als Kindprozesse der aufrufenden Shell, ohne dauerhaften Dienst dazwischen, und ist auf rootless-Betrieb mit User-Namespaces, slirp4netns beziehungsweise pasta ausgelegt. Das ändert, wie Logging, Restart-Verhalten, Cgroup-Zuordnung und Unit-Dateien aussehen. Ein docker run lässt sich meist eins zu eins übersetzen, ein produktiver Betrieb nicht.

Dazu kommt die kaufmännische Seite. Docker Desktop ist ab 250 Beschäftigten oder 10 Millionen US-Dollar Jahresumsatz und für Behörden generell kostenpflichtig, während die Docker Engine unter Linux weiterhin frei verfügbar ist. Diese beiden Dinge werden regelmäßig verwechselt, und die Diskussion endet dann in einer pauschalen Migration, die niemand geplant hat. Dazu kommen typische Fehler im Betrieb: Rootless-Container binden keine Ports unter 1024, Volumes ohne das Suffix :Z scheitern am SELinux-Kontext, und Neustarts über systemd bleiben aus, solange keine Quadlet- oder Unit-Dateien angelegt sind.

Miniatur-Szene: Hafen mit gestapelten Containern, ein Kran hebt einen davon an, daneben ein Steuerrad
KI-generiertDieses Bild wurde mit KI erzeugt · Yves Hoppe / KI / cmt

Entscheidungskriterien im Vergleich

  1. 01 Zielplattform und Distribution
  2. 02 Daemon oder daemonlos
  3. 03 Rechtemodell: root oder rootless
  4. 04 Lizenz: Desktop oder Engine
  5. 05 Toolchain und Docker-Socket
  6. 06 Betrieb über systemd
Was du mitnimmst

So triffst du die Entscheidung und setzt sie sauber um

Die ehrliche Antwort lautet in den meisten Umgebungen: Es ist keine Glaubensfrage, sondern eine Frage von Zielplattform, Rechtemodell und Betriebsprozess. Die folgenden Punkte bilden den Weg ab, den wir in unseren Container-Kursen mit Administratoren durchgehen.

Architekturunterschied verstehen

Daemon gegen daemonlos ist der Kern: dockerd als zentraler Dienst mit eigenem Socket auf der einen Seite, forkende Container mit conmon als Supervisor auf der anderen. Daraus folgt fast alles Weitere, vom Logging über die Prozessbäume bis zum Verhalten beim Neustart des Hosts.

Rootless realistisch bewerten

Podman läuft ohne root sauber im User-Namespace, was die Angriffsfläche verkleinert. Gleichzeitig handelst du dir Einschränkungen ein, etwa bei privilegierten Ports, bei bestimmten Netzwerk-Setups und bei Storage-Treibern. Docker kennt inzwischen ebenfalls einen rootless-Modus, er ist im Alltag aber weniger verbreitet.

Lizenzfrage sauber trennen

Docker Desktop und Docker Engine sind zwei verschiedene Produkte mit unterschiedlichen Bedingungen. Prüfe konkret, wo bei euch Desktop-Installationen laufen, meist auf Entwickler-Notebooks unter Windows und macOS, und entscheide dort separat von der Server-Landschaft.

Kompatibilität testen statt annehmen

Podman bildet die Docker-CLI weitgehend nach, alias docker=podman funktioniert für den Großteil der Befehle. Für Werkzeuge, die den Docker-Socket direkt ansprechen, etwa Testcontainers oder manche CI-Runner, aktivierst du den Podman-Socket über den systemd-Dienst podman.socket und setzt DOCKER_HOST entsprechend.

Betrieb über systemd abbilden

Statt der Docker-Restart-Policies erzeugst du bei Podman Unit-Dateien, heute bevorzugt als Quadlet unter /etc/containers/systemd/ oder für rootless-Dienste unter ~/.config/containers/systemd/. Damit sind Start, Abhängigkeiten, Logging über journald und Update-Strategien im gewohnten systemd-Werkzeugkasten abgebildet.

Hybrid-Strategie zulassen

Viele Teams fahren bewusst zweigleisig: Docker oder Docker Desktop in der Entwicklung, Podman auf den RHEL-Systemen in der Produktion. Weil beide Werkzeuge OCI-konforme Images bauen und dieselben Registries nutzen, ist das ein tragfähiger Weg und kein Kompromiss aus Verlegenheit.

Tutorial

Podman neben Docker stellen und ehrlich messen

Die Reihenfolge hier ist die einer echten Bewertung: erst herausfinden, was deine Container heute vom Host verlangen, dann Podman parallel installieren, dann die drei Stellen abarbeiten, an denen rootless wehtut, und zuletzt den Dauerbetrieb über systemd abbilden. Nach zwei Tagen in dieser Reihenfolge weißt du belastbar, ob ein Wechsel trägt.

01

Herausfinden, was deine Container vom Host verlangen

Über die Machbarkeit entscheiden nicht die Images, sondern das, was drumherum konfiguriert ist. Diese Inventur machst du, bevor du irgendetwas installierst.

Inventur auf dem Docker-Host
# Was läuft, mit welchen Ports
docker ps --format '{{.Names}}\t{{.Image}}\t{{.Ports}}'

# Wer läuft privilegiert oder mit Zusatz-Capabilities?
docker inspect $(docker ps -q) \
  --format '{{.Name}} priv={{.HostConfig.Privileged}} caps={{.HostConfig.CapAdd}}'

# Wer bekommt den Docker-Socket eingehängt? Das ist der harte Fall.
docker inspect $(docker ps -q) \
  --format '{{.Name}} {{range .Mounts}}{{.Source}} {{end}}' | grep docker.sock

# Welche Netzwerke und Volumes hängen dran?
docker network ls && docker volume ls

Drei Ergebnisse dieser Inventur entscheiden fast alles: Container, die /var/run/docker.sock eingebunden bekommen (Traefik, Portainer, CI-Runner), Container mit --privileged und Container auf Ports unter 1024. Der Rest läuft unter Podman in aller Regel ohne Anpassung.

Was sich nicht eins zu eins übertragen lässt

  • Swarm-Stacks. Podman kennt kein Swarm, dafür gibt es keinen Ersatz außer Kubernetes oder systemd.
  • Dockerfiles mit BuildKit-Erweiterungen wie RUN --mount oder --secret. Podman baut mit Buildah, nicht mit BuildKit. Buildah versteht die gängigen RUN --mount-Varianten inzwischen, Sonderfälle testest du trotzdem gesondert, statt Kompatibilität anzunehmen.
  • restart: always aus einer Compose-Datei. Ohne Daemon übernimmt diese Aufgabe systemd, und das musst du aktiv einrichten.
  • Alles, was den Docker-Socket lesend oder schreibend braucht. Podman bietet eine kompatible API an, aber sie muss erst als Dienst laufen und rootless sieht sie nur die Container des eigenen Kontos.
02

Podman daneben installieren, ohne Docker anzufassen

Beide Werkzeuge können dauerhaft nebeneinander auf demselben Host stehen. Genau so bewertest du sie, denn ein Rückweg kostet dann nichts.

Installation und Übernahme der Images
# RHEL, Rocky, AlmaLinux
sudo dnf install -y podman podman-docker skopeo

# Debian, Ubuntu
sudo apt install -y podman podman-docker skopeo

# podman-docker legt /usr/bin/docker als Wrapper an: bestehende Skripte
# und Ansible-Rollen laufen weiter, ohne dass du sie sofort umschreibst.

# Image direkt aus der lokalen Docker-Ablage übernehmen
podman pull docker-daemon:meinimage:1.4

# Gleiches Ergebnis, explizit über skopeo
skopeo copy docker-daemon:meinimage:1.4 containers-storage:localhost/meinimage:1.4

Docker und Podman teilen sich keinen Image-Speicher. Podman legt rootless unter ~/.local/share/containers/storage ab, als root unter /var/lib/containers/storage, Docker unter /var/lib/docker. Rechne während der Testphase mit dem doppelten Plattenbedarf.

Rootless vorbereiten
# Bereich für die UID-Abbildung prüfen, ohne ihn ist rootless nicht möglich
grep "^$USER:" /etc/subuid /etc/subgid

# Fehlt der Eintrag:
sudo usermod --add-subuids 200000-265535 --add-subgids 200000-265535 "$USER"
podman system migrate      # nach jeder Änderung an subuid/subgid nötig

# Dienste sollen ohne angemeldete Sitzung weiterlaufen
sudo loginctl enable-linger "$USER"

# Gegenprobe
podman info --format '{{.Host.Security.Rootless}} {{.Host.IDMappings.UIDMap}}'

podman system migrate ist der Schritt, den fast alle vergessen. Ohne ihn behalten bereits angelegte Container die alte Abbildung und schreiben plötzlich nicht mehr in ihre Volumes.

03

Die drei Stellen, an denen rootless wehtut

Ports, Dateibesitz und Netzwerk. Wer diese drei kennt, hat die typischen Fehlermeldungen einer Umstellung bereits gesehen.

Ports, Volumes, Namespace
# 1. Privilegierte Ports dauerhaft freigeben
echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system

# 2. Volumes: die UID 1000 im Container ist nicht deine UID 1000
# Variante A: Besitzverhältnisse im User-Namespace anpassen
podman unshare chown -R 1000:1000 ./daten

# Variante B, statt A und nicht zusätzlich: eigene UID in den Container abbilden
podman run -d --userns=keep-id -v ./daten:/daten:Z registry.firma.de/app:1.4

# 3. Wer lauscht wirklich, und über welchen Netzwerk-Stack?
ss -tulpn | grep -E 'rootlessport|pasta|slirp'

podman unshare führt den Befehl im User-Namespace des Kontos aus, deshalb setzt es genau die Besitzverhältnisse, die der Container später sieht. :Z lässt Podman das SELinux-Label des Verzeichnisses setzen, das brauchst du auf RHEL, Rocky und AlmaLinux.

Fehlermeldung, Ursache, Abhilfe

Was du siehstUrsacheAbhilfe
bind: permission denied auf Port 80Rootless darf keine Ports unter 1024 belegenip_unprivileged_port_start senken oder auf 8080 veröffentlichen und einen Reverse Proxy davorsetzen
Container schreibt nicht ins VolumeDie UID im Container zeigt im Namespace auf eine andere Host-UIDpodman unshare chown oder --userns=keep-id
Permission denied trotz passender UIDSELinux-Label des Verzeichnisses stimmt nichtMount mit :Z versehen
Im Log steht als Quelle immer dieselbe IPslirp4netns maskiert die Client-AdresseAuf pasta wechseln, das die Quelladresse erhält und seit Podman 5 Standard ist, oder den Reverse Proxy die echte IP weiterreichen lassen
Container startet als root nicht mehr nach UpdateAuf cgroups v2 laufen einige alte Images mit fest verdrahteter cgroup-Erwartung nichtImage auf eine aktuelle Basis heben, statt am Host zurückzurudern
04

Compose weiterbenutzen, ohne die Dateien umzuschreiben

Docker Compose gegen den Podman-Socket
# Podman-Socket als Benutzerdienst starten
systemctl --user enable --now podman.socket
systemctl --user status podman.socket

# Das originale docker compose spricht damit direkt Podman an
export DOCKER_HOST="unix://$XDG_RUNTIME_DIR/podman/podman.sock"
docker compose up -d

# Gegenprobe: die Container liegen jetzt in der Podman-Ablage
podman ps

Dieser Weg bringt dich am weitesten, weil das originale docker compose die Compose-Spezifikation vollständig umsetzt und Podman nur die API bereitstellt. podman-compose ist eine eigenständige Nachbildung und hinkt bei selteneren Schlüsseln hinterher. Prüfe bei beiden Wegen zuerst depends_on mit condition, Healthchecks und benannte Netzwerke.

05

Dauerbetrieb: Quadlet statt Compose

Für alles, was dauerhaft laufen soll, ist Compose unter Podman der Umweg. systemd startet, überwacht und protokolliert die Container ohnehin, Quadlet ist die dafür vorgesehene Beschreibungsform.

~/.config/containers/systemd/app.container
[Unit]
Description=Anwendungscontainer

[Container]
Image=registry.firma.de/app:1.4
PublishPort=8080:8080
Volume=%h/daten:/daten:Z
Environment=TZ=Europe/Berlin
HealthCmd=/usr/bin/curl -fsS http://localhost:8080/health
Notify=healthy
AutoUpdate=registry

[Service]
Restart=always

[Install]
WantedBy=default.target

Systemweite Dienste beschreibst du unter /etc/containers/systemd/, dann läuft der Container als root. Für rootless bleibt der Pfad im Home des Kontos. Die Abhängigkeit vom Netzwerk ergänzt Quadlet selbst, als root über network-online.target, rootless über podman-user-wait-network-online.service.

Aktivieren, prüfen, aktuell halten
systemctl --user daemon-reload      # erzeugt app.service aus app.container
systemctl --user start app
systemctl --user status app
journalctl --user -u app -f

# Automatische Aktualisierung der Images
systemctl --user enable --now podman-auto-update.timer
podman auto-update --dry-run

AutoUpdate=registry und der Timer zusammen ziehen neue Images und starten den Dienst neu. Schlägt der Neustart fehl, kehrt Podman zum vorherigen Image zurück. Weil Notify=healthy den Dienst erst als gestartet meldet, wenn der Healthcheck grün ist, löst auch ein fehlschlagender Healthcheck diesen Rollback aus.

06

Die Abnahme nach dem Test

Erst wenn das alles sitzt, ist die Bewertung fertig

  • Alle Container starten nach einem echten Neustart des Hosts von alleinDas ist der häufigste Fehler nach einer Umstellung. Prüfe ihn mit reboot, nicht mit systemctl restart. Fehlt enable-linger oder der Abschnitt [Install], merkst du es sonst erst beim nächsten Stromausfall.
  • Die Build-Pipeline baut mit podman build vollständig durchPodman baut über Buildah statt über BuildKit. Dockerfiles mit BuildKit-Erweiterungen fallen genau hier auf, und zwar bevor sie in der Produktion fehlen.
  • Protokollmenge und Plattenverbrauch sind geprüftOhne Daemon landen die Container-Ausgaben in journald. Ein gesprächiger Container füllt damit das Journal des Kontos. journalctl --user --disk-usage und ein gesetztes SystemMaxUse gehören zur Abnahme.
  • Das Monitoring liest die neuen EndpunktePrüfungen, die auf den Docker-Socket zeigen, laufen ins Leere und melden trotzdem grün. Podman liefert Kennzahlen über podman stats und über die kompatible API am Podman-Socket.
  • Der Rückweg ist aufgeschriebenSolange Docker auf dem Host bleibt, besteht der Rückweg aus dem Stoppen der systemd-Units und einem docker compose up -d. Halte fest, wer das darf und woran erkannt wird, dass es nötig ist.
Wissen prüfen

Teste dich und finde deinen Weg

Bevor du einen Kurs buchst, lohnt sich eine ehrliche Standortbestimmung. Die Tests sind kostenlos und ohne Anmeldung.

Aus unseren Kursen

Was Teilnehmende über unsere IT-Kurse sagen

Gut vorbereitete professionelle Vermittlung der komplexen Inhalte innerhalb von nur drei Tagen.
Rückmeldung aus dem Kurs „Docker Grundkurs für Einsteiger“
Qualitativ sehr guter Kurs. Ruhiger und wertschätzender Umgang. Keine Informationsüberlastung.
Rückmeldung aus dem Kurs „Ansible Kompaktkurs“
Gut zu wissen

Häufige Fragen zu Docker und Podman im Vergleich

Ist deine Frage nicht dabei? Ruf an oder schreib uns, du sprichst direkt mit jemandem aus der Kursberatung.

Frag uns direkt
Ist Podman ein vollwertiger Docker-Ersatz?
Für den überwiegenden Teil der täglichen Arbeit ja, weil Podman dieselben OCI-Images verarbeitet und eine weitgehend kompatible Kommandozeile bietet. Unterschiede zeigen sich beim Betrieb: Restart-Verhalten, Logging und Orchestrierung löst Podman über systemd statt über einen eigenen Daemon, und Werkzeuge, die zwingend den Docker-Socket erwarten, brauchen eine zusätzliche Konfiguration.
Funktioniert docker-compose auch mit Podman?
Ja, du hast zwei Wege. Entweder du aktivierst podman.socket und lässt docker compose über DOCKER_HOST gegen Podman laufen, oder du nutzt podman-compose beziehungsweise übersetzt die Dienste in Quadlet-Units. Der zweite Weg ist im Serverbetrieb der stabilere, weil die Container dann im normalen systemd-Lebenszyklus hängen.
Muss ein Unternehmen für Docker zahlen?
Die Docker Engine unter Linux ist quelloffen und ohne Lizenzkosten nutzbar. Docker Desktop dagegen darf laut den Bedingungen von Docker (Stand Oktober 2026) nur ohne Abonnement genutzt werden, wenn das Unternehmen weniger als 250 Beschäftigte und weniger als 10 Millionen US-Dollar Jahresumsatz hat oder es um ein nicht kommerzielles Open-Source-Projekt geht. Behörden brauchen unabhängig von ihrer Größe ein Abonnement. Prüfe die Bedingungen vor einer Entscheidung beim Hersteller, weil sie sich in der Vergangenheit geändert haben.
Ist Podman sicherer als Docker?
Podman hat durch den daemonlosen Aufbau und den Fokus auf rootless-Betrieb strukturelle Vorteile, weil kein dauerhaft privilegierter Dienst mit einem Socket existiert, dessen Zugriff faktisch root-Rechten entspricht. Sicherheit entsteht aber erst im Zusammenspiel mit SELinux, sauberen Images, Capability-Beschränkungen und regelmäßigen Updates, nicht allein durch die Wahl der Runtime.
Wie aufwendig ist eine Umstellung von Docker auf Podman?
Der Wechsel der Kommandos ist schnell erledigt, der Aufwand steckt in der Betriebsintegration. Rechne mit Arbeit an Volumes und SELinux-Kontexten, an Netzwerk- und Portfreigaben im rootless-Betrieb, an CI-Pipelines sowie an der Ablösung der Restart-Policies durch systemd-Units. Für eine überschaubare Anzahl an Diensten ist das gut planbar.

Zuletzt geprüft am 05. Oktober 2026.

Persönlich für dich da

Deine Ansprechpartner

Du bist dir nicht sicher, welcher Kurs oder welches Level zu dir passt? Wir beraten dich persönlich und kostenlos.

Yves Hoppe

Yves Hoppe

Weiterbildung & Beratung

Hilft dir, aus dem Linux-Programm den passenden Kurs oder Lernpfad zu finden.

Norbert Jansen

Norbert Jansen

Beratung & Inhouse

Plant mit dir Inhouse-Trainings, die exakt auf eure Systemlandschaft und Distributionen zugeschnitten sind.

Nächster Schritt

Container-Know-how für deine Linux-Umgebung

Im Linux Container Workshop arbeitest du mit Docker und Podman parallel und siehst die Unterschiede direkt am System. Für den Einstieg passt der Docker Grundkurs für Einsteiger, für die Red-Hat-Welt der Kurs DO188 Red Hat OpenShift Development I: Introduction to Containers with Podman. Alle Kurse gibt es als Präsenztermin oder Live-Online. Wenn du unsicher bist, welcher Weg für eure Umgebung sinnvoll ist, sprich uns an, wir gehen deine Ausgangslage gemeinsam durch.