Azure Container Apps 正常性プローブを使用すると、Container Apps ランタイムはコンテナー アプリの状態を定期的に確認できます。
プローブは、TCP または HTTP (S) を排他的に使用して設定できます。
Azure Container Apps では、次のプローブがサポートされています。
| プローブ | 説明 |
|---|---|
| 起動 | アプリケーションが正常に起動するかどうかを確認します。 このチェックはライブネス プローブとは別であり、アプリケーションの初期起動フェーズ中に実行されます。 |
| 稼動 | アプリケーションがまだ実行中で応答性が高いかどうかを確認します。 |
| 対応性 | レプリカが受信要求を処理する準備ができているかどうかを確認します。 |
Azure Container Apps でサポートされているプローブ仕様の完全な一覧については、 Azure REST API の仕様を参照してください。
HTTP プローブ
HTTP プローブを使用すると、正常な状態を報告する前に、アプリケーションの依存関係の状態を確認するカスタム ロジックを実装できます。
成功を示すために、200 以上、400 以下の HTTP 状態コードで応答する正常性プローブ エンドポイントを構成します。 この範囲以外の他の応答コードは、エラーを示します。
次の例は、JavaScript でライブネス エンドポイントを実装する方法を示しています。
const express = require('express');
const app = express();
app.get('/liveness', (req, res) => {
let isSystemStable = false;
// check for database availability
// check filesystem structure
// etc.
// set isSystemStable to true if all checks pass
if (isSystemStable) {
res.status(200); // Success
} else {
res.status(503); // Service unavailable
}
})
TCP プローブ
TCP プローブは、サーバーとの接続が確立されるまで待機して、成功を示します。 アプリケーションへの接続を確立できない場合、このプローブは失敗します。
制限
- コンテナーごとに追加できるプローブの種類は 1 つだけです。
-
execプローブはサポートされていません。 - ポート値は整数である必要があります。名前付きポートはサポートされていません。
- gRPC はサポートされていません。
例
次のコード リストは、コンテナーの正常性プローブを定義する方法を示しています。
... プレースホルダーは省略されたコードを示します。 ARM テンプレートの詳細については、 Container Apps ARM テンプレート API の仕様に関するページを参照してください。
{
...
"containers":[
{
"image":"nginx",
"name":"web",
"probes": [
{
"type": "Liveness",
"httpGet": {
"path": "/health",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "liveness probe"
}]
},
"initialDelaySeconds": 7,
"periodSeconds": 3
},
{
"type": "Readiness",
"tcpSocket": {
"port": 8081
},
"initialDelaySeconds": 10,
"periodSeconds": 3
},
{
"type": "Startup",
"httpGet": {
"path": "/startup",
"port": 8080,
"httpHeaders": [
{
"name": "Custom-Header",
"value": "startup probe"
}]
},
"initialDelaySeconds": 3,
"periodSeconds": 3
}]
}]
...
}
省略可能な failureThreshold 設定では、プローブの実行が失敗した場合の Container Apps での試行回数を定義します。
failureThreshold の量を超える試行は、プローブの種類ごとに異なる結果を引き起こします。
既定の構成
イングレスを有効にした場合、GPU ワークロード プロファイル (専用と消費の両方) を除き、各種類を定義しない場合、ポータルは次の既定のプローブをメイン アプリ コンテナーに自動的に追加します。 ポータルでは、 サイドカー コンテナーに既定のプローブが自動的に追加されることはありません。
| プローブの種類 | 既定の値 |
|---|---|
| 起動 | プロトコル: TCP ポート: イングレス ターゲット ポート タイムアウト: 3 秒 期間: 1 秒 初期遅延: 1 秒 成功しきい値: 1 失敗のしきい値: 240 |
| 稼動 | プロトコル: TCP ポート: イングレス ターゲット ポート |
| 対応性 | プロトコル: TCP ポート: イングレス ターゲット ポート タイムアウト: 5 秒 期間: 5 秒 初期遅延: 3 秒 成功しきい値: 1 失敗のしきい値: 48 |
コンテナー アプリを 複数のリビジョン モードで実行する場合は、リビジョンをデプロイした後、準備プローブが成功を示すまで待ってから、そのリビジョンにトラフィックをシフトします。 単一リビジョン モードでは、準備プローブが正常な状態を返すと、トラフィックは自動的にシフトします。
リビジョンのレプリカが 1 つでも readiness probe のチェックに失敗した場合、リビジョン内の他のすべてのレプリカが正常であっても、リビジョンの状態は異常として示されます。 Container Apps は、問題のレプリカが再度正常であるか、またはエラーのしきい値を超えるまで再起動します。 エラーのしきい値を超えた場合は、リビジョンを再起動してみてくださいが、リビジョンが正しく構成されていないことを意味する可能性があります。
アプリの起動に時間がかかる場合は、準備が整う前にコンテナーが再起動 (または異常とマーク) されないようにプローブの設定を調整します。 プローブ構成をカスタマイズすると、不要な再起動をトリガーせずにアプリを起動するのに十分な時間が確保されます。
次の例では、スタートアップ時間を最適化するために、liveness プローブと readiness プローブを設定する方法を示します。
"probes": [
{
"type": "Liveness",
"failureThreshold": 3,
"periodSeconds": 10,
"successThreshold": 1,
"tcpSocket": {
"port": 80
},
"timeoutSeconds": 1
},
{
"type": "Readiness",
"failureThreshold": 48,
"initialDelaySeconds": 3,
"periodSeconds": 5,
"successThreshold": 1,
"tcpSocket": {
"port": 80
},
"timeoutSeconds": 5
}]