Waarom schakelt een containerized app pas na een image-update terug naar UTC?

Een gecontaineriseerde applicatie kan na een update terugvallen op UTC wanneer de nieuwe image tijdzonegegevens verwijdert, TZ negeert of de tijdzonemount van de host niet langer gebruikt.

De klok van de host kan correct blijven terwijl de applicatie datums in UTC opmaakt, omdat containers normaal gesproken de klok van de hostkernel delen, maar hun eigen tijdzonebestanden, omgeving en gegevens van de taalruntime hebben. Een image-update kan de basisdistributie wijzigen, verwijderen tzdata, wijzig de applicatiegebruiker, vervang het entrypoint of stop met het respecteren van een leveranciersspecifieke TZ variabele. Vergelijk de oude en nieuwe image voordat je de tijdzone van de host wijzigt.

Scheid systeemtijd van tijdzoneopmaak

Leg in de oude en nieuwe containers de UTC-tijd, de lokaal opgemaakte tijd, de tijdzonenaam, de numerieke offset en de door de applicatie zelf weergegeven tijd vast.

De GNU C Library legt uit dat de variabele TZ de conversie naar lokale tijd aanstuurt, terwijl de onderliggende systeemklok een absolute tijdsbron blijft.

Als de epochtijd overeenkomt maar de opgemaakte tijdzone verandert, ligt het probleem bij de tijdzoneconfiguratie en niet bij klokafwijking of NTP.

Controleer of de nieuwe image tzdata nog bevat

Vergelijk de geïnstalleerde pakketten, /usr/share/zoneinfo, /etc/localtime, en /etc/timezone tussen de vorige en huidige imagetag.

Het Debian-pakket tzdata levert tijdzonedefinities die applicaties gebruiken om UTC om te zetten naar regionale lokale tijd.

Een minimale vervangende image kan dit pakket bewust weglaten. Installeer het in een afgeleide image of gebruik in plaats daarvan het door de applicatie ondersteunde tijdzonemechanisme, in plaats van een draaiende container handmatig aan te passen.

Controleer hoe de basisdistributie TZ toepast

Bepaal of de image Debian, Ubuntu, Alpine, distroless of een andere basis gebruikt. Ga er niet van uit dat TZ heeft in elke image hetzelfde effect.

Alpine Linux documenteert tijdzoneconfiguratie via tzdata en zoneinfo.

Als de update de basisimage heeft gewijzigd, voer je de tijdzoneconfiguratie opnieuw uit volgens de ondersteunde methode van die distributie. Als je één bestand uit de oude container kopieert, kunnen de regels voor zomertijd verouderd blijven.

-15% OFF

ZimaBoard 2 - Mini-thuisserver voor jouw grote idee

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Inspecteer de bindkoppeling van localtime op de host

Vergelijk de koppelingen van de actieve container vóór en na het opnieuw aanmaken. Controleer of /etc/localtime of er is nog steeds een zoneinfo-bestand als alleen-lezen gekoppeld.

Docker-bindkoppelingen wijzen een exact hostbestand of een exacte hostmap toe aan de container. De officiële richtlijnen voor bindkoppelingen laten zien waarom een verwijderde Compose-koppeling of gewijzigd bronpad ervoor zorgt dat de nieuwe container terugvalt op de standaardwaarde van de image.

Koppel niet de volledige /etc map. Gebruik het specifieke ondersteunde bestand of de expliciete tijdzoneconfiguratie die de toepassing vereist.

Controleer de eigen zonedatabase van de runtime van de toepassing

Bepaal of de toepassing de zoneinfo-database van het besturingssysteem gebruikt of tijdzonegegevens bundelt in Python, Java, PHP, Node.js of een andere runtime.

De zoneinfo-module van Python zoekt in systeemgegevens of een tzdata-pakket.

Een toepassing kan daarom UTC weergeven, zelfs wanneer shellopdrachten de juiste tijdzone tonen. Vergelijk het runtimegedrag van de toepassing afzonderlijk met de container-shell.

Controleer de prioriteit van Compose-omgevingsvariabelen na het opnieuw aanmaken

Inspecteer de uiteindelijke omgeving van de opnieuw aangemaakte container en vergelijk deze met Compose-interpolatie, omgeving, env_file, en standaardwaarden voor afbeeldingen.

De containerdocumentatie van Red Hat vermeldt dat de runtimeconfiguratie de imageomgeving kan overschrijven. Daardoor kunnen een bijgewerkte image en een oud implementatiebestand een andere uiteindelijke waarde opleveren dan verwacht.

Lees de daadwerkelijke containeromgeving uit in plaats van alleen het Compose-bestand. Een verouderde stackinterface of een ander env-bestand kan de service opnieuw hebben aangemaakt zonder de beoogde tijdzonevariabele.

Leg de configuratie vast en test na een volgende update

Kies één ondersteunde tijdzonemethode, leg deze vast in versiebeheer van de implementatieconfiguratie, maak de container opnieuw aan en controleer winter- en zomertijddata waar dat van toepassing is.

Het ZimaSpace-artikel over de tijd en omgeving van containertaken beschrijft de aangrenzende diagnostische grens voor planningen die verschuiven wanneer de tijdzone-instellingen van de container veranderen.

Het probleem is opgelost wanneer de applicatie, shell, logboeken en geplande taken na een herstart en nog een gecontroleerde recreatie van de image de bedoelde tijdzone gebruiken.

Veelgestelde vragen

Hebben containers hun eigen hardwareklok?

Nee. Normaal delen ze de systeemklok van de hostkernel, maar ze kunnen die tijd formatteren met verschillende tijdzonegegevens en omgevingsinstellingen.

Is het instellen van TZ altijd voldoende?

Nee. De image en applicatie moeten de variabele ondersteunen en toegang hebben tot tijdzoneregels. Sommige runtimes gebruiken een afzonderlijke meegeleverde database.

Moet ik de tijdzone van de NAS-host wijzigen om één container te repareren?

Nee. Corrigeer eerst de container- of applicatieconfiguratie; het wijzigen van de host kan gevolgen hebben voor logboeken, planningen en alle andere services.