Podman vs. Docker auf dem VPS: Die echten Unterschiede

Was unterscheidet Podman und Docker tatsächlich?

Podman und Docker führen auf einem VPS dieselben OCI-Images (Open Container Initiative) aus. Bei der Wahl geht es daher nicht darum, welche Software Sie ausführen können. Der Unterschied liegt im Prozessmodell. Docker verwendet einen root-Daemon, der alle Container verwaltet. Der Befehl docker ist ein kleiner Client, der diesen Daemon mit der Ausführung beauftragt. Podman hat keinen Daemon. podman run startet den Container als Kindprozess des Prozesses, von dem aus der Befehl aufgerufen wurde, und verwendet dabei Ihren eigenen unprivilegierten Benutzer.

Alle weiteren Unterschiede ergeben sich aus dieser einen Tatsache. Der automatische Start ist Aufgabe von systemd und nicht des Daemons. Volume-Berechtigungen werden über einen User Namespace abgebildet. Daher ist der Besitzer, den Sie auf dem Host mit ls -l sehen, nicht derselbe Besitzer, den der Container sieht. Ports unter 1024 können erst gebunden werden, wenn Sie eine Kernel-Einstellung ändern. Die docker-CLI (Command-Line-Schnittstelle) funktioniert über einen Wrapper weiterhin, bis etwas auf den Docker-Socket zugreifen muss.

Kein Daemon: Was beim Starten eines Containers tatsächlich läuft

Auf einem Docker-Host zeigt pstree -a dockerd als root, daneben containerd und für jeden laufenden Container ein containerd-shim-runc-v2. Ihre Anwendung ist ein Kindprozess dieses Shims, und der Shim ist ein Kindprozess von PID 1. Nichts verbindet den Container mit der Shell, die ihn gestartet hat. Wenn Sie den Daemon stoppen, verlieren Sie die Steuerungsebene für alle Container auf dem Host. Bei deaktivierter Standardeinstellung live-restore startet systemctl restart docker außerdem Ihre Container neu.

Podman hat keinen entsprechenden Prozess. Wenn Sie einen Container starten, erhalten Sie genau einen conmon-Prozess (Container-Monitor), der den Hauptprozess des Containers hält und dem Benutzer gehört, der den Befehl ausgeführt hat.

podman run -d --name web -p 8080:80 docker.io/library/caddy:2
ps -o user,pid,ppid,args -C conmon
curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:8080

ps sollte conmon anzeigen, die als Ihr Anmeldebenutzer und nicht als root ausgeführt werden, und curl sollte 200 ausgeben. Da kein zentraler Dienst den Container besitzt, stoppt sudo apt upgrade podman nichts, was bereits läuft. Wenn der Monitor eines Containers abstürzt, werden die anderen Container nicht mit beendet.

Der fehlende Daemon hat jedoch auch Nachteile. Nach einem Reboot startet nichts Ihre Container. --restart=always von Docker ist ein Versprechen, das der Daemon beim Booten einhält. Podman ersetzt es durch systemd. Dafür ist der folgende Quadlet-Abschnitt vorgesehen.

Der Socket ist die andere Hälfte der Geschichte. /var/run/docker.sock ist ein root-eigener API-Endpunkt (application programming interface). Jeder Prozess, der in diesen Socket schreiben kann, kann einen privilegierten Container starten, der das Host-Dateisystem einbindet. Wenn Sie einen Benutzer zur Gruppe docker hinzufügen, gewähren Sie diesem Benutzer auf einem Umweg root-Rechte. Lesen Sie dazu auch jedem Dienstkonto nur die benötigten Zugriffsrechte gewähren. Podman stellt keinen Socket bereit, sofern Sie dies nicht anfordern. Der bereitgestellte Socket gehört einem einzelnen Benutzer unter /run/user/<uid>/podman/podman.sock.

Podman unter Ubuntu 24.04 installieren und bestätigen, dass Rootless wirklich verwendet wird

sudo apt update
sudo apt install -y podman uidmap
podman --version
podman info | grep -i rootless

