第27回 32ビット環境に迫る「2038年問題」 検証で分かった事実：古賀政純の「攻めのITのためのDocker塾」（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