Podman oder Docker auf dem VPS: Die echten Unterschiede

Was sich zwischen Podman und Docker tatsächlich unterscheidet

Podman und Docker führen auf einem VPS dieselben OCI-Images (Open Container Initiative) aus. Die Wahl hängt daher nicht davon ab, welche Software Sie ausführen können. Der Unterschied liegt im Prozessmodell. Docker verwendet einen Daemon mit root-Rechten, 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 untergeordneten Prozess des aufrufenden Prozesses und verwendet dabei Ihren eigenen unprivilegierten Benutzer.

Alle weiteren Unterschiede ergeben sich aus dieser einen Tatsache. Für den automatischen Start ist systemd zuständig, nicht der Daemon. Die Eigentümer von Volumes werden durch einen User-Namespace abgebildet. Daher ist der Eigentümer, den Sie mit ls -l auf dem Host sehen, nicht derselbe Eigentümer, den der Container sieht. Ports unter 1024 können erst gebunden werden, wenn Sie eine Kernel-Einstellung ändern. Die docker-CLI (Befehlszeilenschnittstelle) funktioniert über einen Wrapper weiterhin, bis eine Komponente den Docker-Socket benötigt.

Kein Daemon: Was beim Starten eines Containers tatsächlich ausgeführt wird

Auf einem Docker-Host zeigt pstree -a dockerd als root, daneben containerd und für jeden laufenden Container ein containerd-shim-runc-v2 an. 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 Ihre Container ebenfalls neu.

Podman hat keinen entsprechenden Prozess. Wenn Sie einen Container starten, erhalten Sie 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, das unter Ihrem Anmeldebenutzer und nicht als root ausgeführt wird. curl sollte 200 ausgeben. Da kein zentraler Dienst den Container besitzt, stoppt sudo apt upgrade podman nichts, was bereits ausgeführt wird. Außerdem kann der Absturz des Monitors eines Containers die anderen Container nicht mitreißen.

Der fehlende Daemon hat jedoch auch Nachteile. Nach einem Reboot startet nichts Ihre Container. Docker's --restart=always ist ein Versprechen, das der Daemon beim Booten einlöst. Podman ersetzt es durch systemd. Dafür ist der folgende Abschnitt zu Quadlet 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 über einen indirekten Weg root-Rechte. Lesen Sie dazu auch jedem Dienstkonto nur den benötigten Zugriff gewähren. Podman stellt keinen Socket bereit, sofern Sie dies nicht ausdrücklich 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-Container tatsächlich rootless sind

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 gewöhnlicher Benutzer einen Bereich untergeordneter IDs beanspruchen kann. 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. Dies wurde im August 2026 geprüft. Der Unterschied ist relevant, weil Quadlet-Dateien mindestens Version 4.4 benötigen und .pod-Quadlet-Dateien Version 5.0 voraussetzen. 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 mit einem Konfigurationswerkzeug erstellter Benutzer erhält häufig keinen Bereich. Die Fehlermeldung 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 und 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 Docker Hub nicht automatisch. 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. Diese Kernel-Funktion weist einem Prozess eine eigene Zuordnung von Benutzer-IDs zu. Innerhalb des Namespace ist der Superuser des Containers die 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 Vorteils. Ein Image, das zwingend als root ausgeführt werden muss, eine Webanwendung mit einer Sicherheitslücke für Remote Code Execution oder ein Escape, das außerhalb des Containers die UID 0 voraussetzt: In all diesen Fällen erhält der Prozess die Berechtigungen Ihres unprivilegierten Benutzers und nicht die der Maschine. Rootless schützt Sie nicht vor Kernel-Bugs. Ihre eigenen Dateien schützt es ebenfalls nicht, weil der entwichene Prozess als Sie läuft und alles lesen kann, worauf Sie selbst lesenden Zugriff haben.

Docker kann ebenfalls rootless ausgeführt werden. dockerd-rootless-setuptool.sh install richtet einen Daemon pro Benutzer ein und funktioniert zuverlässig. Der Unterschied liegt in der Voreinstellung. Mit Podman verwenden Sie rootless ohne zusätzliche Aktivierung. Ihr erster Fehler ist daher ein Container, der Port 80 nicht binden kann, statt eines Dienstes, 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 Ihrer Host-UID zugeordnet. Container-UID 1 wird der ersten ID in Ihrem subuid-Bereich zugeordnet. Die Zuordnung zählt von dort aus aufwärts. Bei einem Bereich, der bei 100000 beginnt, wird Container-UID 1000 auf dem Host zu 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. Die Auflistung auf dem Host zeigt den Besitzer 100999, weil 100000 plus 1000 minus 1 100999 ergibt. Es ist nichts defekt. Ein einfaches chown behebt das Problem nicht, weil Ihr unprivilegierter Benutzer außerhalb des Namespace keine Dateibesitzer ändern kann.

