イメージの更新後にのみ、コンテナ化されたアプリのタイムゾーンがUTCに戻るのはなぜですか？
コンテナ化されたアプリケーションは、更新後に UTC に戻ることがあります。新しいイメージでタイムゾーンデータが削除されたり、TZ が無視されたり、ホストのタイムゾーンマウントが使用されなくなったりする場合です。
ホストのクロックが正確なままでも、アプリケーションが日付を UTC で表示することがあります。これは、コンテナが通常ホストのカーネルクロックを共有する一方で、それぞれ独自のタイムゾーンファイル、環境変数、言語ランタイムデータを持つためです。イメージの更新によって、ベースディストリビューションが変更されたり、 tzdata、アプリケーションユーザーを変更する、エントリーポイントを置き換える、またはベンダー固有の TZ 変数。ホストのタイムゾーンを変更する前に、古いイメージと新しいイメージを比較します。
システムクロックの時刻とタイムゾーンの表示を分ける
古いコンテナと新しいコンテナ内で、UTC 時刻、現地時刻の表示、タイムゾーン名、数値オフセット、およびアプリケーション自体が表示する時刻を記録します。
GNU C ライブラリの説明によると、TZ 変数は現地時刻への変換を制御しますが、基盤となるシステムクロックは絶対時刻のソースであり続けます。
エポック時刻が一致しているのに表示されるタイムゾーンが変わる場合、問題はクロックのずれや NTP ではなく、タイムゾーン設定にあります。
新しいイメージに tzdata がまだ含まれているか確認する
インストール済みパッケージを比較する /usr/share/zoneinfo, /etc/localtime、および /etc/timezone 以前のイメージタグと現在のイメージタグの間で
Debian の tzdata パッケージは、アプリケーションが UTC を地域の現地時刻に変換するために使用するタイムゾーン定義を提供します。
最小構成の代替イメージでは、このパッケージが意図的に省かれている場合があります。派生イメージにインストールするか、実行中のコンテナを手動で変更するのではなく、アプリケーションがサポートするタイムゾーンの仕組みを使用してください。
ベースディストリビューションで TZ がどのように適用されるかを確認する
イメージが Debian、Ubuntu、Alpine、distroless、または別のベースのいずれであるかを特定します。設定が TZ すべてのイメージで同じ効果があるわけではありません。
Alpine Linux では、tzdata と zoneinfo を使用したタイムゾーン設定について説明しています。
更新によってベースイメージが変更された場合は、そのディストリビューションでサポートされている方法を使って、タイムゾーンの設定をやり直してください。古いコンテナからファイルを1つコピーするだけでは、夏時間のルールが古いままになる可能性があります。
ホストの localtime バインドマウントを確認する
再作成の前後で、実行中のコンテナのマウントを比較します。次の点を確認してください。 /etc/localtime または zoneinfo ファイルが引き続き読み取り専用でマウントされています。
Docker のバインドマウントは、ホスト上の特定のファイルまたはディレクトリをコンテナ内にマッピングします。公式のバインドマウントに関するガイダンスが示すように、Compose のマウントを削除したりソースパスを変更したりすると、新しいコンテナはイメージのデフォルト値にフォールバックします。
ホスト全体の /etc ディレクトリ。アプリケーションが必要とする、サポート対象の限定的なファイルまたは明示的なタイムゾーン設定を使用してください。
アプリケーションランタイム独自のタイムゾーンデータベースを確認する
アプリケーションがオペレーティングシステムの zoneinfo データベースを使用しているのか、Python、Java、PHP、Node.js などのランタイムにタイムゾーンデータを内蔵しているのかを特定します。
Python の zoneinfo モジュールはシステムデータまたは tzdata パッケージを検索します。
そのため、シェルコマンドで正しいタイムゾーンが表示されても、アプリケーションが UTC を表示する場合があります。アプリケーションの実行時の動作とコンテナシェルを別々に比較してください。
再作成後の Compose 環境変数の優先順位を確認する
再作成されたコンテナの最終的な環境を確認し、Compose の補間結果と比較します。 環境, env_file、画像のデフォルト値。
Red Hatのコンテナドキュメントでは、ランタイム設定でイメージ環境を上書きできると説明されています。そのため、更新されたイメージと古いデプロイファイルを組み合わせると、想定とは異なる最終値になる可能性があります。
Composeファイルだけでなく、実際のコンテナ環境を確認してください。古いスタックUIや別のenvファイルによって、意図したタイムゾーン変数なしでサービスが再作成されている可能性があります。
設定を固定し、別のアップデートでもテストする
サポートされているタイムゾーン方式を1つ選び、バージョン管理されたデプロイ設定に固定して、コンテナを再作成し、該当する場合は冬時間と夏時間の日付で検証してください。
コンテナの時刻と環境に関するZimaSpaceの記事では、コンテナの時刻設定を変更した際にスケジュールがずれる場合の、関連する診断範囲を確認できます。
再起動後、および別の管理されたイメージ再作成後に、アプリケーション、シェル、ログ、スケジュール済みジョブが意図したゾーンを使用していれば、問題は解決しています。
よくある質問
コンテナには独自のハードウェアクロックがありますか？
いいえ。通常、ホストのカーネルクロックを共有しますが、その時刻を異なるタイムゾーンデータや環境設定を使ってフォーマットできます。
TZを設定すれば、常に十分ですか？
いいえ。イメージとアプリケーションがその変数をサポートし、タイムゾーンのルールにアクセスできる必要があります。ランタイムによっては、別途バンドルされたデータベースを使用するものもあります。
1つのコンテナを修正するために、NASホストのタイムゾーンを変更すべきですか？
いいえ。まずコンテナまたはアプリケーションの設定を正しく修正してください。ホストを変更すると、ログ、スケジュール、その他すべてのサービスに影響する可能性があります。
おすすめ商品
サポートとヒント
もっと読む
Dockerボリュームの復元でファイルの内容は再現されるのに、拡張属性が失われるのはなぜですか？
xattr のインベントリ、tar と Rsync のオプション、名前空間、保存先のサポート状況、権限、ラベル、アプリメタデータ、テストを網羅したボリューム復元の診断。
Composeファイルを変更した後も、実行中のコンテナが古いメモリ制限を維持するのはなぜですか？
ライブcgroup、再起動と再作成の違い、Composeのフィールド、ハードリミットとソフトリミット、親スコープ、スワップ、ランタイムヒープを網羅したメモリ制限の診断。
リバースプロキシを再起動すると、1つのセルフホストアプリですべてのセッションが無効になるのはなぜですか？
再起動の範囲、Cookieの所有権、シークレットのローテーション、キャッシュを利用したセッション、スティッキールーティング、認証ゲートウェイ、復旧を網羅したセッション喪失の診断。
