Warum wechselt eine containerisierte App erst nach einer Image-Aktualisierung zu UTC?
Eine containerisierte Anwendung kann nach einem Update zu UTC zurückkehren, wenn das neue Image Zeitzonendaten entfernt, TZ ignoriert oder die Zeitzonen-Mounts des Hosts nicht mehr verwendet.
Die Uhr des Hosts kann weiterhin korrekt gehen, während die Anwendung Datumsangaben in UTC formatiert, da Container normalerweise die Kernel-Uhr des Hosts gemeinsam nutzen, aber eigene Zeitzonendateien, Umgebungsvariablen und Laufzeitdaten der Sprachumgebung enthalten. Ein Image-Update kann die Basisdistribution wechseln, Zeitzonendaten entfernen, tzdata, ändern Sie den Anwendungsbenutzer, ersetzen Sie den Einstiegspunkt oder ignorieren Sie weiterhin eine anbieterspezifische TZ Variable. Vergleichen Sie das alte und das neue Image, bevor Sie die Zeitzone des Hosts ändern.
Trennen Sie die Systemzeit von der Zeitzonenformatierung
Zeichnen Sie in den alten und neuen Containern die UTC-Zeit, die formatierte Ortszeit, den Zeitzonennamen, den numerischen Offset und die von der Anwendung selbst angezeigte Zeit auf.
Die GNU C Library erklärt, dass die Variable TZ die Umwandlung in die Ortszeit steuert, während die zugrunde liegende Systemuhr weiterhin eine absolute Zeitquelle bleibt.
Wenn die Epoch-Zeit übereinstimmt, sich aber die formatierte Zeitzone ändert, liegt das Problem an der Zeitzonenkonfiguration und nicht an einer Uhrabweichung oder NTP.
Überprüfen Sie, ob das neue Image weiterhin tzdata enthält
Vergleichen Sie die installierten Pakete. /usr/share/zoneinfo, /etc/localtime, und /etc/timezone zwischen den vorherigen und aktuellen Image-Tags.
Das Debian-tzdata-Paket stellt Zeitzonendefinitionen bereit, die Anwendungen verwenden, um UTC in die regionale Ortszeit umzuwandeln.
Ein minimales Ersatz-Image enthält dieses Paket möglicherweise absichtlich nicht. Installieren Sie es in einem abgeleiteten Image oder verwenden Sie stattdessen den von der Anwendung unterstützten Zeitzonenmechanismus, anstatt einen laufenden Container manuell zu ändern.
Überprüfen Sie, wie die Basisdistribution TZ anwendet
Ermitteln Sie, ob das Image auf Debian, Ubuntu, Alpine, Distroless oder einer anderen Basis basiert. Gehen Sie nicht einfach davon aus, dass TZ hat in jedem Image dieselben Auswirkungen.
Alpine Linux dokumentiert die Zeitzoneneinrichtung über tzdata und Zoneinfo.
Wenn das Update das Basis-Image geändert hat, wiederholen Sie die Zeitzoneneinrichtung mit der von dieser Distribution unterstützten Methode. Das Kopieren einer einzelnen Datei aus dem alten Container kann dazu führen, dass die Sommerzeitregeln veraltet sind.
Den lokalen Localtime-Bind-Mount des Hosts überprüfen
Vergleichen Sie die Mounts des laufenden Containers vor und nach der Neuerstellung. Überprüfen Sie, ob /etc/localtime oder eine Zoneinfo-Datei weiterhin schreibgeschützt eingebunden ist.
Docker-Bind-Mounts bilden eine exakte Hostdatei oder ein exaktes Hostverzeichnis im Container ab. Die offizielle Anleitung zu Bind-Mounts zeigt, warum der neue Container auf den Standardwert seines Images zurückfällt, wenn ein Compose-Mount entfernt oder der Quellpfad geändert wurde.
Binden Sie nicht das gesamte Host- /etc Verzeichnis. Verwenden Sie die von der Anwendung unterstützte, gezielt angegebene Datei oder die erforderliche explizite Zeitzonenkonfiguration.
Die eigene Zeitzonendatenbank der Anwendungs-Laufzeit überprüfen
Ermitteln Sie, ob die Anwendung die Zoneinfo-Datenbank des Betriebssystems verwendet oder Zeitzonendaten direkt in Python, Java, PHP, Node.js oder einer anderen Laufzeitumgebung enthält.
Das Python-Zoneinfo-Modul durchsucht Systemdaten oder ein tzdata-Paket.
Eine Anwendung kann daher UTC anzeigen, selbst wenn Shell-Befehle die richtige Zeitzone ausgeben. Vergleichen Sie das Laufzeitverhalten der Anwendung separat von der Container-Shell.
Priorität der Compose-Umgebungsvariablen nach der Neuerstellung überprüfen
Überprüfen Sie die endgültige Umgebung des neu erstellten Containers und vergleichen Sie sie mit der Compose-Interpolation. Umgebung, env_file, und Bildstandards.
Die Containerdokumentation von Red Hat weist darauf hin, dass die Laufzeitkonfiguration die Image-Umgebung überschreiben kann. Daher können ein aktualisiertes Image und eine alte Bereitstellungsdatei einen anderen endgültigen Wert erzeugen als erwartet.
Lesen Sie die tatsächliche Containerumgebung aus, anstatt nur die Compose-Datei zu prüfen. Eine veraltete Stack-Oberfläche oder eine alternative Env-Datei kann den Dienst ohne die vorgesehene Zeitzonenvariable neu erstellt haben.
Konfiguration festlegen und über ein weiteres Update hinweg testen
Wählen Sie eine unterstützte Zeitzonenmethode, legen Sie sie in einer versionskontrollierten Bereitstellungskonfiguration fest, erstellen Sie den Container neu und überprüfen Sie gegebenenfalls Winter- und Sommerzeitdaten.
Der ZimaSpace-Artikel über die Zeit von Container-Jobs und die Umgebung beschreibt die angrenzende Diagnosegrenze für Zeitpläne, die sich ändern, wenn die Zeiteinstellungen des Containers geändert werden.
Das Problem ist behoben, wenn die Anwendung, die Shell, die Protokolle und geplante Jobs nach dem Neustart und einer weiteren kontrollierten Neuerstellung des Images die vorgesehene Zeitzone verwenden.
Häufig gestellte Fragen
Haben Container eine eigene Hardware-Uhr?
Nein. Normalerweise verwenden sie die Systemzeit des Host-Kernels gemeinsam, können diese Zeit aber mithilfe unterschiedlicher Zeitzonendaten und Umgebungseinstellungen formatieren.
Reicht das Setzen von TZ immer aus?
Nein. Das Image und die Anwendung müssen die Variable unterstützen und Zugriff auf Zeitzonenregeln haben. Einige Laufzeitumgebungen verwenden eine separate, gebündelte Datenbank.
Soll ich die Zeitzone des NAS-Hosts ändern, um einen Container zu korrigieren?
Nein. Korrigieren Sie zuerst die Container- oder Anwendungskonfiguration. Eine Änderung am Host kann sich auf Protokolle, Zeitpläne und alle anderen Dienste auswirken.
Empfohlene Produkte
Support & Tipps
Mehr zum Lesen
Warum stellt eine Docker-Volume-Wiederherstellung zwar die Dateiinhalte wieder her, lässt aber erweiterte Attribute weg?
Eine Diagnose zur Wiederherstellung von Volumes mit einer Bestandsaufnahme der erweiterten Attribute, Tar- und Rsync-Optionen, Namespaces, Zielunterstützung, Berechtigungen, Labels, App-Metadaten und Tests.
Warum behält ein laufender Container sein altes Speicherlimit bei, nachdem die Compose-Datei geändert wurde?
Eine Diagnose der Speicherbegrenzung mit Erläuterungen zu aktiven cgroups, Neustart gegenüber Neuerstellung, Compose-Feldern, harten und weichen Limits, übergeordneten Bereichen, Swap sowie Laufzeit-Heaps.
Warum macht ein Neustart des Reverse-Proxys jede Sitzung für eine selbst gehostete App ungültig?
Eine Diagnose von Sitzungsverlusten mit Abdeckung des Neustartumfangs, der Cookie-Zuständigkeit, der Geheimnisrotation, cachebasierten Sitzungen, Sticky-Routing, Authentifizierungs-Gateways und der Wiederherstellung.
