I dati della tua app sopravvivranno alla ricreazione di un container? Checklist per la persistenza in Docker

Perché è importante la sostituzione del container

Un container può essere arrestato e riavviato oppure rimosso e sostituito durante una modifica del deployment. Sono eventi diversi: un riavvio riuscito non dimostra che i dati importanti dell’applicazione sopravvivranno alla sostituzione. La documentazione introduttiva ufficiale di Docker tratta la persistenza dei dati come un concetto distinto: https://docs.docker.com/get-started/docker-concepts/running-containers/persisting-container-data/.

Una fonte secondaria, Dash0, afferma che il livello scrivibile di un container arrestato resta disponibile finché il container non viene rimosso e che avviare di nuovo lo stesso container lo ripristina: «How to Preserve Data When a Docker Container Exits», https://www.dash0.com/faq/how-to-preserve-data-when-a-docker-container-exits. Per valutare il tuo caso, verifica la procedura di sostituzione effettivamente usata dal deployment.

• Specifica quale modifica vuoi provare: riavvio, aggiornamento, rimozione e ricreazione oppure un’altra operazione gestita dal provider.
• Esegui la prova in un ambiente non di produzione e usa dati che puoi permetterti di perdere.
• Se non sai se la modifica riutilizza o sostituisce il container, chiedi a chi gestisce il deployment.

Individua dati, configurazione e posizioni di archiviazione

Fai un inventario di ciò che l’applicazione crea o utilizza, per esempio dati relativi al database, file caricati dagli utenti, configurazione, file generati o log. Sono categorie da verificare, non un’affermazione secondo cui tutte le applicazioni le archiviano nello stesso modo.

Per ogni elemento, annota dove l’applicazione o il deployment indica che si trova: nel container, in un punto di mount configurato, in un altro servizio oppure nella configurazione del deployment. Segna come sconosciuto ciò che non riesci a verificare; controlla i percorsi specifici e il comportamento di inizializzazione nella documentazione di deployment dell’applicazione.

Per ogni mount configurato, registra tipo, origine e destinazione così come compaiono nel deployment, la finalità prevista e il comportamento documentato durante la sostituzione. Il nome del mount, da solo, non chiarisce che cosa contiene né se la procedura lo conserva.

• Dati o impostazione: che cosa sono e quale sarebbe l’impatto della loro perdita?
• Posizione e riscontri: dove indicano l’applicazione o il deployment che si trovano e quali istruzioni o impostazioni lo confermano?
• Ciclo di vita: che cosa dovrebbe succedere a quella posizione durante la modifica che intendi provare?
• Aspetti da chiarire: che cosa va confermato prima di intervenire in produzione?

Controlla le istruzioni di deployment prima della prova

Consulta la documentazione ufficiale di deployment del fornitore dell’applicazione per individuare i percorsi dei dati richiesti, gli input di configurazione e il comportamento al primo avvio o durante l’inizializzazione. Confronta queste istruzioni con la definizione effettiva del deployment: non copiare un percorso da un’altra installazione e non dare per scontato che un container nuovo gestisca i dati esistenti come previsto.

Se un percorso obbligatorio non è configurato, un passaggio di inizializzazione non è chiaro o il deployment non corrisponde alle istruzioni, chiedi chiarimenti prima di provare con dati importanti. Annota la documentazione e le impostazioni consultate, così da collegare le tue aspettative al deployment effettivo.

• Quali percorsi documentati contengono dati utente o informazioni persistenti? Il deployment definisce un sistema di archiviazione per quei percorsi?
• Che cosa dice la documentazione sul primo avvio o su un percorso che contiene già dati?
• In base alla documentazione, come viene fornita la configurazione in questo ambiente?
• Quali impostazioni o dettagli del ciclo di vita non sono ancora stati verificati?

Esegui una prova di persistenza controllata

Esegui la prova esclusivamente in un ambiente non di produzione, usando dati che puoi permetterti di perdere. Non usare un servizio attivo per questa verifica: la sostituzione può interessare il servizio e i suoi dati.

Crea nell’applicazione un elemento di prova con un nome riconoscibile e annota come individuarlo. Segui la procedura di sostituzione documentata: un semplice arresto e riavvio non verifica la rimozione e la ricreazione. Poi controlla se l’elemento è presente e utilizzabile e verifica separatamente le altre categorie di dati importanti che hai inventariato.

Registra il risultato e le ipotesi da rivedere. Un test superato vale per quel deployment e quella procedura; non dimostra il comportamento di tutte le categorie di dati né di uno scenario di ripristino diverso.

• Prima: annota applicazione, deployment, elemento di prova e operazione sul ciclo di vita.
• Dopo: controlla l’elemento di prova e le altre categorie di dati importanti.
• Documenta la procedura, il risultato, i dati mancanti o modificati e le questioni ancora aperte.
• Se opportuno, rimuovi l’elemento di prova e verifica che l’applicazione sia nello stato previsto.

Tieni distinti persistenza, backup e responsabilità

Persistenza e backup rispondono a domande diverse. Il fatto che una posizione resti disponibile dopo una determinata procedura di sostituzione non dimostra che i dati possano essere recuperati in caso di perdita o errore. Documenta separatamente quali dati devono essere sottoposti a backup, che cosa include il backup, come avviene il ripristino e chi è responsabile di ogni passaggio.

Chiarisci anche chi può accedere all’applicazione, alla configurazione di archiviazione e agli eventuali meccanismi di ripristino. Non dare per scontato che il tipo di hosting determini quali dati siano coperti, per quanto tempo vengano conservati o chi possa ripristinarli.

Airbip offre backup configurabili con frequenza giornaliera, settimanale e mensile. Le informazioni disponibili sul prodotto non specificano quali dati dell’applicazione includa ciascun backup né quale sia la procedura di ripristino: conferma questi dettagli in base alle tue esigenze.

• Individua i dati che devono poter essere recuperati e chi conferma la copertura dei backup.
• Chiedi che cosa includono ed escludono i backup e come si richiede e si esegue il ripristino.
• Conferma chi può accedere o amministrare i dati dell’applicazione e le impostazioni di deployment.

Domande da porre a un provider di hosting gestito

Chiedi risposte riferite al deployment della tua applicazione e allo specifico evento del ciclo di vita che ti interessa, invece di affidarti a rassicurazioni generiche. Usale per valutare se il modello gestito è adatto ai tuoi requisiti relativi a dati, accesso e governance.

Airbip esegue le istanze delle applicazioni come workload Docker sui propri server cloud e gestisce il ciclo di vita del servizio. Automatizza il routing e i certificati TLS tramite Traefik e Let’s Encrypt e offre backup configurabili con frequenza giornaliera, settimanale e mensile. Queste funzionalità, da sole, non specificano quali percorsi dell’applicazione persistano dopo una sostituzione né che cosa includa un backup.

Se un provider non chiarisce i dettagli del deployment che devi controllare, o se il servizio non soddisfa i tuoi requisiti di governance, valuta un modello di deployment che ti dia il controllo necessario.

• Quale operazione esatta costituisce una sostituzione del container per la mia istanza e quali posizioni dei dati e della configurazione vengono conservate?
• Quali elementi supportano questa risposta e dove posso consultare le impostazioni di archiviazione specifiche dell’applicazione?
• Che cosa includono i backup, come funziona il ripristino e chi è responsabile di ciascun passaggio?
• Quali controlli di accesso si applicano e quali modifiche o operazioni restano sotto la mia responsabilità?