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 Enterprise Linux 8 (RHEL 8) è stato interrotto, molti amministratori e amministratrici devono trovare una nuova soluzione. Podman, sempre di Red Hat, è considerato il diretto successore e, facendo a meno di un demone centrale e dei privilegi di root, è in grado di allontanare molte preoccupazioni sulla sicurezza del suo predecessore. Per il resto, i due strumenti sono simili, anche se Podman deve ancora fare i conti con alcuni bug.

Il mondo dei container è attualmente in fermento. Docker, una delle soluzioni più popolari e apprezzate, non riceverà più alcun supporto ufficiale su Red Hat Enterprise Linux 8. L’azienda produttrice, Red Hat, ha però la nuova soluzione già pronta: Podman. L’ambiente CRI-O è proposto da Red Hat come una soluzione perfettamente equivalente e quindi i fan di Docker non dovrebbero preoccuparsi. La possibilità che in futuro Podman possa davvero sostituire Docker senza limiti resta un’altra faccenda. Per dare una risposta al riguardo è meglio analizzare prima di tutto le tecnologie di entrambi i container.

Dal 2013, quando Docker è stato introdotto come software open source, la sua tecnologia è stata molto apprezzata e ha riscosso molto successo. La soluzione leggera e allo stesso tempo pratica e affidabile offre agli utenti la possibilità di un approccio più libero per lo sviluppo di applicazioni. Tramite l’immagine di un container, è possibile trasferire e installare facilmente i pacchetti come dati. Una singola immagine Docker può anche creare un numero illimitato di container per realizzare, ad esempio, dei cloud OpenStack. Docker, inoltre, è completamente isolato, tranne che per alcune interfacce al sistema operativo o all’hardware. I container contengono soltanto le informazioni veramente necessarie e sono pertanto relativamente leggeri.

Secondo i piani di Red Hat Linux, Docker sarà sostituito da Podman, concepito per la gestione di pod con il fine di creare e sviluppare ulteriormente i container e compatibile con la specifica dei container OCI. Rispetto a Docker, il successore designato non è dotato di permessi di root e quindi dovrebbe essere proporzionalmente più sicuro. Podman è basato su Docker e originariamente è stato progettato come uno strumento di debug, prima di diventare un’alternativa allo strumento di gestione che lo precede. Per facilitare il passaggio, inoltre, si possono usare in Podman i comandi di Docker. Ciò, tuttavia, non rende ancora Podman un successore di pari livello.

È questa, infatti, la domanda cruciale. Poiché su RHEL 8 terminerà il supporto per Docker, gli utenti devono cercare alternative che siano valide e comparabili. Red Hat Linux considera Podman l’alternativa ottimale, molti sviluppatori e sviluppatrici sono però indecise e persino poco propense a usarla. Per avere una valutazione 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 cambiamento è ben accolto. Il sistema host è protetto e i processi con permessi di root non possono più accedere al kernel. Inoltre, per Podman anche la compatibilità con Docker è un grande vantaggio. La migrazione avviene facilmente e per gli amministratori e le amministratrici, abituate alla gestione precedente, anche i singoli passaggi sono molto intuitivi.

Con Podman si possono, inoltre, impiegare le registrazioni di container come Docker Hub o Quay.io. Un’altra possibilità è la creazione di dati YAML per Kubernetes. Lo spazio richiesto da Podman è minimo e ciò lo rende estremamente veloce e, in proporzione, più efficiente. È ormai considerato la soluzione alternativa predefinita per molte distribuzioni Linux come Fedora CoreOS.

Sebbene Red Hat sia entusiasta di Podman, il container engine non è tuttavia privo di errori. Alcuni problemi e alcuni bug, infatti, fanno sì che molti amministratori e amministratrici abbiano ancora dei dubbi su Podman e preferiscano altre alternative a Docker oppure delle soluzioni ibride come Kata Containers.

Gli errori riguardo all’uso dei container sono abbastanza 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 permangono. Ciò vale anche per la promessa compatibilità tra Podman e Docker. Non tutte le richieste, inoltre, sono comprese dal nuovo strumento.

