Ja jūs interesē virtualizācijas un konteinerizācijas pasaule, iespējams, esat sastapies ar Podman un Docker, un jums varētu rasties jautājums, kā tie atšķiras viens no otra.
Šajā ziņojumā mēs izpētīsim atšķirības starp Docker un Podman un mēģināsim atrast, kura no tām būs jums piemērotākā!
Docker
Docker ir konteinerizācijas tehnoloģija, kas atvieglo atkarības pārvaldību projekta ietvaros visos līmeņos (izstrāde un ieviešana).
Pieejams operētājsistēmās Linux, Windows un Mac OS, Docker mehānisms koncentrējas uz konteineriem un to orķestrēšanu, un tieši šeit konteinerizācija atšķiras no virtualizācijas.
Docker ir divi galvenie elementi: Docker CLI un Docker Daemon.
Docker Daemon:
Tas ir pastāvīgs fona process, kas palīdz pārvaldīt Docker attēlus, konteinerus, tīklus un krātuves apjomus. Docker izmanto savu Docker Engine REST API, lai mijiedarbotos ar Docker dēmonu, kuram var piekļūt, izmantojot HTTP protokolu.
Docker CLI:
Attēla kredīts: Redhat
Tas ir Docker komandrindas klients mijiedarbībai ar Docker dēmonu. Tas ir tas, ko izmantojat, palaižot jebkuru Docker komandu.
Docker darbības pamatā ir Linux kodols un šī kodola funkcijas, piemēram, cgroups un namespaces. Šīs funkcijas atdala procesus, lai tie varētu darboties neatkarīgi, jo konteineru mērķis ir palaist vairākus procesus un lietojumprogrammas atsevišķi.
Tas ļauj optimizēt infrastruktūras izmantošanu, nesamazinot drošības līmeni salīdzinājumā ar atsevišķām sistēmām.
Visiem konteineru rīkiem, piemēram, Docker, ir uz attēlu balstīts izvietošanas modelis. Šis modelis vienkāršo lietojumprogrammas vai pakalpojumu kopas koplietošanu vairākās vidēs.
Turklāt Docker palīdz automatizēt lietojumprogrammu izvietošanu konteinera vidē. Izmantojot šos dažādos rīkus, lietotāji iegūst pilnu piekļuvi lietojumprogrammām un var paātrināt izvietošanu, kontrolēt versijas un piešķirt tās.
Podmane
Podman (POD MANAGER) veido, palaiž un pārvalda OCI konteinerus un konteineru attēlus. To izstrādāja Red Hat un sākotnēji bija paredzēts tā uzņēmumam Linux 8. To izmanto konteineru pārvaldībai un darbojas kā oficiālais Docker pēctecis.
Līdz ar to Red Hat pārtrauca atbalstu Docker, taču apliecināja, ka slēdzis lietotājiem būs vienkāršs, jo Podman pamatā ir Docker, lai gan sākotnēji tas bija paredzēts tikai kā atkļūdošanas rīks.
Tas pārvalda visu konteinera ekosistēmu, izmantojot libpod bibliotēku. Tā kā Podman darbojas tikai Linux platformās, pašlaik tiek izstrādāta REST API un klienti, kas ļauj Mac un Windows sistēmām izsaukt pakalpojumu.
Tomēr pašlaik ir uz Varlink balstīts attālais klients, kas darbojas Mac vai Windows platformās, kas nodrošina attālo saziņu ar Linux balstītu Podman serveri. Libpod bibliotēka atbalsta vairākas metodes, lai droši augšupielādētu attēlus, tostarp uzticēšanās un attēla pārbaude.
Tā atbalsta arī podi, lai pārvaldītu konteineru grupas kopā un vairākus attēlu formātus, tostarp OCI un Docker attēlu formātus.
Ļoti mazās un pārvaldāmās vidēs Podman pat var kalpot kā Kubernetes priekštecis. Tas mazina plaisu starp atsevišķu gadījumu pārvaldību no konteineru ažiotāžas sākuma gadiem un mūsdienīgu orķestrēšanu ar Kubernetes.
Ambiciozie konteineru lietotāji jau var izbaudīt nākamo līmeni ar pākstīm. Kubernetes klastera būvniecība un darbība vairs nav nepieciešama. Vienkāršākajā gadījumā jauna dizaina pākstis var pārbaudīt un uzlabot atsevišķās darbībās. Ir iespējama pat vēlāka pāreja uz Kubernetes.
Komanda podman generate kube nodrošina atbilstošos konfigurācijas failus. Pēc tam tie kalpo viens pret vienu kā Kubernetes rīka kubectl ievade.
Pašreizējās Podman versijās pat var izveidot konfigurācijas failus sistēmai — tas ir gardums ikvienam, kurš konteinera orķestrēšanai izmanto visuresošo init pēcteci.
Podman vs Docker: atšķirības
Docker ātri ir kļuvis par konteineru apsaimniekošanas hobiju. Tomēr Docker ir daudz priekšrocību un, galvenais, strauji augošais attēlu repertuārs, kā arī trūkumi un iespējamie drošības riski. Turklāt Docker vairs netiek atbalstīts kā Kubernetes konteiners.
Fakts, ka konteineriem, atšķirībā no virtuālajām sistēmām, nav nepieciešams kodols, parasti tiek uzskatīts par vienu no lielajām priekšrocībām. Tomēr tas rada lielu drošības risku ar Docker, jo Docker konteinerus var palaist tikai ar root tiesībām.
Tas ļauj procesiem, kas darbojas konteineros, piekļūt kodolam ar root tiesībām un tādējādi uzbrukt resursdatora sistēmai.
Pirmā atšķirība ir pamanāma, kad to pirmo reizi lietojat. Lai gan Docker pieprasa vispirms palaist Docker dēmonu, Podman konteineru var palaist tieši no komandrindas. Tāpēc nav fona procesa, un lietojumprogramma tiek izpildīta tikai nepieciešamības gadījumā.
No drošības viedokļa tas ir labi, jo Podman ir mazāk neaizsargāts pret uzbrukumiem, ja dēmonam nav jādarbojas 24/7 ar superlietotāja privilēģijām. Podman nav nepieciešams fona process arhitektūras dēļ, kas būtiski atšķiras no Docker.
Kamēr Docker seko klienta-servera modelim, kur Docker klients sazinās ar Docker dēmonu, izmantojot API, Podman seko fork-exec modelim. Katrs konteiners darbojas kā Podman bērna process.
Lietotāja nosaukumvieta tiek izveidota pirmajā lietošanas reizē, kad Podman tiek palaists ar parastajām lietotāja privilēģijām. Lietotāja nosaukumvietā Podman darbojas ar root tiesībām, un tai ir tiesības uzstādīt failu sistēmas un izveidot konteinerus.
Attiecīgi Podman konteineram ir tikai izpildes lietotāja tiesības. Lietotāju nosaukumvietu izmantošana nozīmē, ka katrs lietotājs var izveidot un pārvaldīt savus konteinerus, taču tie nav redzami citiem lietotājiem un superlietotājam.
Tā kā Podman tiek darbināts neatkarīgi no Docker, izstrādātājiem ir liela rīcības brīvība un viņi var reaģēt uz kopienas vēlmēm. Interesanti Podman papildinājumi ietver pievienošanas/atmontēšanas komandu un sistēmas integrāciju.
Saimniekdators var izmantot mount/atmount komandu, lai pievienotu konteinera failu sistēmu, piemēram, lai piekļūtu failiem vai tos mainītu un pēc tam tos vēlreiz atvienotu.
Lai gan konteineru pārraudzība, izmantojot systemd, nedarbojas Docker ar Podman dēmona dēļ, konteinerus var palaist, pārraudzīt un pat restartēt, izmantojot systemd.
Turklāt Podman nodrošina komandu podman generate systemd, kas ģenerē atbilstošu systemd pakalpojumu attiecīgajam konteineram un tādējādi atbrīvo lietotāju no systemd pakalpojumu izveides, kas nozīmē, ka ir pieejama integrācija resursdatora sistēmā.
Vēl viena būtiska atšķirība starp Podman un Docker ir tā, ka pēdējais nemaina ugunsmūra noteikumus vai pašreizējo dnsmasq instalāciju, jo tas spēj izveidot iekšējo tīklu. Turpretim Docker ir jāpārraksta ugunsmūra noteikumi, lai iespējotu starpkonteineru saziņu.
PodmanDockerArchitecture DaemonDaemon lessServices Management SystemdDocker EngineFirewall savietojamībaPārraksta ugunsmūra noteikumus Ievēro ugunsmūra noteikumusPlatforma Native atbalsts operētājsistēmai LinuxLinux, Windows un Mac
Kad jums vajadzētu migrēt no Docker uz Podman
Ja izvietojat konteinerus vidē, kuras pamatā ir RHEL, tādā gadījumā jums nav daudz iespēju, izņemot lietot Podman, jo tas ir RHEL vietējais. Varat arī migrēt uz vai izvēlēties Podman, nevis Docker, ja jums ir nelieli izvietojumi ar dažiem konteineriem.
Tomēr, ja vēlaties padarīt sarežģītāku, izmantojiet vairākus konteinerus un koordinējošu konteineru kaudzi ar docker-compose/podman-compose, izmantojot tīklu. Labāk ir izmantot Docker, jo tas daudz labāk apstrādā tīklu.
Tāpat, ja jūs tikko sākat ienākt konteineru pasaulē, šajā gadījumā Docker ir labāks risinājums, jo tas ir stabils, labi izveidots ar atbilstošu dokumentāciju un tam ir sekla mācīšanās līkne salīdzinājumā ar Podman, kuram joprojām trūkst stabilitātes un nav precīzi definētas dokumentācijas.
Migrācija no Podman uz Docker
Ja atrodaties komandrindā, ir diezgan viegli pārslēgties no Docker Engine uz Podman. Visvienkāršākajā gadījumā $ aizstājvārds lielākoties darbojas komanda docker=podman.
Protams, tas pieņem, ka sistēmā ir instalēta atbilstošā programmatūra. Linux gadījumā tā arī nav problēma; komerciāli pieejamiem izplatījumiem ir pieejamas gatavas programmatūras pakotnes.
Windows vai macOS nav atbalstīto operētājsistēmu skaitā. Pseidonīmu pieeja darbojas, jo daudzām Docker komandām ir Podman ekvivalents.
Taču ir arī izņēmumi, jo dažām Docker komandām nav līdzinieka Podman pasaulē. Tāpat dažas komandas Docker darbojas savādāk nekā Podmana Visumā. Šobrīd tas ietekmē tikai jau iestatīto sējumu apstrādi.
Slēdzis ir nedaudz grūtāks, ja tiek izmantoti grafiskie rīki, piemēram, Docker Desktop. Tam īpaši vajadzētu ietekmēt tos izstrādātājus, kuri strādā ar Windows vai macOS.
Docker Desktop lietotājiem būs jāpierod pie komandrindas, un tas pats attiecas uz Docker Compose. Tomēr ir projekts podman-compose. Programmatūra, kas rakstīta Python, kalpo kā Docker Compose aizstājējs.
Nobeiguma vārdi
Docker nomaiņu ar Podman var uzskatīt par gandrīz pabeigtu. Lietotājiem un administratoriem lielākā daļa šo izmaiņu aspektu ir vienkārši. Daudzām Docker funkcijām Podman ir identiski ekvivalenti.
Reāls ieguvums ir atsevišķa dēmona procesa un saknes privilēģiju trūkums, nemaz nerunājot par konteineru grupu dabisko izmantošanu. Tomēr ir vērts pieminēt, ka Docker joprojām ir galvenā tehnoloģija attiecībā uz konteineriem, taču tas, visticamāk, mainīsies ilgtermiņā.
Varat arī izpētīt dažas Docker komandas, lai pārvaldītu konteinerus.