Ik ben begonnen met Podman in plaats van Docker Desktop te gebruiken en het is veel sneller dan ik had gedacht

Mijn laptop heeft de vrij betrouwbare gewoonte om me te laten weten wanneer Docker Desktop wordt gestart. Niet via een melding, of een geluid, of iets zo beleefd als dat. Gewoon de ventilator. Een zachte maar onmiskenbare zoem die ruwweg vertaalt als: de daemon is wakker en hongerig.

Ik had Docker Desktop al lang genoeg gebruikt dat ik het nooit in twijfel had getrokken. Het was gewoon wat ik installeerde wanneer ik containers nodig had. Echter, een collega van mij vermeldde terloops dat zij waren overgestapt op Podman Desktop — een van de beste alternatieven voor Docker voor containerbeheer — en ik besloot er wat tijd aan te besteden.

Docker Desktop deed precies niets verkeerd

Het heeft gewoon veel gevoelens over je RAM

Om eerlijk te zijn tegenover Docker, heeft het hulpmiddel zijn reputatie verdiend. Toen containers nog een nieuw en enigszins intimiderend concept waren, maakte Docker Desktop het hele concept benaderbaar op macOS en Windows. Je hoeft geen kennis te hebben van Linux-kernen, hypervisors of VM-netwerken om een container draaiende te krijgen. Docker bundelde de complexiteit in een verfijnd pakket dat de onaangename onderdelen voor je afhandelde, en jarenlang was dat gemak van onschatbare waarde.

Docker Desktop is echter ook gestaag in ambitie gegroeid. Er is nu een zware GUI, Kubernetes-integratie, Dev-omgevingen, Extensies en een credential store die af en toe het niet met je eens is. Voor teams die op die functies vertrouwen, is het platform logisch. Voor degenen onder ons die meestal vier of vijf containers per dag vanaf een terminal draaien en zich de laatste keer dat we de Docker Desktop GUI openden niet kunnen herinneren, is het een hoop gereedschap om mee rond te slepen.

Een deel van dat gewicht komt door de architectuur eronder. Op macOS en Windows draait Docker Desktop containers via een Linux-virtuele machine, wat op zich geen probleem is. Toch betekent het wel dat er altijd een virtualisatielaag betrokken is. Docker is ook afhankelijk van een persistent achtergrondproces, dockerd, om containers te beheren. Docker Desktop regelt dit allemaal netjes, wat een deel van de aantrekkingskracht is, maar het betekent ook dat er meer bewegende onderdelen en meer achtergrondgebruik van middelen zijn tussen jou en de containers die je probeert te draaien.

Wat Podman Desktop anders doet (en waarom je het eigenlijk voelt)

Root? Dat doen we hier niet

Wat mij aantrok in Podman Desktop was hoe direct het werkt. Ik typ podman run, de container start, en het proces staat me niet in de weg. Ik hoef nooit te wachten tot een achtergrondservice opstart omdat Podman een daemonloze architectuur gebruikt. Op Linux wordt elk commando uitgevoerd als een eigen proces direct onder je shell-sessie. Op macOS en Windows communiceert Podman met een lichtgewicht Linux-VM via een snelle SSH-verbinding, start de container, en treedt dan opzij zodra de taak is voltooid.

Dat ontwerp heeft een merkbaar effect op systeembronnen gedurende de dag. Podman Desktop staat inactief met opmerkelijk weinig overhead, terwijl de daemon en GUI van Docker Desktop blijven doorgaan met het verbruiken van geheugen, zelfs wanneer er geen containers draaien. Het verschil wordt vooral zichtbaar zodra je al een browser vol tabbladen hebt, een code-editor, terminals en een half dozijn achtergrondapps die concurreren om RAM. Het is niet het soort transformatie dat je laptop van het bureau doet opzweven, hoewel de vermindering van wrijving na een paar dagen regelmatig gebruik gemakkelijk te waarderen is.

Ik ben ook uiteindelijk het standaard beveiligingsmodel van Podman gaan waarderen. Containers draaien standaard rootless, wat betekent dat ze onder je normale gebruikersaccount draaien in plaats van met verhoogde systeemprivileges. Als een container ooit uit de hand loopt, blijft de schade beperkt omdat het proces niet automatisch root-toegang tot de machine erft. Voor het merendeel van het lokale ontwikkelwerk verandert dit je dagelijkse workflow op geen enkele zichtbare manier. Maar het is een wezenlijk beter beveiligingsbeleid, vooral wanneer je afbeeldingen van derden gebruikt die je zelf niet hebt gebouwd.

