Application Gateway の複数サイトのホスト

  • [アーティクル]

複数サイトのホスティングでは、パブリックを対象にしたリスナーを使用して、アプリケーション ゲートウェイの同じポートに複数の Web アプリケーションを構成することができます。 最大で 100 個以上の Web サイトを 1 つのアプリケーション ゲートウェイに追加することによって、デプロイに効率的なトポロジを構成できます。 各 Web サイトは、独自のバックエンド プールに送られるようにすることができます。 たとえば、contoso.com、fabrikam.com、adatum.com という 3 つのドメインで、アプリケーション ゲートウェイの IP アドレスが示されています。 マルチサイト リスナーを 3 つ作成し、リスナーごとにポートとプロトコル設定を構成します。

マルチサイト リスナーでワイルドカードのホスト名を定義し、リスナー 1 つにつき最大 5 つのホスト名を定義することもできます。 詳細については、リスナーでのワイルドカードのホスト名に関する記事を参照してください。

複数サイト アプリケーション ゲートウェイ

重要

v1 SKU では、規則はポータルに一覧表示されている順序で処理されます。 v2 SKU の場合、[ルールの優先度] を使用して処理順序を指定します。 基本リスナーを構成する前に、まずマルチサイト リスナーを構成することを強くお勧めします。 そうすることで、トラフィックが確実に適切なバックエンドにルーティングされます。 基本リスナーが先に表示されていて、なおかつ受信要求と一致した場合、そのリスナーによって要求が処理されます。

http://contoso.com の要求は ContosoServerPool にルーティングされ、http://fabrikam.com は FabrikamServerPool にルーティングされます。

同様に、同じ親ドメインの複数のサブドメインを、同じアプリケーション ゲートウェイ デプロイでホストすることができます。 たとえば、http://blog.contoso.com および http://app.contoso.com を、単一のアプリケーション ゲートウェイ デプロイでホストできます。

要求ルーティング規則の評価順序

マルチサイト リスナーを使用して、クライアント トラフィックが正確なバックエンドに確実にルーティングされるようにする場合は、要求ルーティング規則が正しい順序で存在することが重要です。 たとえば、 と shop.contoso.comの関連付けられたホスト名を持つリスナーが 2 つの場合、ホスト名*.contoso.comをshop.contoso.com持つリスナーは、 を持つリスナー*.contoso.comの前に処理する必要があります。 を持つ *.contoso.com リスナーが最初に処理された場合、より具体的な shop.contoso.com リスナーによってクライアント トラフィックが受信されません。

規則の順序を確立するには、リスナーに関連付けられている要求ルーティング規則に Priority フィールド値を指定します。 1 から 20000 までの整数値を指定できます。1 が最高の優先度で、20000 が最低の優先度です。 受信クライアント トラフィックが複数のリスナーと一致する場合、要求の処理には、優先順位が最も高い要求ルーティング規則が使用されます。 各要求ルーティング規則には、一意の優先度値が必要です。

[優先度] フィールドは、要求ルーティング規則の評価の順序にのみ影響します。これにより PathBasedRouting 要求ルーティング規則内のパスベースの規則の評価順序が変更されることはありません。

Note

ルール優先度を使用するには、既存のすべての要求ルーティング規則にルール優先度フィールド値を指定する必要があります。 ルール優先度フィールドが使用されたら、作成される新しいルーティング規則には、その構成の一部としてルール優先度フィールド値が必要です。

重要

API バージョン 2021-08-01 以降では、ルールの優先度フィールドは要求ルーティング規則の必須フィールドです。 最初の PUT 呼び出しの一部としての評価の現在の順序に基づいて、既存の要求ルーティング 規則のルール優先度フィールド値は、API バージョン 2021-08-01 以降、ポータル、Azure PowerShell、Azure CLI を使用して構成更新が適用されると、自動的に設定されます。 要求ルーティング規則の今後の更新では、構成の一部としてルールの優先順位フィールドが指定されている必要があります。

リスナーにおけるワイルドカードのホスト名

Application Gateway では、マルチサイト HTTP(S) リスナーを使用したホストベースのルーティングが可能です。 これで、ホスト名でアスタリスク (*) と疑問符 (?) などのワイルドカード文字を使用でき、マルチサイト HTTP(S) リスナーごとに最大 5 つのホスト名を使用できます。 たとえば、「 *.contoso.com 」のように入力します。

ホスト名でワイルドカード文字を使用すると、1 つのリスナー内で複数のホスト名と一致させることができます。 たとえば、*.contoso.com は、ecom.contoso.com、b2b.contoso.com、customer1.b2b.contoso.com などと一致させることができます。 ホスト名の配列を使用すると、1 つのリスナーに対して複数のホスト名を構成し、バックエンド プールに要求をルーティングすることができます。 たとえば、リスナーには、両方のホスト名の要求を受け入れる を含 contoso.com, fabrikam.com めることができます。

ワイルドカード リスナー

Note

この機能は、Application Gateway の Standard_v2 および WAF_v2 SKU でのみ使用できます。

Azure PowerShell の場合は、-HostName ではなく -HostNames を使用する必要があります。 HostNames を使用すると、最大 5 つのホスト名をコンマ区切り値として指定でき、ワイルドカード文字を使用できます。 たとえば、-HostNames "*.contoso.com","*.fabrikam.com" のように指定します。

