Per anni la frase più temuta da chi gestisce server è stata «sul mio computer funziona». Un'applicazione che gira perfettamente sul portatile dello sviluppatore smette di funzionare in produzione perché manca una libreria, la versione di Python è diversa o una variabile di sistema non è impostata. I container sono nati proprio per eliminare questa distanza tra ambienti: impacchettano il programma insieme a tutto ciò di cui ha bisogno per girare.
Che cos'è un container
Un container è un processo isolato che gira sul sistema operativo dell'host, ma vede un proprio file system, una propria rete e un proprio elenco di processi. Dal suo punto di vista sembra di stare su una macchina dedicata; in realtà condivide il kernel con tutti gli altri container della stessa macchina.
Su Linux questo isolamento si ottiene con due meccanismi del kernel:
- namespace, che separano ciò che il processo può vedere (processi, rete, punti di montaggio, utenti, nome host);
- cgroup, che limitano ciò che il processo può consumare (CPU, memoria, operazioni di I/O).
Container e macchine virtuali
La differenza con una macchina virtuale è sostanziale e conviene averla chiara.
| Aspetto | Macchina virtuale | Container |
|---|---|---|
| Cosa virtualizza | L'hardware intero | Il sistema operativo |
| Kernel | Uno per ogni VM | Condiviso con l'host |
| Avvio | Decine di secondi o minuti | Di solito meno di un secondo |
| Dimensione tipica | Gigabyte | Da pochi a qualche centinaio di megabyte |
| Isolamento | Molto forte | Buono, ma più sottile |
Una VM contiene un sistema operativo completo, con il suo kernel, i suoi servizi e i suoi aggiornamenti da gestire. Un container contiene solo l'applicazione e le librerie che le servono. Per questo su un server se ne possono far girare molti più che di VM.
L'altra faccia della medaglia è l'isolamento: poiché il kernel è condiviso, una vulnerabilità del kernel può in teoria permettere a un container di uscire dal proprio recinto. Per carichi davvero non fidati, o per separare clienti diversi, la VM resta più robusta. Nella pratica si usano spesso entrambe: container che girano dentro macchine virtuali.
Immagini e layer
Un container nasce da un'immagine, cioè un pacchetto di sola lettura che contiene il file system di partenza e i metadati su come avviare il processo. L'immagine è costruita a strati: ogni istruzione della ricetta di build aggiunge un layer sopra al precedente.
Questo sistema ha conseguenze pratiche importanti:
- I layer comuni vengono condivisi. Se dieci immagini partono dalla stessa base Debian, la base è scaricata e salvata una volta sola.
- Le build sono rapide, perché i layer non modificati vengono riutilizzati dalla cache.
- Quando un container gira, aggiunge sopra l'immagine uno strato scrivibile temporaneo. Alla sua cancellazione quello strato sparisce.
L'ultimo punto è il più frainteso: un container è effimero. Tutto ciò che scrive al proprio interno va perso quando viene ricreato. I dati che devono sopravvivere, come un database o i file caricati dagli utenti, vanno salvati su volumi esterni al container.
Perché i container hanno cambiato il deploy
Il vantaggio principale non è tecnico ma organizzativo: l'immagine diventa l'unità di rilascio. Lo stesso identico artefatto passa dal computer dello sviluppatore ai test automatici, poi allo staging e infine alla produzione. Se qualcosa si rompe, si torna all'immagine precedente con un solo comando.
Altri benefici concreti:
- Dipendenze isolate: due applicazioni che richiedono versioni diverse della stessa libreria convivono sulla stessa macchina senza conflitti.
- Ambiente di sviluppo rapido: un nuovo collaboratore avvia database, coda di messaggi e applicazione in pochi minuti, senza installare nulla a mano.
- Portabilità: l'immagine gira allo stesso modo su un portatile, su un VPS o su un servizio cloud gestito.
- Scalabilità: avviare dieci copie di un servizio è banale quando ciascuna è un container identico.
Quando i container non sono la risposta
I container non sono obbligatori. Per un sito statico, uno script lanciato una volta al giorno o un'applicazione desktop, aggiungono complessità senza un vero ritorno. Anche un singolo server con un'unica applicazione stabile può vivere benissimo senza.
Ci sono inoltre aspetti da mettere in conto fin da subito:
- le immagini vanno aggiornate regolarmente, perché contengono librerie che invecchiano e accumulano vulnerabilità;
- i log non vanno scritti su file dentro il container, ma sullo standard output, dove il sistema può raccoglierli;
- la gestione di rete e volumi richiede un minimo di studio per non perdere dati.
Nel mio lavoro il criterio è semplice: se un'applicazione ha dipendenze non banali, deve girare in più ambienti o deve essere riprodotta da più persone, il container ripaga in fretta lo sforzo iniziale. Se invece è un servizio piccolo e immobile, spesso basta un buon pacchetto di sistema e un file di configurazione documentato.
Gli strumenti dell'ecosistema
Docker ha reso popolari i container, ma oggi il formato delle immagini è standardizzato dalla Open Container Initiative. Questo significa che un'immagine costruita con Docker può essere eseguita anche con Podman o con i runtime usati da Kubernetes. Imparare i concetti, più che il singolo strumento, è l'investimento che dura.
In sintesi
- Un container è un processo Linux isolato con namespace e cgroup, che condivide il kernel dell'host.
- È più leggero e rapido di una macchina virtuale, ma offre un isolamento meno forte.
- Le immagini sono composte da layer riutilizzabili; i dati persistenti vanno sempre sui volumi.
- Il vero vantaggio è avere un unico artefatto che viaggia identico dallo sviluppo alla produzione.
- Per progetti piccoli e stabili i container possono essere una complessità inutile.
