Pourquoi un service Compose utilise-t-il le mauvais fichier d’environnement uniquement après le redémarrage de l’hôte ?
Un service Compose peut utiliser des valeurs d’environnement différentes après un redémarrage lorsque le lanceur au démarrage résout un autre répertoire de projet, fichier d’environnement ou source de priorité.
Une commande manuelle peut être exécutée depuis le dossier prévu avec un environnement shell, tandis que systemd, un planificateur NAS ou Portainer démarre le même fichier Compose depuis un autre contexte après le démarrage. Le service peut également redémarrer un conteneur existant dont l’environnement a été défini lors de la création, au lieu de relire le fichier modifié. Comparez le modèle Compose rendu et l’environnement du processus en cours entre le lancement manuel et le lancement au démarrage avant de modifier plusieurs fichiers à la fois.
Comparez l’environnement en cours avec le fichier prévu
Notez l’identifiant du conteneur, sa date de création, l’image, les libellés Compose, le nom du projet et les valeurs réellement visibles dans le processus principal. Comparez-les au fichier d’environnement prévu sans afficher de secrets dans des journaux partagés.
L’environnement du processus Linux expose les valeurs fournies lors de l’exécution, ce qui constitue une preuve plus fiable que la lecture d’un fichier d’environnement que le conteneur actuel n’a peut-être jamais utilisé.
Si le conteneur contient les anciennes valeurs et est antérieur au déploiement effectué au redémarrage, le service a peut-être simplement été redémarré. Si le conteneur est nouveau, poursuivez avec l’analyse des priorités et de la résolution des chemins.
Appliquez les priorités des variables d’environnement Compose dans le bon ordre
Répertoriez toutes les sources d’une variable sans risque : indicateurs CLI, valeurs du shell, environment:, env_file:, fichier .env par défaut ou explicite, et ENV de l’image.
Docker définit un ordre formel de priorité des variables d’environnement : un fichier d’environnement correct peut donc être supplanté par une valeur de priorité supérieure injectée par le service au démarrage ou le gestionnaire de stack.
Ne recherchez pas uniquement les noms de fichiers en double. Recherchez le nom de la variable dans le modèle Compose rendu, le fichier d’unité, les paramètres du gestionnaire, l’environnement du shell et les valeurs par défaut de l’image.
Vérifiez le répertoire du projet et les chemins relatifs des fichiers d’environnement
Comparez le répertoire de travail de la commande manuelle avec celui du lanceur au démarrage, ainsi que les arguments des fichiers Compose, le répertoire du projet et les références relatives à env_file.
La spécification Compose définit le modèle d’application utilisé pour résoudre les services et la configuration : la définition de projet sélectionnée et ses chemins sont donc des paramètres du déploiement, et non des propriétés redécouvertes à partir du conteneur en cours d’exécution.
Utilisez des chemins absolus pour les fichiers d’environnement essentiels au démarrage lorsque l’outil de déploiement le permet, ou définissez explicitement un répertoire de projet et un répertoire de travail afin que les lancements manuels et automatisés résolvent les mêmes fichiers.
Inspectez le répertoire de travail et les fichiers d’environnement de systemd
Lisez l’unité effective, tous les fichiers de surcharge, ainsi que WorkingDirectory=, Environment=, EnvironmentFile= et ExecStart=. Comparez l’unité chargée au démarrage avec la commande utilisée manuellement.
Les paramètres d’exécution de systemd définissent le répertoire de travail du service et les fichiers d’environnement ; ils n’héritent pas automatiquement du répertoire courant ni des variables exportées d’un shell de connexion interactif.
Après avoir modifié une unité ou un fichier de surcharge, rechargez le gestionnaire systemd et inspectez à nouveau l’unité effective. Modifier un modèle ou un fichier inutilisé ne change pas le service réellement démarré.
Vérifiez les variables du gestionnaire de stacks et l’état de déploiement enregistré
Si Portainer ou une interface NAS gère la stack, comparez ses variables enregistrées, le fichier d’environnement importé, le chemin du déploiement Git, le comportement de mise à jour par webhook et le modèle Compose affiché.
Portainer distingue le fonctionnement de .env et de stack.env : les valeurs saisies dans le gestionnaire peuvent donc différer de celles d’un fichier modifié directement sur l’hôte.
Choisissez une source de vérité unique. Une stack gérée depuis Git ou un éditeur web ne doit pas également être démarrée manuellement depuis une autre copie locale après chaque redémarrage.
Recréez le conteneur au lieu de simplement le redémarrer
Comparez la date de création du conteneur avec la date de modification du fichier d’environnement. Rendez la configuration Compose prévue, puis effectuez une recréation contrôlée du seul service concerné.
Les recommandations de Red Hat pour systemd conseillent de vérifier les fichiers et remplacements réellement utilisés par un service avant de le redémarrer, afin d’éviter qu’une ancienne unité ou un wrapper ne recrée le conteneur avec d’anciennes valeurs.
Le redémarrage d’un conteneur ne reconstruit pas son environnement à partir de Compose. Ne le recréez qu’après avoir protégé les données persistantes et confirmé que le modèle rendu pointe vers les volumes et secrets prévus.
Faites en sorte que le démarrage manuel, le redémarrage et le redéploiement produisent le même modèle
Figez les fichiers Compose, le nom du projet, le répertoire du projet, le chemin du fichier d’environnement, le propriétaire de la stack et la dépendance au démarrage. Enregistrez une configuration rendue expurgée et une empreinte d’environnement sans risque.
L’article de ZimaSpace sur la portée des sauvegardes Docker fournit la règle complémentaire : les fichiers d’environnement et les définitions de déploiement doivent être conservés avec l’état persistant.
Le problème est résolu lorsqu’une recréation manuelle, un redémarrage de l’hôte, une mise à jour planifiée et un redéploiement depuis le gestionnaire de stacks créent tous le service avec la même empreinte d’environnement expurgée.
Questions fréquemment posées
Quelle est la différence entre .env et env_file ?
Un fichier .env de projet fournit généralement des valeurs d’interpolation à Compose, tandis qu’un env_file de service fournit des variables au conteneur. Leur interaction et leur priorité dépendent du modèle Compose complet.
Le redémarrage d’un conteneur recharge-t-il un fichier d’environnement modifié ?
Non. Les valeurs d’environnement sont définies lors de la création du conteneur. Le service doit normalement être recréé à partir de la configuration Compose corrigée.
Pourquoi le problème apparaît-il uniquement après un redémarrage ?
Le chemin de redémarrage peut utiliser une unité systemd, un planificateur, des variables enregistrées par le gestionnaire, un autre répertoire de travail ou une ancienne copie de Compose différente de celle utilisée lors du lancement manuel.
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,...
