Flux de migration de volumes nommés Docker entre deux serveurs domestiques

La démarche sûre consiste à traiter une archive mise au repos ou une copie synchronisée vers un volume cible explicitement identifié, suivie d'une validation par somme de contrôle et par l'application, comme une séquence de contrôles observables et non comme une simple commande.

Sur deux serveurs domestiques Linux exécutant Docker Compose, le risque concret est qu'un conteneur avec état doive être déplacé vers un autre hôte sans copier un volume actif ou mal nommé. Notez l'identité actuelle et le point de récupération, commencez par le discriminateur le moins invasif, interprétez les résultats réussis et échoués avant de modifier une autre variable, puis arrêtez-vous lorsque le stockage devient instable ou que la seule copie récupérable risque d'être exposée. Le flux de travail ci-dessous ne se termine qu'une fois la charge de travail d'origine exécutée avec succès ou lorsque les éléments disponibles atteignent un seuil nécessitant une escalade.

Identifier les contrats du volume source et du volume cible

Notez le condensat de l'image du conteneur source, le nom du projet Compose, le service, la clé du volume, le nom réel du volume Docker, le point de montage, le pilote de volume et la version de l'application. Utilisez docker inspect et docker volume inspect ; ne déduisez pas le chemin physique à partir d'un simple libellé YAML.

Compose préfixe normalement les volumes nommés avec le nom du projet, sauf si un nom explicite ou un volume externe est utilisé. Sur la cible, générez la configuration Compose et créez explicitement le volume vide prévu afin que la migration ne puisse pas aboutir dans un volume tandis que le service en démarre un autre.

Si le volume contient une base de données, utilisez son export natif ou sa sauvegarde prise en charge comme principal moyen de récupération portable et considérez la copie du volume comme un point de récupération pour la même version. Arrêtez-vous si le pilote est distant, si le stockage source est instable ou si l'état de l'application s'étend à d'autres volumes qui ne sont pas inclus.

Mettre les processus d'écriture au repos et créer une copie préservant les métadonnées

Placez l'application en mode maintenance, arrêtez les tâches en arrière-plan, puis arrêtez proprement l'application et la base de données. Vérifiez qu'aucun conteneur ne monte le volume en lecture-écriture. Créez une archive via un conteneur temporaire ou utilisez une copie contrôlée du système de fichiers qui préserve les propriétaires numériques, les permissions, les liens symboliques, les attributs étendus si nécessaire et les fichiers creux.

Un guide indépendant sur la migration de volumes Docker avec rsync montre comment déplacer les données d'un volume Docker avec rsync. Le point essentiel est que la source doit être au repos et que la commande de copie doit agir sur le contenu du volume identifié, sans manipuler aveuglément le répertoire interne de Docker pendant que le démon l'utilise.

Générez un manifeste indiquant le nombre de fichiers, le nombre total d'octets, des condensats représentatifs et la somme de contrôle de l'archive. Conservez le volume source et la sauvegarde native intacts ; l'étape de copie n'est validée que si l'artefact transféré est lisible sur l'hôte cible.

Restaurer dans le volume cible explicite

Vérifiez la capacité du système de fichiers cible, la disponibilité des inodes, les UID et GID attendus ainsi que la même version de l'image de l'application. Restaurez l'archive dans le volume cible vide sans aplanir la structure de ses répertoires de premier niveau, puis comparez les propriétaires, les quantités, les tailles et certains condensats.

Une discussion communautaire sur un cas d'échec de migration d'un volume nommé montre pourquoi le remplacement direct de fichiers dans les éléments internes des volumes Docker peut échouer ou laisser un état difficile à comprendre. Utilisez l'environnement d'exécution pour monter le volume dans un conteneur auxiliaire et effectuez la restauration via cette interface contrôlée.

Ne connectez d'abord qu'une copie jetable du service, en utilisant des ports différents et sans accès aux systèmes homologues de production. Si l'application signale des mises à niveau de schéma ou un état corrompu, arrêtez-vous et restaurez à nouveau le volume à partir de l'artefact inchangé après avoir résolu la compatibilité des versions.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Basculer et conserver un hôte de restauration

Démarrez les dépendances avant l'application, vérifiez les journaux, la connexion, les enregistrements récents, les pièces jointes, les tâches planifiées et une écriture jetable. Redémarrez la pile cible et confirmez qu'elle rattache le même volume nommé. Ne mettez à jour le proxy ou le DNS qu'après la réussite de ces vérifications.

L'article connexe de ZimaSpace sur la sauvegarde cohérente des données d'un conteneur peut être utile si la cible démarre vide malgré une copie réussie. Comparez la source du montage de l'environnement d'exécution avec le volume prévu avant de recopier les données ; les copies répétées vers la mauvaise cible ne font qu'ajouter de l'ambiguïté.

Gardez l'application source arrêtée et l'ancien volume en lecture seule jusqu'à ce qu'une nouvelle sauvegarde et un test de restauration réussissent sur la cible. Revenez à la source inchangée en redirigeant le trafic uniquement si aucune nouvelle écriture n'a été acceptée sur la cible ; sinon, arrêtez-vous et réconciliez délibérément les données.