ニュース
» 2016年08月10日 08時00分 UPDATE

古賀政純の「攻めのITのためのDocker塾」:第27回 32ビット環境に迫る「2038年問題」 検証で分かった事実 (1/4)

ここまで32ビット環境における「2038年問題」と、その検証に向けた準備を進めてきました。今回は準備した環境で実際に検証してみます。ついでに、筆者が18年間愛用する腕時計でも試してみました。

[古賀政純(日本ヒューレット・パッカード),ITmedia]

西暦2038年1月19日3時14分7秒を過ぎたら、Docker環境では何が起こるのか?

 前回に挙げた5つの疑問のうち、最後の疑問5はDockerの2038年問題です。実際に、2038年1月19日3時14分7秒を過ぎたらDockerコンテナがどうなるのかを見てみましょう。

 Dockerエンジンが稼働するホストOSを2038年にセットする前に、まずは準備として、必要なDockerイメージを2つ入手しておきます。時刻を2038年にセットした後では、Dockerイメージの入手に失敗する可能性がありますので、この時点で入手しておきます。32ビット版のDockerイメージ「tenforward/centos-i386」と比較のための64ビット版CentOS 6.8のDockerイメージ「centos:centos6.8」を入手し、ホストOS上に保存しておきます。


# docker pull tenforward/centos-i386
# docker pull centos:centos6.8

 さて、Dockerイメージを入手したら、Dockerエンジンが稼働する64ビット版のホストOS側の時計を「2038年1月19日3時10分00秒」(協定世界時の場合)にセットします。この状態でホストOS側は問題なく時計を刻んでいるはずです。次に、この状態で32ビット環境のDockerコンテナを起動します。問題の時間を過ぎて、Dockerコンテナの時計がどうなるかを確認します。

※注意

 今回、ホストOS側の時計を2038年にセットしますので、ホストOS側は、個人のテスト環境など、業務に全く影響がでないシステムで行ってください。本番環境での安易なテストは、システム障害の原因になりますので、絶対に行わないで下さい。

 なお、「2038年1月19日3時14分7秒」は協定世界時ですので、日本標準時(JST)の場合は9時間をプラスします。まず、64ビットのホストOS上で現在の時刻を確認します。今回のホストOSはCentOS 7.2を想定します。


# date
2016年  6月 29日 水曜日 04:29:43 JST

 上記のように、「JST」と表示されている場合は日本標準時ですので、2038年問題の時間は「2038年1月19日12時14分8秒」になります。それでは、2038年問題が発生する4分8秒前に時刻をセットします。ホストOSがJSTの場合は、以下のコマンドで時刻を2038年1月19日12時10分00秒にセットできます。


# date 011912102038
# date
2038年  1月 19日 火曜日 12:10:00 JST

 ホストOSが、2038年1月19日12時10分00秒にタイムスリップしました。この状態で32ビット版のDockerコンテナを起動します。連載第19回でも取り上げましたが、DockerコンテナでホストOSと同じタイムゾーンを設定するには、コンテナ起動時に「-v /etc/localtime:/etc/localtime:ro」を付与します。今回、コンテナ名は「test2038」にしました。


# docker run -it \
--rm \
--name test2038 \
-v /etc/localtime:/etc/localtime:ro \
tenforward/centos-i386 /usr/bin/linux32 /bin/bash

 32ビット版のDockerコンテナ上で、dateコマンドを入力してみましょう。


bash-4.1# date
Tue Jan 19 12:13:05 JST 2038

 まだ、2038年問題が発生する1分3秒前です。dateコマンドを何回か入力して、時刻が刻まれていることを確認します。


bash-4.1# date
Tue Jan 19 12:13:46 JST 2038

       1|2|3|4 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

ピックアップコンテンツ

- PR -

注目のテーマ

マーケット解説

- PR -