- システム障害への対応には、Dockerのネイティブな再起動ポリシーを使用します。
- 異常状態にあるコンテナ向けに、カスタムスクリプトとcronを実装する。
- systemdとの高度な統合により、起動およびシャットダウンのシーケンスを制御します。
- Podman Quadletなどの外部監視代替手段およびツール。
きっとあなたにもこんな経験があるはずです。 ドッカー 不思議なことに、数日おきに動かなくなってしまう。 Dockerコンテナが応答しなくなった場合に、自動的に再起動するにはどうすればよいですか？ コードや設定を最適化しようとしても何も効果がなく、結局手動で再起動するだけで問題が解決し、さらに1週間も正常に動作し続けることに気づくのは、非常にイライラするものです。常に時間を確認するのではなく、こうした面倒な作業を自動で行ってくれるシステムを構築するのが理想的な解決策です。
コンテナの可用性を管理するには、サーバーの電源投入時にコンテナが自動的に起動するようにするだけでは不十分です。 正しく反応するようにしてください リクエストに対して。コンテナはDocker上では「稼働中」に見えるものの、内部のアプリケーションが応答しない場合があり、基本的なデーモンパラメータの設定からオペレーティングシステム内での複雑なサービスの作成まで、さまざまな解決策を探さざるを得なくなります。
Dockerネイティブの再起動ポリシー
Dockerコンテナを自動的に再起動する最も簡単な方法は、フラグを使用することです。 --restart コンテナを起動するとき、またはコマンドを使用するとき docker update コンテナが既に作成されている場合、Docker はニーズに応じていくつかのオプションを提供します。たとえば、ポリシー いつも これにより、プロセスがエラーで終了したか、Dockerデーモン自体が再起動したかに関わらず、コンテナは常に再起動されます。
もっと外科的な方法をご希望の場合は、 停止されない限り これは多くの人にとって最良の選択肢です。この構成は、メンテナンスのためにコンテナを手動で停止した場合を除いて、前の構成と同一です。 Dockerはそれを有効化しようとはしません。 サーバー再起動後に自動的に実行されますが、手動で設定した内容は尊重されます。
重大な失敗に対してのみ行動を起こしたい人向けには、 故障時このポリシーでは、コンテナがゼロ以外の終了コードで終了した場合にのみ再起動がトリガーされます。さらに、最大再試行回数を設定することで、エラーが継続的かつ重大な場合にシステムが無限再起動ループに陥るのを防ぐことができます。
「不健全」なコンテナの自動化
ここからが面白いところです。コンテナが「稼働中」と表示されていても、その健康状態が 不健康 内部チェックに失敗するためです。プロセスは技術的には停止していないため、以前のポリシーはここでは効果がありません。これを解決するには、次の指示を実装できます。 健康診断 Dockerfile または Docker Compose ファイルでコマンドを定義します (例: curl アプリが応答するかどうかを確認するために、特定のポートに（）接続します。
健康チェックの設定が完了したら、 Bashスクリプト 数分ごとに実行される crontab Linux から。このスクリプトは、特定の状態にあるコンテナを除外します。 unhealthy またはエラーコード128で終了し、 docker restart それらについて。
これをスムーズに実行し、Dockerコンテナを自動的に再起動するためには、cronジョブを実行するユーザーが必要な権限を持っていることが不可欠です。 dockerグループに必要な権限このようにして、システムは5分または10分ごとに環境を監視し、「ゾンビ」状態になったサービスを起動することで、人間の介入なしにほぼ完全な可用性を保証します。
systemdとの高度な統合
よりプロフェッショナルな環境で作業する場合、コンテナが次のように動作することを望むかもしれません。 ネイティブLinuxサービス統合する ドッカー Systemd を使用すると、Web アプリケーションより先にデータベースが起動するようにするなど、複雑な依存関係を管理できます。これは、ファイルを作成することによって実現されます。 .service ルートで /etc/systemd/system/.
私たちはデザインすることができます 電源オフと電源オンのシーケンス 制御可能。systemd にリンクされたカスタムスクリプトを使用すると、データ破損を防ぐために、コンテナを依存関係の逆順で停止できます。 oneshot そして構成する targets 適切な（例： multi-user.target o shutdown.targetサーバーはコンテナのライフサイクル全体を管理します。
Dockerコンテナが応答しなくなったときに自動的に再起動するもう1つの強力なオプションは、フラグを使用することです。 --rm systemd と組み合わせて使用します。これにより、停止時にコンテナが削除され、起動時にベースイメージから新しいコンテナが作成され、 容器は常に清潔で、状態が変化していないものでなければならない。データ永続化を外部ボリュームのみに委任する。
外部ツールと最新の代替手段
Bash スクリプトを書くのが面倒な場合は、サードパーティ製のツールが利用できます。コンテナを再起動するために特別に設計されたオープンソースのアプリケーションもあります。 確立されたスケジュールこれは、SSL証明書の更新などの繰り返し発生するタスクに非常に役立ちます。同様に、次のようなツールも アップタイムクマ これらを使用すると、視覚的なダッシュボードからサービスの健全性を監視し、問題が発生した場合はTelegramやGotifyに通知を送信できます。また、Dockerコンテナが応答しなくなった場合に自動的に再起動するのにも非常に役立ちます。
より軽いものやネイティブなものをお探しの方には、 ポッドマン これは素晴らしい選択肢です。デーモンレスアーキテクチャと機能性のおかげで、 クワッドレットこれにより、systemdが自動的に最適化されたサービスに変換するシンプルな宣言型ファイルを作成できるため、従来のDockerよりもはるかに自然な統合が可能になります。
サービスのライフサイクルを完全に制御するには、以下の要素を組み合わせる必要があります。 再起動ポリシー絶え間ない監視 健康診断 さらに複雑なケースでは、 systemdまたは監視ツール そうすることで、インフラストラクチャが堅牢になり、誰かが毎週手動でサーバーを再起動することを覚えておく必要がなくなります。
テクノロジーとインターネット問題を専門とする編集者で、さまざまなデジタル メディアで 10 年以上の経験があります。私は、電子商取引、通信、オンライン マーケティング、広告会社で編集者およびコンテンツ作成者として働いてきました。経済、金融、その他の分野のウェブサイトにも執筆しています。私の仕事は私の情熱でもあります。さて、私の記事を通じて、 Tecnobits, 私は、私たちの生活を向上させるために、テクノロジーの世界が私たちに提供するすべてのニュースや新しい機会を毎日調査しようとしています。