Docker ili Podman: slična brzina, drukčije ovlasti

Ako razvojno računalo ili CI već ovise o Dockerovu API-ju i Composeu, Docker je obično jednostavniji izbor. Podman je privlačan na dijeljenom Linux poslužitelju kada korisnici trebaju zasebno upravljati svojim kontejnerima. U objavljenom mjerenju toplog pokretanja razlika u brzini bila je premala da bi sama odlučila o izboru.

Razlika u ovlastima ovisi o konfiguraciji. Dockerova uputa za rootless način navodi da tada i daemon i kontejneri rade bez administratorskih ovlasti unutar korisničkog imenskog prostora. Docker pritom zadržava odnos klijenta i daemona, dok Podman za lokalno pokretanje ne treba stalni daemon.

Ovlasti: daemon je važniji od imena alata

U uobičajenoj instalaciji Dockerov klijent šalje zahtjeve daemonu koji upravlja kontejnerima. Pristup njegovoj upravljačkoj utičnici zato je osjetljiva ovlast: proces koji njome može upravljati može zatražiti pokretanje kontejnera i pristup resursima domaćina. Rootless način smanjuje ovlasti daemona i kontejnera, ali ne uklanja daemon iz tog odnosa.

Podmanov priručnik opisuje lokalni rad bez stalnog daemona: kada naredbu pokrene običan korisnik, Podman automatski stvara korisnički imenski prostor, a njegovi kontejneri nisu vidljivi drugim korisnicima. Za takav rad korisniku trebaju dodijeljeni podređeni UID i GID rasponi u sustavu. Administrator zato i dalje priprema domaćin, iako svakodnevno pokretanje kontejnera ne mora zahtijevati administratorske ovlasti.

Na dijeljenom poslužitelju ta razlika određuje tko upravlja čijim kontejnerima i slikama. Za dugotrajne usluge Podmanov Quadlet omogućuje deklarativno upravljanje kroz systemd, uključujući korisničke usluge. Dockerov rootless daemon također može raditi kao korisnička usluga, pa stvaran izbor nije jednostavna podjela na rad s ovlastima i bez njih: bitno je želite li zaseban daemon i kako su uređeni korisnički računi.

Naredbe su slične, ali Compose traži provjeru

Za osnovne radnje, poput preuzimanja slike, pokretanja i zaustavljanja kontejnera, Podman nudi naredbeni redak usporediv s Dockerovim. Zamjena imena naredbe zato može biti dovoljna za jednostavnu skriptu. Alat koji očekuje Dockerovu utičnicu, određeno ponašanje API-ja ili poseban dodatak za izgradnju slike ima drukčije zahtjeve od skripte koja poziva samo naredbu za pokretanje.

Compose je konkretna granica te kompatibilnosti. Uputa za podman compose opisuje naredbu kao omotač koji poziva vanjskog pružatelja Compose funkcija, primjerice docker-compose ili podman-compose, i povezuje ga s lokalnom Podmanovom utičnicom. Ponašanje projekta zato ovisi i o instaliranom pružatelju, a sama prisutnost naredbe ne jamči jednak rezultat za svaku Compose datoteku.

U CI-ju je važan cijeli lanac: način izgradnje slike, očekivana lokacija utičnice, mreža među uslugama i datoteke koje koraci razmjenjuju. Skripta koja uspješno izvrši jednostavno pokretanje kontejnera još ne dokazuje da će raditi njezin dodatak za izgradnju ili testni alat koji se izravno spaja na Dockerov API. To je funkcionalna zapreka migraciji, a ne razlika koju otkriva usporedba sintakse naredbi.

Rootless mreža mijenja način pristupa usluzi

Objavljeni port sigurnija je pretpostavka za pristup rootless usluzi od oslanjanja na adresu samog kontejnera. U Podmanovu početnom primjeru rootless HTTP kontejner nema dodijeljenu zasebnu IP adresu: lokalno mu se pristupa preko objavljenog porta, a s drugog računala preko adrese domaćina. To opisuje prikazanu konfiguraciju, ne svaku moguću Podmanovu mrežu.

Ako postojeća aplikacija već koristi objavljene portove, prilagodba može biti mala. Ako nadzor, druga usluga ili skripta traži adresu kontejnera, treba promijeniti način pronalaženja usluge. Valja provjeriti i promet među kontejnerima te prosljeđivanje portova: isti naziv mreže u konfiguraciji ne jamči isti put prometa nakon promjene alata.

Što je izmjereno pri pokretanju

U mjerenju Botmonster Tech na Linux Mintu 22.3, Docker Engine 29.5 s administratorskim ovlastima prosječno je postigao 352 ms (± 12 ms), a rootless Podman 4.9.3 342 ms (± 31 ms) tijekom 20 toplih pokretanja već preuzete slike Alpine s naredbom true; autor je razliku ocijenio šumom mjerenja. To je rezultat tih dviju konfiguracija na jednom računalu, a ne usporedba oba alata u rootless načinu.

Postupak je moguće ponoviti tako da se na istom računalu unaprijed preuzme ista slika, zabilježe verzije i način rada s ovlastima te više puta mjeri izvršavanje iste kratke naredbe. Preuzimanje slike, izgradnja, mrežni promet i rad stvarne aplikacije zasebni su poslovi s drukčijim ograničenjima. Za izbor alata ovaj rezultat govori samo da toplo pokretanje malog, kratkotrajnog kontejnera u izmjerenim uvjetima nije pokazalo uvjerljivu prednost.

Odluka prema mjestu uporabe

Razvojno računalo: Docker je razuman izbor kada projekt već koristi Compose, dodatke i alate vezane uz njegov API. Podman odgovara jednostavnijem tijeku rada pod običnim korisnikom; prije zamjene treba provjeriti montirane direktorije, vlasništvo nastalih datoteka i veze među uslugama.
Dijeljeni Linux poslužitelj: Podman odgovara kada korisnički računi trebaju zasebno upravljati svojim kontejnerima, a Quadlet može voditi dugotrajne usluge kroz systemd. Dockerov rootless način ostaje mogućnost ako tim želi zadržati Dockerove postupke, uz daemon pokrenut pod korisničkim računom.
CI: Docker smanjuje prilagodbe kada zadaci ili dodaci izravno očekuju njegovu utičnicu i ponašanje API-ja. Podman ima smisla kada su poslovi prenosivi i mogu se provjeriti Compose, izgradnja, mreža te ovlasti nad datotekama između koraka.

Prije migracije najviše vrijedi popisati stvarne ovisnosti: procese koji koriste Dockerovu utičnicu, tražene Compose mogućnosti, pretpostavke o adresama kontejnera i vlasništvo datoteka u montiranim direktorijima. Ti zahtjevi mogu zaustaviti zamjenu i kada osnovne naredbe izgledaju jednako. Brzina toplog pokretanja iz objavljenog testa ne nadoknađuje posao potreban da se takve ovisnosti promijene.

Pročitajte i: