Pourquoi une stack Compose attache-t-elle un nouveau volume nommé vide après son redéploiement ?
Une stack Compose peut associer un nouveau volume nommé vide lorsque le redéploiement modifie le nom du volume associé au projet ou ne parvient pas à retrouver le volume d’origine.
Les anciennes données peuvent toujours exister dans un autre volume Docker, tandis que le service recréé monte un volume nouvellement généré au même chemin dans le conteneur. Les causes courantes incluent la modification du nom de la stack ou du projet, le changement de clé du volume, sa suppression à l’aide d’une commande qui supprime les volumes, la perte d’une déclaration externe, un déploiement via un autre gestionnaire ou un nom de volume explicite qui est désormais résolu différemment. Répertoriez le volume monté et les candidats orphelins avant de restaurer les données ou d’initialiser l’application.
Identifier le volume exact monté par le nouveau conteneur
Examinez les montages du conteneur en cours d’exécution et notez le nom du volume, le pilote, le point de montage, les étiquettes, la date de création, la destination dans le conteneur et le mode lecture-écriture. Comparez-les aux relevés effectués avant le redéploiement.
La commande docker volume inspect d’Ubuntu expose l’identité du volume, ce qui permet de distinguer le nouveau volume vide d’un ancien volume démonté au nom similaire.
Ne copiez pas de données dans le nouveau volume avant d’avoir retrouvé l’original. Le démarrage de l’application peut créer une nouvelle base de données et donner l’impression que la destination a été initialisée volontairement.
Vérifier si le nom du projet Compose a changé
Comparez l’ancien et le nouveau nom du projet, le nom de la stack, le répertoire Compose, l’option -p, COMPOSE_PROJECT_NAME, la valeur name: de niveau supérieur et le gestionnaire de déploiement.
Docker explique que Compose associe normalement à un volume le nom du projet suivi de la clé du volume, sauf si un nom explicite ou une recherche de volume externe est configuré.
Déplacer le même fichier Compose dans un autre répertoire peut donc créer un deuxième projet et un deuxième volume, même lorsque les clés du service et du volume restent inchangées.
Vérifier les paramètres du nom stable et du volume externe
Comparez la définition du volume de niveau supérieur avant et après le redéploiement. Vérifiez name:, external:, les options du pilote, les variables d’interpolation et l’existence du volume attendu.
Le tutoriel Docker Compose de Microsoft indique que les volumes nommés persistent indépendamment du remplacement des conteneurs ; un nouvel état vide signifie donc généralement qu’un autre volume a été associé ou que l’ancien a été supprimé.
Ne marquez un volume comme externe que lorsque son cycle de vie est volontairement géré en dehors de la stack. Compose doit échouer clairement lorsqu’un volume externe est absent, plutôt que de créer silencieusement un remplacement.
Vérifier si un nettoyage a supprimé le volume d’origine
Examinez les journaux de déploiement, les scripts, les actions de l’interface, les tâches de nettoyage et les commandes de suppression des volumes. Comparez la date de création du volume avec l’événement de redéploiement.
Red Hat indique que les volumes nommés gérés par les conteneurs disposent d’emplacements de stockage distincts des couches inscriptibles des conteneurs ; c’est pourquoi supprimer un conteneur et supprimer son volume nommé sont deux événements différents du cycle de vie.
Si le volume d’origine est absent, désactivez les démarrages automatiques et restaurez uniquement depuis une sauvegarde vérifiée. Ne supposez pas qu’un volume de remplacement vide contient une couche supprimée récupérable.
Comparer l’identité du gestionnaire de stack et la méthode de déploiement
Notez si la stack a été lancée via l’interface CLI, Portainer, une boutique d’applications NAS, un déploiement Git ou un autre outil d’automatisation. Comparez le nom de la stack et les valeurs d’environnement enregistrées par ce gestionnaire.
Portainer exige un nom de stack descriptif lors du déploiement, et l’identité contrôlée par ce gestionnaire peut différer du nom de projet basé sur le répertoire et utilisé par une commande Compose manuelle.
Un démarrage manuel d’urgence peut donc créer des ressources sous un autre préfixe de projet. Choisissez un seul responsable du déploiement et documentez les noms de volumes résolus qu’il crée.
Écarter la présence de données masquées sous le nouveau montage de volume
Arrêtez le conteneur et inspectez l’image ou le chemin de liaison sans le volume nommé dans un test temporaire. Déterminez si le démarrage a écrit des données dans la couche du conteneur avant le montage du volume.
Le manuel Linux consacré au montage explique qu’un montage masque le contenu préexistant d’un répertoire ; les données peuvent donc sembler absentes lorsqu’un nouveau volume vide recouvre des fichiers créés dans l’image ou dans la couche inscriptible.
Ne fusionnez pas aveuglément la couche masquée et l’ancien volume persistant. Déterminez quel état fait autorité et utilisez la méthode de récupération prise en charge par l’application.
Reconnecter le volume d’origine avec un test contrôlé
Arrêtez la stack, sauvegardez les deux volumes candidats, associez l’original à un conteneur temporaire ou à un service de test sur un chemin provisoire, puis vérifiez les fichiers de l’application, l’identité de la base de données, les propriétaires et les horodatages.
Le guide ZimaSpace consacré au déplacement des données de conteneur sans modifier les points de montage présente le processus complémentaire de correspondance des chemins ; cet article se concentre sur l’identité des volumes nommés associés au projet.
Le problème est résolu lorsque l’ancien volume souhaité est monté sous un nom explicite ou externe stable et que les redéploiements successifs le réutilisent sans créer un autre volume vide candidat.
Foire aux questions
Un volume nommé vide signifie-t-il que les anciennes données ont été supprimées ?
Pas nécessairement. L’ancien volume peut toujours exister sous un autre préfixe de projet ou un autre nom explicite, tandis que le nouveau conteneur utilise un volume vide différent.
Le changement de nom du dossier Compose peut-il créer un nouveau volume ?
Oui. Lorsqu’aucun nom de projet n’est fixé, Compose peut le déduire du répertoire du projet et créer des ressources portant des préfixes différents.
Les volumes importants doivent-ils être marqués comme externes ?
Les volumes externes peuvent empêcher la suppression de la stack de gérer leur cycle de vie, mais ils nécessitent une création, un nommage, une sauvegarde et des vérifications de déploiement rigoureux.
Produits recommandés
Assistance et conseils
Plus à lire
Guide de stockage pour l’enregistrement de la télévision en direct : capacité, conservation et nettoyage
Mesurez les enregistrements réels, prévoyez une marge de sécurité, combinez les limites d’ancienneté et de capacité, et vérifiez que le programme admissible le plus...
Flux de récupération des métadonnées multimédias à domicile après la restauration d’une base de données
Protégez l’état restauré, vérifiez l’identité et les chemins des médias, puis corrigez les illustrations ou les correspondances manquantes dans une bibliothèque pilote avant d’appliquer...
Liste de contrôle de compatibilité du client Jellyfin pour l’audio, la vidéo et les sous-titres
Testez des fichiers représentatifs en ne faisant varier qu’un paramètre à la fois, puis consignez pour chaque client la lecture directe, le remuxage, la...
