Ciao, e benvenuto nella sesta puntata della dodicesima stagione. Nella scorsa puntata abbiamo scritto la ricetta, il Dockerfile, e alla fine ho accennato a un meccanismo ingegnoso che rende le costruzioni efficienti, e che spiega perché l'ordine delle istruzioni conta. Oggi svisceriamo quel meccanismo, che è una delle idee più eleganti di tutto Docker e che i principianti spesso ignorano, pagandone il prezzo in lentezza: il sistema degli strati. Capirlo ti farà scrivere immagini più veloci e leggere, e ti darà un vero momento di illuminazione su come funziona Docker sotto il cofano.
Partiamo dall'idea di base. Ricordi che il Dockerfile è una sequenza di istruzioni, eseguite una dopo l'altra dall'alto verso il basso. Ebbene, ecco il punto centrale: ogni istruzione del Dockerfile crea uno strato, uno strato dell'immagine. L'immagine finale non è un blocco unico e indistinto, ma è fatta di tanti strati sovrapposti, impilati uno sull'altro, ciascuno corrispondente a un passo della ricetta. Il primo strato è l'immagine di base, poi ogni istruzione successiva aggiunge un nuovo strato sopra, come i fogli di una lasagna che si accumulano. L'immagine è la pila completa di tutti questi strati.
Ora arriva la parte geniale, quella che rende il sistema così efficiente: gli strati vengono conservati e riutilizzati. Docker tiene in memoria gli strati che ha già costruito, e quando ricostruisci un'immagine, non rifà da capo tutti gli strati: riutilizza quelli che non sono cambiati, e ricostruisce solo quelli nuovi o modificati. Questo si chiama uso della memoria di ciò che è già stato fatto. Se ricostruisci un'immagine dopo aver cambiato solo il tuo codice, Docker non reinstalla tutto da zero: riparte dagli strati già pronti e rifà solo la parte finale che è cambiata. Il che rende le ricostruzioni, dopo la prima, molto più veloci.
Facciamo un esempio concreto per capire la potenza di questo. Immagina che la tua ricetta faccia tre cose: parte da un ambiente di base, poi installa un mucchio di librerie, che è un'operazione lunga, e infine copia il tuo codice, che è veloce. La prima volta, Docker fa tutti e tre i passi, e ci mette un po' per via delle librerie. Ma la seconda volta, se hai cambiato solo il tuo codice e non le librerie, Docker si accorge che i primi due strati, l'ambiente di base e le librerie, non sono cambiati, e li riutilizza istantaneamente dalla memoria. Rifà solo l'ultimo strato, la copia del codice, che è velocissima. Da minuti a pochi secondi. Questa è la magia degli strati riutilizzati.
Ed è qui che si capisce perché l'ordine delle istruzioni conta enormemente, il punto che avevo anticipato. Siccome Docker riutilizza gli strati fino al primo che cambia, e poi ricostruisce tutto ciò che viene dopo, ti conviene mettere le cose che cambiano raramente all'inizio, e le cose che cambiano spesso alla fine. Le librerie, che cambi di rado, vanno messe prima; il tuo codice, che cambi di continuo, va messo dopo. Così, quando cambi il codice, Docker riutilizza tutti gli strati precedenti delle librerie e rifà solo l'ultimo. Se invece, per errore, metti la copia del codice prima dell'installazione delle librerie, allora ogni volta che tocchi il codice invalidi tutto ciò che segue, e Docker si ritrova a reinstallare le librerie ogni volta. Un errore che rende le costruzioni lentissime.
Questo è un esempio bellissimo di come capire il meccanismo interno ti renda più bravo, un tema caro a questo podcast. Chi non sa nulla degli strati scrive Dockerfile a caso, e si ritrova ricostruzioni lente senza capirne il motivo, dando la colpa a Docker. Chi invece capisce come funzionano gli strati e la loro memoria, ordina le istruzioni con intelligenza e ottiene costruzioni fulminee. Riprendo la prima stagione: la differenza tra usare uno strumento a scatola chiusa e capire come funziona dentro è enorme, e si vede proprio in questi dettagli. Un piccolo pezzo di comprensione si traduce in un grande guadagno pratico quotidiano.
Gli strati hanno un altro vantaggio, oltre alla velocità: il risparmio di spazio. Se hai dieci immagini diverse che partono dallo stesso ambiente di base, quello strato non viene copiato dieci volte, ma conservato una volta sola e condiviso tra tutte. È come se più lasagne condividessero lo stesso primo strato di pasta. Un altro pezzo dell'eleganza efficiente del sistema.
Voglio darti anche l'avvertenza che completa il quadro. Il rovescio della medaglia è che, siccome ogni istruzione aggiunge uno strato, un Dockerfile scritto senza attenzione può produrre immagini gonfie, molto più grandi del necessario, lente da spostare e avviare. Per questo esistono tecniche per tenere le immagini snelle: unire le operazioni con giudizio, eliminare ciò che non serve, partire da immagini di base minime. Scrivere immagini leggere è, di nuovo, un segno di cura e competenza.
Per oggi ci fermiamo qui. Ogni istruzione di un Dockerfile crea uno strato, e l'immagine è la pila di questi strati sovrapposti. La genialità è che gli strati vengono conservati e riutilizzati: ricostruendo, Docker rifà solo ciò che è cambiato, rendendo le ricostruzioni velocissime. Per questo l'ordine conta: metti prima ciò che cambia di rado, dopo ciò che cambia spesso. Gli strati si condividono anche tra immagini, risparmiando spazio, ma vanno tenuti d'occhio per non gonfiare le immagini. Nella prossima puntata affrontiamo un problema cruciale: come non perdere i dati quando un container muore. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.