De overgang naar de CLI was ook gemakkelijker dan ik had verwacht. Podman behoudt een sterke compatibiliteit met de commando-structuur van Docker, dus het merendeel van mijn bestaande workflow werd vrijwel intact overgenomen. Ik maakte een alias docker=podman en bleef de commando's gebruiken die al in mijn spiergeheugen zaten: run, ps, images, rmi en de rest. Binnen een dag of twee was ik vrijwel helemaal gestopt met nadenken over de overstap.

Podman Desktop is ook aanzienlijk volwassen geworden, vooral op macOS en Windows, waar het nu netjes integreert met het hostsysteem en snelle bestandssdelingstechnologieën zoals VirtioFS gebruikt. Onder de motorkap vertrouwt Podman nog steeds op een Linux VM via podman machine, vergelijkbaar met hoe Docker Desktop achter de schermen werkt. Het verschil is dat Podman meer van die machinerie direct blootstelt, waardoor je de VM zelf kunt schalen, configureren en beheren in plaats van het te verbergen achter lagen van abstractie. De snelheidsverbeteringen die ik merkte kwamen door een slanker gastomgeving en het ontbreken van een constant draaiende daemon, niet door virtualisatie te elimineren.

Er zijn wat ruwe kanten aan Podman

Hier is wat ik eigenlijk heb geraakt

De migratie verliep niet zonder wrijving, en ik vertel dat liever meteen dan dat je het halverwege het project ontdekt.

Als je al precies weet hoe je Docker Compose moet gebruiken, is Compose-ondersteuning waarschijnlijk het lastigste onderdeel van de overstap. Podman kan op twee hoofdmanieren met Compose werken: via podman-compose, een community-implementatie in Python, of door het officiële docker-compose-programma te laten verwijzen naar de API-socket van Podman met behulp van de DOCKER_HOST omgevingsvariabele. Voor eenvoudige Compose-bestanden werken beide goed. Echter, zodra je setup complexere netwerken, aangepaste bruggen of randgevallen van servicegedrag bevat, kun je tegen tekortkomingen aanlopen. (En als je vertrouwt op tools die automatisch Compose-bestanden aanmaken vanuit draaiende Docker-containers, verwacht dan dat je een paar handmatige aanpassingen moet doen).

Rootless containers kunnen ook het monteren van volumes iets ongemakkelijker maken. Ik stuitte onmiddellijk op "permission denied"-fouten bij sommige bind mounts totdat ik begon met het toevoegen van :Z-labels aan volume mappings of het configureren van userns_mode: keep-id zodat containers de correcte gebruikersidentiteit van de hostmachine overnamen. Niets hiervan is een dealbreaker, maar als je Compose-bestanden meer doen dan basisservice-orchestratie, is het de moeite waard om wat tijd vrij te maken om de lokale eigenaardigheden glad te strijken.

Het bredere ecosysteem is ook nog steeds volledig rond Docker gevormd. Wanneer er iets misgaat en je begint te graven door Stack Overflow of GitHub-issues, gaat bijna elke oplossing ervan uit dat je Docker gebruikt. Het vertalen van die oplossingen naar Podman vereist meestal slechts kleine aanpassingen. Toch bevond ik mezelf af en toe in het uitpluizen van Linux sub-gebruikersnamenruimten en /etc/subuid-configuraties om te begrijpen waarom een permissiemodel zich anders gedroeg.

Ik ga mijn spiergeheugen niet verwijderen

Ik zou Docker Desktop nog steeds aan veel mensen aanraden. Als je team het al gebruikt, je gereedschappen ervan afhankelijk zijn, of je de meest gedocumenteerde route door containerontwikkeling wilt, is er geen schande in het blijven bij de walvis. Vertrouwdheid heeft waarde, vooral als deadlines boven je hoofd hangen.

Ik beschouw Docker Desktop echter niet langer als de automatische toegangspoort tot elk lokaal containerwerk. Podman herinnerde me eraan dat sommige tools beter aanvoelen, niet omdat ze luider schreeuwen, maar omdat ze de kamer verlaten zodra het werk begint. En dat is waarschijnlijk het grootste compliment dat ik Podman kan geven.