Das Paket uidmap stellt newuidmap und newgidmap bereit. Dabei handelt es sich um die setuid-Hilfsprogramme, mit denen ein normaler Benutzer einen Bereich untergeordneter IDs verwenden darf. Ohne diese Programme werden Rootless-Container nicht gestartet. podman info sollte rootless: true ausgeben.

Ubuntu 24.04 enthält Podman 4.9, Debian 13 enthält Podman 5.x. Diese Angaben wurden im August 2026 überprüft. Der Unterschied ist relevant, weil Quadlet-Dateien mindestens Version 4.4 benötigen und .pod-Quadlet-Dateien mindestens Version 5.0. Führen Sie podman --version aus, bevor Sie ein Beispiel aus der Upstream-Dokumentation übernehmen.

Jeder Rootless-Benutzer benötigt einen Bereich untergeordneter IDs:

grep "$USER" /etc/subuid /etc/subgid

Ein mit adduser erstellter Benutzer erhält unter Ubuntu automatisch einen Bereich. Ein mit useradd -M oder von einem Konfigurationswerkzeug erstellter Benutzer erhält ihn häufig nicht. Der Fehler weist darauf hin:

Error: cannot find UID/GID for user deploy: no subuid ranges found for user "deploy" in /etc/subuid - check rootless mode in man pages.

Weisen Sie einen Bereich zu. Setzen Sie anschließend den Speicher dieses Benutzers zurück, damit die neue Zuordnung verwendet wird:

sudo usermod --add-subuids 100000-165535 --add-subgids 100000-165535 deploy
podman system migrate

Eine weitere Überraschung beim ersten Start: Podman verwendet nicht automatisch Docker Hub. Ein kurzer Image-Name wird anhand von unqualified-search-registries in /etc/containers/registries.conf aufgelöst. In einem Skript ohne verbundenes Terminal schlägt der Pull mit short-name resolution enforced but cannot prompt without a TTY fehl. Verwenden Sie immer den vollständigen Namen. Verwenden Sie docker.io/library/nginx:1.27 statt nginx.

Was Ihnen rootless Container auf einem gemieteten Server tatsächlich bringen

Ein rootless Container läuft innerhalb eines User-Namespace. Dabei handelt es sich um eine Kernel-Funktion, die einem Prozess eine eigene Zuordnung von Benutzer-IDs gibt. Innerhalb des Namespace ist der Superuser des Containers UID (user ID) 0. Außerhalb des Namespace, auf Ihrem VPS, ist derselbe Prozess Ihr normaler Login-Benutzer. Root im Container ist nicht root auf dem Host.

Das ist der tatsächliche Umfang des Sicherheitsgewinns. Ein Image, das zwingend als root läuft, eine Webanwendung mit einer Remote-Code-Execution-Schwachstelle oder ein Escape, der voraussetzt, dass der Prozess außerhalb des Containers UID 0 hat: In all diesen Fällen verfügt der Prozess nur über die Berechtigungen Ihres unprivilegierten Benutzers und nicht über die Berechtigungen des Systems. Rootless schützt Sie nicht vor Kernel-Bugs. Ihre eigenen Dateien sind ebenfalls nicht geschützt, weil der entwichene Prozess als Sie läuft und alles lesen kann, was auch Sie lesen können. Die Isolierung der Unit ist mindestens ebenso wichtig wie die UID-Zuordnung. Das lässt sich als Nächstes an einem FreeBSD-Jail, das eine komplette Userland-Umgebung kapselt, die Sie wie eine kleine Maschine verwalten leichter erkennen als an einem geschichteten Image, das aus einer Registry abgerufen wurde.

Auch Docker kann rootless ausgeführt werden. dockerd-rootless-setuptool.sh install richtet einen Daemon pro Benutzer ein, und das funktioniert gut. Der Unterschied liegt in der Standardausrichtung. Mit Podman erhalten Sie rootless ohne zusätzliche Anforderung. Ihr erster Fehler ist daher ein Container, der Port 80 nicht binden kann, und nicht ein Dienst, der zwei Jahre lang unbemerkt als root lief.

Warum gehören meine Volume-Dateien UID 100999?

Das liegt an demselben User Namespace. Container-UID 0 wird auf Ihre Host-UID abgebildet. Container-UID 1 wird auf die erste ID in Ihrem subuid-Bereich abgebildet. Danach werden die IDs fortlaufend erhöht. Beginnt der Bereich bei 100000, entspricht Container-UID 1000 auf dem Host der UID 100999.

