Prima del Dockerfile:
mappa del processo
Analizziamo come l'applicazione viene costruita, avviata e aggiornata. Identifichiamo versione del runtime, pacchetti di sistema, dipendenze applicative, file generati, processi in background, schedulazioni e servizi esterni.
Distinguiamo tre categorie che spesso vengono confuse:
Codice e dipendenze: devono entrare nell'immagine tramite una build ripetibile;
Configurazione: cambia tra ambienti e viene fornita al momento dell'esecuzione;
Dati: devono sopravvivere al container e richiedono volumi o servizi persistenti.
Se l'applicazione scrive file nella propria directory, dipende da un cron sul server o utilizza indirizzi locali impliciti, questi comportamenti vengono resi visibili prima di progettare l'immagine.
I TRE PILASTRI DELLA CONTAINERIZZAZIONE
Come costruiamo una
infrastruttura containerizzata stabile
Dockerfile piccoli, deterministici e controllabili
Utilizziamo immagini di base coerenti con il runtime e fissiamo le versioni con precisione. Una build che cambia risultato senza una modifica al repository è difficile da diagnosticare e riprodurre.
Le build multi-stage separano compilazione e immagine finale, lasciando gli strumenti di sviluppo e sorgenti non necessari fuori dal runtime. Ordiniamo i passaggi per sfruttare la cache senza conservare artefatti superati e utilizziamo un file di esclusione per impedire l’invio di dati segreti, repository e file locali al contesto di build.
Il processo applicativo viene eseguito con un utente non privilegiato quando possibile. Permessi e directory scrivibili sono dichiarati. L’immagine contiene un solo ruolo operativo chiaro; worker e scheduler possono usare la stessa base, ma vengono avviati come servizi distinti.
Un healthcheck verifica un comportamento significativo e leggero. Deve soltanto controllare che il processo esista senza sovraccaricare database e dipendenze a ogni esecuzione.
Compose come descrizione dell'ambiente
Docker Compose definisce applicazione, database, cache, code e altri servizi necessari, insieme a reti e volumi. Un nuovo sviluppatore può avviare lo stack con istruzioni limitate e ottenere versioni coerenti.
Le dipendenze di avvio vengono gestite considerando la reale disponibilità. Un container “started” non significa che il database sia pronto ad accettare connessioni. L’applicazione deve comunque tollerare ritardi e tentare nuovamente entro limiti controllati.
Creiamo reti con esposizione minima. Database e cache non devono essere pubblicati sulla macchina host in produzione se vengono usati soltanto dall’applicazione. Nomi dei servizi sostituiscono indirizzi IP fissi.
Profili o file di override possono aggiungere strumenti utili allo sviluppo senza entrare nello stack operativo. Evitiamo però una distanza tale da rendere l’ambiente locale incapace di riprodurre i problemi di produzione.
Volumi: persistenza, inizializzazione e copia
Database, upload e altri dati non possono dipendere dal ciclo di vita del container. Definiamo volumi e responsabilità della copia. Eliminare e ricreare un servizio deve essere un’operazione distinta dall’eliminazione dei suoi dati.
Le migration dello schema vengono eseguite come passaggio controllato del rilascio, non in modo concorrente da ogni replica. Seed e inizializzazioni sono idempotenti oppure chiaramente limitati al primo avvio.
Una copia di un volume non è sufficiente se il database è in scrittura e non viene garantita consistenza. Utilizziamo procedure adatte al motore, registriamo esito e proviamo il ripristino. Per i file definiamo conservazione e sincronizzazione con il record applicativo.