次の方法で共有

コンテナー アプリのトラブルシューティング

  • [アーティクル]

コンテナー アプリが正しく動作しない場合は、Azure Container Apps のログと構成設定を見直すと、根底にある問題が明らかになる可能性があります。 作成したコンテナー アプリに関する詳細情報を見つけて確認するには、次のガイドを参考にしてください。

シナリオ

次の表は、Azure Container Apps の使用中に発生する可能性がある問題と、その解決のために取ることができるアクションをまとめたものです。

シナリオ 説明 アクション
すべてのシナリオ ログを見る

問題の診断と解決のツールを使用する
新しいリビジョンをデプロイするときのエラー 新しいリビジョンをデプロイしようとしたときにエラー メッセージが返されます。 Container Apps がコンテナー イメージをプルできることを確認する
プロビジョニングに時間がかかりすぎる 新しいリビジョンをデプロイした後に、新しいリビジョンの [プロビジョニングの状態] が "プロビジョニング中"、[実行の状態] が "処理中" のままになります。 正常性プローブが正しく構成されていることを確認する
リビジョンが "低下" になる 新しいリビジョンのプロビジョニングに 10 分以上かかります。 最終的に [プロビジョニングの状態] が "プロビジョニング済み" になりますが、[実行の状態] は "低下" になります。 [実行の状態] のツールヒントに Details: Deployment Progress Deadline Exceeded. 0/1 replicas ready. と表示されます。 正常性プローブが正しく構成されていることを確認する
エンドポイントへの要求が失敗する コンテナー アプリ エンドポイントが要求に応答しません。 イングレス構成を確認する
要求に対して状態 403 が返される コンテナー アプリ エンドポイントへの要求に対して HTTP エラー 403 (アクセス拒否) という応答が返されます。 ネットワーク構成が正しいことを確認する
応答が期待どおりではない コンテナー アプリ エンドポイントは要求に応答しますが、その応答が期待どおりではありません。 トラフィックが正しいリビジョンにルーティングされていることを確認する

イメージをコンテナー レジストリにデプロイするときに一意のタグを使用していることを確認する
不足しているパラメーターに関するエラー Azure CLI で az containerapp コマンドを実行するとき、または Azure PowerShell の Az.App モジュールからコマンドレットを実行するときに、不足しているパラメーターに関するエラー メッセージが表示されます。 最新バージョンの Azure Container Apps 拡張機能がインストールされていることを確認する
プレビュー機能を使用できない プレビュー機能は、Azure CLI で az containerapp コマンドを実行するときには使用できません。 Azure Container Apps 拡張機能でプレビュー機能が許可されていることを確認する
アプリまたは環境の削除が機能しない この問題には多くの場合、provisioningState: ScheduledForDelete などのメッセージが伴います。 関連付けられている VNet を手動で削除する

ログを表示する

コンテナー アプリの問題を見つけるために最初に行う手順の 1 つは、ログ メッセージを見ることです。 コンソール ログとシステム ログの両方の出力を見ることができます。 コンテナー アプリのコンソール ログには、アプリの stdout と stderr のストリームがキャプチャされます。 Container Apps のシステム ログはサービス レベルのイベントについて生成されます。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] セクションで、コンテナー アプリの名前を選択します。
  4. ナビゲーション バーの [監視] を展開して [ログ ストリーム] を選択します ([ログ] ではありません)。
  5. [ログ ストリーム] ページに "このリビジョンは 0 にスケーリングされています。" と表示されている場合は、[[リビジョン管理] に移動] ボタンを選択します。 新しいリビジョンを、最小レプリカ数 1 というスケーリングを指定してデプロイします。 詳細については、「Azure Container Apps でスケーリング ルールを設定する」を参照してください。
  6. [ログ ストリーム] ページで、[ログ] を [コンソール] または [システム] に設定します。

問題の診断と解決のツールを使用する

"問題の診断と解決" ツールを使用すると、コンテナー アプリの正常性、構成、パフォーマンスに関する問題を見つけることができます。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] セクションで、コンテナー アプリの名前を選択します。
  4. 左側のナビゲーション バーで、[問題の診断と解決] を選択します。
  5. [問題の診断と解決] ページで、トラブルシューティング カテゴリの 1 つを選択します。
  6. ナビゲーション バーでカテゴリの 1 つを選択して、コンテナー アプリの問題を解決する方法を見つけます。

コンテナー イメージのアクセス可能性を確認する

新しいリビジョンをデプロイしようとしたときにエラー メッセージが返された場合は、Container Apps がコンテナー イメージをプルできることを確認してください。

  • コンテナー環境のファイアウォールによってコンテナー レジストリへのアクセスがブロックされていないことを確認します。 詳細については、「ユーザー定義のルートを使用して送信トラフィックを制御する」を参照してください。
  • 既存の VNet で既定の Azure 提供の DNS サーバーではなくカスタム DNS サーバーが使用されている場合は、その DNS サーバーが正しく構成されていることと、コンテナー レジストリの DNS 参照が失敗しないことを確認します。 詳しくは、DNS をご覧ください。
  • Container Apps クラウド ビルド機能を使用してコンテナー イメージを生成した場合は (Azure Container Apps のコードからクラウドへのパスに関するページを参照)、そのイメージはパブリック アクセス可能ではないため、このセクションの説明は当てはまりません。

