Perché uno stack Compose collega un nuovo volume denominato vuoto dopo la ridistribuzione?
Uno stack Compose può collegare un nuovo volume denominato vuoto quando una nuova distribuzione modifica il nome del volume associato al progetto o non riesce a trovare il volume originale.
I vecchi dati potrebbero essere ancora presenti in un altro volume Docker, mentre il servizio ricreato monta un volume appena generato nello stesso percorso del container. Tra le cause comuni figurano la modifica del nome dello stack o del progetto, la rinomina della chiave del volume, la rimozione tramite un comando che elimina i volumi, la perdita di una dichiarazione esterna, la distribuzione tramite un altro gestore o un nome di volume esplicito che ora viene risolto diversamente. Inventaria sia il volume montato sia i possibili volumi orfani prima di ripristinare i dati o inizializzare l’app.
Identificare il volume esatto montato dal nuovo container
Ispeziona i mount del container in esecuzione e annota il nome del volume, il driver, il punto di mount, le etichette, l’ora di creazione, la destinazione nel container e la modalità di sola lettura o lettura-scrittura. Confrontali con i dati registrati prima della nuova distribuzione.
Il comando Ubuntu docker volume inspect espone l’identità del volume, consentendo di distinguere il nuovo volume vuoto da un volume precedente non montato con una denominazione simile.
Non copiare dati nel nuovo volume finché non hai trovato quello originale. L’avvio dell’app può creare un nuovo database e far sembrare che la destinazione sia stata inizializzata intenzionalmente.
Verificare se il nome del progetto Compose è cambiato
Confronta il vecchio e il nuovo nome del progetto, il nome dello stack, la directory Compose, l’opzione -p, COMPOSE_PROJECT_NAME, il campo name: di primo livello e il gestore della distribuzione.
Docker spiega che Compose normalmente assegna a un volume un nome composto da nome-del-progetto più chiave-del-volume, a meno che non sia configurato un nome esplicito o la ricerca di un volume esterno.
Spostare lo stesso file Compose in un’altra directory può quindi creare un secondo progetto e un secondo volume anche quando il servizio e le chiavi del volume non sono cambiati.
Verificare le impostazioni del nome stabile e del volume esterno
Confronta la definizione del volume di primo livello prima e dopo la nuova distribuzione. Controlla name:, external:, le opzioni del driver, le variabili di interpolazione e l’eventuale presenza del volume previsto.
L’esercitazione di Microsoft su Docker Compose osserva che i volumi denominati persistono indipendentemente dalla sostituzione del container, quindi un nuovo stato vuoto indica generalmente che è stata collegata un’identità di volume diversa oppure che il vecchio volume è stato rimosso.
Contrassegna un volume come esterno solo quando il suo ciclo di vita viene gestito intenzionalmente al di fuori dello stack. Compose dovrebbe segnalare chiaramente l’assenza di un volume esterno invece di crearne silenziosamente uno sostitutivo.
Verificare se una pulizia ha rimosso il volume originale
Esamina i log della distribuzione, gli script, le azioni dell’interfaccia, i processi di pruning e i comandi di eliminazione dei volumi. Confronta l’ora di creazione del volume con l’evento di nuova distribuzione.
Red Hat documenta che i volumi denominati gestiti dai container hanno percorsi di archiviazione separati dai layer scrivibili dei container, motivo per cui la rimozione di un container e quella del suo volume denominato sono eventi distinti del ciclo di vita.
Se il volume originale non è presente, interrompi gli avvii automatici e ripristina i dati solo da un backup verificato. Non presumere che un volume sostitutivo vuoto contenga un layer eliminato recuperabile.
Confrontare l’identità del gestore dello stack e il metodo di distribuzione
Registra se lo stack è stato avviato tramite CLI, Portainer, un app store NAS, una distribuzione Git o un altro strumento di automazione. Confronta il nome dello stack e i valori dell’ambiente memorizzati dal gestore.
Portainer richiede un nome descrittivo dello stack durante la distribuzione, e l’identità gestita da questo strumento può differire dal nome del progetto basato sulla directory utilizzato da un comando Compose manuale.
Un avvio manuale di emergenza può quindi creare risorse con un altro prefisso di progetto. Scegli un unico responsabile della distribuzione e documenta i nomi effettivi dei volumi che crea.
Escludere la presenza di dati nascosti sotto il nuovo mount del volume
Arresta il container e ispeziona l’immagine o il percorso bind senza il volume denominato collegato, utilizzando un test usa e getta. Determina se l’avvio ha scritto dati nel layer del container prima del montaggio del volume.
Il manuale Linux sui mount spiega che un mount nasconde i contenuti preesistenti della directory, quindi i dati possono sembrare mancanti quando un nuovo volume vuoto copre i file creati nell’immagine o nel layer scrivibile.
Non unire alla cieca il layer nascosto e il vecchio volume persistente. Identifica quale stato è quello autorevole e utilizza il metodo di ripristino supportato dall’applicazione.
Ricollegare il volume originale con un test controllato
Arresta lo stack, esegui il backup di entrambi i volumi candidati, collega quello originale a un container usa e getta o a un servizio temporaneo e verifica i file dell’applicazione, l’identità del database, la proprietà e i timestamp.
La guida ZimaSpace per spostare i dati dei container senza interrompere i mount illustra il relativo flusso di lavoro per la mappatura dei percorsi; questo articolo si concentra sull’identità dei volumi denominati associati al progetto.
Il problema è risolto quando il vecchio volume desiderato viene montato con un nome esplicito stabile o come volume esterno e le nuove distribuzioni lo riutilizzano senza creare un altro candidato vuoto.
Domande frequenti
Un volume denominato vuoto significa che i vecchi dati sono stati eliminati?
Non necessariamente. Il vecchio volume potrebbe essere ancora presente con un altro prefisso di progetto o un nome esplicito, mentre il nuovo container utilizza un volume vuoto diverso.
La modifica del nome della cartella Compose può creare un nuovo volume?
Sì. Quando non viene fissato alcun nome del progetto, Compose può ricavarlo dalla directory del progetto e creare risorse con prefissi diversi.
I volumi importanti dovrebbero essere contrassegnati come esterni?
I volumi esterni possono impedire che la rimozione dello stack ne gestisca il ciclo di vita, ma richiedono creazione, denominazione, backup e verifiche di distribuzione deliberate.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
