Dockerには、コンテナーのライフサイクルを管理するためのいくつかのオプションがあります。コンテナは通常、終了後に自動的に再起動しません。再起動ポリシーを使用すると、個々のコンテナのライフサイクルを制御できます。
再起動ポリシーは、コンテナの実行が停止するたびに使用されます。 Dockerは、デーモンの起動時に再起動ポリシーも調べます。このメカニズムを使用して、再起動後にコンテナをホストに表示できます。
現在、4つの異なる再起動ポリシーがあります：
いいえ–このポリシーは、コンテナーを自動的に開始することはありません。これは、docker runで作成されたすべてのコンテナのデフォルトポリシーです。 。常に– Dockerは、コンテナーが常に実行されていることを確認します。コンテナが停止すると、すぐに再起動されます。docker stopを使用して、コンテナを手動で停止することもできます ただし、Dockerは、次にデーモンが再起動したときにそれを元に戻します。障害時–エラーのために停止した場合、コンテナは再起動されます。デーモンの再起動後、Dockerはコンテナを起動しません。停止しない限り–これは常にと同様に機能します 。違いは、コンテナが手動で停止されている場合、Dockerがコンテナを再起動しないことです。
通常、本番ワークロードには最後の3つのオプションのいずれかを使用します。 Dockerコンテナーは、長時間実行されるバックグラウンドサービスによく使用されるため、通常、問題が発生したときにコンテナーを再起動する必要があります。 no ポリシーは、ローカル開発での使用に最適です。また、単一の実行可能ファイルを実行してから終了するユーティリティコンテナにも役立ちます。
使用する再起動ポリシーを決定するのは難しい場合があります。 常に 多くの場合、これが最も自然な選択ですが、デーモンの再起動動作は簡単に見落とされる可能性があります。 docker stop を実行した後、コンテナを確実に停止したままにしたい場合 、 unless-stoppedを使用する必要があります 。
Dockerは、コンテナーのフォアグラウンドプロセスから発行された終了コードに基づいてエラーを検出します。 1の終了コード 以上はエラーと解釈されます。これは、Unixでの終了コードの処理と一致します。 0のみです。 成功した実行を表します。
Dockerがコンテナを再起動するときは、 docker runを実行するのと同じです。 また。つまり、画像の ENTRYPOINT スクリプトが呼び出されます。ブートストラップシステムは、常に複数の呼び出しに対して回復力がある必要があります。
-restart を渡すことで、特定の再起動ポリシーでコンテナを起動できます。 docker runへのフラグ ：
docker run --name httpd --restart always httpd:latest
Docker Composeを使用している場合は、 restartを追加します docker-compose.ymlへのフィールド ：
services:
httpd:
image: httpd:latest
restart: always
docker update を使用して、既存のコンテナの再起動ポリシーを変更できます 。コンテナの名前をコマンドに渡します。 docker ps -a を実行すると、コンテナ名を見つけることができます。 。
docker update --restart-policy unless-stopped httpd
docker updateを使用できます 実行中または停止中のコンテナを使用します。
Dockerには、永続的な再起動ループに対するいくつかの保護手段が含まれています。 1つ目は、再起動ポリシーがアクティブになるまでの必須の時間遅延です。 Dockerは、コンテナーが少なくとも10秒間実行されるまで、再起動の監視を開始しません。これにより、障害が発生したコンテナが継続的に再起動するのを防ぎます。
その他の専門家の行動は、 docker stopに関するものです。 指図。 Dockerは常にdockerstopの使用を尊重します そのため、コマンドを実行した後、コンテナはすぐには再起動しません。実際にコンテナを再起動する場合は、 docker restartを使用してください 代わりに。
on-failure 再起動ポリシーを使用すると、再試行する回数を指定できます。 Dockerは、コンテナが連続して複数回起動に失敗した場合、あきらめてコンテナを停止状態のままにします。
docker run httpd:latest --restart on-failure:5
この例では、Dockerは障害（ゼロ以外の終了コード）の後にコンテナーを5回再起動しようとします。 5回目の試行でコンテナの起動に失敗した場合、それ以上の再試行は試行されません。このオプションは、手動による介入なしに永続的な開始エラーが解決される可能性が低いコンテナに役立ちます。
コンテナが停止した理由を知る必要がある場合は、 docker ps -aを実行してください 。これにより、停止しているか実行中かを問わず、すべてのコンテナの詳細が表示されます。ターゲットコンテナを見つけて、その「ステータス」列を確認します。停止したコンテナーの場合、終了コードは括弧内に示されます。コードがゼロより大きい場合、エラーが原因でコンテナが終了しました。
個々のエラーコードの意味を判断するには、コンテナで実行されているプロセスのドキュメントを参照する必要があります。ただし、多くの場合、コンテナのログを取得することで、クラッシュの原因についての洞察を得ることができます。コンテナが停止した後も、ログは引き続き利用できます。
docker logs my-container
ログストリームは、コンテナの標準出力と標準エラーストリームを集約します。エラーがログに記録されている場合は、出力の最後の数行にエラーが表示されることを期待する必要があります。
再起動ポリシーは、Dockerコンテナーが必要なときに確実に存在するようにするのに役立ちます。デフォルトのno ポリシーは、ほとんどの本番ワークロードには適していません。コンテナがクラッシュした場合に、コンテナを停止したままにしたくないのです！
3つの再起動可能なポリシーのいずれかを使用すると、コンテナはハードウェアの再起動や予期しない終了に対してより回復力があります。 Dockerは、コンテナーがクラッシュした場合でもサービスの可用性を維持します。