Azure Container Apps の正常性プローブ
Azure Container Apps 正常性プローブを使用すると、Container Apps ランタイムがコンテナー アプリの状態を定期的に検査できるようになります。
TCP または HTTP(S) を排他的に使用してプローブを設定できます。
Container Apps では、次のプローブがサポートされています。
| プローブ | 説明 |
|---|---|
| Startup | アプリケーションが正常に開始されたかどうかを確認します。 このチェックは liveness probe とは別のもので、アプリケーションの初期起動フェーズ中に実行されます。 |
| 稼動 | アプリケーションがまだ実行中で応答性が高いかどうかを確認します。 |
| 対応性 | レプリカが受信要求を処理する準備ができているかどうかを確認します。 |
Azure Container Apps でサポートされているプローブ仕様の完全な一覧については、Azure REST API の仕様に関するページをご覧ください。
HTTP プローブ
HTTP プローブを使用すると、正常性状態を報告する前に、アプリケーションの依存関係の状態を確認するカスタム ロジックを実装できます。
成功を示すために、200 以上、400 以下の HTTP 状態コードで応答する正常性プローブ エンドポイントを構成します。 この範囲以外の他の応答コードは、エラーを示します。
次の例は、JavaScript で liveness エンドポイントを実装する方法を示しています。
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 の量を超える試行は、プローブの種類ごとに異なる結果を引き起こします。
既定の構成
イングレスが有効になっている場合で種類ごとに何も定義されていない場合、次の既定のプローブがメイン アプリ コンテナーに自動的に追加されます。
Note
従量課金プランを使用するとき、既定のプローブは現在、ワークロード プロファイル環境に適用されません。 この動作は将来変更される可能性があります。
| プローブの種類 | 既定の値 |
|---|---|
| Startup | プロトコル: TCP ポート: イングレス ターゲット ポート タイムアウト: 3 秒 期間: 1 秒 初期遅延: 1 秒 成功のしきい値: 1 失敗のしきい値: 240 |
| 対応性 | プロトコル: TCP ポート: イングレス ターゲット ポート タイムアウト: 5 秒 期間: 5 秒 初期遅延: 3 秒 成功のしきい値: 1 失敗のしきい値: 48 |
| 稼動 | プロトコル: TCP ポート: イングレス ターゲット ポート |
アプリの起動が遅い場合には (Java ではよくある)、コンテナーをクラッシュさせないためにプローブのカスタマイズが何度も必要となります。
次の例では、起動時間を延ばす、liveness probe と readiness probe の構成方法を示します。
"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
}]