コンソール アプリケーションとして実行できる Docker コンテナーの場合は、管理者特権のコマンド プロンプトで次のコマンドを実行すると、イメージがパブリック アクセス可能であることを確認できます。 このコマンドを実行する前に、<> で囲まれたプレースホルダーを実際の値で置き換えてください。

docker run --rm <YOUR_CONTAINER_IMAGE>

エラーが報告されることなく Docker によってイメージが実行されることを確認します。 Docker on Windows を実行する場合は、Docker エンジンが実行中であることを確認してください。

イメージがパブリック アクセス可能ではない場合は、次のエラーが返される可能性があります。

docker: Error response from daemon: pull access denied for <YOUR_CONTAINER_IMAGE>, repository does not exist or may require 'docker login': denied: requested access to the resource is denied. See 'docker run --help'.

詳細については、「Azure Container Apps 環境でのネットワーク」を参照してください。

イングレス構成を確認する

コンテナー アプリのイングレス設定は、コンテナー アプリへの外部と内部のトラフィックのルーティングを制御する一連の規則によって適用されます。 コンテナー アプリへの接続ができない場合は、これらのイングレス設定を見直して、イングレス設定が原因で要求がブロックされていないことを確認してください。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] の下で、コンテナー アプリの名前を選択します。
  4. ナビゲーション バーの [設定] を展開して [イングレス] を選択します。
問題点 アクション
イングレスは有効化されていますか? [有効] チェック ボックスがオンであることを確認します。
外部イングレスを許可しますか? [イングレス トラフィック] が [どこからでもトラフィックを受け入れます] に設定されていることを確認します。 コンテナー アプリが HTTP トラフィックをリッスンしない場合は、[イングレス トラフィック] を [Container Apps 環境に限定] に設定します。
クライアントは HTTP または TCP を使用してコンテナー アプリにアクセスしますか? [イングレス タイプ] が正しいプロトコル (HTTP または TCP) に設定されていることを確認します。
クライアントは mTLS をサポートしていますか? クライアントが mTLS をサポートしている場合にのみ [クライアント証明書モード] が [必須] に設定されていることを確認します。 詳細情報については、「クライアント証明書認証を構成する」を参照してください。
クライアントは HTTP/1 または HTTP/2 を使用しますか? [転送] が正しい HTTP バージョン (HTTP/1 または HTTP/2) に設定されていることを確認します。
ターゲット ポートは正しく設定されていますか? [ターゲット ポート] が、コンテナー アプリによるリッスン対象と同じポートに、つまりコンテナー アプリの Dockerfile によって公開されているものと同じポートに設定されていることを確認します。
クライアント IP アドレスが拒否されていますか? [IP セキュリティ制限モード] が [すべてのトラフィックを許可する] に設定されていない場合は、クライアントの IP アドレスが拒否されていないことを確認します。

詳細については、「Azure Container Apps でのイングレス」を参照してください。

ネットワーク構成を確認する

Azure の再帰リゾルバーによる要求解決には、IP アドレス 168.63.129.16 が使用されます。

  1. VNet で既定の Azure 提供の DNS サーバーではなくカスタム DNS サーバーが使用されている場合は、未解決の DNS クエリを 168.63.129.16 に転送するように DNS サーバーを構成します。
  2. NSG またはファイアウォールを構成するときに、アドレス 168.63.129.16 をブロックしないでください。

詳細については、「Azure Container Apps 環境でのネットワーク」を参照してください。

正常性プローブの構成を確認する

すべての種類の正常性プローブ (liveness、readiness、startup) のうち、トランスポートとして TCP を使用するものについて、そのポート番号がコンテナー アプリのイングレス ターゲット ポートとして構成済みのものと一致することを確認します。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] の下で、コンテナー アプリの名前を選択します。
  4. ナビゲーション バーの [アプリケーション] を展開して [コンテナー] を選択します。
  5. [コンテナー] ページで、[正常性プローブ] を選択します。
  6. [liveness probe]、[readiness probe]、[startup probe] を展開します。
  7. 各プローブの [ポート] の値が正しいことを確認します。

[ポート] の値を次の手順で更新します。

  1. 新しいリビジョンを作成するために [編集とデプロイ] を選択します。
  2. [新しいリビジョンの作成とデプロイ] ページで、コンテナー イメージの横にあるチェック ボックスをオンにして [編集] を選択します。
  3. [コンテナーの編集] ウィンドウで、[正常性プローブ] を選択します。
  4. [liveness probe]、[readiness probe]、[startup probe] を展開します。
  5. 各プローブの [ポート] の値を編集します。
  6. 保存ボタンを選択します。
  7. [新しいリビジョンの作成とデプロイ] ページで [作成] ボタンを選択します。

