Podman of Docker: rootless beheer versus Compose

Voor een nieuwe self-hosted dienst op Linux past Podman goed als je containers onder een gewone gebruiker en zonder centrale daemon wilt beheren. Draait er al een stack met Docker Compose en hulpmiddelen die de Docker-socket verwachten, dan beperkt Docker doorgaans het migratiewerk. De Podman-handleiding beschrijft het daemonloze model, beheer onder gewone gebruikers en systemd-integratie via Quadlet.

Rootless draaien is geen exclusief voordeel van Podman: in Dockers rootless-modus draaien zowel de daemon als de containers zonder rootrechten. Die modus moet wel apart worden ingericht. De keuze voor een self-hosted Linux-host draait daarmee vooral om gebruikersrechten, het beheer van diensten en de afhankelijkheid van bestaande Compose-workflows.

Wat rootless verandert op een gedeelde Linux-host

Podman laat gebruikers containers beheren zonder dat iedere opdracht via één centrale daemon loopt. Images en opslag staan bij rootless gebruik standaard in de omgeving van de betreffende gebruiker. Op een gedeelde host maakt dat afzonderlijke serviceaccounts aantrekkelijk: beheerders hoeven voor hun eigen diensten geen toegang tot een gezamenlijke Docker-daemon te krijgen.

De grens van die scheiding ligt bij het hostaccount. Diensten die onder dezelfde Linux-gebruiker draaien, delen diens rechten op bestanden die voor dat account toegankelijk zijn. Bind mounts verdienen daarom evenveel aandacht als de runtime: een rootless container met toegang tot een gevoelige hostmap kan nog steeds bij de bestanden die zijn gebruiker daar mag openen.

Ook Docker kan onder een gewoon account draaien, maar daarvoor zijn onder meer subordinate gebruikers- en groeps-ID’s en een afzonderlijke rootless installatie nodig. Een bestaande systeemdaemon wordt daardoor niet vanzelf rootless; Docker laat met docker info zien met welke daemon de CLI verbonden is. Wie vooral vertrouwde Docker-opdrachten wil behouden, kan dus eerst beoordelen of rootless Docker bij de huidige hostindeling past.

Waarom Compose de overstap kan bepalen

Een Compose-bestand beschrijft niet alleen welke containers starten, maar ook hun netwerken, opslag, poorten en onderlinge samenhang. Bij Docker horen de runtime en de gebruikelijke Compose-workflow bij dezelfde omgeving. Het commando podman compose voert volgens de Podman-documentatie voor Compose een externe provider uit, zoals docker-compose of podman-compose, en laat die met de lokale Podman-socket communiceren.

Daarom zegt de aanwezigheid van het commando nog weinig over een specifieke stack. Welke provider is geïnstalleerd, welke Compose-functies gebruikt het bestand en welke hulpmiddelen spreken rechtstreeks met een Docker-socket? Een eenvoudige dienst met een volume en een gepubliceerde poort kan weinig aanpassing vergen. Builds, profielen en automatisering rond de socket maken een proef met de werkelijke configuratie belangrijker.

Voor bestaande applicaties telt ook de beheerkost na de overstap. Als installatie-instructies, updatescripts en CI-jobs op Docker Compose zijn ingericht, moet iemand afwijkingen in de Podman-provider blijven opvangen. Bij een nieuwe dienst zonder die afhankelijkheden weegt dat nadeel veel minder zwaar; Quadlet kan de container dan als systemd-dienst laten beheren.

Wat de metingen wel en niet laten zien

Docker en Podman hebben in de gepubliceerde test vrijwel gelijke warme starttijden, terwijl alleen Docker stationair daemon-geheugen gebruikt.

De gepubliceerde cijfers wijzen geen algemene snelheidswinnaar aan. In Botmonsters test op een Ryzen 9 5900X met Linux Mint 22.3 werden Docker Engine 29.5 in rootful modus en Podman 4.9.3 in rootless modus vergeleken: een warme Alpine-start duurde gemiddeld 352 tegenover 342 milliseconden, dockerd en containerd gebruikten zonder containers samen 144 MB geheugen, en de gemeten download via een gepubliceerde poort lag op 21–52 Gbit/s met Dockers bridge tegenover 60–65 Gbit/s met Podmans pasta-netwerk.

