Azure Container Apps でのイングレス
Azure Container Apps を使用すると、イングレスを有効にすることで、コンテナー アプリをパブリック Web、仮想ネットワーク (VNET)、または環境内の他のコンテナー アプリに公開できます。 イングレス設定は、コンテナー アプリへの外部トラフィックと内部トラフィックのルーティングを制御する一連の規則によって適用されます。 イングレスを有効にすると、Azure Load Balancer、パブリック IP アドレス、またはその他の Azure リソースを作成しなくても、受信 HTTPS 要求または TCP トラフィックを有効にすることができます。
イングレスでは、次の機能がサポートされます。
2 つのリビジョン間のイングレス分割を示すイングレス構成の例:
構成の詳細については、「イングレスの構成」を参照してください。
外部イングレスと内部イングレス
イングレスを有効にすると、次の 2 種類のイングレスから選択できます。
- 外部: パブリック インターネットとコンテナー アプリの内部環境の両方からのトラフィックを受け入れます。
- 内部: コンテナー アプリの環境内からの内部アクセスのみを許可します。
環境内の各コンテナー アプリは、異なるイングレス設定で構成できます。 たとえば、複数のマイクロサービス アプリを使うシナリオでは、セキュリティを強化するために、単一のコンテナー アプリを使ってパブリック要求を受信し、その要求をバックグラウンド サービスに渡す場合があります。 このシナリオでは、外部イングレスを使用して公開コンテナー アプリを構成し、内部イングレスを使用して内部向けのコンテナー アプリを構成します。
プロトコルの種類
Container Apps では、イングレス用に HTTP と TCP の 2 つのプロトコルがサポートされています。
HTTP
HTTP イングレスが有効になっている場合、Container Apps には次の機能があります。
- TLS 終端のサポート
- HTTP/1.1 および HTTP/2 のサポート
- WebSocket と gRPC のサポート
- 常に TLS 1.2 か 1.3 を使い、イングレス ポイントで終了する HTTPS エンドポイント
- 常にポート 80 (HTTP 用) と 443 (HTTPS 用) を公開するエンドポイント
- 既定では、ポート 80 への HTTP 要求は 443 の HTTPS に自動的にリダイレクトされる
- 完全修飾ドメイン名 (FQDN)
- 要求のタイムアウトは 240 秒である
HTTP ヘッダー
HTTP イングレスは、クライアント要求に関するメタデータをコンテナー アプリに渡すヘッダーを追加します。 たとえば、X-Forwarded-Proto ヘッダーは、クライアントが Container Apps サービスとの接続に使用したプロトコルを識別するために使用されます。 次の表に、Container Apps のイングレスに関連する HTTP ヘッダーを示します。
| Header | 説明 | 値 |
|---|---|---|
X-Forwarded-Proto |
Container Apps サービスに接続するためにクライアントによって使用されるプロトコル。 | http または https |
X-Forwarded-For |
要求を送信したクライアントの IP アドレス。 | |
X-Forwarded-Host |
クライアントが Container Apps サービスに接続するために使用したホスト名。 | |
X-Forwarded-Client-Cert |
clientCertificateMode が設定されている場合のクライアント証明書。 |
ハッシュ、証明書、チェーンのセミコロン区切りリスト。 例: Hash=....;Cert="...";Chain="..."; |
TCP
Container Apps では、HTTP または HTTPS 以外の TCP ベースのプロトコルがサポートされています。 たとえば、TCP イングレスを使用して、Redis プロトコルを使用するコンテナー アプリを公開できます。
Note
外部 TCP イングレスは、カスタム VNET を使用する Container Apps 環境でのみサポートされます。 プライベート エンドポイント経由で受信トラフィックを受け入れるアプリでは、TCP イングレスはサポートされていません。
TCP イングレスが有効になっている場合、Container Apps には次の機能があります。
- 名前 (Container Apps リソースの
nameプロパティで定義) と公開されているポート番号を使用して、同じ環境内の他のコンテナー アプリからアクセスできます。 - イングレスが
externalに設定されている場合は、完全修飾ドメイン名 (FQDN) と公開ポート番号を使用して外部からアクセスできます。
追加の TCP ポート
コンテナー アプリの主要な HTTP/TCP ポートに加えて、追加の TCP ポートを公開して、アプリケーションが複数のポートで TCP 接続を受け入れるようにできます。
Note
この機能を使用するには、コンテナー アプリの CLI 拡張機能が必要です。 最新バージョンのコンテナー アプリ CLI 拡張機能をインストールするには、az extension add -n containerapp を実行してください。
追加の TCP ポートには、次の内容が適用されます。
- 追加の TCP ポートは、アプリ自体が外部として設定されていて、Container Apps がカスタム VNet を使用している場合にのみ外部にできます。
- 外部に公開される追加の TCP ポートは、Container Apps 環境全体で一意である必要があります。 これには、すべての外部追加 TCP ポート、外部メイン TCP ポート、組み込みの HTTP イングレスで使用される 80/443 ポートが含まれます。 追加のポートが内部にある場合は、同じポートを複数のアプリで共有できます。
- 公開ポートが指定されていない場合、公開ポートは既定でターゲット ポートと一致します。
- 各ターゲット ポートは一意である必要があり、同じターゲット ポートを異なる公開ポートで公開することはできません。
- アプリごとに最大 5 つの追加ポートがあります。 追加のポートが必要な場合は、サポート リクエストを開いてください。
- CORS やセッション アフィニティなどの組み込みの HTTP 機能をサポートするのは、メインイングレス ポートのみです。 追加の TCP ポート上で HTTP を実行する場合、これらの組み込み機能はサポートされません。
Container Apps の追加ポートを有効にする方法の詳細については、「イングレスに関する記事」を参照してください。
ドメイン名
アプリは、次のような方法で表示できます。
- 既定の完全修飾ドメイン名 (FQDN): Container Apps 環境内の各アプリには、環境の DNS サフィックスに基づいて FQDN が自動的に割り当てられます。 環境の DNS サフィックスをカスタマイズするには、「カスタム環境の DNS サフィックス」を参照してください。
- カスタム ドメイン名: Container Apps 環境のカスタム DNS ドメインを構成できます。 詳細については、「カスタム ドメイン名と証明書」を参照してください。
- アプリ名: 同じ環境内のアプリ間の通信にアプリ名を使用できます。
アプリの FQDN を取得するには、「場所」を参照してください。
IP 制限
Container Apps では、イングレスの IP 制限がサポートされています。 ルールを作成して、Container Apps へのアクセスを許可または拒否する IP アドレスを構成できます。 詳細については、「IP 制限の構成」に関するページをご覧ください。
認証
Azure Container Apps には、外部のイングレスが有効な Container Apps をセキュリティで保護するための組み込みの認証と認可機能が用意されています。 詳細については、「Azure Container Apps での認証および認可」を参照してください。
認証とトラフィックの暗号化のためにクライアント証明書 (mTLS) をサポートするようにアプリを構成できます。 詳細については、「クライアント証明書の構成」に関するページを参照してください。
ピアツーピア環境レベルのネットワーク暗号化を使用する方法の詳細については、「ネットワークの概要」をご覧ください。
トラフィックの分割
Containers Apps を使用すると、受信トラフィックをアクティブなリビジョン間で分割できます。 分割ルールを定義するときは、受信トラフィックの割合を割り当てて、異なるリビジョンに移動します。 詳細については、「トラフィックの分割」を参照してください。
セッション アフィニティ
セッション アフィニティ (スティッキー セッションとも呼ばれます) は、クライアントから同じコンテナー アプリ レプリカにすべての HTTP 要求をルーティングできる機能です。 この機能は、同じレプリカへの一貫性のある接続を必要とするステートフル アプリケーションに役立ちます。 詳細については、セッション アフィニティに関するページを参照してください。
クロス origin リソース共有 (CORS)
既定では、ブラウザーを介してページからドメインに対して行われた要求が、ページの配信元ドメインと一致しない場合はブロックされます。 Container Apps にデプロイされるサービスに対するこの制限を回避するには、クロスオリジン リソース共有 (CORS) を有効にします。
詳細については、「Azure Container Apps で CORS を構成する」を参照してください。