Un prodotto può funzionare su una macchina di uno sviluppatore e fallire quando raggiunge un server. Docker impacchetta un'applicazione e le sue dipendenze di runtime in un'immagine che può eseguire come un container. Questo rende gli ambienti più ripetibili e i rilasci più facili da descrivere. I container non forniscono automaticamente backup, sicurezza, monitoraggio o un'architettura in grado di sopravvivere a un guasto del server.
Cosa includere in un'immagine
Includere l'applicazione e le dipendenze necessarie per avviarla, ma mantenere password e impostazioni specifiche dell'ambiente fuori dall'immagine. Bloccare le versioni delle dipendenze e ricostruire le immagini quando arrivano aggiornamenti di sicurezza. Un'immagine piccola e ben definita è più facile da ispezionare e distribuire rispetto a una che installa silenziosamente strumenti all'avvio.
Trattare i dati diversamente
Un container può essere sostituito in qualsiasi momento. Carichi di clienti e file del database necessitano di storage persistente e regole di backup, non uno strato scrivibile che sparisce con il container. Testare percorsi di riavvio e recupero prima di affidarsi alla configurazione per i dati di produzione.
Utilizzarlo dove conta la ripetizione
Docker aiuta i team ad allineare lo sviluppo locale, i test automatizzati e il deployment. È utile quando un prodotto ha diversi servizi o necessita di un rilascio riproducibile. Per un'applicazione semplice su una piattaforma gestita, l'orchestrazione dei container può aggiungere più parti mobili di valore. Scegliere il setup operativo più piccolo che soddisfi l'obiettivo di affidabilità.
La disciplina di rilascio rimane necessaria
Verificare la salute prima di alternare il traffico, mantenere una versione precedente e sapere come fare il rollback. Registrare i guasti fuori dal container e monitorare il servizio dal punto di vista dell'utente. L'immagine è un'unità di consegna; un rilascio affidabile è un processo testato intorno ad essa.
