Podman vs. Docker: qual è il futuro del mondo dei container?

Poiché il supporto ufficiale per il popolare strumento di gestione dei container Docker in Red Hat En­ter­pri­se Linux 8 (RHEL 8) è stato in­ter­rot­to, molti am­mi­ni­stra­to­ri e am­mi­ni­stra­tri­ci devono trovare una nuova soluzione. Podman, sempre di Red Hat, è con­si­de­ra­to il diretto suc­ces­so­re e, facendo a meno di un demone centrale e dei privilegi di root, è in grado di al­lon­ta­na­re molte pre­oc­cu­pa­zio­ni sulla sicurezza del suo pre­de­ces­so­re. Per il resto, i due strumenti sono simili, anche se Podman deve ancora fare i conti con alcuni bug.

Il mondo dei container è at­tual­men­te in fermento. Docker, una delle soluzioni più popolari e ap­prez­za­te, non riceverà più alcun supporto ufficiale su Red Hat En­ter­pri­se Linux 8. L’azienda pro­dut­tri­ce, Red Hat, ha però la nuova soluzione già pronta: Podman. L’ambiente CRI-O è proposto da Red Hat come una soluzione per­fet­ta­men­te equi­va­len­te e quindi i fan di Docker non do­vreb­be­ro pre­oc­cu­par­si. La pos­si­bi­li­tà che in futuro Podman possa davvero so­sti­tui­re Docker senza limiti resta un’altra faccenda. Per dare una risposta al riguardo è meglio ana­liz­za­re prima di tutto le tec­no­lo­gie di entrambi i container.

Dal 2013, quando Docker è stato in­tro­dot­to come software open source, la sua tec­no­lo­gia è stata molto ap­prez­za­ta e ha riscosso molto successo. La soluzione leggera e allo stesso tempo pratica e af­fi­da­bi­le offre agli utenti la pos­si­bi­li­tà di un approccio più libero per lo sviluppo di ap­pli­ca­zio­ni. Tramite l’immagine di un container, è possibile tra­sfe­ri­re e in­stal­la­re fa­cil­men­te i pacchetti come dati. Una singola immagine Docker può anche creare un numero il­li­mi­ta­to di container per rea­liz­za­re, ad esempio, dei cloud OpenStack. Docker, inoltre, è com­ple­ta­men­te isolato, tranne che per alcune in­ter­fac­ce al sistema operativo o all’hardware. I container con­ten­go­no soltanto le in­for­ma­zio­ni veramente ne­ces­sa­rie e sono pertanto re­la­ti­va­men­te leggeri.

Secondo i piani di Red Hat Linux, Docker sarà so­sti­tui­to da Podman, concepito per la gestione di pod con il fine di creare e svi­lup­pa­re ul­te­rior­men­te i container e com­pa­ti­bi­le con la specifica dei container OCI. Rispetto a Docker, il suc­ces­so­re designato non è dotato di permessi di root e quindi dovrebbe essere pro­por­zio­nal­men­te più sicuro. Podman è basato su Docker e ori­gi­na­ria­men­te è stato pro­get­ta­to come uno strumento di debug, prima di diventare un’al­ter­na­ti­va allo strumento di gestione che lo precede. Per fa­ci­li­ta­re il passaggio, inoltre, si possono usare in Podman i comandi di Docker. Ciò, tuttavia, non rende ancora Podman un suc­ces­so­re di pari livello.

È questa, infatti, la domanda cruciale. Poiché su RHEL 8 terminerà il supporto per Docker, gli utenti devono cercare al­ter­na­ti­ve che siano valide e com­pa­ra­bi­li. Red Hat Linux considera Podman l’al­ter­na­ti­va ottimale, molti svi­lup­pa­to­ri e svi­lup­pa­tri­ci sono però indecise e persino poco propense a usarla. Per avere una va­lu­ta­zio­ne obiettiva dal confronto tra Docker e Podman è opportuno dare un’occhiata ai punti di forza e di debolezza degli sfidanti.

