Ciao, e benvenuto nella settima puntata della dodicesima stagione. Finora abbiamo celebrato i container per la loro leggerezza e per il fatto di essere usa e getta. Ma questa qualità nasconde un problema serio, che oggi affrontiamo di petto, perché è uno dei punti su cui i principianti sbagliano più spesso, con conseguenze dolorose: se i container sono usa e getta, cosa succede ai dati quando un container viene buttato via? Come facciamo a non perdere le cose importanti? La risposta si chiama volumi, ed è essenziale per usare Docker in modo serio.
Partiamo dal problema, che è cruciale capire bene. Abbiamo detto che i container sono effimeri, usa e getta: li avvii, li spegni, li butti via, ne crei di nuovi con disinvoltura. Ma ecco il punto: quando butti via un container, tutto ciò che era stato scritto o modificato al suo interno sparisce con lui, per sempre. Il container nasce sempre pulito dalla sua immagine immutabile, e qualsiasi cosa cambi durante la sua vita viene cancellata quando il container muore. È come una lavagna che, ogni volta che chiudi il container, viene pulita completamente, tornando allo stato di partenza.
Riprendo qui un tema che avevamo affrontato nella stagione sul backend, perché è lo stesso identico problema. Ricordi quando parlavamo della memoria volatile, quella che sparisce quando il programma si ferma, e della necessità di una memoria permanente, il database, per conservare i dati? Ecco: il contenuto interno di un container è come quella memoria volatile. Va benissimo per il programma in esecuzione, ma non è il posto dove conservare qualcosa che deve sopravvivere. Se metti dati importanti dentro un container e poi quel container viene sostituito, come succede di continuo, quei dati sono persi. È un disastro annunciato, se non lo sai.
Facciamo un esempio che rende il pericolo evidente. Immagina di avviare un database dentro un container e di salvarci i dati dei tuoi utenti. Tutto sembra funzionare. Poi, un giorno, devi aggiornare quel container a una versione nuova del database, cosa normalissima: butti via il vecchio e ne avvii uno nuovo. E scopri, con orrore, che tutti i dati sono spariti, perché erano dentro il container che hai buttato via. Un'intera base di dati, svanita: esattamente la catastrofe di cui parlavamo nella stagione sul backend.
Ed è qui che entrano in gioco i volumi, la soluzione elegante a questo problema. Un volume è uno spazio di conservazione dei dati che vive fuori dal container, separato dal suo ciclo di vita. Invece di scrivere i dati importanti dentro il container, dove sparirebbero, li scrivi in un volume, che è un'area di memoria permanente gestita da Docker ma indipendente dal singolo container. Il container, mentre è vivo, usa il volume come se fosse una sua cartella, ma quei dati, in realtà, stanno al sicuro fuori. Così, quando butti via il container e ne crei uno nuovo, gli dai lo stesso volume, e il nuovo container ritrova tutti i dati intatti, come se nulla fosse.
Voglio che tu colga la bellezza di questa separazione, perché è un principio profondo. I volumi separano nettamente due cose che hanno nature diverse: la parte usa e getta dell'applicazione, cioè il programma che gira nel container, e la parte durevole e preziosa, cioè i dati. Il programma è sostituibile: lo aggiorni, lo butti, lo ricrei senza pensieri, perché è definito dall'immagine e riparte sempre uguale. I dati, invece, sono unici e insostituibili: vanno conservati con cura, al sicuro, indipendentemente dai container che vanno e vengono. Tenere separati il sostituibile e il prezioso è un'idea di ottima architettura, che va ben oltre Docker.
Questa separazione abilita cose molto comode. Siccome i dati stanno al sicuro in un volume, puoi aggiornare il programma a piacimento, buttando il vecchio container e avviandone uno nuovo, senza mai toccare i dati. Puoi spostarli da un container all'altro. Puoi farne copie di sicurezza salvando il volume. La disinvoltura con cui trattiamo i container usa e getta diventa finalmente sicura, perché ciò che conta davvero, i dati, è protetto e separato.
Chiudo con una regola pratica che riassume tutto, e che ogni persona che usa Docker dovrebbe tatuarsi in mente. La regola è: mai conservare dati importanti dentro un container; conservali sempre in un volume. Il container è per il programma che gira, effimero e sostituibile; il volume è per i dati che devono sopravvivere, permanente e prezioso. Ogni volta che hai qualcosa che deve durare oltre la vita di un singolo container, un database, i file caricati dagli utenti, qualsiasi dato importante, quella cosa va in un volume. Interiorizzare questa distinzione ti eviterà una delle catastrofi più comuni e dolorose di chi comincia con Docker.
Per oggi ci fermiamo qui. I container sono usa e getta, e tutto ciò che scrivi al loro interno sparisce quando li butti via: come la memoria volatile di cui parlavamo per il backend. Per non perdere i dati importanti, come un database, servono i volumi: spazi di conservazione che vivono fuori dal container, separati dal suo ciclo di vita, così che i dati sopravvivano ai container che vanno e vengono. È la sana separazione tra il sostituibile, il programma, e il prezioso, i dati. La regola d'oro: i dati che devono durare vanno sempre in un volume. Nella prossima puntata vediamo come i container si parlano tra loro: la rete. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.