Docker コンテナにデプロイされた Django のタイムゾーンの問題

現在、コンテナ デプロイメントは非常に成熟しています。当社のサービスの多くはコンテナ デプロイメントを使用しており、更新とリカバリは非常に便利です。ただし、より厄介な問題があります。それは、タイム ゾーンの処理です。通常、これは TZ 環境変数を挿入することで解決されますが、この処理方法は Django では機能しません。

Django でのタイムゾーン設定

Django の設定ファイル settings.py には、時間とタイムゾーンに関連する TIME_ZONE と USE_TZ という 2 つの設定パラメータがあります。 settings.py で設定した後、Django はローカル時間を正しく取得できると期待していましたが、実際は期待に反しています。これら 2 つの設定が何をするのか見てみましょう。

USE_TZ=真

USE_TZ が True に設定されている場合、Django はシステムのデフォルトのタイムゾーンを使用します。このとき、TIME_ZONE 設定は基本的に無効であり、設定されているかどうかに関係なく効果はありません。

USE_TZ=偽

USE_TZがFalseに設定されている場合

1. TIME_ZONEはNoneに設定されています
2. Djangoはデフォルトのタイムゾーンを引き続き使用します
3. TIME_ZONEが別のタイムゾーンに設定されている場合

Windows を使用している場合、TIME_ZONE 設定は役に立たず、Django はローカル時間を使用します。他のシステムを使用している場合は、そのタイムゾーンの UTC 時間を使用します。

たとえば、USE_TZ = False、TIME_ZONE = 'Asia/Shanghai' に設定すると、上海の UTC 時間が使用されます。

この時点では、時間は適切だと思うかもしれませんが、実際はそうではありません。システムのタイムゾーン設定にも注意する必要があります。

Linux コンテナでのタイムゾーンの設定

私の現地時間は16:15で、Djangoの設定はUSE_TZ = False、TIME_ZONE = 'Asia/Shanghai'です。

コンテナの時間とタイムゾーンを表示するためにコンテナに入るときに、TZ=Asia/Shanghai 環境変数を挿入しないでください。

システム時間はUTCタイムゾーンで表示され、時刻は08:15で、ちょうど8時間の差です。

Django環境に入り、時間とタイムゾーンを表示します。

python manage.py シェル 
 
datetime から datetime をインポート 
日付時刻.now() 
# 出力 datetime.datetime(2021, 10, 8, 8, 24, 8, 289230) 
 
django.utilsからタイムゾーンをインポートする 
タイムゾーン.get_current_timezone_name() 
# 'Asia/Shanghai' を出力

環境変数 TZ=Asia/Shanghai を挿入します
コンテナに入ると時間とタイムゾーンが表示されます

システム時間はアジアタイムゾーンで表示されますが、時間は実際の現地時間ではなく、UTC 時間のままです。

Django環境に入り、時間とタイムゾーンを表示します。

python manage.py シェル 
 
datetime から datetime をインポート 
日付時刻.now() 
# 出力 datetime.datetime(2021, 10, 8, 8, 24, 8, 289230) 
 
django.utilsからタイムゾーンをインポートする 
タイムゾーン.get_current_timezone_name() 
# 'Asia/Shanghai' を出力 

ご覧のとおり、タイムゾーンは変更されていますが、コンテナ自体とDjangoの両方で時刻はUTC時間のままです。

オンラインで検索すると、Linux システムのタイムゾーンを変更するには、/etc/localtime ファイルを変更する必要があることがわかります。

Linuxコンテナのタイムゾーンを変更する

通常は、ホストの /etc/localtime ファイルをコンテナの /etc/localtime ファイルにコピーします。しかし、クエリによって、/etc/localtime ファイルは実際には単なるソフト リンクであることがわかりました。実際のファイルは次のとおりです: /usr/share/zoneinfo/Asia/Shanghai

docker cp /usr/share/zoneinfo/Asia/Shanghai テスト:/etc/localtime
TZ=Asia/Shanghai 環境変数をコンテナに挿入せずにコンテナにログインすると、コンテナのシステム時刻がローカル時刻とタイムゾーンを正しく取得していることがわかります。

TZ=Asia/Shanghai 環境変数が挿入されている場合、/etc/localtime ファイルが置き換えられても、タイムゾーンのみが変更され、時間は UTC 時間のままです。

Django環境に入り、時間を表示します

python manage.py シェル 
 
datetime から datetime をインポート 
日付時刻.now() 
# 出力 datetime.datetime(2021, 10, 8, 8, 43, 43, 754698) 

Linux のシステム時間は正常ですが、Django 環境の時間は依然として不正確で、UTC 時間のままです。この時点で、多くの人が少し頭がおかしくなり、settings.py の USE_TZ と TIME_ZONE の設定に問題があると考えるかもしれません。実際には、問題はここにはありません。その理由は、datetime ライブラリは /usr/share/zoneinfo/ ディレクトリで Asia/Shanghai ファイルを検索しますが、イメージにはこのディレクトリが含まれていないため、Django は引き続き UTC タイムゾーンを使用するためです。解決策は非常に簡単です。/usr/share/zoneinfo/Asia ディレクトリを作成し、ファイルをこのディレクトリにコピーします。

# コンテナ内（このディレクトリが存在しない場合） 
mkdir -p /usr/share/zoneinfo/アジア 
 
# コンテナ外 docker cp /usr/share/zoneinfo/Asia/Shanghai test:/usr/share/zoneinfo/Asia/Shanghai

次にコンテナにログインし、Django環境に入り時間を確認します。

python manage.py シェル 
 
datetime から datetime をインポート 
日付時刻.now() 
# 出力 datetime.datetime(2021, 10, 8, 16, 49, 32, 57) 

今回はタイミングがぴったりでした。

要約する

コンテナのタイムゾーンの問題については、コンテナ作成フェーズで/etc/localtimeをインストールして設定することをお勧めします。たとえば、Dockerfileに次のステートメントを追加します。

/usr/share/zoneinfo/Asia/Shanghai を追加します。 /usr/share/zoneinfo/Asia/Shanghai 
 
RUN ln -s /usr/share/zoneinfo/Asia/Shanghai /etc/localtime 

この方法では、コンテナを起動するときにタイムゾーンの問題を気にする必要はありません。コンテナが作成されている場合は、起動時にタイムゾーンファイルをマウントします。

docker run -d -v /etc/localtime:/etc/localtime -v /usr/share/zoneinfo/Asia/Shanghai:/usr/share/zoneinfo/Asia/Shanghai イメージ名 

この方法はもっと面倒です。私たちが現在直面しているもう 1 つの状況は、サービスがすでにオンラインになっていることです。時間的な問題があることがわかりました。2 つのファイルを手動でコンテナーにコピーし、コンテナーを再起動します。

docker cp /usr/share/zoneinfo/Asia/Shanghai テスト:/etc/localtime 
docker cp /usr/share/zoneinfo/Asia/Shanghai テスト:/usr/share/zoneinfo/Asia/Shanghai 
docker 再起動テスト 

これで、Docker コンテナに Django をデプロイする際のタイムゾーン問題についての記事は終了です。Django のタイムゾーンの Docker デプロイの詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。