Un giudizio finale che stabilisca quale delle due soluzioni vinca la sfida tra Docker, lo standard per molti anni, e Podman, il suo successore, è possibile solo tramite il confronto diretto dei due motori. Quali sono dunque le differenze tra i due sistemi di gestione?

Rispetto a Docker, Podman rinuncia a un demone centrale per lo sviluppo, la gestione e l’esecuzione di container OCI. Il concetto su cui si basa Podman è, infatti, quello dei pod di Kubernetes. In questo caso si raggruppano diversi container all’interno di uno spazio dei nomi Linux comune. Ciò permette una configurazione flessibile e diverse possibilità di combinazione. Docker non offre questa possibilità senza una configurazione aggiuntiva tramite docker-compose.

Questo aspetto rappresenta una delle maggiori critiche rivolte a Docker. Il suo demone richiede necessariamente i permessi di root e ciò crea un potenziale rischio per la sicurezza. In questo modo, i container possono anche propagarsi attraverso Docker e avere effetti anche sull’host. In alcune situazioni ciò può anche provocare gravi danni al kernel se, ad esempio, un container configurato 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 amministratori e le amministratrici non possono eseguire comandi che richiedono i permessi di root sull’host.

Nella comparazione tra Kubernetes e Docker le differenze tra i due sfidanti sono evidenti, ma entrambi gli strumenti lavorano bene insieme per quanto concerne l’orchestrazione di container. Tuttavia, probabilmente questo aspetto cambierà con Kubernetes 1.24, poiché Kubernetes sta interrompendo il supporto per Docker. Invece, con Podman la collaborazione continuerà. Già dal nome si nota che Podman (al contrario di Docker) supporta anche i pod, introdotti da Kubernetes.

Diversamente da Docker, Podman agisce secondo il modello fork-exec e registra le modifiche nel sistema auditd. Nel caso di Docker, invece, non avviene alcuna registrazione.

La differenza tra i due strumenti diminuirà sempre più nel tempo. Attualmente, però, la documentazione di Docker è ampiamente migliore di quella di Podman. Dal 2013, il “veterano” ha quasi raggiunto lo status di standard e una vasta community supporta gli amministratori e le amministratrici per qualsiasi problema con consigli e suggerimenti. Il suo successore, più giovane di cinque anni, tuttavia, deve ancora fare molta strada per raggiungere gli stessi livelli. In futuro, i due strumenti probabilmente si allineeranno.

L’aspetto grafico dei due strumenti Docker e Podman è molto diverso, anche se ciò influisce poco sul lavoro quotidiano. Per chi ha già dimestichezza con Docker, passerà a Podman agevolmente, anche perché molti comandi appariranno familiari e usarli sarà semplice.

Proprio la similitudine in precedenza menzionata rende semplice la migrazione 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 compatibili con Podman. Del resto, ciò era un obiettivo perseguito dagli sviluppatori. Prima di effettuare il passaggio, è importante tuttavia assicurarvi che Docker sia stato arrestato. Installate quindi Podman o usate il software preinstallato in alcune versioni di Linux. Rinominate successivamente “Dockerfile” e docker-compose.yml come “Containerfile” e container-compose.yml. Un altro dettaglio importante: Podman salva i suoi container e le immagini in un’altra posizione rispetto al suo predecessore.

La sfida tra Podman e Docker è tutto sommato impari, dato che lo strumento precedente ha un certo vantaggio sul suo successore, ma non è più supportato da Red Hat. Ci sono delle buone ragioni al riguardo, in particolare per quanto concerne la sicurezza. Docker, infatti, da molto tempo, avrebbe avuto bisogno di maggiore attenzione su questo aspetto, ma le lacune sono state infine colmate da Podman. La rinuncia a un demone centrale e la migliore protezione che ne deriva potrebbero essere accolte positivamente, prima o poi, anche da amministratori 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 entusiasti di Docker potrebbero ancora cambiare, prima o poi, o decidere di ricorrere a un’alternativa a Kubernetes con cui Docker può ancora essere usato. Tuttavia, a causa della grande somiglianza delle due soluzioni container e degli sforzi di Red Hat Linux per far diventare Podman il successore di Docker, è molto probabile che questo passaggio avrà successo.