“Installa una macchina virtuale Linux e ricrea esattamente lo stesso ambiente.”
Tre mesi dopo il mio ingresso in azienda, l’atmosfera in ufficio era strana. L’unico senior del team era stato assegnato a un altro progetto e, più che pensare al passaggio di consegne, era occupato a preparare le proprie cose. Il team leader, invece, si era staccato da tempo dal lavoro di sviluppo pratico ed era piuttosto lontano dalle tendenze tecniche più recenti.
Un giorno il team leader mi chiamò. “Quando il tuo senior se ne andrà, l’unica persona che potrà gestire i server sarai tu. Anche se il server va giù, devi essere in grado di ripristinarlo da solo. Installa Linux come macchina virtuale, VM, sul tuo attuale portatile di sviluppo, Windows, e prova a ricostruire esattamente lo stesso ambiente del server di produzione.”
Da quel giorno iniziò la mia fatica. Installai VMware, scaricai il file ISO di Ubuntu, e solo l’installazione mi portò via mezza giornata. Frugando nel wiki aziendale installai Java, Node.js e PostgreSQL. Pensai: “Più nuovo sarà meglio”, quindi installai Java 17, ma poi scoprii che il codice legacy si basava su Java 8 e non compilava nemmeno. Dovetti eliminare tutto e reinstallare. Ogni volta che cambiavo una sola riga di codice, dovevo lanciare mvn build, spostare il file jar nella VM ed eseguirlo lì. Era una sofferenza pura.
A un certo punto mi venne un dubbio. “Aspetta un attimo. L’ultima volta che abbiamo fatto deploy sul server di produzione, non era bastato scrivere una sola volta docker service update?”
La mia macchina virtuale locale era così pesante e richiedeva una montagna di configurazioni. Allora che cos’era esattamente quel ‘Docker’ sul server di produzione, capace di aggiornare tutto con un solo comando?
La soluzione pesante: la macchina virtuale
Il metodo che mi aveva indicato il team leader, cioè installare Linux sopra Windows, è esattamente ciò che chiamiamo macchina virtuale, VM. È come costruire un’intera ‘casa virtuale’, un guest OS, sopra un computer fisico, l’host.
Alla fine una VM garantisce davvero l’isolamento dell’ambiente, ma per sviluppo o deploy è semplicemente troppo pesante e troppo lenta da scambiarsi continuamente.
La rivoluzione leggera: Docker
Per questo è arrivato Docker, cioè la tecnologia dei container. Docker non costruisce un’intera casa come fa una VM. Al contrario, pianta una tenda.
Il comando update che avevo eseguito sul server di produzione non stava reinstallando un pesante sistema operativo. Stava solo “smontando la vecchia tenda e rimontandone una nuova contenente la nuova versione del codice”. Per forza doveva finire in un attimo.
[Code Verification] Docker è davvero così leggero?
Non limitiamoci a dire che Docker è leggero: verifichiamolo davvero. Se l’obiettivo è eseguire un ambiente Linux, Ubuntu, la differenza tra una VM e Docker è netta.
# Avvia Ubuntu con il comando Docker (scarica limmagine se mancante)
$ docker run -it ubuntu:latest /bin/bash
Risultato:
Nel momento stesso in cui ho premuto Enter, ero già dentro un ambiente Ubuntu. Questo è possibile perché un container Docker non è un vero sistema operativo. È soltanto “uno spazio isolato che prende in prestito il kernel dell’host OS, cioè il mio computer, facendo finta di essere un OS separato”.
Consiglio pratico: il vero motivo per usare Docker
Da quando abbiamo introdotto Docker sul lavoro, la mia vita è cambiata completamente.
In chiusura: non consegniamo un eseguibile, ma un ambiente
Con l’arrivo di Docker è cambiato il paradigma dello sviluppo. Non inviamo più al server soltanto il codice sorgente, .java. Congeliamo in un’‘image’ anche la configurazione dell’OS, le librerie e le variabili d’ambiente necessarie al codice, e spediamo l’intero pacchetto.
Allora come viene davvero costruita questa magica ‘Docker image’? È solo un file compresso? Sorprendentemente, si dice che una Docker image sia composta da più layer sovrapposti, come una torta.
La prossima volta esploriamo il segreto dietro l’efficienza di Docker: le image e la loro struttura a layer.