Docker apo Podman: nisja është barazim, daemon-i ndryshon serverin

Kalimi nga Docker në Podman ia vlen kryesisht për një server Linux ku dëshiron t’i ekzekutosh kontejnerët si përdorues pa privilegje dhe të shmangësh një daemon qendror rezident. Nëse projekti varet nga Docker Compose, mjetet që përdorin Docker API ose një konfigurim CI tashmë funksional, kostoja e migrimit mund ta tejkalojë përfitimin.

Nisja e kontejnerit nuk jep një arsye të fortë për ndërrim: në një matje të publikuar, rezultatet dolën praktikisht të barabarta. Dallimi që mund të ndihet në një server të vogël është kujtesa e proceseve që mbeten aktive kur nuk ka kontejnerë në punë. Siguria, ndërkaq, duhet krahasuar mes konfigurimeve konkrete rootless, jo vetëm mes emrave të produkteve.

Rootless varet nga përdoruesi dhe konfigurimi

Dokumentacioni i Podman e përshkruan mjetin si pa daemon qendror dhe thotë se shumica e komandave mund të ekzekutohen nga një përdorues i zakonshëm. Në një server, kjo lejon që shërbimet të administrohen nga një llogari e caktuar pa i dhënë asaj kontroll mbi një daemon qendror me privilegje root. Podman mund të përdoret edhe me privilegje root, prandaj vetë instalimi i tij nuk përcakton mënyrën e ekzekutimit.

Edhe Docker mbështet ekzekutimin rootless. Udhëzimi i Docker për Rootless shpjegon se si daemon-i, ashtu edhe kontejnerët ekzekutohen pa privilegje root brenda një hapësire përdoruesi. Kjo ndryshon nga userns-remap, ku daemon-i vazhdon të punojë si root. Krahasimi i dobishëm është mes Docker Rootless dhe Podman rootless për të njëjtin shërbim, ose mes instalimit Docker me daemon root dhe Podman të nisur nga një përdorues i zakonshëm.

Për të dyja mjetet, kufiri praktik i privilegjeve shfaqet te vëllimet, skedarët e montuar nga hosti dhe portat e publikuara. Një shërbim që shkruan në një dosje të hostit duhet të ketë leje të përshtatshme për përdoruesin që e ekzekuton. Në prodhim, kjo kërkon të vendosësh se cila llogari do të zotërojë të dhënat dhe do të nisë shërbimin pas rindezjes, përpara se të gjykosh se cili motor është më i përshtatshëm.

Çfarë matin nisja dhe kujtesa në pushim

Në matjen e Botmonster, 20 nisje me imazh të shkarkuar paraprakisht dhanë mesatarisht 352 ms për Docker dhe 342 ms për Podman; pa kontejnerë aktivë, dockerd dhe containerd përdorën së bashku 144 MB kujtesë. Prova u krye në një makinë me Docker Engine 29.5 me privilegje root dhe Podman 4.9.3 rootless. Diferenca e nisjes ishte brenda luhatjes së matjes, ndaj nuk mbështet premtimin se arkitektura pa daemon e nis domosdoshmërisht më shpejt një aplikacion.

Shifra e kujtesës ka një kuptim tjetër nga koha e nisjes. Docker mban procese qendrore aktive edhe kur nuk po ekzekutohet asnjë kontejner; Podman nuk mban një daemon të tillë. Kjo mund të ketë peshë në një host me pak RAM, veçanërisht kur shërbimet nisen vetëm herë pas here. Megjithatë, kujtesa e daemon-it nuk është kujtesa totale e instalimit: aplikacionet, proceset mbikëqyrëse dhe rrjeti i kontejnerëve në punë vazhdojnë të konsumojnë burime.

Prova e nisjes përdori një imazh të gatshëm dhe një komandë që përfundon shpejt. Ajo mat kryesisht rrugën e krijimit dhe nisjes së kontejnerit, ndërsa një shërbim real mund të presë shkarkimin e imazhit, inicializimin e aplikacionit ose lidhjen me bazën e të dhënave. Për një migrim, këto pjesë të ngarkesës kanë më shumë rëndësi sesa një epërsi prej pak milisekondash në një provë të kufizuar.

Rrjeti mund ta ndryshojë bilancin e RAM-it

Në provën e cituar, Podman rootless me pasta dha shkarkim më të qëndrueshëm përmes një porte të publikuar sesa ura e Docker me privilegje root. Kjo krahason dy rrugë të ndryshme të trafikut në të njëjtin host; nuk është një renditje universale e motorëve. Zgjedhja e mekanizmit të rrjetit, mënyra rootless dhe konfigurimi i portave ndikojnë në rezultatin që do të shohë një shërbim i caktuar.

