Docker eller Podman? Rootless-netværket kan afgøre mere end daemonen

Behold Docker, hvis eksisterende Compose-filer, API-klienter og driftsrutiner vejer tungest. Vælg Podman, hvis I ønsker at styre de enkelte containere gennem systemd og kan afprøve afhængighederne før et skifte. For begge valg skal rootless-netværket vurderes særskilt: den vej, trafikken tager mellem container og vært, kan få større betydning for ydelsen end forskellen mellem en daemon og en daemonless engine.

Podmans dokumentation beskriver en daemonless, OCI-baseret engine med en Docker-lignende kommandolinje, som kan køre containere som root eller almindelig bruger. Ligheden gør mange kommandoer genkendelige, men afgør ikke, om en bestemt Compose-fil, socketklient eller netværksopsætning fungerer på samme måde. Beslutningen bør derfor deles op i sikkerhed, kompatibilitet, drift og netværk.

Sikkerhed: sammenlign rootless med rootless

Fraværet af en permanent Podman-daemon er en arkitekturforskel, men Docker har også en rootless driftsform. Ifølge Dockers rootless-vejledning kører både daemonen og containerne i et user namespace uden rootprivilegier på værten. Opsætningen kræver blandt andet subordinate UID- og GID-intervaller samt værktøjerne newuidmap og newgidmap. En sammenligning mellem rootless Podman og en Docker-daemon med rootprivilegier ville derfor blande engine-valget sammen med et særskilt sikkerhedsvalg.

Rootless drift begrænser konsekvensen af fejl, der ellers kunne give containerens runtime værtsrettigheder som root. Den bruger, der starter containerne, kan dog stadig få adgang til sine egne filer og ressourcer. Ved en migration er det derfor relevant at gennemgå ejerskab af bind mounts, hvilke mapper tjenesterne må skrive til, og hvem der kan bruge containerens administrationssocket. De spørgsmål ændrer ikke karakter, blot fordi kommandoen skifter navn.

Compose og sockets kræver hver sin kompatibilitetstest

En fungerende podman run-kommando viser ikke, at hele Docker-arbejdsgangen kan flyttes. Podmans Compose-beskrivelse kalder podman compose en wrapper om en ekstern udbyder som docker-compose eller podman-compose; udbyderen kommunikerer med en lokal Podman-socket. Det er derfor både den installerede Compose-udbyder, Podmans API og den konkrete arbejdsfil, der afgør resultatet.

Afprøv de filer, teamet faktisk bruger, med deres profiler, miljøvariabler, mounts, healthchecks og netværk. En tjeneste, der starter, kan stadig fejle senere, hvis en afhængighed ikke bliver klar som forventet, et volumen får andre rettigheder, eller en klient læser containerstatus gennem API'et. Også nedlukning og genstart hører med: de er en del af den daglige drift, selv om den første opstart lykkes.

Socketafhængigheder fortjener deres egen gennemgang. CI-job, udviklingsværktøjer og overvågning kan tale direkte med et Docker-endpoint uden at bruge den synlige CLI. Podman kan stille en API-tjeneste til rådighed, men klienten skal forbindes til den tilsigtede brugers socket, og dens konkrete kald skal fungere. Kortlæg derfor endpoint, adgangsrettigheder og de operationer, klienterne udfører, før et kompatibelt kommandonavn tæller som en vellykket migration.

Netværksmålingen handler om forbindelsens vej

Rootless netværk kan føre trafik gennem komponenter i brugerrummet, fordi en almindelig bruger ikke kan oprette de samme netværksforbindelser på værten som en privilegeret proces. Det giver en mulig omkostning, som engine-navnet ikke oplyser. I et forsøg med iperf3 mellem virtuelle maskiner målte forskerne bag bypass4netns mere end 30 gange højere gennemløb for deres rootless konfiguration med socket-accelerationen end for den sammenlignede rootless konfiguration uden den.

Den langsommere forsøgsopsætning førte trafikken gennem slirp4netns og RootlessKit. bypass4netns skiftede udvalgte containersockets til sockets oprettet på værten, så trafikken kunne omgå dele af denne vej. Målingen er en sammenligning af netværkskonfigurationer i forsøgets miljø, ikke et generelt ydelsestal for Docker eller Podman. I forsøgets applikationstests varierede forbedringen også med belastningen: en databaseforespørgsel med mere arbejde uden for netværket havde mindre gavn af hurtigere trafik end en ren gennemløbstest.

For et platformteam betyder det, at en ydelsestest skal fastholde netværksbackend, portpublicering og trafikmønster ved siden af engine-navnet. Mål både gennemløb og svartid for de forbindelser, tjenesten bruger: udgående trafik, indgående kald gennem publicerede porte og kommunikation mellem containere. DNS og adgang til værten bør indgå, hvis applikationen afhænger af dem. Ellers kan to tilsyneladende ens rootless tests i praksis måle forskellige netværksveje.

Systemd ændrer, hvad der styres

Podmans Quadlet lader systemd styre containerressourcer gennem deklarative enhedsfiler. Quadlet-dokumentationen beskriver blandt andet filer for containere, netværk og volumener, som genererer systemd-services. Rootless enheder skal ligge i søgestien for en brugerinstans; en system-service bliver ikke til en rootless Quadlet ved blot at angive en anden bruger i servicefilen.

Docker rootless kan også køre som en systemd-brugertjeneste, men her styrer tjenesten Docker-daemonen. Med Quadlet kan systemd i stedet få særskilte enheder for Podmans ressourcer. Det kan gøre afhængigheder og genstartspolitik lettere at knytte til den enkelte tjeneste, hvis det passer til teamets eksisterende systemd-drift. Forskellen skal vurderes mod den nuværende Compose-opsætning, ikke som en automatisk grund til at omskrive den.

Migrationsmatrix: hvad skal fungere efter skiftet?

• Compose: Kør de eksisterende filer med den valgte udbyder. Kontrollér profiler, mounts, miljøvariabler, healthchecks, netværk samt nedlukning og genstart.
• Socket og API: Find alle klienter, der bruger Docker-endpointet. Prøv deres faktiske kald mod Podman, og kontrollér både socketens ejer og den adgang, klienten får.
• Rootless netværk: Registrér backend, portopsætning og trafikmønster. Sammenlign applikationens svartid og gennemløb under samme belastning, før et benchmarktal bruges som argument for et skifte.
• Systemd: Afgør, om driften skal styre en rootless Docker-daemon eller Podmans enkelte ressourcer. Afprøv brugerinstans, opstart efter værtsgenstart, afhængigheder og genstartspolitik.

Hvis Docker allerede opfylder sikkerhedskravene i rootless drift, skal et skifte til Podman give en konkret fordel i værktøjer eller systemd-drift. Hvis Podmans model passer bedre, er Compose, API-klienter og netværksadfærd de forhold, der afgør, hvor stor migrationen faktisk bliver.

Læs også:

• Docker eller Podman: Rootless-sikkerhed har en målbar pris
• Proton Mail eller Tuta? Mailklienten kan afgøre mere end krypteringen
• Dropbox eller OneDrive? Office-pakken kan afgøre mere end synkhastigheden