Es gibt vier Möglichkeiten:

• podman unshare chown 1000:1000 "$PWD/data" führt chown innerhalb desselben User-Namespace aus. Dort haben die Nummern die Bedeutung, die sie im Container haben.
• -v "$PWD/data:/data:U" weist Podman an, den Besitz des Quellverzeichnisses für Sie zu korrigieren. Verwenden Sie das bei einem neuen Verzeichnis, nicht bei Daten, die Sie benötigen.
• --userns=keep-id ordnet Ihre Host-UID derselben UID innerhalb des Containers zu. Neue Dateien gehören dann Ihnen.
• Ein benanntes Volume wie -v appdata:/data vermeidet das Problem, weil Podman es in Ihrem eigenen Speicher mit den bereits korrekten Besitzrechten erstellt.

Wenn Sie dieses Problem bereits mit Docker hatten, handelt es sich um dasselbe Problem auf einer weiteren Abstraktionsebene. Die Variablen PUID und PGID, die viele Images bereitstellen legen die UID fest, die der Prozess innerhalb des Containers verwendet. Unter rootless Podman wird diese UID anschließend ein zweites Mal zugeordnet. PUID=1000 in einem rootless Container schreibt weiterhin Host-Dateien, die UID 100999 gehören. Wählen Sie die Nummern unter Berücksichtigung dieser zweiten Zuordnung, oder 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 Fedora- und RHEL-Beispielen sehen, sind Optionen für die SELinux-Neukennzeichnung. Ubuntu verwendet AppArmor, daher haben sie dort keine Wirkung. Rootless Podman kann außerdem kein Host-Verzeichnis mounten, das Ihr Benutzer nicht lesen kann. Das ist beabsichtigt und kein Fehler.

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

Das Binden eines Ports unter 1024 erfordert ein Privileg, 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

Es gibt zwei funktionierende Antworten. Senken Sie den Schwellenwert für den gesamten Host:

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 dann Port 80 und 443 binden, nicht nur der Benutzer, unter dem Container ausgeführt werden. Auf einem VPS, der von einem einzelnen Administrator verwaltet wird, ist das ein vertretbarer Kompromiss. Auf einem System mit Konten anderer Benutzer ist das nicht vertretbar. Die andere Möglichkeit besteht darin, Port 8080 zu veröffentlichen und einen Reverse Proxy davorzusetzen. Dort sollen von certbot in nginx ausgestellte und erneuerte Zertifikate ohnehin verwaltet werden.

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

Es gibt hier eine erfreuliche Besonderheit. Ein im rootless-Modus veröffentlichter Port ist ein gewöhnlicher Listening-Socket, der einem normalen Prozess gehört. Daher gelten die eingehenden Firewall-Regeln auch für diesen Port. Docker veröffentlicht Ports, indem es NAT-Regeln (Network Address Translation) und eigene Accept-Regeln für die Weiterleitung schreibt. Genau deshalb ignoriert ein veröffentlichter Docker-Port die ufw-Regel, die ihn Ihrer Annahme nach blockieren sollte. Rootful Podman verwendet eine ähnliche Netzwerkverwaltung und hat dieselbe Schwachstelle. Für rootless Podman gilt das nicht.

Funktionieren meine Docker-Compose-Dateien weiterhin mit Podman?

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

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

Der zweite ist echtes 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 es nur einen Containersatz gibt. Auch die Namensauflösung funktioniert: Das Standard-Netzwerk-Backend von Podman, netavark, führt aardvark-dns aus. Dadurch finden Container in einem benutzerdefinierten Netzwerk einander über ihren Namen.