De starttijden liggen binnen de spreiding van deze test dicht bij elkaar. Het geheugencijfer vergelijkt stationaire daemonprocessen, niet het totale verbruik van draaiende diensten: ook Podman-containers en hun netwerkprocessen gebruiken geheugen. Het netwerkresultaat vergelijkt bovendien verschillende netwerkpaden én rootful met rootless gebruik. Daaruit volgt geen algemene uitspraak over de doorvoer van elke Docker- of Podman-installatie.

Voor een thuisserver is vooral de testopstelling leerzaam. De Podman-versie die een distributie levert, de gekozen rootless netwerkmodus en het aantal actieve containers kunnen de uitkomst veranderen. Een kleine besparing wanneer er geen containers draaien zegt bijvoorbeeld weinig over een server waarop de diensten voortdurend actief zijn. Prestaties zijn pas een doorslaggevend keuzecriterium als de eigen belasting en configuratie erop aansluiten.

Welke keuze past bij de omgeving?

Een thuisserver draait self-hosted diensten onder een gewoon Linux-gebruikersaccount.

Gedeelde Linux-host: Podman past bij afzonderlijke accounts die hun eigen containers en systemd-diensten beheren. Docker blijft logisch als er al een gecontroleerde Docker- en Compose-werkwijze is; rootless Docker kan dan een alternatief zijn. De toegang tot hostbestanden en beheersockets bepaalt hier meer dan het verschil in warme starttijd.
Thuisserver: voor een nieuwe, beperkte verzameling diensten biedt Podman een directe route naar beheer per gebruiker met Quadlet. Bestaat de server vooral uit onderhouden Compose-bestanden van applicatieprojecten, dan spaart Docker doorgaans omzettingswerk. Opslagpaden, netwerktoegang en het starten van diensten na een herstart moeten bij beide keuzes kloppen.
CI-omgeving: Docker ligt voor de hand als jobs Docker Compose, een Docker-socket of daarop afgestemde hulpmiddelen vereisen. Podman kan goed passen bij een geïsoleerde runner die onder een gewoon account images bouwt of containers start. De hele pipeline is hier de relevante proef: een geslaagde losse containerstart zegt nog niets over builds en gekoppelde testdiensten.

Migratiecheck voor een bestaande Compose-stack

Bij een overstap is het uitgewerkte Compose-model een bruikbaar vertrekpunt. De opdracht docker compose config voegt configuratiebestanden samen, verwerkt variabelen en toont het model dat Docker toepast. Bewaar die uitvoer als referentie en leg vervolgens vast welke provider de Podman-proef uitvoert.

Controleer welke Compose-provider is geïnstalleerd en gebruik in de proef dezelfde versie als op de beoogde host. Zo wordt duidelijk of een verschil uit de provider, de runtime of de configuratie komt.
Loop bind mounts en volumes na. Controleer welk hostaccount bestanden mag lezen en schrijven en of persistente gegevens na een herstart op dezelfde plaats beschikbaar zijn.
Probeer gepubliceerde poorten, naamresolutie tussen diensten en het pad via een eventuele reverse proxy. Rootless netwerkverkeer kan zich anders gedragen dan de bestaande Docker-bridge.
Voer de gebruikte builds, profielen, gezondheidscontroles en CI-stappen uit. Controleer ook herstartgedrag en hulpmiddelen die een socket aanspreken; een geaccepteerd Compose-bestand garandeert nog geen werkende dienst.

Blijft de stack met beperkte aanpassingen beheersbaar, dan kan Podman het gewenste model per gebruikersaccount bieden. Vraagt de migratie blijvend herstelwerk in Compose en omliggende hulpmiddelen, dan is Docker behouden en waar passend rootless inrichten een praktische keuze.