Perché un’app containerizzata torna all’ora UTC solo dopo un aggiornamento dell’immagine?
Un’applicazione containerizzata può tornare all’UTC dopo un aggiornamento quando la nuova immagine rimuove i dati dei fusi orari, ignora TZ o non utilizza più il mount del fuso orario dell’host.
L’orologio dell’host può rimanere corretto mentre l’applicazione formatta le date in UTC, perché i container condividono normalmente l’orologio del kernel dell’host, ma dispongono dei propri file dei fusi orari, dell’ambiente e dei dati del runtime del linguaggio. Un aggiornamento dell’immagine può cambiare la distribuzione di base, rimuovere tzdatacambia l’utente dell’applicazione, sostituisci l’entrypoint o smetti di rispettare una specifica TZ variabile. Confronta l’immagine precedente e quella nuova prima di modificare il fuso orario dell’host.
Separa l’ora dell’orologio di sistema dalla formattazione del fuso orario
Registra l’ora UTC, l’ora locale formattata, il nome del fuso orario, l’offset numerico e l’ora visualizzata dall’applicazione stessa nei container precedente e nuovo.
La GNU C Library spiega che la variabile TZ controlla la conversione dell’ora locale, mentre l’orologio di sistema sottostante rimane una fonte di tempo assoluta.
Se l’ora epoch corrisponde ma il fuso formattato cambia, il problema riguarda la configurazione del fuso orario, non la deriva dell’orologio o NTP.
Verifica se la nuova immagine contiene ancora tzdata
Confronta i pacchetti installati, /usr/share/zoneinfo, /etc/localtimee /etc/timezone tra i tag dell’immagine precedente e quelli dell’immagine attuale.
Il pacchetto tzdata di Debian fornisce le definizioni dei fusi orari utilizzate dalle applicazioni per convertire l’ora UTC nell’ora locale regionale.
Un’immagine sostitutiva minimale potrebbe omettere intenzionalmente questo pacchetto. Installalo in un’immagine derivata oppure utilizza il meccanismo per il fuso orario supportato dall’applicazione, invece di modificare manualmente un container in esecuzione.
Verifica come la distribuzione di base applica il fuso orario
Identifica se l’immagine è basata su Debian, Ubuntu, Alpine, distroless o altro. Non dare per scontato che... TZ ha effetti identici in ogni immagine.
Alpine Linux documenta la configurazione del fuso orario tramite tzdata e zoneinfo.
Se l’aggiornamento ha modificato l’immagine di base, ripeti la configurazione del fuso orario usando il metodo supportato da quella distribuzione. Copiare un singolo file dal vecchio container può lasciare obsolete le regole dell’ora legale.
Controlla il bind mount localtime dell’host
Confronta i mount del container in esecuzione prima e dopo la ricreazione. Verifica se /etc/localtime oppure un file zoneinfo è ancora montato in sola lettura.
I bind mount di Docker mappano un file o una directory specifici dell’host nel container. Le indicazioni ufficiali sui bind mount spiegano perché la rimozione di un mount Compose o la modifica del percorso di origine fa sì che il nuovo container ricorra al valore predefinito dell’immagine.
Non montare l’intero /etc directory. Usa il file supportato specifico o la configurazione esplicita del fuso orario richiesta dall’applicazione.
Controlla il database dei fusi orari del runtime dell’applicazione
Individua se l’applicazione usa il database zoneinfo del sistema operativo oppure include i dati sui fusi orari direttamente in Python, Java, PHP, Node.js o in un altro runtime.
Il modulo zoneinfo di Python cerca i dati di sistema o un pacchetto tzdata.
Pertanto, un’applicazione può visualizzare UTC anche quando i comandi della shell mostrano il fuso orario corretto. Confronta separatamente il comportamento dell’applicazione in esecuzione e quello della shell del container.
Verifica la precedenza delle variabili d’ambiente di Compose dopo la ricreazione
Ispeziona l’ambiente finale del container ricreato e confrontalo con l’interpolazione di Compose, ambiente, env_file, e le impostazioni predefinite delle immagini.
La documentazione di Red Hat sui container osserva che la configurazione del runtime può sostituire l’ambiente dell’immagine; pertanto, un’immagine aggiornata e un vecchio file di distribuzione possono produrre un valore finale diverso da quello previsto.
Leggi l’ambiente effettivo del container, non solo il file Compose. Un’interfaccia dello stack obsoleta o un file env alternativo potrebbe aver ricreato il servizio senza la variabile del fuso orario prevista.
Fissa la configurazione e verifica dopo un altro aggiornamento
Scegli un metodo di gestione dei fusi orari supportato, fissalo nella configurazione di distribuzione sottoposta al controllo versione, ricrea il container e verifica le date invernali e quelle dell’ora legale, ove applicabile.
L’articolo di ZimaSpace su orario dei processi del container e ambiente fornisce il confine diagnostico adiacente per le pianificazioni che cambiano quando vengono modificate le impostazioni dell’ora del container.
Il problema è risolto quando l’applicazione, la shell, i log e i processi pianificati utilizzano il fuso orario previsto dopo il riavvio e un’altra ricreazione controllata dell’immagine.
Domande frequenti
I container hanno un proprio orologio hardware?
No. Normalmente condividono l’orologio del kernel dell’host, ma possono formattare quell’ora utilizzando dati sui fusi orari e impostazioni dell’ambiente differenti.
Impostare TZ è sempre sufficiente?
No. L’immagine e l’applicazione devono supportare la variabile e avere accesso alle regole dei fusi orari. Alcuni runtime utilizzano un database integrato separato.
Devo modificare il fuso orario dell’host NAS per correggere un solo container?
No. Correggi prima la configurazione del container o dell’applicazione; modificare l’host può influire sui log, sulle pianificazioni e su ogni altro servizio.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Perché il ripristino di un volume Docker ricrea il contenuto dei file, ma elimina gli attributi estesi?
Una diagnosi del ripristino del volume che copre l’inventario degli xattr, le opzioni di tar e Rsync, gli spazi dei nomi, il supporto della...
Perché un container in esecuzione mantiene il vecchio limite di memoria dopo la modifica del file Compose?
Una diagnosi dei limiti di memoria che copre i cgroup attivi, il riavvio rispetto alla ricreazione, i campi di Compose, i limiti rigidi e...
Perché il riavvio di un proxy inverso invalida ogni sessione per una determinata app self-hosted?
Una diagnosi della perdita di sessione che copra l’ambito dei riavvii, la gestione dei cookie, la rotazione dei segreti, le sessioni basate sulla cache,...
