Ciao, e benvenuto nella quinta puntata della dodicesima stagione. Nella scorsa puntata abbiamo distinto l'immagine, lo stampo immutabile, dal container, l'istanza viva. Ma è rimasta una domanda: come si costruisce un'immagine? Da dove viene? Oggi rispondiamo, e conosciamo uno dei protagonisti più importanti di tutto Docker, la ricetta scritta con cui si costruisce ogni immagine: il Dockerfile. È un concetto semplice ma potentissimo, che porta ordine, ripetibilità e trasparenza nella creazione degli ambienti.
Partiamo dal nome, che dice già tutto. Un Dockerfile è, semplicemente, un file di testo, un documento scritto, che contiene le istruzioni per costruire un'immagine. Riprendendo l'analogia della scorsa puntata: se l'immagine è la torta congelata e pronta, il Dockerfile è la ricetta scritta che spiega, passo per passo, come preparare quella torta. È un elenco ordinato di istruzioni che Docker legge dall'alto verso il basso ed esegue una dopo l'altra, e alla fine di questo procedimento ottiene l'immagine finita. Il Dockerfile è la ricetta, l'immagine è il risultato di averla seguita.
Cosa contiene, tipicamente, questa ricetta? Una sequenza logica di passi, che seguono più o meno sempre lo stesso ordine sensato. Il primo passo, quasi sempre, è dichiarare da quale immagine di base si parte. Ricordi che si può partire dal lavoro di altri: la prima istruzione dice, in sostanza, parti da questo ambiente già pronto, per esempio l'ambiente ufficiale del mio linguaggio. Poi vengono i passi successivi: copia dentro l'immagine il mio codice, installa le librerie di cui ho bisogno, imposta certe configurazioni, e infine dichiara qual è il comando da eseguire quando il container si avvierà. Ogni riga è un pezzo della costruzione dell'ambiente.
Fermiamoci sul primo passo, quello dell'immagine di base, perché è più profondo di quanto sembri. Praticamente nessuno costruisce un'immagine partendo dal nulla assoluto. Si parte quasi sempre da un'immagine di base già pronta, costruita da altri, che fornisce le fondamenta: un sistema minimo con già dentro, per esempio, il linguaggio che ti serve. Tu ci costruisci sopra soltanto la parte specifica del tuo programma. È di nuovo l'idea, cara al podcast, di stare sulle spalle di chi ci ha preceduto: non reinventi l'ambiente da zero, ti appoggi a fondamenta collaudate e condivise, e aggiungi solo ciò che è unico del tuo lavoro. La scelta di una buona immagine di base è una delle decisioni più importanti.
Ora voglio farti apprezzare perché questa ricetta scritta è così preziosa, perché va oltre la semplice comodità. Il grande valore del Dockerfile è che rende la costruzione dell'ambiente esplicita, scritta, ripetibile e verificabile. Prima, configurare un ambiente era un lavoro manuale, fatto di comandi digitati a mano e ricordati a memoria, impossibile da riprodurre con esattezza. Con il Dockerfile, invece, ogni singolo passo per costruire l'ambiente è scritto nero su bianco, in un file. Chiunque legga quel file capisce esattamente com'è fatto l'ambiente, e chiunque lo esegua ottiene esattamente la stessa immagine. La costruzione dell'ambiente smette di essere un'arte misteriosa e diventa una procedura trasparente e ripetibile.
Questo collega Docker a un'idea importante di cui abbiamo parlato nella stagione sul backend: l'infrastruttura come codice. Ricordi? L'idea che descrivere i sistemi con istruzioni scritte, invece di configurarli a mano, porta enormi vantaggi. Il Dockerfile è un esempio perfetto di questa filosofia. L'ambiente non è più qualcosa che sistemi a mano su una macchina, sperando di ricordare cosa hai fatto: è qualcosa che descrivi con precisione in un file di testo. E siccome è un file di testo, puoi trattarlo come codice: lo puoi conservare con il resto del progetto, tenerne traccia delle modifiche nel tempo, condividerlo, rivederlo insieme ai colleghi. L'ambiente diventa parte del progetto, versionato e curato come il codice stesso.
C'è un beneficio pratico di questo che voglio evidenziare, perché tocca il lavoro di squadra e riprende la prima stagione. Quando l'ambiente è descritto in un Dockerfile conservato insieme al progetto, un nuovo membro del team che arriva non deve più passare giorni a configurare faticosamente il proprio computer seguendo istruzioni confuse. Gli basta prendere il progetto, che contiene la ricetta, e costruire l'immagine: in pochi minuti ha l'ambiente esatto e identico a quello di tutti gli altri, garantito. La ricetta scritta trasforma un processo doloroso e soggetto a errori in un gesto automatico e affidabile. È un enorme guadagno di tempo e di serenità per tutta la squadra.
Voglio darti anche un consiglio pratico, perché scrivere un buon Dockerfile è un'arte. Come per il codice, di cui parlavamo nella prima stagione, anche un Dockerfile va scritto pensando a chi lo leggerà: ordinato, chiaro, con i passi in un ordine sensato, senza cose inutili. E come vedremo nella prossima puntata, l'ordine dei passi non è solo eleganza, ma ha conseguenze concrete sulla velocità, per via del modo ingegnoso in cui Docker costruisce le immagini.
Per oggi ci fermiamo qui. Il Dockerfile è la ricetta scritta, un file di testo con le istruzioni passo per passo per costruire un'immagine: parti da un'immagine di base già pronta, copi il tuo codice, installi ciò che serve, e dichiari il comando da eseguire. Il suo grande valore è rendere la costruzione dell'ambiente esplicita, ripetibile e trasparente, un esempio perfetto di infrastruttura come codice, che si conserva e versiona insieme al progetto e semplifica enormemente il lavoro di squadra. Nella prossima puntata scopriamo il meccanismo ingegnoso degli strati, che rende le costruzioni efficienti. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.