Azure CLI の場合は、--host-name ではなく --host-names を使用する必要があります。 host-names を使用すると、最大 5 つのホスト名をコンマ区切り値として指定でき、ワイルドカード文字を使用できます。 たとえば、--host-names "*.contoso.com,*.fabrikam.com" のように指定します。

Azure portal のマルチサイト リスナーで、[複数/ワイルドカード] ホストの種類を選択し、使用できるワイルドカード文字を使用して最大 5 つのホスト名を指定する必要があります。

ワイルドカード リスナー UI

ホスト名フィールドで使用できる文字

  • (A-Z,a-z,0-9) - 英数字
  • - - ハイフンまたはマイナス
  • . - 区切り記号としてのピリオド
  • * - 許可された範囲内の複数の文字と一致することができます
  • ? - 許可された範囲内の 1 つの文字と一致することができます

リスナーでワイルドカード文字と複数のホスト名を使用する場合の条件

  • 1 つのリスナーでは最大で 5 つのホスト名のみを指定できます
  • アスタリスク * は、ドメイン スタイルの名前またはホスト名の構成要素で 1 回だけ使用できます。 たとえば、component1*.component2*.component3 などです。 (*.contoso-*.com) は有効です。
  • ホスト名では、アスタリスク * を最大で 2 つまで使用できます。 たとえば、*.contoso.* は有効ですが、*.contoso.*.*.com は無効です。
  • ホスト名で使用できるワイルドカード文字は最大 4 つです。 たとえば、????.contoso.com、w??.contoso*.edu.* は有効ですが、????.contoso.* は無効です。
  • ホスト名の 1 つの構成要素でアスタリスク * と疑問符 ? を一緒に使用すること (*? または ?* または **) は無効です。 たとえば、*?.contoso.com や **.contoso.com は無効です。

リスナーでワイルドカードまたは複数のホスト名を使用する場合の考慮事項と制限事項

  • SSL ターミネーションとエンド ツー エンド SSL では、プロトコルを HTTPS として構成し、リスナー構成で使用される証明書をアップロードする必要があります。 マルチサイト リスナーの場合は、ホスト名も入力できます。通常、これは SSL 証明書の CN です。 リスナーで複数のホスト名を指定する場合、またはワイルドカード文字を使用する場合は、次の点を考慮する必要があります。
    • *.contoso.com のようなワイルドカードのホスト名の場合、*.contoso.com のような CN を含むワイルドカード証明書をアップロードする必要があります
    • 同じリスナーで複数のホスト名が指定されている場合は、指定されているホスト名と一致する CN が含まれる SAN 証明書 (サブジェクトの別名) をアップロードする必要があります。
  • 正規表現を使用してホスト名を指定することはできません。 ホスト名のパターンを構成するには、アスタリスク (*) や疑問符 (?) などのワイルドカード文字のみを使用できます。
  • バックエンドの正常性チェックでは、HTTP の設定ごとに複数のカスタム プローブを関連付けることはできません。 代わりに、バックエンドで Web サイトの 1 つをプローブするか、"127.0.0.1" を使用してバックエンド サーバーの localhost をプローブすることができます。 ただし、リスナーでワイルドカードまたは複数のホスト名を使用している場合、指定されたすべてのドメイン パターンの要求は、ルールの種類 (基本またはパスベース) に応じてバックエンド プールにルーティングされます。
  • "hostname" プロパティは入力として 1 つの文字列を受け取ります。ワイルドカード以外のドメイン名を 1 つだけ指定できます。 "hostname" プロパティは入力として文字列の配列を受け取ります。ワイルドカードのドメイン名を最大 5 つ指定できます。 両方のプロパティを同時に使用することはできません。

マルチサイト リスナーでワイルドカード ホスト名を構成する方法に関するステップ バイ ステップ ガイドについては、Azure PowerShell を使用したマルチサイトの作成または Azure CLI の使用に関する記事を参照してください。

ホスト ヘッダーと Server Name Indication (SNI)

同じインフラストラクチャで複数サイトのホストを有効にするための一般的な方法は 3 つあります。

  1. 複数の Web アプリケーションをそれぞれ、一意の IP アドレスでホストする。
  2. ホスト名を使用して、同じ IP アドレスで複数の Web アプリケーションをホストする。
  3. さまざまなポートを使用して、同じ IP アドレスで複数の Web アプリケーションをホストする。

現在、Application Gateway は、トラフィックをリッスンする単一のパブリック IP アドレスをサポートします。 そのため、それぞれ独自の IP アドレスを持つ複数のアプリケーションは、現在サポートされていません。

Application Gatewayでは、それぞれ異なるポートでリッスンする複数のアプリケーションがサポートされていますが、このシナリオでは、アプリケーションが非標準ポートでトラフィックを受け入れる必要があります。

Application Gateway は、複数の Web サイトを同じパブリック IP アドレスとポートでホストするために、HTTP 1.1 ホスト ヘッダーを利用します。 アプリケーション ゲートウェイでホストされているサイトでは、Server Name Indication (SNI) TLS 拡張機能によって TLS オフロードをサポートすることもできます。 つまり、クライアント ブラウザーとバックエンド Web ファームは、HTTP/1.1 と、RFC 6066 で定義されている TLS 拡張機能をサポートする必要があります。

次のステップ

Application Gateway で複数サイトのホスティングを構成する方法を確認します

エンド ツー エンドのテンプレート ベースのデプロイについては、複数サイトのホスティングを使用する Resource Manager テンプレートを参照してください。