Varför återgår en containerbaserad app till UTC först efter en bilduppdatering?
En containeriserad app kan återgå till UTC efter en uppdatering när den nya avbildningen tar bort tidszonsdata, ignorerar TZ eller inte längre använder värddatorns monterade tidszon.
Värddatorns klocka kan förbli korrekt medan programmet formaterar datum i UTC, eftersom containrar normalt delar värddatorns kärnklocka men har egna tidszonsfiler, miljövariabler och data för språkkörningen. En uppdatering av avbildningen kan byta basdistribution, ta bort tzdata, ändra programanvändaren, ersätt startpunkten eller slutar följa en leverantörsspecifik TZ variabeln. Jämför den gamla och den nya avbildningen innan du ändrar värddatorns tidszon.
Separera systemklockans tid från tidszonsformatering
Anteckna UTC-tid, lokalt formaterad tid, tidszonsnamn, numerisk förskjutning och programmets egen visade tid i de gamla och nya containrarna.
GNU C Library förklarar att variabeln TZ styr konvertering till lokal tid, medan den underliggande systemklockan fortfarande är en källa till absolut tid.
Om epoktiden överensstämmer men den formaterade tidszonen ändras, beror problemet på tidszonskonfigurationen och inte på klockdrift eller NTP.
Kontrollera om den nya avbildningen fortfarande innehåller tzdata
Jämför installerade paket, /usr/share/zoneinfo, /etc/localtime, och /etc/timezone mellan de föregående och aktuella avbildningstaggarna.
Debians tzdata-paket tillhandahåller tidszonsdefinitioner som program använder för att konvertera UTC till regional lokal tid.
En minimal ersättningsavbildning kan avsiktligt utelämna det här paketet. Installera det i en härledd avbildning eller använd programmets stödda mekanism för tidszoner i stället för att manuellt ändra en körande container.
Verifiera hur basdistributionen tillämpar tidszon
Identifiera om avbildningen är Debian, Ubuntu, Alpine, distroless eller någon annan bas. Anta inte att inställningen TZ har identiska effekter i alla avbildningar.
Alpine Linux dokumenterar konfiguration av tidszon via tzdata och zoneinfo.
Om uppdateringen ändrade basavbildningen upprepar du tidszonskonfigurationen med den distributionens metod som stöds. Om du kopierar en enda fil från den gamla containern kan reglerna för sommartid bli inaktuella.
Kontrollera värdens bind-montering för localtime
Jämför den körande containerns monteringar före och efter återskapandet. Kontrollera om /etc/localtime eller så är en zoneinfo-fil fortfarande monterad skrivskyddad.
Dockers bind-monteringar mappar en exakt värdfil eller värdkatalog till containern. Den officiella vägledningen om bind-monteringar visar varför en borttagen Compose-montering eller ändrad källsökväg gör att den nya containern återgår till sin standardinställning från avbildningen.
Montera inte värdens hela /etc katalog. Använd den begränsade fil eller uttryckliga tidszonskonfiguration som programmet kräver.
Kontrollera körningsmiljöns egen tidszonsdatabas
Identifiera om programmet använder operativsystemets zoneinfo-databas eller inkluderar tidszonsdata i Python, Java, PHP, Node.js eller en annan körtidsmiljö.
Pythons zoneinfo-modul söker i systemdata eller ett tzdata-paket.
Ett program kan därför visa UTC även när skalkommandon visar rätt tidszon. Jämför programmets körningsbeteende separat från containerns skal.
Verifiera Compose-miljövariablernas prioritet efter återskapandet
Inspektera den återskapade containerns slutliga miljö och jämför den med Compose-interpoleringen, miljö, env_file, och standardvärden för bilder.
Reds Hats containerdokumentation påpekar att konfiguration vid körning kan åsidosätta avbildningens miljö, så en uppdaterad avbildning och en gammal distributionsfil kan ge ett annat slutvärde än förväntat.
Läs den faktiska containermiljön i stället för att bara läsa Compose-filen. Ett inaktuellt stackgränssnitt eller en alternativ env-fil kan ha återskapat tjänsten utan den avsedda tidszonsvariabeln.
Lås fast konfigurationen och testa efter ytterligare en uppdatering
Välj en tidszonsmetod som stöds, lås fast den i versionshanterad distributionskonfiguration, återskapa containern och verifiera vinter- och sommartidsdatum där det är tillämpligt.
ZimaSpace-artikeln om tiden för containerjobb och miljön beskriver den angränsande diagnostiska gränsen för scheman som ändras när containerns tidszonsinställningar ändras.
Problemet är löst när applikationen, skalet, loggarna och de schemalagda jobben använder den avsedda tidszonen efter omstart och ytterligare en kontrollerad återskapning av avbildningen.
Vanliga frågor
Har containrar en egen hårdvaruklocka?
Nej. De delar normalt värdkärnans klocka, men kan formatera tiden med olika tidszonsdata och miljöinställningar.
Räcker det alltid att ange TZ?
Nej. Avbildningen och applikationen måste ha stöd för variabeln och åtkomst till tidszonsregler. Vissa körmiljöer använder en separat medföljande databas.
Bör jag ändra tidszonen på NAS-värden för att åtgärda en enda container?
Nej. Korrigera först konfigurationen av containern eller applikationen. Att ändra värden på värden kan påverka loggar, scheman och alla andra tjänster.
Rekommenderade produkter
Support och tips
Mer att läsa
Varför återskapar en återställning av en Docker-volym filinnehållet men tar bort utökade attribut?
En felsökning av volymåterställning som omfattar inventering av xattr, alternativ för tar och Rsync, namnrymder, stöd för måldestinationen, behörigheter, etiketter, appmetadata och tester.
Varför behåller en körande container sin gamla minnesgräns efter att Compose-filen har ändrats?
En minnesgränsdiagnos som omfattar aktiva cgroups, omstart kontra återskapande, Compose-fält, hårda och mjuka gränser, överordnade scope, växlingsutrymme och körningsheapar.
Varför ogiltigförklarar en omstart av en omvänd proxy varje session för en självhostad app?
En sessionsförlustdiagnos som omfattar omstartens omfattning, cookie-ägarskap, rotation av hemligheter, cachebaserade sessioner, sticky routing, autentiseringsgatewayer och återställning.
