Pourquoi un alias réseau Compose cesse-t-il d’être résolu après la recréation de la stack sous un nouveau nom de projet ?
Un alias Compose peut cesser d’être résolu après une recréation lorsque le service rejoint un réseau associé à un autre projet ou que l’alias n’y est plus attaché.
Les alias Docker sont associés à un réseau, et non des noms globaux. Recréer une stack dans un autre répertoire, avec un nom de projet explicite, un nom de stack Portainer ou un autre projet Compose peut créer un nouveau réseau par défaut alors qu’une autre application reste connectée à l’ancien. Le service peut être sain et accessible via un port publié, tout en ayant un alias interne qui échoue, car l’appelant et la cible ne partagent plus le même réseau ou parce qu’un proxy inverse a sélectionné une autre interface réseau.
Comparer les noms des anciens et nouveaux projets Compose
Notez l’ancien et le nouveau nom de projet, le répertoire de travail, le nom de la stack, les noms des réseaux et les étiquettes des conteneurs. Comparez les services appelant et cible après la recréation.
Docker Compose utilise le nom du projet pour regrouper et nommer les ressources. Sa priorité des noms de projet explique pourquoi le changement de répertoire ou de nom de déploiement peut créer un nouveau réseau au lieu de réutiliser l’ancien réseau du projet.
Si l’appelant reste connecté à oldproject_default tandis que la cible rejoint newproject_default, l’ancien alias ne bénéficie d’aucun espace DNS partagé.
Vérifier l’alias sur le réseau partagé exact
Inspectez les deux conteneurs et répertoriez chaque réseau connecté, chaque point de terminaison, chaque adresse IPv4 ou IPv6 et chaque alias. Testez la résolution DNS depuis le conteneur appelant.
La spécification Compose définit les alias comme des noms associés à un réseau : un alias déclaré sur un réseau n’existe donc pas automatiquement sur une autre interface réseau.
Déplacez la déclaration de l’alias vers le réseau effectivement partagé par les services. Ne vous appuyez pas sur container_name pour remplacer une découverte de services pensée explicitement.
Vérifier les noms des réseaux externes et la substitution lors du déploiement
Comparez la clé logique du réseau Compose avec son attribut externe explicite name. Vérifiez la substitution des variables d’environnement et les variables d’interface utilisées lors du déploiement de la stack.
Portainer indique que les stacks peuvent utiliser des réseaux Docker existants, qui doivent être sélectionnés de manière cohérente lorsque des stacks déployées indépendamment doivent communiquer entre elles.
Un réseau externe empêche les changements de préfixe du projet uniquement lorsque chaque stack référence le même nom de réseau réel. Une faute de frappe peut créer ou sélectionner un autre réseau sans modifier le port publié du service.
Confirmer que l’appelant utilise le DNS Docker plutôt qu’une adresse mise en cache
Effectuez une nouvelle résolution depuis l’appelant, inspectez sa configuration de résolution et redémarrez uniquement le processus qui met en cache le DNS si nécessaire. Comparez la résolution de l’alias avec une résolution directe par nom de service.
Le modèle des espaces de noms réseau Linux isole les ressources réseau, raison pour laquelle une résolution DNS réussie sur l’hôte ne prouve pas que le conteneur appelant partage le réseau Docker de la cible.
N’ajoutez pas l’adresse IP actuelle du conteneur cible à /etc/hosts. Les conteneurs recréés peuvent recevoir une autre adresse, laissant une dépendance obsolète supplémentaire.
Vérifier le réseau utilisé par le proxy inverse
Inspectez les connexions réseau du proxy et de l’application, les étiquettes des fournisseurs et le réseau sélectionné pour le routage vers le backend. Testez l’alias depuis le conteneur du proxy.
Le fournisseur Docker de Traefik permet de spécifier le réseau Docker utilisé pour les connexions aux backends.
Si le proxy est connecté à plusieurs réseaux, la sélection automatique peut changer après une recréation. Définissez explicitement le réseau partagé souhaité et conservez son nom réel stable.
Supprimer les points de terminaison obsolètes sans supprimer le mauvais réseau
Répertoriez les conteneurs connectés aux anciens et aux nouveaux réseaux. Identifiez les points de terminaison orphelins, les conteneurs arrêtés et les services actifs qui dépendent encore de l’ancien réseau du projet.
Le guide Red Hat sur la mise en réseau des conteneurs décrit la connexion des conteneurs aux réseaux définis par l’utilisateur comme une partie de l’état du moteur de conteneurs, et non du contenu des fichiers de l’application.
Ne supprimez un ancien réseau qu’après avoir prouvé qu’aucune stack active ne l’utilise. Supprimer les deux réseaux et tout recréer simultanément détruit les éléments permettant de déterminer quelle connexion était incorrecte.
Recréer un seul service et vérifier le DNS depuis chaque appelant
Uniformisez le nom du projet ou le réseau externe, recréez uniquement le service concerné et testez le nom du service ainsi que l’alias depuis chaque conteneur dépendant.
L’article de ZimaSpace sur les dépendances d’exécution des conteneurs rappelle une règle connexe : un test de connectivité effectué au niveau de l’hôte ne valide ni l’espace de noms ni le chemin de découverte des services du conteneur.
Le problème est résolu lorsque l’alias renvoie vers le point de terminaison actuel depuis chaque appelant prévu après la recréation de la stack et le redémarrage, sans adresses IP codées en dur.
Questions fréquentes
Les alias des réseaux Docker sont-ils globaux ?
Non. Un alias existe uniquement sur le réseau où il est configuré et n’est utile qu’aux conteneurs qui partagent ce réseau.
Le changement de nom du dossier Compose peut-il interrompre le DNS ?
Oui. Le dossier peut influencer le nom de projet par défaut, ce qui affecte les noms des réseaux générés, sauf si le nom du projet ou celui du réseau externe est fixé.
Dois-je utiliser container_name pour conserver un DNS stable ?
En général, non. Des noms de services stables et des réseaux partagés explicites préservent la possibilité de mise à l’échelle de Compose et évitent les collisions de noms globaux.
Produits recommandés
Assistance et conseils
Plus à lire
Pourquoi la restauration d’un volume Docker recrée-t-elle le contenu des fichiers, mais supprime-t-elle les attributs étendus ?
Un diagnostic de restauration de volume couvrant l’inventaire des xattr, les options de tar et de Rsync, les espaces de noms, la prise en...
Pourquoi un conteneur en cours d’exécution conserve-t-il son ancienne limite de mémoire après la modification du fichier Compose ?
Un diagnostic des limites mémoire couvrant les cgroups actifs, le redémarrage par rapport à la recréation, les champs Compose, les limites strictes et souples,...
Pourquoi le redémarrage d’un proxy inverse invalide-t-il toutes les sessions d’une application auto-hébergée ?
Un diagnostic de perte de session couvrant la portée des redémarrages, la propriété des cookies, la rotation des secrets, les sessions adossées au cache,...
