Flusso di migrazione dei volumi denominati Docker tra due server domestici

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

Docker Named Volume Migration Workflow Between Two Home Servers - Zima Store Online

L'approccio sicuro consiste nel trattare un archivio quiescente o una copia sincronizzata in un volume di destinazione identificato esplicitamente, seguita dalla verifica tramite checksum e dalla validazione dell'applicazione, come una sequenza di controlli osservabili, non come un singolo comando.

Su due home server Linux che eseguono Docker Compose, il rischio concreto è che un container con stato debba essere spostato su un altro host senza copiare un volume attivo o denominato in modo errato. Registra l'identità attuale e il punto di ripristino, inizia dal discriminante meno invasivo, interpreta i risultati positivi e negativi prima di modificare un'altra variabile e fermati quando lo storage diventa instabile o l'unica copia recuperabile rischia di essere esposta. Il flusso di lavoro seguente termina solo dopo che il carico di lavoro originale funziona correttamente o le evidenze raggiungono una soglia di escalation.

Identifica i contratti del volume di origine e di destinazione

Registra il digest dell'immagine del container di origine, il nome del progetto Compose, il servizio, la chiave del volume, il nome effettivo del volume Docker, la destinazione del mount, il driver del volume e la versione dell'applicazione. Usa docker inspect e docker volume inspect; non dedurre il percorso fisico basandoti soltanto sull'etichetta YAML.

Compose normalmente antepone ai volumi denominati il nome del progetto, a meno che non venga usato un nome esplicito o un volume esterno. Sulla destinazione, renderizza la configurazione Compose e crea esplicitamente il volume vuoto previsto, così la migrazione non può finire in un volume mentre il servizio ne avvia un altro.

Se il volume contiene un database, usa il suo dump nativo o un backup supportato come principale percorso di ripristino portabile e tratta la copia del volume come un punto di ripristino della stessa versione. Fermati se il driver è remoto, lo storage di origine è instabile o lo stato dell'applicazione si estende ad altri volumi non inclusi nell'ambito.

Metti in pausa i processi di scrittura e crea una copia che preservi i metadati

Metti l'applicazione in modalità manutenzione, arresta i processi in background, quindi arresta correttamente l'applicazione e il database. Verifica che nessun container monti il volume in lettura-scrittura. Crea un archivio tramite un container temporaneo oppure usa una copia controllata del filesystem che preservi proprietà numeriche, permessi, collegamenti simbolici, attributi estesi quando necessari e file sparsi.

La guida indipendente su migrazione dei volumi Docker con rsync mostra come spostare i dati dei volumi Docker con rsync. Il limite importante è che l'origine deve essere quiescente e il comando di copia deve operare sui contenuti del volume identificato, non manipolare alla cieca la directory interna di Docker mentre il demone la sta usando.

Genera un manifest con il numero di file, i byte totali, hash rappresentativi e il checksum dell'archivio. Mantieni intatti il volume di origine e il backup nativo; la fase di copia supera il controllo solo quando l'artefatto del trasferimento è leggibile sull'host di destinazione.

Ripristina nel volume di destinazione esplicito

Verifica la capacità del filesystem di destinazione, la disponibilità di inode, le aspettative relative a UID e GID e la stessa versione dell'immagine dell'applicazione. Ripristina l'archivio nel volume di destinazione vuoto senza appiattire la struttura delle directory di primo livello, quindi confronta proprietà, conteggi, dimensioni e hash selezionati.

Una discussione della community sul caso di errore nella migrazione di un volume denominato mostra perché la sostituzione diretta dei file nelle strutture interne dei volumi Docker può non riuscire o lasciare uno stato ambiguo. Usa il runtime per montare il volume in un container di supporto ed esegui il ripristino tramite quell'interfaccia controllata.

Collega inizialmente solo una copia usa e getta del servizio, usando porte alternative e senza accesso ai peer di produzione. Se l'applicazione segnala aggiornamenti dello schema o uno stato corrotto, fermati e ripristina nuovamente il volume dall'artefatto invariato dopo aver risolto la compatibilità delle versioni.

Featured

ZimaCube 2 NAS personale cloud domestico

ZimaCube2

Esegui il passaggio e conserva un host per il rollback

Avvia le dipendenze prima dell'applicazione, verifica i log, l'accesso, i record recenti, gli allegati, i processi pianificati e una scrittura usa e getta. Riavvia lo stack di destinazione e verifica che ricolleghi lo stesso volume denominato. Aggiorna il proxy o il DNS solo dopo che questi controlli hanno avuto esito positivo.

L'articolo correlato di ZimaSpace sul backup coerente dei dati dei container è utile se la destinazione si avvia vuota nonostante una copia riuscita. Confronta l'origine del mount del runtime con il volume previsto prima di copiare nuovamente i dati; ripetere le copie nella destinazione sbagliata aggiunge soltanto ambiguità.

Mantieni l'applicazione di origine arrestata e il vecchio volume in sola lettura finché sulla destinazione non è stato completato correttamente un nuovo test di backup e ripristino. Esegui il rollback reindirizzando il traffico all'origine invariata solo se sulla destinazione non sono state accettate nuove scritture; in caso contrario, fermati e riconcilia deliberatamente i dati.