Pourquoi une application conteneurisée repasse-t-elle à l’UTC uniquement après la mise à jour d’une image ?
Une application conteneurisée peut revenir à l’UTC après une mise à jour si la nouvelle image supprime les données de fuseau horaire, ignore TZ ou n’utilise plus le montage du fuseau horaire de l’hôte.
L’horloge de l’hôte peut rester correcte tandis que l’application formate les dates en UTC, car les conteneurs partagent normalement l’horloge du noyau de l’hôte, mais possèdent leurs propres fichiers de fuseau horaire, variables d’environnement et données de l’environnement d’exécution du langage. Une mise à jour de l’image peut changer de distribution de base, supprimer tzdata, modifiez l’utilisateur de l’application, remplacez le point d’entrée ou cessez de respecter une TZ variable. Comparez l’ancienne et la nouvelle image avant de modifier le fuseau horaire de l’hôte.
Séparez l’heure de l’horloge système du formatage du fuseau horaire
Consignez l’heure UTC, l’heure locale formatée, le nom du fuseau horaire, le décalage numérique et l’heure affichée par l’application elle-même dans les anciens et les nouveaux conteneurs.
La bibliothèque GNU C explique que la variable TZ contrôle la conversion de l’heure locale, tandis que l’horloge système sous-jacente reste une source de temps absolu.
Si l’heure epoch correspond, mais que le fuseau affiché change, le problème vient de la configuration du fuseau horaire, et non d’une dérive de l’horloge ou de NTP.
Vérifiez si la nouvelle image contient toujours tzdata
Comparez les paquets installés, /usr/share/zoneinfo, /etc/localtime, et /etc/timezone entre les balises d’image précédente et actuelle.
Le paquet tzdata de Debian fournit les définitions de fuseaux horaires utilisées par les applications pour convertir l’UTC en heure locale régionale.
Une image de remplacement minimale peut omettre intentionnellement ce paquet. Installez-le dans une image dérivée ou utilisez plutôt le mécanisme de gestion des fuseaux horaires pris en charge par l’application, au lieu de modifier manuellement un conteneur en cours d’exécution.
Vérifiez comment la distribution de base applique le fuseau horaire
Identifiez si l’image est basée sur Debian, Ubuntu, Alpine, distroless ou une autre distribution. Ne supposez pas que le réglage TZ a des effets identiques dans chaque image.
Alpine Linux documente la configuration du fuseau horaire via tzdata et zoneinfo.
Si la mise à jour a modifié l’image de base, reprenez la configuration du fuseau horaire en utilisant la méthode prise en charge par cette distribution. Copier un seul fichier depuis l’ancien conteneur peut laisser les règles de passage à l’heure d’été obsolètes.
Inspecter le montage bind localtime de l’hôte
Comparez les montages du conteneur en cours d’exécution avant et après la recréation. Vérifiez si /etc/localtime ou un fichier zoneinfo est toujours monté en lecture seule.
Les montages bind de Docker mappent un fichier ou un répertoire hôte précis dans le conteneur. La documentation officielle sur les montages bind explique pourquoi la suppression d’un montage Compose ou la modification du chemin source fait revenir le nouveau conteneur à la valeur par défaut de son image.
Ne montez pas l’intégralité de l’hôte /etc répertoire. Utilisez le fichier pris en charge précis ou la configuration explicite du fuseau horaire requise par l’application.
Vérifier la propre base de données de fuseaux horaires de l’environnement d’exécution de l’application
Déterminez si l’application utilise la base de données zoneinfo du système d’exploitation ou intègre les données de fuseau horaire dans Python, Java, PHP, Node.js ou un autre environnement d’exécution.
Le module zoneinfo de Python recherche les données système ou un paquet tzdata.
Une application peut donc afficher UTC même lorsque les commandes du shell indiquent le bon fuseau horaire. Comparez séparément le comportement d’exécution de l’application et celui du shell du conteneur.
Vérifier la priorité des variables d’environnement de Compose après la recréation
Inspectez l’environnement final du conteneur recréé et comparez-le avec l’interpolation de Compose, environnement, env_fileet les valeurs d’image par défaut.
La documentation de Red Hat sur les conteneurs indique que la configuration d’exécution peut remplacer l’environnement de l’image ; ainsi, une image mise à jour et un ancien fichier de déploiement peuvent produire une valeur finale différente de celle attendue.
Consultez l’environnement réel du conteneur plutôt que le seul fichier Compose. L’interface de la pile obsolète ou un autre fichier d’environnement a peut-être recréé le service sans la variable de fuseau horaire prévue.
Figez la configuration et testez-la après une autre mise à jour
Choisissez une méthode de gestion des fuseaux horaires prise en charge, enregistrez-la dans la configuration de déploiement versionnée, recréez le conteneur, puis vérifiez les dates d’hiver et d’heure d’été, le cas échéant.
L’article de ZimaSpace sur l’heure des tâches des conteneurs et l’environnement fournit la limite de diagnostic connexe pour les planifications qui changent lorsque les paramètres d’heure du conteneur sont modifiés.
Le problème est résolu lorsque l’application, le shell, les journaux et les tâches planifiées utilisent le fuseau prévu après le redémarrage et une autre recréation contrôlée de l’image.
Foire aux questions
Les conteneurs ont-ils leur propre horloge matérielle ?
Non. Ils partagent normalement l’horloge du noyau de l’hôte, mais peuvent formater cette heure à l’aide de données de fuseau horaire et de paramètres d’environnement différents.
La définition de TZ suffit-elle toujours ?
Non. L’image et l’application doivent prendre en charge cette variable et avoir accès aux règles de fuseaux horaires. Certains environnements d’exécution utilisent une base de données distincte intégrée.
Dois-je modifier le fuseau horaire de l’hôte NAS pour corriger un seul conteneur ?
Non. Corrigez d’abord la configuration du conteneur ou de l’application ; modifier l’hôte peut affecter les journaux, les planifications et tous les autres services.
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,...