Die Einschränkungen sind jedoch real. Alles, was /var/run/docker.sock einbindet, muss auf den Podman-Socket verwiesen werden oder entfallen. network_mode: host verhält sich unter einem User Namespace 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; der nächste Abschnitt behebt dieses Problem. Compose bleibt eine gute Möglichkeit, einen Stack mit mehreren Containern in einer einzigen Datei zu beschreiben. Unter Podman dient es als Übersetzungsschicht. Wenn Sie einen Stack voraussichtlich über Jahre betreiben, konvertieren Sie ihn in Quadlets und verwalten 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 einen Netzwerk-Namespace teilen. Podman startet einen kleinen infra-Container, um diesen Namespace offen zu halten. Die enthaltenen Container erreichen einander 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 folgen zwei Regeln: Ports werden am Pod und niemals an einem Mitglied veröffentlicht, und kein Mitglied darf auf demselben Port lauschen wie ein anderes.

Das ist das Kubernetes-Modell, und Podman setzt konsequent darauf. podman kube generate app > app.yaml erstellt aus dem laufenden Zustand ein Kubernetes-Manifest. In älteren Paketen heißt der Befehl podman generate kube. podman kube play app.yaml stellt den Zustand auf einem anderen Host wieder her. Quadlet verfügt über einen .kube-Unit-Typ, der eine solche Datei als systemd-Dienst ausführt. Dies ist eine grundlegend andere Methode, Dienste zu gruppieren. Es ist der wichtigste Grund, Podman zu wählen, wenn Kubernetes künftig eine Rolle spielen könnte.

Automatischer Start ohne Daemon: quadlet-Units

Quadlet ist ein systemd-Generator. Er wandelt eine kurze Datei mit der Containerbeschreibung beim Systemstart in einen vollständigen systemd-Dienst um. Dateien für einen Rootless-Benutzer gehören nach ~/.config/containers/systemd/, Dateien für root nach /etc/containers/systemd/.

~/.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, da der Abschnitts-Header das Volume erstellt:

[Volume]

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

Der Dienstname ergibt sich aus dem Dateinamen: caddy.container wird zu 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 Systemstart, und daemon-reload regeneriert die Unit, nachdem Sie die Datei bearbeitet haben.

Nun zu der Einstellung, die fast alle übersehen:

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 Systemstart wird keiner von ihnen erneut gestartet. Container, die beim Abmelden verschwinden, sind immer auf dieses Problem zurückzuführen.

Da der Container der Hauptprozess einer normalen Service-Unit ist, gelten die eigenen Steuerungsmöglichkeiten von systemd direkt. MemoryMax= und CPUQuota= im Abschnitt [Service] verhalten sich genau 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 mit demselben Tag, startet die Unit neu und stellt das vorherige Image wieder her, wenn der neue Container nicht gestartet werden kann. Führen Sie zuerst podman auto-update --dry-run aus, um zu sehen, welche Änderungen vorgenommen würden. Der ältere Befehl podman generate systemd ist weiterhin vorhanden, gilt aber als 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 zunächst 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 klarer abgegrenzte Liste. Für den Swarm-Modus gibt es kein Äquivalent. Ein Swarm-Stack kann daher nicht bereitgestellt werden. 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 verweist. Für Watchtower gibt es dagegen keine Entsprechung, weil podman auto-update diese Aufgabe übernimmt. Der Speicher ist getrennt. Podman kann daher keine Images sehen, die Sie bereits mit Docker abgerufen haben. podman images ist auf einem ausgelasteten Docker-Host zunächst leer.

Migration eines laufenden Stacks, Schritt für Schritt

1. Erstellen oder wählen Sie den unprivilegierten Benutzer, dem die Container gehören sollen, und prüfen Sie, ob ihm in /etc/subuid ein Bereich zugewiesen ist.
2. Laden Sie alle Images, die aus einer Registry stammen, mit vollständig qualifizierten Namen erneut herunter. Podman verwendet 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 und korrigieren Sie anschließend die Eigentümer mit podman unshare chown -R 1000:1000 <path>.
5. Klären Sie die Port-Frage: Veröffentlichen Sie Ports oberhalb von 1024 hinter einem Reverse Proxy oder setzen Sie net.ipv4.ip_unprivileged_port_start.
6. Schreiben Sie eine Quadlet-Datei pro Container, 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 jeden Dienst auflistet.

Die beiden Engines verwenden nichts gemeinsam: weder den Image-Speicher noch die Netzwerke. Daher können Sie beide während der Migration ausführen. Der einzige mögliche Konflikt betrifft eine Portnummer des Hosts. Verschieben Sie jeweils einen Dienst, überwachen Sie ihn einen Tag lang und verschieben 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 definiert ist, die auch von anderen gepflegt werden, oder wenn Sie auf Werkzeuge angewiesen sind, die mit dem Docker-Socket kommunizieren. Die Kompatibilität mit den Konfigurationen, die alle anderen verwenden, 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 einzusetzen.