Il vantaggio maggiore che offre Podman rispetto a Docker è l’assenza di un demone centrale e dei permessi di root. Ciò rende l’avvio non solo veloce, ma in termini di sicurezza questo cam­bia­men­to è ben accolto. Il sistema host è protetto e i processi con permessi di root non possono più accedere al kernel. Inoltre, per Podman anche la com­pa­ti­bi­li­tà con Docker è un grande vantaggio. La mi­gra­zio­ne avviene fa­cil­men­te e per gli am­mi­ni­stra­to­ri e le am­mi­ni­stra­tri­ci, abituate alla gestione pre­ce­den­te, anche i singoli passaggi sono molto intuitivi.

Con Podman si possono, inoltre, impiegare le re­gi­stra­zio­ni di container come Docker Hub o Quay.io. Un’altra pos­si­bi­li­tà è la creazione di dati YAML per Ku­ber­ne­tes. Lo spazio richiesto da Podman è minimo e ciò lo rende estre­ma­men­te veloce e, in pro­por­zio­ne, più ef­fi­cien­te. È ormai con­si­de­ra­to la soluzione al­ter­na­ti­va pre­de­fi­ni­ta per molte di­stri­bu­zio­ni Linux come Fedora CoreOS.

Sebbene Red Hat sia en­tu­sia­sta di Podman, il container engine non è tuttavia privo di errori. Alcuni problemi e alcuni bug, infatti, fanno sì che molti am­mi­ni­stra­to­ri e am­mi­ni­stra­tri­ci abbiano ancora dei dubbi su Podman e pre­fe­ri­sca­no altre al­ter­na­ti­ve a Docker oppure delle soluzioni ibride come Kata Con­tai­ners.

Gli errori riguardo all’uso dei container sono ab­ba­stan­za comuni. Senza un demone nella rete, la creazione e la gestione dei container tramite un host remoto sono difficili. Anche se Podman offre delle prime soluzioni in merito, questi problemi per­man­go­no. Ciò vale anche per la promessa com­pa­ti­bi­li­tà tra Podman e Docker. Non tutte le richieste, inoltre, sono comprese dal nuovo strumento.

Un giudizio finale che sta­bi­li­sca quale delle due soluzioni vinca la sfida tra Docker, lo standard per molti anni, e Podman, il suo suc­ces­so­re, è possibile solo tramite il confronto diretto dei due motori. Quali sono dunque le dif­fe­ren­ze tra i due sistemi di gestione?

Rispetto a Docker, Podman rinuncia a un demone centrale per lo sviluppo, la gestione e l’ese­cu­zio­ne di container OCI. Il concetto su cui si basa Podman è, infatti, quello dei pod di Ku­ber­ne­tes. In questo caso si rag­grup­pa­no diversi container all’interno di uno spazio dei nomi Linux comune. Ciò permette una con­fi­gu­ra­zio­ne fles­si­bi­le e diverse pos­si­bi­li­tà di com­bi­na­zio­ne. Docker non offre questa pos­si­bi­li­tà senza una con­fi­gu­ra­zio­ne ag­giun­ti­va tramite docker-compose.

Questo aspetto rap­pre­sen­ta una delle maggiori critiche rivolte a Docker. Il suo demone richiede ne­ces­sa­ria­men­te i permessi di root e ciò crea un po­ten­zia­le rischio per la sicurezza. In questo modo, i container possono anche pro­pa­gar­si at­tra­ver­so Docker e avere effetti anche sull’host. In alcune si­tua­zio­ni ciò può anche provocare gravi danni al kernel se, ad esempio, un container con­fi­gu­ra­to in modo errato ottiene l’accesso all’host. Podman risolve questo problema poiché i container possono essere avviati senza i permessi di root. A fronte di questo vantaggio, il rovescio della medaglia consiste nel fatto che gli am­mi­ni­stra­to­ri e le am­mi­ni­stra­tri­ci non possono eseguire comandi che ri­chie­do­no i permessi di root sull’host.

