Azure Container Apps内のコンテナーアプリ間で通信する

Azure Container Appsでは、コンテナーアプリがインフラストラクチャを管理せずに相互に通信できるように、組み込みのサービス検出とルーティングが提供されます。複数のコンテナーアプリを同じ環境にデプロイすると、プラットフォームは DNS 解決、負荷分散、セキュリティで保護されたトラフィックルーティングを自動的に処理します。

イングレスが有効になっている場合、各コンテナーアプリはドメイン名を取得します。そのエンドポイントをパブリックに使用できるようにするか、同じ環境内の他のコンテナーアプリに制限することができます。

コンテナーアプリは、次のいずれかの方法で相互にアクセスできます。

完全修飾ドメイン名 (FQDN): 既定で生成されるドメイン
アプリ名: 内部呼び出し用の短い形式の http://<APP_NAME> アドレス
Dapr サービス呼び出し: 組み込みの再試行と可観測性を備えたサイドカーベースのアプローチ
カスタムドメイン: マネージド証明書を使用した独自のドメイン名

注意

FQDN またはアプリ名を使用して同じ環境で別のコンテナーアプリを呼び出すと、ネットワークトラフィックが環境から離れることはありません。

共同作業の重要性

マイクロサービスアーキテクチャでは、サービスは互いを確実に呼び出す必要があります。 Azure Container Appsは、サービス検出の設定、DNS レコードの管理、リバースプロキシの構成に関する運用上の負担を軽減します。

プラットフォームが処理する内容は以下のとおりです。

自動 DNS 登録: すべてのコンテナーアプリは、デプロイされるとすぐに解決可能なホスト名を取得します。
プロキシ管理ルーティング: すべてのアプリ間トラフィックは、TLS 終了、トラフィックの分割、負荷分散を処理する組み込みの Envoy プロキシレイヤーを経由します。
環境スコープの分離: 内部エンドポイントは同じ環境内からのみ到達可能であり、自然なセキュリティ境界が作成されます。
プロトコルの柔軟性: ワークロードのニーズに応じて、HTTP/1.1、HTTP/2 (gRPC の場合)、未加工の TCP 経由の通信。

これらの機能は、ネットワークの組み込みではなく、アプリケーションロジックに集中できることを意味します。

コンテナーアプリの場所 (FQDN)

各コンテナーアプリの完全修飾ドメイン名は、アプリ名、一意の環境識別子、およびリージョンで構成されます。これらのドメインフラグメントはすべて、 azurecontainerapps.io 最上位ドメインに分類されます。

Azure Container Apps コンテナーアプリの完全修飾ドメイン名

外部 FQDN と内部 FQDN

イングレス可視性設定では、環境の外部からアプリに到達できるかどうかを制御します。

視認性	FQDN パターン	から到達可能
エクスターナル	`<APP_NAME>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io`	Anywhere (パブリックインターネット)
内部	`<APP_NAME>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io`	同じ環境のみ

イングレスを内部に設定すると、FQDN には .internal. セグメントが含まれます。同じ環境内の他のコンテナーアプリでも、このアドレスを使用してアプリに到達できますが、環境の外部からの要求は、環境のプロキシから 404 応答を受け取ります。 DNS 名は環境の共有 IP に解決されますが、アプリは内部専用であるため、プロキシによって要求が拒否されます。

完全修飾ドメイン名の取得

この az containerapp show コマンドは、コンテナーアプリの完全修飾ドメイン名を返します。

Bash
PowerShell

az containerapp show \
  --resource-group <RESOURCE_GROUP_NAME> \
  --name <CONTAINER_APP_NAME> \
  --query properties.configuration.ingress.fqdn

(Get-AzContainerApp -Name <CONTAINER_APP_NAME> -ResourceGroupName <RESOURCE_GROUP_NAME>).Configuration.IngressFqdn

この例では、<> で囲まれたプレースホルダーを実際の値に置き換えます。

このコマンドから返される値は、次の例のようなドメイン名に似ています。

myapp.happyhill-70162bb9.canadacentral.azurecontainerapps.io

FQDN のリビジョンラベル

特定のリビジョンにラベルを割り当てると、ラベルごとに三つのダッシュで区切られた一意のFQDNが与えられます。

<APP_NAME>---<LABEL>.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

内部アプリの場合、パターンには .internal. セグメントが含まれます。

<APP_NAME>---<LABEL>.internal.<ENVIRONMENT_UNIQUE_ID>.<REGION>.azurecontainerapps.io

ラベル FQDN を使用すると、トラフィックを特定のリビジョンに直接送信できます。この方法は、新しいバージョンのテスト、A/B 実験の実行、または特定のリビジョンデプロイ用の安定したエンドポイントの提供に役立ちます。

名前でコンテナーアプリを呼び出す

