docker run によって起動されたコンテナがハングしてデータが失われた場合の対処方法

シナリオの説明

あるシステムでは、機能サービスはdocker stack deploy xxxで起動し、国内データベースのサービスはdocker run xxxで別途起動しています。データベースサービスは保存場所をマウントしません。

その結果、顧客はサーバーを再起動しました... サービスを再起動するためにサーバーにログインすると、データベース内の以前のデータが消える可能性があるという問題が見つかりました (docker run を使用してサービスを再度開始する場合)。

解決

試行 1

最初はデータが確実に失われたと思ったので、再度データを復旧する必要がありましたが、作業量が膨大すぎました...

でも仕方がない、次回起動時にストレージをハードディスクにマウントするだけだ、Orz

しかし、同僚と話し合った結果、より簡単な（ただし永続的ではない）解決策を見つけました。試行 2 を参照してください。

試行2

同僚によると、 docker start container_nameを使用してコンテナを再度起動できるので、データはそのまま残っているとのことでした。後で試してみたところ、データはまだ残っていました...一時的な解決策に過ぎませんでしたが

後で考えてみると、docker によって起動されたイメージのデータがマッピングされていない場合、そのデータはデフォルトのボリュームに保存されます。docker restart xxx でコンテナを再起動しても、変更されたデータはそのまま残ります。つまり、この時点では、サーバーが再起動され、コンテナがハングアップしています (docker ps を使用して表示すると、コンテナのステータスは Exited です)。ただし、実際には、以前のデータはデフォルトのボリュームに残っており、変更されたデータはコンテナが削除された場合にのみ失われます。

検証テスト

イメージをパックし、コンテナを起動し、ファイルを作成し、停止し、再度起動して、ファイルが存在するかどうかを確認するだけです。

# コンテナを起動します ➜ docker_start_test docker run -itd --name docker_run_test 4cbf48630b46 ping 127.0.0.1
d6278f537113122d4ccbe00950790750215c5a09002bcbd1ef6f9e660fc9eaac
➜ docker_start_test docker ps -a
コンテナID イメージ コマンド 作成ステータス ポート名
d6278f537113 4cbf48630b46 "ping 127.0.0.1" 3秒前 2秒前 docker_run_test
# コンテナにファイルを追加 ➜ docker_start_test docker exec -it docker_run_test /bin/sh
sh-4.2#パスワード
/
sh-4.2# タッチテスト
sh-4.2# 終了
出口
# コンテナを再起動します ➜ docker_start_test docker stop docker_run_test
docker_run_test
➜ docker_start_test docker ps -a | grep docker_run_test
d6278f537113 4cbf48630b46 "ping 127.0.0.1" 約1分前 終了しました (137) 12秒前 docker_run_test
# ファイルが存在するか確認します ➜ docker_start_test docker start docker_run_test
docker_run_test
➜ docker_start_test docker exec -ti docker_run_test /bin/sh
sh-4.2# ls
anaconda-post.log bin dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys test tmp usr var

ご覧のとおり、ファイル test はまだ存在しています。コンテナを停止し、docker rm を使用してコンテナを削除し、同じ名前のコンテナを再起動すると、コンテナ内に test ファイルがないことがわかります。

# コンテナを停止/rm ➜ docker_start_test docker stop docker_run_test
docker_run_test
➜ docker_start_test docker ps -a | grep docker_run
d6278f537113 4cbf48630b46 "ping 127.0.0.1" 7 分前 終了 (137) 13 秒前 docker_run_test
➜ docker_start_test docker rm d6278f537113
d6278f537113
# 同じ名前で新しいコンテナを起動します ➜ docker_start_test docker run -itd --name docker_run_test 4cbf48630b46 ping 127.0.0.1
99a6f5df0a86e4c07abf184e322a23e4fbec89ff354691459cdac8fcd8687ba3
# 検証するコンテナに入る ➜ docker_start_test docker exec -ti docker_run_test /bin/sh
sh-4.2# ls
anaconda-post.log bin dev etc home lib lib64 lost+found media mnt opt proc root run sbin srv sys tmp usr var
sh-4.2# ls テスト
ls: テストにアクセスできません: そのようなファイルまたはディレクトリはありません

docker runの手順

公式サイトによると、start コマンドの機能は次のとおりです。

Start one or more stopped containers

うーん、かなり単純で、言うことはあまりないですね

追伸

実際、コンテナのストレージディレクトリをマウントするのが最善の方法です...また、一般的に言えば、コンテナを使用してデータベースサービスを起動すべきではないようです

要約する

上記は、docker run によって起動されたコンテナがデータをハングアップした場合の対処方法について紹介したものです。お役に立てば幸いです。ご質問がある場合は、メッセージを残してください。すぐに返信いたします。また、123WORDPRESS.COM ウェブサイトをサポートしてくださっている皆様にも感謝申し上げます。
この記事が役に立ったと思われた方は、ぜひ転載していただき、出典を明記してください。ありがとうございます!

以下もご興味があるかもしれません: