Macchine virtuali o container: quando in azienda serve Docker

"Dobbiamo passare a Docker?" Me lo chiedono spesso, di solito dopo che qualcuno in azienda ha letto che "ormai si fa tutto con i container".

La risposta onesta è: dipende da cosa deve girare. Docker non sostituisce le macchine virtuali. Risolve un problema diverso, e lo risolve molto bene.

La differenza, spiegata senza gergo

Immagini un edificio di uffici.

Una macchina virtuale è un appartamento completo: ingresso, impianti, cucina propri. È indipendente e isolato dagli altri, ma occupa spazio e richiede manutenzione come una casa vera. Ogni macchina virtuale ha il suo sistema operativo, che va aggiornato e protetto.

Un container è una postazione arredata in un open space: scrivania, computer e documenti pronti, ma impianti e servizi condivisi con l'edificio. Si allestisce in pochi secondi, si sposta facilmente, se ne aggiungono dieci in un attimo. Condivide però il sistema operativo del server che lo ospita.

Docker è lo strumento più diffuso per creare e far girare container. Ogni applicazione viene distribuita come immagine: un pacchetto che contiene il programma e tutto ciò che gli serve per funzionare, sempre uguale ovunque venga avviato.

Quando servono le macchine virtuali

• Gestionali tradizionali che richiedono un sistema operativo specifico, spesso Windows Server.
• Servizi da isolare completamente, per sicurezza o per obblighi contrattuali.
• Sistemi con esigenze particolari: driver dedicati, licenze legate alla macchina, software datato che nessuno può più modificare.
• Ambienti diversi sullo stesso server, per esempio Linux e Windows insieme.

Sono gli scenari tipici delle piattaforme di virtualizzazione come Proxmox, VMware o XCP-ng, che ho confrontato nell'articolo Proxmox, VMware, Xen e XCP-ng: le differenze che contano.

Quando conviene Docker

• Applicazioni web moderne, composte da più servizi: sito, database, cache, code di lavoro.
• Aggiornamenti frequenti: si sostituisce l'immagine con quella nuova e, se qualcosa non va, si torna alla precedente in pochi minuti.
• Ambienti identici tra sviluppo, test e produzione: finisce il classico "sul mio computer funzionava".
• Servizi da replicare quando aumenta il carico, senza riconfigurare server.

Il vantaggio economico è concreto: sullo stesso server girano molte più applicazioni, perché ogni container usa solo le risorse che gli servono davvero.

La soluzione più comune: entrambi

Nella pratica le due tecnologie lavorano insieme. Un'infrastruttura tipica che progetto per una PMI ha questa forma:

Così si ottengono i vantaggi di entrambe: l'isolamento delle macchine virtuali e l'agilità dei container. E il backup dell'intera macchina virtuale protegge anche tutti i container che contiene.

Gli errori da evitare

Il primo errore è containerizzare tutto per principio. Un gestionale nato vent'anni fa non diventa moderno perché gira in un container: diventa solo più difficile da gestire.

Il secondo è dimenticare i dati. Un container si cancella e si ricrea in un attimo; i dati no. Database e file caricati dagli utenti devono stare in volumi persistenti, inclusi nei backup e provati in ripristino.

Il terzo è lasciare i container senza manutenzione. Le immagini vanno aggiornate come qualsiasi software: un container dimenticato è una porta lasciata aperta.