同じ環境内から別のコンテナーアプリを呼び出す最も簡単な方法は、その名前です。 http://<CONTAINER_APP_NAME>に要求を送信すると、環境の組み込み DNS によって名前が自動的に解決されます。

http://my-backend-api

DNS 解決のしくみ

バックグラウンドで、Azure Container Appsは、コンテナーアプリ名をルーティング可能なアドレスに変換するカスタム DNS 構成を使用します。アプリが別のアプリの名前または FQDN に対して要求を行った場合:

環境の DNS サーバーは、ホスト名を Envoy プロキシサービスアドレスに解決します。
Envoy プロキシは、元のホスト名からターゲットアプリを識別します。
プロキシは、トラフィック構成に基づいて要求を正しいリビジョンにルーティングします。

このアーキテクチャは、コンテナーアプリが互いのポッドと直接通信することはないことを意味します。すべてのトラフィックはプロキシレイヤーを通過します。これにより、TLS 終端、負荷分散、トラフィックの分割が提供されます。

ヒント

同じ環境内のコンテナーアプリ間の呼び出しには、短いアプリ名 (http://<APP_NAME>) を使用します。完全な FQDN よりも簡単で、DNS が同じプロキシを介して両方のパターンを解決するため、同じように動作します。

トランスポートプロトコル

コンテナーアプリでは、 transport プロパティを使用して構成された、イングレスの 3 つのトランスポートモードがサポートされています。

トランスポート	利用シーン	詳細情報
自動 (既定値)	標準 Web API とサービス	HTTP/1.1 と HTTP/2 を自動的にネゴシエートします
HTTP/2	gRPC サービス	gRPC に必要な HTTP/2 エンドツーエンドを有効にします
TCP	HTTP 以外のプロトコル (データベース、カスタムプロトコル)	ポートマッピングを使用した未加工の TCP 接続

注意

外部 TCP イングレスには、カスタム VNet が必要です。カスタム VNet なしで外部 TCP アプリを作成しようとすると、 ContainerAppTcpRequiresVnet エラーが表示されます。内部 TCP イングレスは、カスタム VNet なしで機能します。

TCP トランスポートを使用する場合は、プライマリイングレスポートを超える追加のポートを公開することもできます。追加ポートごとに、環境内の他のアプリが接続できる個別の TCP エンドポイントが作成されます。

トラフィックスプリッティングとリビジョンルーティング

Azure Container Appsでは、コンテナーアプリ間でのトラフィックの分散方法に影響する 3 つのリビジョンモードがサポートされています。

モード	行動
Single	すべてのトラフィックは、最新のアクティブなリビジョンに送信されます。
複数	トラフィックは、トラフィックルールに基づいて、リビジョン間で割合によって分割されます。
ラベル	ラベル付けされた各リビジョンは、直接アクセスするための一意の FQDN を取得します。

複数モードでは、別のコンテナーアプリがアプリの FQDN を呼び出すと、プロキシは構成された重みに従ってリビジョン間で要求を自動的に分散します。 ラベル モードでは、呼び出し元はラベル FQDN を使用して特定のリビジョンをターゲットにすることができます。

詳細については、「revisions in Azure Container Apps」を参照してください。

Dapr サービスの呼び出し

Dapr (分散アプリケーションランタイム) は、アプリ間通信にサイドカーベースのアプローチを提供します。 Dapr を有効にすると、コンテナーアプリは、相互 TLS による組み込みのサービス呼び出し、自動再試行、Azure アプリケーション Insights による分散トレースを取得します。

Azure Container Appsのコンテナーアプリの場所をDaprと共に示すダイアグラム

Dapr 呼び出しのしくみ

Dapr 対応の各コンテナーアプリは、アプリケーションと共にサイドカープロセスを実行します。別の Dapr 対応アプリを呼び出すには、サービスの検出とルーティングを処理する Dapr サイドカーにローカル HTTP 要求を行います。

http://localhost:3500/v1.0/invoke/<DAPR_APP_ID>/method/<METHOD_NAME>

たとえば、Dapr アプリ ID が catalog のアプリで order-processor メソッドを呼び出すには、次のようにします。

http://localhost:3500/v1.0/invoke/order-processor/method/catalog

サイドカーは、専用 DNS ドメインを介してターゲットアプリを解決し、Envoy プロキシレイヤーを介して要求をルーティングします。これは、FQDN ベースのルーティングを処理するのと同じインフラストラクチャです。

注意

Dapr では、標準の FQDN 解決とは別の独自の DNS 解決パス ( .dapr ドメイン) が使用されます。どちらのパスも、環境のプロキシインフラストラクチャを経由します。

Dapr アプリ ID

Dapr アプリ ID は、他のアプリがサービスを呼び出すために使用する ID です。明示的なアプリ ID を設定しない場合、Dapr ランタイムは既定でコンテナーアプリ名になります。 ARM API では、カスタム ID を構成しない場合に appId: null が表示されますが、ランタイムによってアプリ名が自動的に適用されます。別の識別子が必要な場合は、Dapr 構成でカスタムアプリ ID を設定します。

Dapr アプリ ID は、環境内で一意である必要があります。別のアプリで既に使用されている Dapr アプリ ID を持つコンテナーアプリをデプロイしようとすると、コンテナーアプリリソースが作成されますが、そのリビジョンはプロビジョニングに失敗します (provisioningState: Failed)。エラーメッセージは、競合するアプリ ID と、それを所有するアプリを識別します。

Dapr 専用アプリ (HTTP イングレスなし)

HTTP イングレスを構成しなくても、コンテナーアプリで Dapr を有効にすることができます。この場合、アプリは FQDN またはアプリ名を介して到達できませんが、他の Dapr 対応アプリは Dapr サービス呼び出しを通じて呼び出すことができます。このパターンは、メッシュ内の他のサービスからの呼び出しのみを受信する必要があるバックグラウンドワーカーまたはイベントプロセッサに役立ちます。

ヒント

Azure CLIを使用してイングレスなしのアプリを作成する場合は、--ingress フラグと --target-port フラグの両方を省略します。 --target-portなしで--ingressを含めると、使用エラーが返されます。

Dapr サイドカーの構成

Dapr サイドカーは、コンテナーアプリのプロパティを使用して構成します。主な設定は次のとおりです。

Setting	説明
`appId`	Dapr アプリ ID (デフォルトではコンテナーアプリ名)
`appPort`	アプリがリッスンするポート (イングレスターゲットポートにフォールバック)
`appProtocol`	Dapr からアプリへの通信のプロトコル ( `http`、 `grpc`など)
`logLevel`	Dapr サイドカーログの冗長性
`enableApiLogging`	Dapr API 呼び出しをログに記録するかどうか
`httpMaxRequestSize`	Dapr の HTTP サーバーの最大要求本文サイズ (MB)
`httpReadBufferSize`	HTTP 読み取りバッファーの最大サイズ (KB 単位)

Azure Container Appsを使用した Dapr の構成の詳細については、Dapr と Azure Container Apps の統合を参照してください。

アプリ間通信のセキュリティ

Azure Container Appsには、コンテナーアプリの通信方法に影響を与えるいくつかのセキュリティ機能が含まれています。

既定の TLS: コンテナーアプリ間のすべてのトラフィックは、TLS 終了を処理する Envoy プロキシ経由でルーティングされます。 HTTPS リダイレクトを適用するには、 allowInsecure を false (既定値) に設定します。
クライアント証明書モード (mTLS): クライアント証明書モードを require、 accept、または ignoreに設定して、相互 TLS を構成します。
IP 制限: アプリに到達できる IP アドレスを制限する許可または拒否規則を定義します。
CORS ポリシー: コンテナーアプリを呼び出すブラウザーベースのクライアントのクロスオリジンリソース共有ルールを構成します。

注意

Dapr サービス呼び出しを使用すると、Dapr サイドカーはサービス間の相互 TLS との通信を自動的にセキュリティで保護します。 Dapr から Dapr への呼び出し用に mTLS を個別に構成する必要はありません。

詳細については、「Azure Container Apps の Ingress」を参照してください。

カスタムドメイン

イングレス設定でカスタムドメインを構成することで、独自のドメイン名をコンテナーアプリにマップできます。各カスタムドメインは、マネージドまたはアップロードされた TLS 証明書を参照できます。

カスタムドメインは既定の FQDN と共に登録されるため、アプリは両方のアドレスに応答します。環境内の他のコンテナーアプリがアプリに到達する必要がある場合は、既定の FQDN、アプリ名、またはカスタムドメインを使用できます。

詳細については、Azure Container Apps のカスタムドメインを参照してください。

サンプルソリューション

FQDN と Dapr の両方を使用してコンテナー間で呼び出す方法を示すサンプルは、Azure サンプルで入手できます。

Azure Container Appsでのアプリ間通信について理解することは、いくつかの関連トピックに接続します。

Azure Container Apps: コンテナーアプリが互いを検出して通信する共有境界
Azure Container Apps のIngress:外部および内部エンドポイント、TLS、およびルーティング規則を構成する方法
Dapr と Azure Container Apps: サービス呼び出しと共に Dapr コンポーネント、pub/sub、および状態管理をより深くカバー
Azure Container Apps におけるネットワーク: 環境の VNet 統合、プライベートエンドポイント、ネットワークセキュリティ
Azure Container Apps でのプロビジョニング: リビジョンモードとトラフィック分割がアプリ間ルーティングに与える影響

次のステップ

コンテナーアプリのイングレスを構成する

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-04-08