Dlaczego aplikacja w kontenerze przechodzi na czas UTC dopiero po aktualizacji obrazu?

Aplikacja uruchomiona w kontenerze może po aktualizacji wrócić do UTC, jeśli nowy obraz nie zawiera danych stref czasowych, ignoruje TZ albo przestał używać montowania strefy czasowej hosta.

Zegar hosta może działać prawidłowo, podczas gdy aplikacja formatuje daty w UTC, ponieważ kontenery zwykle współdzielą zegar jądra hosta, ale mają własne pliki stref czasowych, zmienne środowiskowe i dane środowiska uruchomieniowego języka. Aktualizacja obrazu może zmienić dystrybucję bazową, usunąć tzdata, zmień użytkownika aplikacji, zastąp punkt wejścia lub przestań uwzględniać specyficzne dla dostawcy TZ zmienną. Porównaj stary i nowy obraz przed zmianą strefy czasowej hosta.

Oddziel czas zegara systemowego od formatowania strefy czasowej

Zapisz czas UTC, sformatowany czas lokalny, nazwę strefy czasowej, przesunięcie numeryczne oraz czas wyświetlany przez samą aplikację w starym i nowym kontenerze.

Biblioteka GNU C wyjaśnia, że zmienna TZ steruje konwersją czasu lokalnego, podczas gdy zegar systemowy pozostaje źródłem czasu absolutnego.

Jeśli czas epoki jest zgodny, ale sformatowana strefa się zmienia, problem dotyczy konfiguracji strefy czasowej, a nie rozbieżności zegara ani NTP.

Sprawdź, czy nowy obraz nadal zawiera tzdata

Porównaj zainstalowane pakiety, /usr/share/zoneinfo, /etc/localtime oraz /etc/timezone między poprzednim a bieżącym tagiem obrazu.

Pakiet tzdata Debiana dostarcza definicje stref czasowych używane przez aplikacje do konwersji czasu UTC na regionalny czas lokalny.

Minimalny obraz zastępczy może celowo pomijać ten pakiet. Zainstaluj go w obrazie pochodnym albo użyj obsługi stref czasowych dostępnej w aplikacji, zamiast ręcznie modyfikować działający kontener.

Sprawdź, w jaki sposób dystrybucja bazowa stosuje TZ

Określ, czy obraz bazuje na Debianie, Ubuntu, Alpine, dystrybucji distroless czy innej bazie. Nie zakładaj, że ustawienie TZ ma identyczne działanie w każdym obrazie.

Alpine Linux opisuje konfigurację strefy czasowej za pomocą tzdata i zoneinfo.

Jeśli aktualizacja zmieniła obraz bazowy, ponownie skonfiguruj strefę czasową, korzystając z metody obsługiwanej przez daną dystrybucję. Skopiowanie jednego pliku ze starego kontenera może pozostawić nieaktualne reguły czasu letniego.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Sprawdź montowanie bind pliku localtime z hosta

Porównaj montowania działającego kontenera przed odtworzeniem i po nim. Sprawdź, czy /etc/localtime lub plik zoneinfo jest nadal zamontowany tylko do odczytu.

Wiązania Docker mapują dokładny plik lub katalog z hosta do kontenera. Oficjalne wskazówki dotyczące montowań bind wyjaśniają, dlaczego usunięte montowanie Compose lub zmieniona ścieżka źródłowa powodują, że nowy kontener wraca do wartości domyślnej obrazu.

Nie montuj całego /etc katalogu. Użyj obsługiwanego pliku lub jawnej konfiguracji strefy czasowej wymaganej przez aplikację.

Sprawdź własną bazę danych stref czasowych środowiska uruchomieniowego aplikacji

Ustal, czy aplikacja korzysta z systemowej bazy danych zoneinfo, czy zawiera dane stref czasowych wewnątrz środowiska Python, Java, PHP, Node.js lub innego środowiska uruchomieniowego.

Moduł Python zoneinfo przeszukuje dane systemowe lub pakiet tzdata.

Aplikacja może więc wyświetlać czas UTC, nawet gdy polecenia powłoki pokazują prawidłową strefę. Zachowanie aplikacji w czasie działania porównuj niezależnie od powłoki kontenera.

Zweryfikuj priorytety zmiennych środowiskowych Compose po odtworzeniu

Sprawdź końcowe środowisko odtworzonego kontenera i porównaj je z interpolacją Compose. środowisko, env_fileoraz ustawienia domyślnych obrazów.

Dokumentacja kontenerów firmy Red Hat wskazuje, że konfiguracja środowiska uruchomieniowego może zastąpić środowisko obrazu, dlatego zaktualizowany obraz i stary plik wdrożenia mogą dać inną końcową wartość, niż oczekiwano.

Sprawdź rzeczywiste środowisko kontenera, a nie tylko plik Compose. Nieaktualny interfejs stosu lub alternatywny plik env mógł odtworzyć usługę bez zamierzonej zmiennej strefy czasowej.

Przypnij konfigurację i przetestuj ją po kolejnej aktualizacji

Wybierz jedną obsługiwaną metodę ustawiania strefy czasowej, przypnij ją w wersjonowanej konfiguracji wdrożenia, odtwórz kontener i sprawdź daty zimowe oraz przejścia na czas letni, jeśli ma to zastosowanie.

Artykuł ZimaSpace o czasie zadań kontenera i środowisku wyznacza sąsiednią granicę diagnostyczną dla harmonogramów, które przesuwają się po zmianie ustawień czasu kontenera.

Problem jest rozwiązany, gdy po ponownym uruchomieniu i kolejnym kontrolowanym odtworzeniu obrazu aplikacja, powłoka, logi i zadania zaplanowane korzystają z właściwej strefy czasowej.

Najczęściej zadawane pytania

Czy kontenery mają własny zegar sprzętowy?

Nie. Zwykle współdzielą zegar systemowy hosta, ale mogą formatować ten czas przy użyciu innych danych stref czasowych i ustawień środowiska.

Czy samo ustawienie TZ zawsze wystarcza?

Nie. Obraz i aplikacja muszą obsługiwać tę zmienną oraz mieć dostęp do reguł stref czasowych. Niektóre środowiska uruchomieniowe korzystają z osobnej, dołączonej bazy danych.

Czy zmienić strefę czasową hosta NAS, aby naprawić jeden kontener?

Nie. Najpierw popraw konfigurację kontenera lub aplikacji; zmiana hosta może wpłynąć na logi, harmonogramy i każdą inną usługę.