異常なコンテナを強制的に再起動し、Dockerをさらに改善します

今日は、Docker ヘルスチェック メカニズムに関する前回の記事に引き続き、不健全なコンテナを再起動する方法について説明します。さらに、一部の読者から、いくつかのパラメータがよくわからないという報告があったので、この記事ではそれらについてさらに詳しく説明します。

Docker はバージョン 1.12 以降で HEALTHCHECK 命令を提供します。サービスの状態が正常かどうかを判断するためのコマンドラインを設定することで、サービスの状態をより正確に判断することができます。

起動後の HEALTHCHECK コンテナの初期ステータスは「開始中」です。命令チェックが成功すると、ステータスが正常になります。連続した障害回数が指定回数を超えると、異常状態に変わります。 HealthCheck の仕組みを見てみましょう。

HEALTHCHECK パラメータ オプション:

--interval: ヘルスチェック間隔、デフォルトは30秒

--timeout: ヘルスチェックがこの設定時間を超えると失敗とみなされます。デフォルト設定は30秒です

--retries: ヘルス チェックが連続してこの回数以上失敗すると、ステータスはデフォルトで 3 回、異常に変更されます。

--start-period: 開始時間、デフォルトは 0 秒

HEALTHCHECK は Dockerfile または docker-compose.yml 経由で設定できます。

Dockerfileの例

Dockerfileでは、HEALTHCHECK命令の形式は

HEALTHCHECK [options] CMD <command>

<command> は、シェル コマンドまたは exec 形式にすることができます (他の Dockerfile 命令と同じ、ENTRYPOINT を参照)。 Dockerfile には HEALTHCHECK 命令が 1 つだけ存在できます。同時に複数の HEALTHCHECK 命令がある場合、最後の命令のみが有効になります。

<command> の戻り値はコンテナのステータスを表します。

0: 成功、コンテナは正常です

1: 失敗。失敗が指定された回数を超えると、コンテナは正常ではありません。

2: 予約済み、この値は使用しないでください

コンテナ サービスが Web サービスであると仮定すると、これを使用してサービスが正常に実行されているかどうかを確認できます。たとえば、5 秒以内にリクエストに応答できるかどうかを 30 秒ごとに確認します。curl http://localhost:3000

 # ... HEALTHCHECK --interval=30s --timeout=5s --retries=5 --start_period=30s \ CMD curl -fs http://localhost:3000/ || exit 1 # ...

Docker-compose の例

docker-compose.yml のヘルスチェックは次のとおりです。

 version: "3.7" services: api: restart: always image: api container_name: api ports: - 3000:3000 build: context: ./api healthcheck: test: curl -fs http://localhost:3000/ || exit 1 interval: 30s timeout: 5s retries: 5 start_period: 30s networks: - net networks: net: name: net driver: bridge

ここで、test は文字列またはリストである必要があります。リストの場合、最初の項目は NONE または CMD-SHELL である必要があります。文字列の場合はCMD-SHELLと同等です。

健康状態を確認する

ヘルスチェックコマンドを設定したら、コンテナを起動してコンテナの状態を確認します。初期ステータスは「health:starting」であることがわかります。

 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6c7b9ca321d2 api:1.0.0 "uwsgi --ini /home/d…" 5 seconds ago Up 2 seconds (health: starting) 0.0.0.0:3000->3000/tcp api

30 秒後に docker ps を再度実行すると、コンテナのステータスが正常になることがわかります。

 $ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6c7b9ca321d2 api:1.0.0 "uwsgi --ini /home/d…" 35 seconds ago Up 32 seconds (healthy) 0.0.0.0:3000->3000/tcp api

連続した障害の数が指定された数を超えると、ステータスは不健全になります。

重要なステップ: 不健全なコンテナを再起動する

上記の手順では、コンテナの正常性状態のみをチェックし、正常でないコンテナに対しては何も行いません。 docker-autoheal を使用して、異常なコンテナを再起動できます。まず、AutoHeal の動作メカニズムを見てみましょう。

Autoheal は docker を使用して直接実行することも、docker-compose で記述することもできます。

docker コマンドを使用します:

 $ docker run -d \ --name autoheal \ --restart=always \ -e AUTOHEAL_CONTAINER_LABEL=all \ -v /var/run/docker.sock:/var/run/docker.sock \ willfarrell/autoheal

docker-compose コマンドを使用します。

 version: "3.7" services: autoheal: restart: always image: willfarrell/autoheal container_name: autoheal environment: - AUTOHEAL_CONTAINER_LABEL=all volumes: - /var/run/docker.sock:/var/run/docker.sock

次に、docker-compose up -d autoheal を実行して起動します。

起動後、docker ps を使用して、異常なコンテナが再起動されたかどうかを確認できます。自動修復ログをチェックして、起動記録があるかどうかを確認することもできます。

最後に、不健康な状態をシミュレートする方法を紹介します。通常の状況では正常ですが、コマンドを変更することで不健全な状態をシミュレートできます。たとえば、MySQL サービスをシミュレートするには、次のコマンドを使用できます。

 test: ["CMD", "nc -vz localhost 3307 || exit 1"]

通常はポート 3306 をリッスンしますが、接続してチェックするには 3307 を使用しますが、常に不健全な状態になります。この時点で、自動修復ログを通じて MySQL コンテナの再起動を確認できます。

このメカニズムにより、疑似的な停止が発生した場合に Docker を自動的に再起動できます。このチェックと自動再起動のメカニズムは、データベースまたは Tomcat サービスに非常に役立ちます。ご使用中にご不明な点がございましたら、メッセージをお送りください。