起動時間の長さに合わせて正常性プローブを構成する

イングレスが有効になっている場合で種類ごとに何も定義されていない場合、次の既定のプローブがメイン アプリ コンテナーに自動的に追加されます。

プローブの種類別の既定値を次に示します。

プロパティ Startup 対応性 稼動
Protocol TCP TCP TCP
ポート イングレス ターゲット ポート イングレス ターゲット ポート イングレス ターゲット ポート
タイムアウト 3 秒 5 秒 該当なし
Period 1 秒 5 秒 該当なし
初期延期時間 1 秒 3 秒 該当なし
成功のしきい値 1 1 該当なし
失敗のしきい値 240 48 該当なし

コンテナー アプリの起動に時間がかかる場合は (Java では一般的です)、それに応じて liveness と readiness のプローブの [初期延期期間 (秒)] プロパティをカスタマイズすることが必要になる可能性があります。 ログを見ると、コンテナー アプリの一般的な起動時間を確認できます。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] の下で、コンテナー アプリの名前を選択します。
  4. ナビゲーション バーの [アプリケーション] を展開して [コンテナー] を選択します。
  5. [コンテナー] ページで、[正常性プローブ] を選択します。
  6. 新しいリビジョンを作成するために [編集とデプロイ] を選択します。
  7. [新しいリビジョンの作成とデプロイ] ページで、コンテナー イメージの横にあるチェック ボックスをオンにして [編集] を選択します。
  8. [コンテナーの編集] ウィンドウで、[正常性プローブ] を選択します。
  9. [liveness probe] を展開します。
  10. [liveness probe を有効にする] が選択されている場合は、[初期延期期間 (秒)] の値を大きくします。
  11. [readiness probe] を展開します。
  12. [readiness probe を有効にする] が選択されている場合は、[初期延期期間 (秒)] の値を大きくします。
  13. [保存] を選択します。
  14. [新しいリビジョンの作成とデプロイ] ページで [作成] ボタンを選択します。

その後で、ログを見るとコンテナー アプリが正常に起動したかどうかを確認できます。

詳細については、正常性プローブの使用に関するページ参照してください。

トラフィックが正しいリビジョンにルーティングされていることを確認する

コンテナー アプリが期待どおりに動作しない場合は、古いリビジョンに要求がルーティングされていることが問題である可能性があります。

  1. Azure portal にサインインします。
  2. 検索バーにコンテナー アプリの名前を入力します。
  3. [リソース] の下で、コンテナー アプリの名前を選択します。
  4. ナビゲーション バーの [アプリケーション] を展開して [リビジョン] を選択します。

[リビジョン モード] が Single に設定されている場合は、すべてのトラフィックが既定で最新のリビジョンにルーティングされます。 [アクティブ リビジョン] タブのリストにはリビジョンが 1 つだけ表示され、その [トラフィック] の値は 100% です。

[リビジョン モード] が Multiple に設定されている場合は、古いリビジョンにトラフィックがルーティングされていないことを確認してください。

トラフィック分割の構成の詳細については、「Azure Container Apps でのトラフィック分割」を参照してください。

最新バージョンの Azure Container Apps 拡張機能がインストールされていることを確認する

Azure CLI で az containerapp コマンドを実行したとき、または Azure PowerShell で Az.App モジュールからコマンドレットを実行したときに、パラメーターの不足に関するエラーが表示される場合は、最新バージョンの Azure Container Apps 拡張機能がインストールされていることを確認してください。

az extension add --name containerapp --upgrade

Azure Container Apps 拡張機能でプレビュー機能が許可されていることを確認する

Azure CLI で az containerapp コマンドを実行するときにプレビュー機能を使用できない場合は、Azure Container Apps 拡張機能でプレビュー機能を有効にします。

az extension add --name containerapp --upgrade --allow-preview true

Azure Container Apps 環境で使用されている VNet を手動で削除する

provisioningState: ScheduledForDelete というメッセージが表示されるにも関わらず、実際には環境が削除できない場合は、関連付けられている VNet を手動で削除するようにしてください。

  1. 削除しようとしている環境で使用されている VNet を特定します。 <プレースホルダー> は実際の値に置き換えてください。

    az containerapp env show --resource-group <RESOURCE_GROUP> --name <ENVIRONMENT>

    出力で、infrastructureSubnetId を探し、VNet ID をメモします。 VNet ID の例は vNet::myVNet.id です。

  2. 以下のように VNet を手動で削除します。

    az network vnet delete --resource-group <RESOURCE_GROUP> --name <VNET_ID>

  3. 以下のように Azure Container Apps 環境を削除します。

    az containerapp env delete --resource-group <RESOURCE_GROUP> --name <ENVIRONMENT> --yes

次のステップ

Azure Container Apps の信頼性