devops
Docker: ambienti riproducibili e rilasci senza sorprese
Container per ambienti riproducibili: dev = staging = produzione.
Perché ci poggiamo su Docker
- ›Compose per stack multi-servizio
- ›CI/CD pipeline
- ›Riduce 'on my machine'
Perché containerizzare
Il problema che Docker risolve ha un nome preciso: il software funziona sulla macchina di chi lo ha scritto e si comporta diversamente altrove, perché le versioni di runtime, librerie di sistema e configurazioni non coincidono. Il container mette applicazione e dipendenze nella stessa scatola, e quella scatola è identica ovunque venga eseguita.
Il beneficio per il cliente è indiretto ma concreto: i problemi che si scoprono al collaudo sono problemi veri del software, non differenze d'ambiente, e il tempo speso a inseguirli sparisce dal preventivo.
Stack completo in locale
Con Docker Compose descriviamo in un file l'intero sistema: applicazione, database PostgreSQL, code, servizi di supporto. Chi entra nel progetto ha tutto in funzione con un comando, invece di passare un giorno a installare dipendenze seguendo istruzioni che nessuno aggiorna mai.
Vale anche per i sistemi di integrazione: possiamo riprodurre in locale il contorno di un gestionale, dati di prova compresi, e sviluppare il connettore senza toccare l'ambiente di produzione del cliente.
CI/CD e rilasci reversibili
L'immagine costruita dalla pipeline è la stessa che va in collaudo e poi in produzione, identificata dalla versione del codice. Nessuna ricompilazione sul server, nessun file caricato a mano, nessun dubbio su cosa stia effettivamente girando.
La conseguenza più utile è che tornare indietro significa riavviare l'immagine precedente: pochi secondi, con la certezza che sia esattamente quella che funzionava.
Quando serve restare in casa
Non tutti i progetti possono stare su una piattaforma gestita. Alcuni clienti hanno vincoli di riservatezza, integrazioni raggiungibili solo dalla rete interna o infrastruttura già pagata. In quei casi consegniamo l'applicazione containerizzata e la facciamo girare sui loro server.
È anche una forma di indipendenza: l'applicazione non è legata a un fornitore specifico e può essere spostata altrove senza riscritture.
Domande frequenti su Docker
- Docker serve anche a progetti piccoli?
- Se il progetto ha un solo servizio e vive su una piattaforma gestita, spesso no. Diventa utile appena i servizi sono più di uno, l'ambiente va replicato o l'applicazione deve essere ospitata su server del cliente.
- Container o macchina virtuale?
- Il container condivide il kernel del sistema ospite: si avvia in un istante e pesa pochissimo rispetto a una macchina virtuale completa. Per far girare applicazioni è quasi sempre la scelta migliore; la VM resta dove serve isolamento a livello di sistema operativo.
- Possiamo ospitare l'applicazione sui nostri server?
- Sì. Consegniamo immagini e file di orchestrazione documentati e affianchiamo il reparto IT nella messa in esercizio, oppure gestiamo noi l'infrastruttura come servizio continuativo.