mkdir -p "$PWD/data"
podman run --rm --user 1000 -v "$PWD/data:/data" docker.io/library/alpine:3 sh -c 'id -u; touch /data/f'
ls -ln "$PWD/data"

Der Container gibt 1000 aus. In der Host-Auflistung steht als Eigentümer 100999, weil 100000 plus 1000 minus 1 100999 ergibt. Das ist kein Fehler. Ein einfaches chown behebt das Problem nicht, weil Ihr unprivilegierter Benutzer außerhalb des Namespace keine Dateieigentümer ändern darf.

Es gibt vier Möglichkeiten:

• podman unshare chown 1000:1000 "$PWD/data" führt chown im selben User Namespace aus. Dort haben die Nummern die Bedeutung, die sie für den Container haben.
• -v "$PWD/data:/data:U" weist Podman an, den Eigentümer des Quellverzeichnisses für Sie zu korrigieren. Verwenden Sie das bei einem neuen Verzeichnis, nicht bei Daten, die Sie benötigen.
• --userns=keep-id bildet Ihre Host-UID auf dieselbe UID im Container ab. Neu erstellte Dateien gehören dann Ihnen.
• Ein benanntes Volume wie -v appdata:/data vermeidet das Problem. Podman erstellt es in Ihrem eigenen Speicher und setzt den Eigentümer dort bereits korrekt.

Wenn Sie dieses Problem bereits mit Docker hatten, handelt es sich um dasselbe Problem auf einer zusätzlichen Abstraktionsebene. Die Variablen PUID und PGID, die viele Images bereitstellen legen die UID fest, die der Prozess im Container verwendet. Unter rootless Podman wird diese UID anschließend ein zweites Mal abgebildet. PUID=1000 schreibt innerhalb eines rootless Containers weiterhin Host-Dateien, die UID 100999 gehören. Berücksichtigen Sie diese zweite Abbildung bei der Auswahl der Nummern. Alternativ verschieben Sie die Daten in ein benanntes Volume und müssen sich darum nicht mehr kümmern.

Zwei weitere Hinweise zu Mounts: Die Flags :z und :Z, die Sie in Beispielen für Fedora und RHEL sehen, sind Optionen zur SELinux-Neubeschriftung. Ubuntu verwendet AppArmor, daher haben diese Flags dort keine Wirkung. Rootless Podman kann außerdem kein Host-Verzeichnis mounten, das Ihr Benutzer nicht lesen darf. Das ist beabsichtigt und kein Fehler.

Warum verweigert rootless Podman die Veröffentlichung von Port 80?

Weil das Binden eines Ports unter 1024 ein Privileg erfordert, das Ihr Benutzer nicht besitzt. Die Fehlermeldung nennt die Lösung:

Error: rootlessport cannot expose privileged port 80, you can add 'net.ipv4.ip_unprivileged_port_start=80' to /etc/sysctl.conf (currently 1024), or choose a larger port number (>= 1024): listen tcp 0.0.0.0:80: bind: permission denied

Beide Ansätze funktionieren. Sie können den Schwellenwert für den gesamten Host herabsetzen:

echo 'net.ipv4.ip_unprivileged_port_start=80' | sudo tee /etc/sysctl.d/99-podman.conf
sudo sysctl --system
sysctl net.ipv4.ip_unprivileged_port_start

Der letzte Befehl sollte 80 ausgeben. Machen Sie sich klar, was diese Einstellung bewirkt: Jeder Benutzer auf dem Rechner kann nun Port 80 und 443 binden, nicht nur der Benutzer, unter dem Container ausgeführt werden. Auf einem VPS mit einem einzigen Administrator ist dieser Kompromiss vertretbar. Auf einem System mit Konten anderer Benutzer ist er es nicht. Der andere Ansatz besteht darin, Port 8080 zu veröffentlichen und einen Reverse Proxy davorzuschalten. Dort sollen ohnehin von certbot auf nginx ausgestellte und erneuerte Zertifikate verwendet werden.

