Docker Compose を使用すると、単一のコマンドを実行して 複数のコンテナーを起動できます 。これにより、いくつかの独立したコンポーネントから形成される複雑なサービスの起動が簡素化されます。
ただし、これが常に十分であるとは限りません。一部のコンテナーには、相互に依存関係があり、それを満たせないとアプリケーションが中断される場合があります。このガイドでは、これらの依存関係に対応するように Compose サービスを構成し、コンテナーを順番に起動できるようにする方法を説明します。
基礎
depends_onのフィールド
docker .compose .ymlファイル。サービスには兄弟の名前を含めることができます。
depends_on
。これにより、依存するサービスが起動するまでコンテナーが起動できなくなります。
サービス:
API:
画像: example.com/api:latest
依存:
– データベース
ウェブアプリ:
画像: example.com/web-app:latest
依存:
– API
データベース:
画像: mysql:8.0
この例では、
depends_on
フィールドにより、サービスが次の順序で開始されます。
-
db -
api -
web-app
各サービスの依存関係は再帰的に解決されます。それぞれを定義するサービス
depends_onフィールドは最後、チェーンの最後から開始されます。サービスが他の複数のコンテナに依存している場合、それらのコンテナは、
depends_on
分野。
次のコマンドでスタックを停止すると、サービスのチェーンが逆に使用されます。
docker-compose stop
。上の例では、
web-app
コンテナが最初に削除され、次に
apiそして
db。これにより、
web-app
解体作業の開始時にコンテナが破損するのを防ぎます。
準備が整うのを待っています
デフォルト
depends_on構成は、依存するコンテナーが開始されるのを待つだけです。上の例では、Compose は
apiすぐにコンテナ
dbコンテナ内のデータベース サーバーが接続を受信する準備ができていない場合でも、実行されています。これはつまり
depends_on単独で十分であることはほとんどありません。
この機能を ヘルスチェック と組み合わせて、依存関係が実際に準備できるまでコンテナーが起動しないようにすることができます。この機能を使用するには、
condition
下のフィールド
depends_onと
service_healthyその値として:
サービス:
API:
画像: example.com/api:latest
依存:
– データベース
健康診断：
テスト:curl –fail http://127.0.0.1 ||出口1
間隔: 10秒
再試行: 5
開始期間: 5秒
タイムアウト: 10秒
ウェブアプリ:
画像: example.com/web-app:latest
依存:
API:
条件: サービス_健全
データベース:
画像: mysql:8.0
今、
api
コンテナには healthcheck コマンドが添付されています。の
web-appまでサービスを開始しないように指示されます。
api
ヘルスチェック結果が成功した状態で作成されました。これは、API がリクエストへの応答を開始し、
curl
コマンドはステータス コード 0 で終了します。
コンテナの正常な終了を待機しています
場合によっては、依存関係が、最後まで実行したい使い捨てコンテナである場合があります。この種の依存関係を待機するには、
condition
フィールドから
service_completed_successfully。これは、別のコンテナーで実行される初回実行セットアップ スクリプトがある場合に便利です。
サービス:
アプリ：
画像: example.com/app:latest
依存:
config_builder:
条件: サービス完了_成功
ボリューム:
– 設定:/opt/app/config
config_builder:
画像: example.com/config_builder:latest
環境:
– 例_キー
– ANOTHER_KEY
ボリューム:
– config:/出力
ボリューム:
構成:
この例は、依存イメージが共有ボリュームに構成ファイルを書き込むコマンドを実行する方法を示しています。
app
。データの書き込み後、
config_builder
コンテナは終了コード 0 で停止します。 Compose を実行すると、自動的に
app依存関係条件が満たされたため、サービスが返されます。
他のツールを使用してさらに制御
状況によっては
depends_onとともに
conditionあなたのユースケースに対応するにはまだ十分ではないかもしれません。外部ツールを追加して、ヘルスチェックを手動で実装し、コンテナ間のリンクを処理できます。
Wait-for-It は、 別のプロセスをラップするユーティリティ スクリプトです。特定の条件が満たされた後、指定したコマンドが実行されます。これを使用して、Docker の組み込みサポートとは独立してヘルスチェック手順を定義できます。
使用方法は次のとおりです
healthcheckリンクされたコンテナ ポートがアクセス可能になるまで待機するには:
サービス:
API:
画像: example.com/api:latest
依存:
– データベース
ウェブアプリ:
画像: example.com/web-app:latest
依存:
– API
コマンド: [“./wait-for-it.sh”、”api:8080″、”–“、”node”、”app.js”]
データベース:
画像: mysql:8.0
ここでは、Docker Compose を待機させるだけの状態に戻しました。
api
コンテナを起動します。の
web-appサービスは、次のことを確認する責任を負います。
api
健康です。 Wait-for-It スクリプトを使用して、コンテナがポート 8080 でアクセス可能になったことを検出します。次に、Wait-for-It は、次のように定義された Web アプリ コンテナの実際のコマンドを起動します。
node app .js
。
このアプローチは、Docker で適切なヘルスチェックを設定できない特定の状況のために予約するのが最適です。これは、healthcheck コマンドを実行するように構成できないサードパーティのイメージを使用している場合に必要になる場合があります。 Wait-for-It は、ポートが代わりのトラフィックを提供しているかどうかを検出する方法を提供します。確実ではありませんが、多くの場合、これはコンテナーの健全性を示す良い指標となります。
まとめ
Docker Compose は、デフォルトでスタック内のすべてのサービスを同時に開始します。これは、サービス間のリンクによって親子依存関係が作成される場合には望ましくないことがよくあります。
の
depends_onフィールドでは、サービスの起動シーケンスを定義できます。 Compose は新しいコンテナを順番に作成し、次のコンテナが追加される前に前のコンテナが開始されていることを保証します。
前のコンテナが終了するまで待つか、または追加することで肯定的なヘルスチェックを報告できます。
condition
依存関係の定義に。ヘルスチェックを使用できない状況では、Wait-for-It などのツールを使用して、親コンテナーに依存関係の準備ができたことを検出させることができます。
