Containerd vs. Docker

Ci sono alcune domande che spesso ricorrono nell’informatica, che differenza c’è fra Git e Github… (risposta, parecchia) per cui ho voluto fare una breve sinstesi di una delle domande che mi sono state poste con più frequenza. Che differenza c’è fra Docker e ContainerD. In quest’articolo andrò ad analizzare le due risorse fondamentali per le applicazioni basate su container, Containerd e Docker, spiegando che, sebbene siano spesso usate insieme, ricoprono ruoli distinti nella gestione dei container.

Cos’è Docker?

Docker è una soluzione PaaS (Platform as a Service) e un motore di container open-source. È uno strumento ad alto livello che offre un’esperienza di sviluppo completa.

• Orientamento: È “a misura d’uomo” e progettatato per interagire direttamente con gli sviluppatori tramite la sua CLI (Command Line Interface).
• Funzionalità: Fornisce un ecosistema completo che include Docker Engine, CLI e altre risorse. Semplifica drasticamente il processo di creazione, gestione e ottimizzazione dei container.
• Vantaggi: Riduce i tempi e i costi di sviluppo, migliora la produttività e offre una grande flessibilità operativa.

Cos’è Containerd?

Containerd è un runtime di container essenziale. È un processo daemon che opera dietro le quinte e gestisce l’intera esistenza dei container su un host. Inizialmente era un derivato di Docker Engine, ma è stato poi donato alla CNCF (Cloud Native Computing Foundation).

• Orientamento: È “orientato ai dispositivi” e lavora a basso livello.
• Funzionalità: È responsabile della gestione del ciclo di vita del container (creazione, esecuzione, distruzione), del pull delle immagini (scaricamento), della configurazione della rete e della gestione dello storage.
• Requisiti: Spesso utilizza un runtime di livello inferiore come runc per avviare e gestire effettivamente i container a livello del sistema operativo.

Le Principali Differenze

La differenza fondamentale risiede nel loro ruolo all’interno dello stack tecnologico:

Caratteristica	Docker	Containerd
Livello	Alto livello (Piattaforma)	Basso livello (Runtime)
Interazione Utente	Interagisce direttamente tramite CLI	Opera come un daemon in background
Ruolo	Accetta le richieste dell’utente (es. docker run)	Esegue le azioni necessarie per la containerizzazione
Complessità/Risorse	Ampio e ricco di funzionalità	Leggero e con risorse limitate
Dipendenza	Richiede Containerd per funzionare	Può funzionare senza Docker CLI

In sintesi:

1. Docker è un ecosistema completo che prende le istruzioni dell’utente e le traduce in azioni.
2. Containerd è il componente essenziale che riceve gli ordini (da Docker o da orchestratori come Kubernetes) e si assicura che il container venga effettivamente scaricato ed eseguito sull’host.

Per la containerizzazione è obbligatorio avere Containerd (o un altro runtime), mentre Docker è uno strumento opzionale per semplificare e gestire l’intero processo.

Quali sono le alternative a Containerd?

Containerd è uno dei runtime di container ad alto livello più diffusi, soprattutto perché è lo standard in Kubernetes e il backend di Docker. Tuttavia, esistono diverse alternative, specialmente nel contesto di Kubernetes.

Le principali alternative a containerd come runtime conforme a CRI (Container Runtime Interface) per Kubernetes sono:

1. CRI-O: L’Alternativa Nata per Kubernetes

CRI-O è l’alternativa più diretta a containerd, in quanto è anch’essa un runtime di container ad alto livello che implementa la specifica CRI di Kubernetes.

• Focus principale: A differenza di containerd, che è un runtime più generico (utilizzato anche da Docker), CRI-O è stato costruito esclusivamente per Kubernetes.
• Architettura: È progettato per essere leggero, minimalista e privo di funzionalità non necessarie per l’orchestrazione di Kubernetes, riducendo la superficie di attacco e la complessità.
• Utilizzo: È spesso la scelta preferita in ambienti come Red Hat OpenShift che mirano al minimalismo e a un runtime strettamente ottimizzato per Kubernetes.

2. Runtimes a Basso Livello (Runtime OCI)

Sia containerd che CRI-O si appoggiano a runtime di basso livello conformi alla specifica OCI (Open Container Initiative) per interagire direttamente con il kernel del sistema operativo e avviare il container. Questi non sono alternative dirette a containerd nel senso di rimpiazzarlo nello stack, ma sono i motori di esecuzione effettivi che possono essere utilizzati:

• runC: È il runtime OCI standard de facto e quello predefinito utilizzato sia da containerd che da CRI-O. È un’implementazione minimalista per l’esecuzione dei container.
• crun: Un’alternativa a runC implementata in C (invece che in Go), nota per le sue prestazioni e il basso consumo di memoria.

3. Runtimes di Sicurezza e Virtualizzazione

Esistono anche runtime che aggiungono un livello di isolamento superiore, spesso tramite l’utilizzo di macchine virtuali leggere (MicroVMs):

• Kata Containers: Utilizza MicroVMs (come Firecracker di AWS) per fornire una forte separazione tra i container, offrendo un maggiore isolamento di sicurezza, ideale per carichi di lavoro sensibili.
• gVisor (Google): Un runtime che intercetta le chiamate di sistema del container prima che raggiungano il kernel dell’host. Questo crea un kernel utente per ogni container, migliorando l’isolamento senza il sovraccarico di una VM completa.

4. Piattaforme che Eseguono Runtime

Infine, ci sono strumenti che offrono un’esperienza utente completa (similmente a come faceva Docker prima della sua modularizzazione) o che sono piattaforme di orchestrazione che possono supportare diversi runtime:

• Podman: Un motore di container open source daemonless (senza un processo sempre attivo in background), che si propone come alternativa a Docker. Può eseguire i container direttamente senza containerd, appoggiandosi ai runtime OCI a basso livello.
• LXC (Linux Containers): Una tecnologia di containerizzazione a livello di sistema operativo Linux, che fornisce un isolamento a livello di sistema. Storicamente è stato il precursore di Docker.