Die Veröffentlichung im rootless-Modus verändert außerdem, was Ihre Anwendung sieht. Podman 4.x verwendet standardmäßig slirp4netns mit dem rootlesskit-Port-Handler. Weitergeleitete Verbindungen treffen daher mit einer geänderten Quelladresse ein, und das Access-Log zeichnet jeden Besucher als 10.0.2.100 auf. Podman 5.0 änderte den Standard auf pasta. Dadurch bleibt die echte Clientadresse erhalten. Unter 4.x stellt --network slirp4netns:port_handler=slirp4netns die ursprüngliche Quelladresse wieder her, allerdings mit Einbußen beim Durchsatz.

Hier gibt es eine erfreuliche Besonderheit. Ein veröffentlichter Port im rootless-Modus ist ein gewöhnlicher Listening-Socket, der einem normalen Prozess gehört. Daher gelten die Eingangsregeln Ihrer Firewall für ihn. Docker veröffentlicht Ports, indem es NAT-Regeln (Network Address Translation) sowie eigene Accept-Regeln für die Weiterleitung schreibt. Genau deshalb ignoriert ein veröffentlichter Docker-Port die ufw-Regel, von der Sie dachten, dass sie ihn blockiert. Rootful Podman verwendet eine ähnliche Netzwerkanbindung und unterliegt derselben Falle. Rootless nicht.

Funktionieren meine Docker-Compose-Dateien weiterhin mit Podman?

Meistens ja, und zwar über zwei verschiedene Wege. Der erste ist podman-compose, eine separate Implementierung, die dieselbe Datei einliest und die Podman-CLI steuert:

sudo apt install -y podman-compose
podman-compose up -d
podman ps

Der zweite ist das echte Docker Compose, das über einen benutzerbezogenen Socket mit der Docker-kompatiblen API von Podman kommuniziert:

systemctl --user enable --now podman.socket
export DOCKER_HOST="unix:///run/user/$(id -u)/podman/podman.sock"
docker compose up -d
podman ps

docker compose ps und podman ps sollten dieselben Container auflisten, weil nur ein gemeinsamer Containersatz vorhanden ist. Auch die Namensauflösung funktioniert: Podmans standardmäßiges Netzwerk-Backend netavark führt aardvark-dns aus. Dadurch finden sich Container in einem benutzerdefinierten Netzwerk über ihren Namen.

Die Einschränkungen sind real. Alles, was /var/run/docker.sock mountet, muss auf den Podman-Socket verweisen oder entfernt werden. network_mode: host verhält sich innerhalb eines User Namespaces anders. depends_on mit condition: service_healthy wird von den verschiedenen podman-compose-Versionen uneinheitlich unterstützt. restart: always übersteht einen Reboot nicht selbstständig, was im nächsten Abschnitt behoben wird. Compose bleibt eine gute Möglichkeit, einen Stack mit mehreren Containern in einer einzigen Datei zu beschreiben, und dient unter Podman als Übersetzungsschicht. Wenn Sie einen Stack über Jahre betreiben möchten, konvertieren Sie ihn in Quadlets und pflegen Sie nur eine Abstraktion statt zwei.

Pods: Das Konzept, für das Docker keine Lösung bietet

Ein Pod ist eine Gruppe von Containern, die sich denselben Netzwerk-Namespace teilen. Podman startet einen kleinen infra-Container, der diesen Namespace offen hält. Die Mitglieder erreichen sich anschließend über 127.0.0.1, ohne benutzerdefiniertes Netzwerk und ohne Service Discovery.

podman pod create --name app -p 8080:80
podman run -d --pod app --name app-cache docker.io/library/redis:7
podman run -d --pod app --name app-web docker.io/library/nginx:1.27
podman pod ps
podman ps --pod

podman pod ps sollte den Pod Running mit drei Containern anzeigen, einschließlich des Infra-Containers. Der Web-Container erreicht Redis jetzt unter 127.0.0.1:6379 statt unter app-cache:6379. Aus dem gemeinsamen Namespace ergeben sich zwei Regeln: Veröffentlichen Sie Ports am Pod und niemals an einem Mitglied. Außerdem darf kein Port von zwei Mitgliedern gleichzeitig verwendet werden.