Pasta përdor një proces ndihmës për trafikun e kontejnerit rootless. Kur qëndrojnë aktivë disa kontejnerë, këta procese mund të zbusin kursimin e kujtesës që sjell mungesa e daemon-it qendror. Për një shërbim të ekspozuar në internet, krahasimi duhet të përfshijë si trafikun përmes portës së publikuar, ashtu edhe RAM-in e përdorur nga rruga e rrjetit. Një rezultat i mirë i throughput-it në makinën e autorit nuk parashikon automatikisht sjelljen e një VPS me burime të kufizuara.

Compose përcakton sa punë kërkon migrimi

Komandat e ngjashme nuk garantojnë një rrjedhë pune identike. Dokumentacioni për podman compose thotë se komanda thërret një ofrues të jashtëm Compose, si docker-compose ose podman-compose, dhe e lidh atë me soketin lokal të Podman. Sjellja varet nga ofruesi i instaluar dhe nga mënyra si projekti përdor ndërtimin e imazheve, rrjetet, vëllimet dhe veçoritë e Compose.

Për një projekt me shërbime të thjeshta, kalimi mund të kërkojë pak ndryshime, por skedari konkret Compose mbetet prova vendimtare. Nëse mjetet e zhvillimit ose punët e CI presin një soket Docker në një vend të caktuar, një API të caktuar ose sjelljen e shtojcave të Docker Compose, zëvendësimi i komandës mund të mos mjaftojë. Në këtë mjedis, mbajtja e Docker shmang një migrim që nuk sjell përfitim të qartë në nisje dhe mund të prekë ndërtimin, testet ose vendosjen në server.

Shërbimet e përhershme në Linux

Për një server që i menaxhon shërbimet me systemd, Podman ka një rrugë të drejtpërdrejtë përmes Quadlet. Udhëzimi zyrtar për Quadlet përshkruan skedarë që gjenerojnë njësi systemd për kontejnerë, rrjete dhe vëllime, përfshirë njësi të përdoruesve pa privilegje root. Quadlet kërkon cgroup v2; një shërbim rootless duhet vendosur në rrugën përkatëse të njësive të përdoruesit, jo thjesht në një njësi sistemi me direktivën User.

Ky model i përshtatet një hosti ku cikli i jetës së kontejnerëve duhet të lidhet me nisjen, rindezjen dhe varësitë e shërbimeve të Linux. Ai kërkon gjithashtu që konfigurimi ekzistues të përkthehet në njësi Quadlet dhe të provohen lejet e të dhënave e rruga e rrjetit. Kur një instalim Docker Compose tashmë i kryen këto detyra pa problem, përfitimi nga një model tjetër administrimi duhet të justifikojë atë punë.

Zgjedhja sipas mjedisit

• Laptop zhvillimi me Linux: Mbaj Docker kur ekipi përdor skedarë Compose dhe mjete lokale që punojnë tashmë. Podman ia vlen të provohet në një projekt të veçuar nëse kërkohet punë rootless; lejet e skedarëve të montuar dhe sjellja e Compose vendosin nëse ndryshimi mbetet i thjeshtë.
• VPS hipotetik me 2 GB RAM: Podman është kandidat i fortë kur ka pak shërbime dhe kujtesa e proceseve rezidente ka peshë. Llogarit edhe proceset e rrjetit për kontejnerët aktivë dhe mënyrën si shërbimet nisen pas rindezjes; kursimi i matur për daemon-in nuk kalon i plotë në çdo konfigurim.
• CI: Mbaj Docker kur punët presin shprehimisht daemon-in, soketin ose shtojcat e tij. Podman bëhet alternativë kur të njëjtat hapa të ndërtimit, nisjes së shërbimeve ndihmëse dhe pastrimit përfundojnë në runner-in që do të përdoret.
• Server prodhimi: Zgjidh Podman kur administrimi rootless sipas përdoruesit dhe integrimi me systemd janë kërkesa të qarta. Nëse kërkohet pajtueshmëri e plotë me rrjedhën ekzistuese Docker Compose, mbaj Docker derisa shërbimet, të dhënat dhe automatizimet të jenë provuar në mjedisin e ri.

Lexoni gjithashtu:

• Typefully apo Hypefury: krahasimi prishet pasi Hypefury hoqi X-in
• Cloudflare 1.1.1.1 apo Quad9: shpejtësia përballet me bllokimin e malware
• Flodesk apo Kit: dizajni përballet me automatizimin e shitjeve