Nella com­pa­ra­zio­ne tra Ku­ber­ne­tes e Docker le dif­fe­ren­ze tra i due sfidanti sono evidenti, ma entrambi gli strumenti lavorano bene insieme per quanto concerne l’or­che­stra­zio­ne di container. Tuttavia, pro­ba­bil­men­te questo aspetto cambierà con Ku­ber­ne­tes 1.24, poiché Ku­ber­ne­tes sta in­ter­rom­pen­do il supporto per Docker. Invece, con Podman la col­la­bo­ra­zio­ne con­ti­nue­rà. Già dal nome si nota che Podman (al contrario di Docker) supporta anche i pod, in­tro­dot­ti da Ku­ber­ne­tes.

Di­ver­sa­men­te da Docker, Podman agisce secondo il modello fork-exec e registra le modifiche nel sistema auditd. Nel caso di Docker, invece, non avviene alcuna re­gi­stra­zio­ne.

La dif­fe­ren­za tra i due strumenti diminuirà sempre più nel tempo. At­tual­men­te, però, la do­cu­men­ta­zio­ne di Docker è am­pia­men­te migliore di quella di Podman. Dal 2013, il “veterano” ha quasi raggiunto lo status di standard e una vasta community supporta gli am­mi­ni­stra­to­ri e le am­mi­ni­stra­tri­ci per qualsiasi problema con consigli e sug­ge­ri­men­ti. Il suo suc­ces­so­re, più giovane di cinque anni, tuttavia, deve ancora fare molta strada per rag­giun­ge­re gli stessi livelli. In futuro, i due strumenti pro­ba­bil­men­te si al­li­nee­ran­no.

L’aspetto grafico dei due strumenti Docker e Podman è molto diverso, anche se ciò influisce poco sul lavoro quo­ti­dia­no. Per chi ha già di­me­sti­chez­za con Docker, passerà a Podman age­vol­men­te, anche perché molti comandi ap­pa­ri­ran­no familiari e usarli sarà semplice.

Proprio la si­mi­li­tu­di­ne in pre­ce­den­za men­zio­na­ta rende semplice la mi­gra­zio­ne da Docker a Podman. Non solo comandi come “pull”, “push”, “build”, “run”, “commit” e altri sono in buona parte identici, ma anche le immagini Docker sono com­pa­ti­bi­li con Podman. Del resto, ciò era un obiettivo per­se­gui­to dagli svi­lup­pa­to­ri. Prima di ef­fet­tua­re il passaggio, è im­por­tan­te tuttavia as­si­cu­rar­vi che Docker sia stato arrestato. In­stal­la­te quindi Podman o usate il software pre­in­stal­la­to in alcune versioni di Linux. Ri­no­mi­na­te suc­ces­si­va­men­te “Doc­ker­fi­le” e docker-compose.yml come “Con­tai­ner­fi­le” e container-compose.yml. Un altro dettaglio im­por­tan­te: Podman salva i suoi container e le immagini in un’altra posizione rispetto al suo pre­de­ces­so­re.

La sfida tra Podman e Docker è tutto sommato impari, dato che lo strumento pre­ce­den­te ha un certo vantaggio sul suo suc­ces­so­re, ma non è più sup­por­ta­to da Red Hat. Ci sono delle buone ragioni al riguardo, in par­ti­co­la­re per quanto concerne la sicurezza. Docker, infatti, da molto tempo, avrebbe avuto bisogno di maggiore at­ten­zio­ne su questo aspetto, ma le lacune sono state infine colmate da Podman. La rinuncia a un demone centrale e la migliore pro­te­zio­ne che ne deriva po­treb­be­ro essere accolte po­si­ti­va­men­te, prima o poi, anche da am­mi­ni­stra­to­ri scettici. Neanche Podman, tuttavia, è esente da errori e alcuni piccoli problemi devono essere ancora risolti. Se ciò avverrà, lo sfidante Podman supererà Docker, anche se di poco.

Molti utenti en­tu­sia­sti di Docker po­treb­be­ro ancora cambiare, prima o poi, o decidere di ricorrere a un’al­ter­na­ti­va a Ku­ber­ne­tes con cui Docker può ancora essere usato. Tuttavia, a causa della grande so­mi­glian­za delle due soluzioni container e degli sforzi di Red Hat Linux per far diventare Podman il suc­ces­so­re di Docker, è molto probabile che questo passaggio avrà successo.