Das ist das Kubernetes-Modell, und Podman unterstützt es konsequent. podman kube generate app > app.yaml erstellt aus dem aktuellen Zustand ein Kubernetes-Manifest. In älteren Paketen lautet der Befehl podman generate kube. podman kube play app.yaml stellt dieses Manifest auf einem anderen Host wieder her. Quadlet verfügt über einen .kube-Unit-Typ, der eine solche Datei als systemd-Dienst ausführt. Das ist eine grundsätzlich andere Möglichkeit, Dienste zu gruppieren. Es ist der wichtigste Grund, Podman zu wählen, wenn Kubernetes künftig eine Rolle spielen könnte.

Autostart ohne Daemon: quadlet-Units

Quadlet ist ein systemd-Generator. Er wandelt eine kurze Datei mit der Beschreibung eines Containers beim Booten in einen echten systemd-Dienst um. Dateien werden für einen rootless Benutzer in ~/.config/containers/systemd/ und für root in /etc/containers/systemd/ abgelegt.

~/.config/containers/systemd/caddy.container:

[Unit]
Description=Caddy web server
After=network-online.target

[Container]
Image=docker.io/library/caddy:2
ContainerName=caddy
PublishPort=8080:80
Volume=caddy-data.volume:/data
Environment=TZ=UTC
AutoUpdate=registry

[Service]
Restart=always
MemoryMax=512M

[Install]
WantedBy=default.target

~/.config/containers/systemd/caddy-data.volume kann fast leer sein, weil der Abschnittsheader das Volume erstellt:

[Volume]

systemctl --user daemon-reload
systemctl --user start caddy
systemctl --user status caddy
journalctl --user -u caddy -n 50

Der Dienstname stammt aus dem Dateinamen: Aus caddy.container wird caddy.service. Führen Sie systemctl --user enable caddy nicht aus. Generierte Units können nicht aktiviert werden, und systemd antwortet mit Failed to enable unit: Unit /run/user/1000/systemd/generator/caddy.service is transient or generated.. Der Abschnitt [Install] startet den Container beim Booten. daemon-reload generiert die Unit neu, nachdem Sie die Datei bearbeitet haben.

Nun zu der Einstellung, die fast immer übersehen wird:

sudo loginctl enable-linger deploy
loginctl show-user deploy --property=Linger

Rechnen Sie mit Linger=yes. Ohne Linger beendet systemd die gesamte Benutzersitzung, sobald Ihre letzte SSH-Verbindung geschlossen wird. Dadurch werden auch alle rootless Container beendet, und beim Booten startet keiner von ihnen erneut. Container, die beim Abmelden verschwinden, sind immer darauf zurückzuführen.

Da der Container der Hauptprozess einer gewöhnlichen Service-Unit ist, gelten die systemd-eigenen Steuerungsmöglichkeiten direkt. MemoryMax= und CPUQuota= im Abschnitt [Service] verhalten sich genauso wie bei jedem anderen Dienst, den Sie mit systemd begrenzen. Dafür ist cgroup v2 (Control-Group-Version 2) erforderlich. Ubuntu verwendet diese Version seit 22.04 standardmäßig. Prüfen Sie dies mit podman info | grep -i cgroup.

Für Updates gibt es einen passenden Mechanismus. AutoUpdate=registry zusammen mit systemctl --user enable --now podman-auto-update.timer prüft die Registry auf ein neueres Image unter demselben Tag, startet die Unit neu und führt ein Rollback auf das vorherige Image durch, wenn der neue Container nicht gestartet werden kann. Führen Sie zuerst podman auto-update --dry-run aus, um die geplanten Änderungen anzuzeigen. Der ältere Befehl podman generate systemd ist weiterhin vorhanden, aber veraltet. Verwenden Sie daher für neue Konfigurationen Quadlets.

Wo der docker-Alias funktioniert und wo nicht

sudo apt install -y podman-docker
sudo touch /etc/containers/nodocker
docker ps

podman-docker installiert einen /usr/bin/docker-Wrapper, der Podman aufruft. Ohne die Datei nodocker gibt jeder Aufruf zuerst Emulate Docker CLI using podman. Create /etc/containers/nodocker to quiet msg. aus. Der Wrapper deckt die Befehle ab, die Sie täglich verwenden: run, ps, logs, exec, build, pull, push, inspect, cp, volume, network.

