Programmazione · DevOps · Container

Docker vs Podman: quale motore di container, e quando?

Risposta rapida: Docker e Podman fanno lo stesso lavoro di fondo — costruire ed eseguire container — e usano lo stesso formato d’immagine, quindi un’immagine costruita con uno gira sull’altro. La differenza principale è l’architettura: Docker esegue i container tramite un daemon centrale di lunga durata (dockerd) che di solito gira come root, mentre Podman è senza daemon e rootless per progettazione, avviando ogni container come un normale processo figlio. Le loro righe di comando sono abbastanza vicine perché alias docker=podman copra gran parte dell’uso quotidiano. Scegli Podman quando vuoi fare a meno del daemon root e avere un’integrazione stretta con systemd; resta su Docker quando dipendi da Docker Desktop, da un flusso Compose maturo o da un ecosistema più ampio.

Se sei alle prime armi con l’uno o con l’altro, conviene capire prima cosa sono Docker e i container. Questa guida parte da lì e si concentra su ciò che distingue i due motori.

Architettura: con daemon vs senza daemon

Docker si basa su un modello client-server. Il comando docker che digiti è un client che parla con un servizio in background, il daemon di Docker (dockerd), che in realtà crea ed esegue i tuoi container. Quel daemon gira di continuo e, nella configurazione predefinita, come root. È comodo — un solo servizio gestisce tutto — ma è anche un unico processo privilegiato che possiede tutti i container dell’host.

Podman prende un’altra strada. Nessun daemon centrale: quando avvii un container, Podman lo fa fork e poi exec direttamente come processo figlio della tua shell, usando le stesse primitive Linux (namespace, cgroup). Ogni container è solo un normale albero di processi. Questo modello senza daemon significa che non c’è un servizio root sempre attivo da compromettere, e che un crash in un container non passa attraverso un daemon condiviso.

Container rootless e sicurezza

Questa differenza di architettura porta alla differenza di sicurezza che conta di più. Podman è stato costruito per girare in rootless: un utente senza privilegi può costruire ed eseguire container senza root, usando gli user namespace per mappare gli UID del container sull’host. Anche Docker può girare in rootless, e lo supporta da anni, ma la sua installazione predefinita resta incentrata sul daemon root, quindi il rootless è una modalità opzionale più che la base.

Non avere un daemon root riduce la superficie di attacco: non c’è un servizio privilegiato in background che una fuga dal container potrebbe prendere di mira per impadronirsi dell’host. Per server multiutente e runner di CI, quella proprietà di «nessun daemon root» è un motivo concreto e reale per passare a Podman. Non è magia — i container richiedono comunque una configurazione attenta — ma la postura predefinita è più conservativa.

Stesse immagini, CLI quasi identica

Ecco la parte che rende il passaggio indolore: entrambi gli strumenti seguono gli standard OCI (Open Container Initiative) per immagini ed esecuzione. Un’immagine costruita con Docker gira sotto Podman e viceversa, ed entrambi scaricano dagli stessi registry (Docker Hub, GitHub Container Registry, Quay e altri). Non esiste un formato d’immagine esclusivo di Docker o di Podman.

Le righe di comando sono volutamente simili. podman run, podman build, podman ps e podman pull rispecchiano i loro equivalenti Docker, con gli stessi flag comuni. Molti impostano semplicemente un alias:

alias docker=podman

e mantengono le proprie abitudini. Anche i Dockerfile funzionano così come sono sotto Podman. La CLI non è identica al 100 % in ogni caso limite, ma per costruire ed eseguire ogni giorno è abbastanza vicina perché la memoria muscolare si trasferisca.

I pod: il raggruppamento in stile Kubernetes di Podman

Podman prende il nome dal pod — un concetto che mutua da Kubernetes. Un pod è un gruppo di container che condividono risorse come un namespace di rete, così da comunicare tra loro via localhost come se fossero sulla stessa macchina. Podman può creare e gestire questi pod direttamente, il che avvicina lo sviluppo locale al modo in cui le cose girano in un cluster Kubernetes. Docker non ha una primitiva «pod» nativa nello stesso senso; i montaggi multi-container si compongono con le reti di Compose.

Integrazione con systemd

Poiché i container di Podman sono normali processi figli anziché figli di un daemon, si inseriscono naturalmente in systemd, il gestore di servizi di Linux. Storicamente si poteva eseguire podman generate systemd per produrre un file di unit per container; l’approccio attuale raccomandato è Quadlet, che permette di descrivere i container in file dichiarativi in stile unit gestiti direttamente da systemd — avviandoli al boot, riavviandoli in caso di errore e seguendoli come qualsiasi altro servizio. Per i server che già usano systemd per tutto il resto, è un modo pulito per tenere i container sotto lo stesso supervisore senza un daemon aggiuntivo.

Compose: docker compose vs podman

Molti progetti si affidano a Compose per avviare più container da un solo file YAML. Docker fornisce docker compose (il plugin Compose v2) come strumento di prima classe e ben mantenuto. Anche Podman supporta i flussi Compose: può lavorare con lo strumento separato podman-compose, e Podman fornisce inoltre un socket con cui il tooling Compose standard può dialogare, così che file compose.yaml esistenti spesso girano con poche o nessuna modifica. In pratica, l’esperienza Compose di Docker è la più matura e rifinita delle due, il che spiega perché i team con uso intensivo di Compose a volte restano su Docker.

Licenza di Docker Desktop vs modello open source di Podman

Su Windows e macOS, Docker si usa di solito tramite Docker Desktop. Docker Desktop è gratuito per uso personale, didattica e piccole imprese, ma richiede un abbonamento a pagamento per le organizzazioni più grandi (oltre la soglia di dimensione pubblicata da Docker). Questo cambio di licenza è una reale questione di budget e conformità per le aziende più grandi.

Podman è completamente open source e gratuito, senza licenza per postazione. Il suo compagno desktop, Podman Desktop, è anch’esso open source. Per le organizzazioni che vogliono evitare una licenza desktop commerciale — o semplicemente preferire uno stack open source end-to-end — questa differenza conta quanto qualsiasi differenza tecnica.

Quindi, quale usare?

Criterio	Docker	Podman
Architettura	Daemon centrale (dockerd)	Senza daemon (fork/exec per container)
Rootless	Supportato, opzionale	Rootless per progettazione (predefinito)
Formato immagine	OCI	OCI — intercambiabile con Docker
CLI	CLI di riferimento	Quasi identica (alias docker=podman)
Pod	Nessuna primitiva pod nativa	Pod nativi (stile Kubernetes)
systemd	Gira sotto il daemon	Unit native tramite Quadlet
Compose	docker compose (maturo)	podman-compose / Compose via socket
Licenza desktop	Docker Desktop a pagamento per org grandi	Open source, gratuito (Podman Desktop)

Non c’è un vincitore universale. Scegli Podman quando vuoi fare a meno del daemon root, avere container rootless di default, una gestione systemd/Quadlet nativa, o evitare la licenza di Docker Desktop. Resta su Docker quando dipendi da Docker Desktop, da un flusso Compose maturo, o dall’ampiezza del suo ecosistema e della sua documentazione. Poiché entrambi parlano OCI, puoi anche mescolarli — costruire con uno, eseguire con l’altro — o provare Podman senza buttare via le tue immagini e i tuoi Dockerfile esistenti. E se in seguito devi orchestrare molti container su più macchine, è un compito per Kubernetes, che si colloca al di sopra di entrambi.