Ciao, e benvenuto nella quarta puntata della dodicesima stagione. Finora ho usato la parola container in modo un po' generico, per farti afferrare l'idea. Ma ora dobbiamo essere più precisi, perché nel mondo di Docker ci sono due concetti distinti che i principianti confondono di continuo, e capirne la differenza è la chiave per capire tutto il resto. I due concetti sono l'immagine e il container. Oggi li distinguiamo con chiarezza, perché una volta afferrata questa distinzione, molte cose andranno a posto da sole.
Partiamo con un'analogia che risolve il novanta per cento della confusione. Pensa alla differenza tra una ricetta e il piatto cucinato. La ricetta è il documento scritto, le istruzioni, lo stampo: descrive come fare la torta, ma non è una torta che puoi mangiare. Il piatto, invece, è la torta vera, cucinata seguendo la ricetta, quella che puoi assaporare. Da una sola ricetta puoi cucinare infinite torte, tutte uguali. Ecco: nel mondo di Docker, l'immagine è la ricetta, e il container è la torta cucinata. L'immagine è lo stampo immutabile, il container è l'istanza viva creata a partire da esso.
Rendiamo la definizione precisa. L'immagine è un pacchetto sigillato e immutabile che contiene tutto il necessario per il tuo programma: il codice, le librerie, l'ambiente. È come una fotografia congelata di un ambiente pronto all'uso, che non cambia mai. Il container, invece, è ciò che ottieni quando prendi quell'immagine e la avvii, la metti in esecuzione: è l'istanza viva e funzionante, il programma che effettivamente gira. L'immagine è ferma e statica, il container è in movimento e attivo. Costruisci un'immagine una volta, e da quella puoi avviare quanti container vuoi.
Questo punto merita di essere sottolineato, perché è potente: da una singola immagine puoi creare tanti container identici. Come da una sola ricetta cucini cento torte uguali, da una sola immagine avvii cento container tutti uguali, ciascuno una copia viva e indipendente dello stesso ambiente congelato. Ricordi la stagione sul backend, e il bisogno di far girare tante copie identiche del proprio programma per reggere la scala? Ecco, l'immagine è ciò che rende questo banale: prepari l'ambiente una volta, lo congeli in un'immagine, e poi ne sforni istanze identiche a piacere. La riproducibilità perfetta nasce proprio da qui, dall'immutabilità dell'immagine.
C'è una conseguenza importante dell'immutabilità dell'immagine che vale la pena capire. Siccome l'immagine non cambia mai, è congelata, ti dà una garanzia fortissima: ogni container avviato da quella immagine parte esattamente dalle stesse identiche condizioni, sempre. Non c'è modo che due container dalla stessa immagine partano diversi, perché nascono tutti dallo stesso stampo immutabile. Questo è il fondamento della coerenza di cui abbiamo tanto parlato: l'immagine è il punto fermo, la verità congelata, da cui tutto parte uguale. Se qualcosa deve cambiare, non modifichi l'immagine esistente: ne costruisci una nuova versione. L'immagine, una volta fatta, è sacra e intoccabile.
Ora ti introduco un'idea che moltiplica il valore delle immagini: le immagini si possono condividere. Siccome un'immagine è un pacchetto autosufficiente e congelato, puoi prenderla e spedirla ad altri, o pubblicarla in un luogo comune da cui chiunque può scaricarla. Esistono infatti dei grandi magazzini pubblici di immagini, delle biblioteche online, dove sono raccolte moltissime immagini già pronte, costruite e condivise dalla comunità e dalle aziende. Hai bisogno di un database pronto all'uso? Scarichi l'immagine già pronta di quel database e la avvii, senza doverla costruire tu. Hai bisogno di un ambiente per un certo linguaggio? C'è già l'immagine pronta.
Questa possibilità di condividere e riutilizzare immagini già pronte è enormemente potente, e riprende un tema caro al podcast. Riprendo la stagione sull'open source: puoi partire dal lavoro già fatto da altri, invece di costruire tutto da zero. Vuoi il tuo programma? Parti dall'immagine ufficiale già pronta del tuo linguaggio, che qualcuno ha già preparato con cura, e ci aggiungi solo il tuo codice. Non reinventi l'ambiente ogni volta: ti appoggi a fondamenta pronte e collaudate, condivise da tutta la comunità. Questa cultura del condividere e riutilizzare immagini è una delle cose che rende l'ecosistema dei container così produttivo e ricco.
Voglio fissare bene la distinzione con un'ultima immagine mentale, perché è davvero la chiave di tutto. Pensa all'immagine come a uno stampo per biscotti, quella forma di metallo rigida e immutabile. Il container è il biscotto che esce da quello stampo: puoi farne quanti vuoi, tutti della stessa forma, e mangiarli, mentre lo stampo resta lì, sempre uguale, pronto a produrne altri. Lo stampo è uno, i biscotti sono tanti. L'immagine è una, i container sono tanti. Quando senti parlare di costruire, si parla quasi sempre dell'immagine, lo stampo; quando si parla di eseguire, si parla del container, il biscotto vivo. Tieni a mente questa coppia e non ti perderai più.
Per oggi ci fermiamo qui. Immagine e container sono due concetti distinti: l'immagine è la ricetta, lo stampo immutabile e congelato che contiene tutto l'ambiente; il container è la torta, l'istanza viva e funzionante avviata a partire dall'immagine. Da una sola immagine si avviano infiniti container identici, e questa è la radice della riproducibilità perfetta. Le immagini, essendo pacchetti autosufficienti, si possono condividere e riutilizzare attraverso grandi biblioteche pubbliche, appoggiandosi al lavoro di altri. Nella prossima puntata vediamo come si costruisce un'immagine: la ricetta scritta, il Dockerfile. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.