Was nicht übernommen wird, ist eine kürzere und eindeutigere Liste. Für den Swarm-Modus gibt es kein Äquivalent. Daher gibt es für einen Swarm-Stack kein Zielsystem. Tools, die mit dem Docker-Socket kommunizieren, benötigen einen exportierten Podman-Socket. Einige erkennen den Unterschied trotzdem. Der Docker-Provider von Traefik funktioniert, wenn er auf /run/user/<uid>/podman/podman.sock zeigt. Watchtower kann dagegen nicht eingesetzt werden, weil podman auto-update diese Aufgabe übernimmt. Der Speicher ist getrennt. Podman kann daher Images, die Sie bereits mit Docker geladen haben, nicht sehen. podman images auf einem ausgelasteten Docker-Host ist anfangs leer.

Laufenden Stack Schritt für Schritt migrieren

1. Erstellen Sie den nicht privilegierten Benutzer, dem die Container gehören sollen, oder wählen Sie einen vorhandenen aus. Stellen Sie sicher, dass ihm in /etc/subuid ein Bereich zugewiesen ist.
2. Laden Sie alle Images, die aus einer Registry stammen, erneut herunter. Verwenden Sie vollständig qualifizierte Namen. Podman verfügt über einen eigenen Image-Speicher und liest den Docker-Speicher nicht.
3. Übertragen Sie lokal erstellte Images mit docker save app:1.4 | podman load.
4. Stoppen Sie den Docker-Container. Kopieren Sie den Inhalt jedes Volumes aus /var/lib/docker/volumes/<name>/_data heraus. Korrigieren Sie anschließend die Eigentümer mit podman unshare chown -R 1000:1000 <path>.
5. Legen Sie fest, wie Sie mit den Ports umgehen: Veröffentlichen Sie Ports oberhalb von 1024 hinter einem Reverse Proxy oder setzen Sie net.ipv4.ip_unprivileged_port_start.
6. Schreiben Sie für jeden Container eine Quadlet-Datei, führen Sie systemctl --user daemon-reload aus und starten Sie jeden Dienst.
7. Führen Sie sudo loginctl enable-linger <user> aus, starten Sie die VPS neu, melden Sie sich wieder an und prüfen Sie, ob podman ps erneut alle Dienste auflistet.

Die beiden Engines haben keine gemeinsamen Ressourcen: Der Image-Speicher und die Netzwerke sind getrennt. Sie können daher beide Engines während der Migration ausführen. Sie können sich nur um eine Portnummer auf dem Host in die Quere kommen. Migrieren Sie einen Dienst, beobachten Sie ihn einen Tag lang und migrieren Sie anschließend den nächsten.

Podman vs Docker: Was gehört auf Ihren VPS?

Bleiben Sie bei Docker, wenn Ihr Stack in Compose-Dateien lebt, die auch andere Personen pflegen, oder wenn Sie von Werkzeugen abhängen, die mit dem Docker-Socket kommunizieren. Die Kompatibilität mit dem, was alle anderen schreiben, ist ein echter Vorteil, und Docker bietet davon mehr. Ein Team, auf dessen Laptops überall Docker läuft, profitiert außerdem konkret davon, in der Produktion dieselbe Engine zu verwenden.

Wechseln Sie zu Podman, wenn auf dem VPS nur einige wenige Dienste laufen, die Sie vollständig kontrollieren, oder wenn Sie jede Anwendung unter einem eigenen unprivilegierten Benutzer ausführen möchten und auf dem System überhaupt keine docker-Gruppe benötigen. Auch die Ausrichtung an der Distribution ist relevant: RHEL und dessen Rebuilds liefern Podman als unterstützte Engine aus. Auf diesen Systemen ist Podman daher der Weg mit weniger Überraschungen. Wenn Sie auf einem dieser Hosts trotzdem Docker verwenden möchten, beginnt der dnf-Weg auf Rocky Linux und AlmaLinux damit, den podman-docker-Wrapper zu entfernen, der dort bereits den Befehl docker bereitstellt. Wenn Sie alle anderen Komponenten bereits mit systemd-Units verwalten, wirken Quadlets eher wie ein fehlendes Teil, das ergänzt wird, als wie ein neues Werkzeug, das Sie erst erlernen müssen.