Wechseln Sie zu Podman, wenn auf dem VPS nur einige wenige Dienste laufen, die Sie vollständig selbst kontrollieren, oder wenn jede Anwendung unter einem eigenen unprivilegierten Benutzer laufen soll und es auf dem System überhaupt keine docker-Gruppe geben soll. Auch die Ausrichtung der Distribution ist relevant: RHEL und seine kompatiblen Derivate liefern Podman als unterstützte Engine aus. Auf diesen Systemen ist Podman daher der Weg mit weniger Überraschungen. Wenn Sie alles andere bereits mit systemd-Units überwachen, wirken Quadlets wie ein fehlendes Puzzleteil, das hinzukommt, und nicht wie ein neues Werkzeug, das Sie erst lernen müssen.

Eine Zwischenlösung ist ebenfalls erwähnenswert. Rootful Podman verhält sich ähnlich wie Docker, stellt den docker-Befehl über den Wrapper bereit und entfernt trotzdem den ständig laufenden Daemon. Dabei entfällt jedoch der Rootless-Anteil. Genau dieser verändert Ihre Sicherheitslage. Betrachten Sie Rootful Podman daher als Zwischenstation.

Wenn Sie Ihren ersten Container-Host noch einrichten, ist der Pfad zur Einrichtung und Absicherung von Docker auf einem neuen VPS der kürzere Weg. Das dabei erworbene Wissen bleibt vollständig nutzbar. Images und Volumes sind unter beiden Engines dieselben Objekte. Bei einem späteren Wechsel ändert sich daher vor allem, wie Ihre Dienste überwacht werden, und nur sehr wenig anderes.

FAQ

Ist Podman ein Drop-in-Ersatz für Docker?

Bei den Befehlen, die Sie eingeben, kommt das weitgehend hin. Die Installation von podman-docker stellt einen /usr/bin/docker-Wrapper bereit, und run, ps, build, logs und exec verhalten sich gleich. Podman ersetzt jedoch nicht den Daemon. Für Swarm gibt es kein entsprechendes Gegenstück. Tools, die eine Verbindung zu /var/run/docker.sock herstellen, müssen stattdessen auf den Podman-Socket des jeweiligen Benutzers zeigen. Von Docker abgerufene Images bleiben für Podman unsichtbar, weil beide getrennten Speicher verwenden.

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

Weil systemd die Benutzersitzung und damit alle darin laufenden Benutzerdienste beendet, sobald Ihre letzte Anmeldung geschlossen wird. Führen Sie sudo loginctl enable-linger <user> aus und 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 auch ohne aktive Sitzung am Laufen. Dadurch werden die Container nach einem Reboot ebenfalls wieder gestartet.

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

Rootless Podman ordnet die Container-UID 0 Ihrem Benutzer auf dem Host zu. Danach werden die Container-UIDs ab 1 auf Ihren subuid-Bereich abgebildet. Bei einem Bereich, der bei 100000 beginnt, wird die Container-UID 1000 auf dem Host zu 100999. Korrigieren Sie die Eigentümer aus dem Namespace heraus 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 UIDs entsprechen.

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

Ja, auf zwei Arten. podman-compose liest die Datei und steuert die Podman CLI direkt. Oder aktivieren Sie den Kompatibilitäts-Socket mit systemctl --user enable --now podman.socket, setzen Sie DOCKER_HOST=unix:///run/user/$(id -u)/podman/podman.sock und führen Sie das echte docker compose dagegen aus. Mit Einschränkungen müssen Sie bei network_mode: host, bei Diensten, die den Docker-Socket mounten, und bei restart: always rechnen. Dafür benötigen Sie eine Quadlet-Unit und Linger, damit der Dienst 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 die von root. Das ist sinnvoll. Deshalb gibt es unter rootless Podman auch keine Entsprechung zur root-äquivalenten Gruppe docker. Rootless verhindert jedoch keine Kernel-Schwachstellen. Außerdem schützt es keine Dateien, die Ihr eigener Benutzer lesen kann. Führen Sie daher weiterhin die übrigen Härtungsmaßnahmen durch, die Sie auf jedem Server anwenden würden.