Eine Zwischenlösung sollte erwähnt werden. Rootful Podman verhält sich weitgehend wie Docker, behält den Befehl docker über den Wrapper bei und entfernt trotzdem den dauerhaft laufenden Daemon. Gleichzeitig verzichten Sie damit auf den Rootless-Anteil. Dieser verändert Ihre Sicherheitslage wesentlich. Betrachten Sie Rootful Podman daher als Zwischenstation.

Wenn Sie Ihren ersten Container-Host noch einrichten, ist der Weg zur Einrichtung und Absicherung von Docker auf einem frischen VPS kürzer. Das dabei erworbene Wissen bleibt trotzdem vollständig nutzbar. Images und Volumes sind unter beiden Engines dieselben Objekte. Ein späterer Wechsel verändert daher vor allem die Verwaltung Ihrer Dienste und nur sehr wenig mehr.

FAQ

Ist Podman ein direkter Ersatz für Docker?

Bei den eingegebenen Befehlen weitgehend. Die Installation von podman-docker stellt einen /usr/bin/docker-Wrapper bereit, und run, ps, build, logs und exec verhalten sich gleich. Podman ersetzt den Daemon nicht. Für Swarm gibt es kein Äquivalent. Tools, die eine Verbindung zu /var/run/docker.sock herstellen, müssen stattdessen auf den benutzerbezogenen Podman-Socket zeigen. Von Docker abgerufene Images bleiben für Podman unsichtbar, weil beide getrennte Speicher verwenden.

Warum werden meine rootless Podman-Container beendet, wenn ich mich von SSH abmelde?

Weil systemd die Benutzersitzung und damit alle zugehörigen Benutzerdienste beendet, sobald die letzte Anmeldung geschlossen wird. Führen Sie sudo loginctl enable-linger <user> aus. Prüfen Sie anschließend, ob loginctl show-user <user> --property=Linger den Wert Linger=yes ausgibt. Linger hält die systemd-Instanz dieses Benutzers ohne aktive Sitzung am Laufen. Dadurch werden die Container auch nach einem Reboot wieder gestartet.

Warum gehören die Dateien in meinem Volume UID 100999?

Rootless Podman ordnet Container-UID 0 Ihrem Host-Benutzer zu. Container-UID 1 und höhere Werte werden anschließend auf Ihren subuid-Bereich abgebildet. Bei einem Bereich, der bei 100000 beginnt, wird Container-UID 1000 auf dem Host zu 100999. Korrigieren Sie die Eigentümer innerhalb des Namespace mit podman unshare chown 1000:1000 /path/to/data. Verwenden Sie beim ersten Start das :U-Flag für den Mount. Alternativ können Sie --userns=keep-id verwenden, damit die Container-UIDs Ihren eigenen entsprechen.

Kann ich docker-compose.yml weiterhin mit Podman verwenden?

Ja, auf zwei Arten. podman-compose liest die Datei ein und steuert die Podman-CLI direkt. Alternativ aktivieren Sie den Kompatibilitäts-Socket mit systemctl --user enable --now podman.socket, setzen DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock und führen echtes docker compose dagegen aus. Bei network_mode: host, bei Diensten, die den Docker-Socket mounten, und bei restart: always müssen Sie mit Einschränkungen rechnen. restart: always benötigt eine quadlet-Unit und Linger, damit es einen Reboot übersteht.

Macht rootless Container wirklich sicherer?

Es beseitigt ein bestimmtes Risiko: Wenn ein Prozess aus einem rootless Container ausbricht, verfügt er über die Berechtigungen Ihres nicht privilegierten Benutzers und nicht über root-Berechtigungen. Das ist ein wichtiger Vorteil. Deshalb gibt es unter rootless Podman auch kein Gegenstück zur root-äquivalenten Gruppe docker. Kernel-Schwachstellen werden dadurch nicht verhindert. Dateien, die Ihr eigener Benutzer lesen kann, sind ebenfalls nicht geschützt. Führen Sie deshalb weiterhin die übrigen Härtungsmaßnahmen durch, die Sie auf jedem Server umsetzen würden.