次の方法で共有


Application Gateway を使用した App Service の構成

Application Gateway では、App Service アプリまたはその他のマルチテナント サービスをバックエンド プール メンバーとして使用できます。 この記事では、Application Gateway を使用して App Service アプリを構成する方法について説明します。 Application Gateway の構成は、App Service にアクセスする方法によって異なります。

  • 1 つ目のオプションでは、Application Gateway とバックエンドの App Service の両方でカスタム ドメインを使います。
  • 2 つ目のオプションでは、Application Gateway は、既定のドメインに ".azurewebsites.net" というサフィックスを付けたものを使って App Service にアクセスします。

この構成は、運用レベルのシナリオに推奨され、要求フローでホスト名を変更しないというプラクティスを満たします。 既定の ".azurewebsites" ドメインに依存しなくて済むよう、カスタム ドメイン (および関連付けられた証明書) を使用できる必要があります。

バックエンド プールの Application Gateway と App Service の両方に同じドメイン名を関連付けることにより、要求フローでホスト名をオーバーライドする必要がありません。 バックエンド Web アプリケーションは、クライアントによって使用された元のホストが認識されます。

両方に同じカスタム ドメインを使用する Application Gateway から App Service へのシナリオの概要

この記事では、以下を行う方法について説明します。

  • DNS を構成する
  • App Service をバックエンド プールとして Application Gateway に追加する
  • App Service への接続用に HTTP の設定を構成する
  • HTTP リスナーを構成する
  • 要求のルーティング規則を構成する

前提条件

DNS の構成

このシナリオのコンテキストでは、DNS は 2 つの場所で関連があります。

  • ユーザーまたはクライアントが Application Gateway に対して使用しており、ブラウザーに表示される DNS 名
  • Application Gateway がバックエンドの App Service にアクセスするために内部的に使用している DNS 名

カスタム ドメインを使って、ユーザーまたはクライアントを Application Gateway にルーティングします。 Application Gateway 用の DNS を指す CNAME の別名を使って DNS を設定します。 Application Gateway の DNS アドレスは、関連付けられたパブリック IP アドレスの概要ページに表示されます。 または、IP アドレスを直接指す A レコードを作成します。 (Application Gateway V1 の場合、サービスを停止して開始すると VIP が変わる可能性があるため、このオプションは望ましくありません)。

着信ホストとしてカスタム ドメイン名を使って、Application Gateway からのトラフィックを受け入れるように、App Service を構成する必要があります。 カスタム ドメインを App Service にマップする方法について詳しくは、「チュートリアル: 既存のカスタム DNS 名を Azure App Service にマップする」をご覧ください。ドメインを検証するには、App Service で TXT レコードを追加することだけが必要です。 CNAME または A レコードを変更する必要はありません。 カスタム ドメインの DNS 構成は、Application Gateway を指し示した状態のままになります。

App Service への HTTPS 経由の接続を受け入れるには、その TLS バインドを構成します。 詳しくは、「Azure App Service で TLS/SSL バインドを使用してカスタム DNS 名をセキュリティで保護する」をご覧ください。カスタム ドメインの証明書を Azure Key Vault からプルするように App Service を構成します。

バックエンド プールとして App Service を追加する

  1. Azure portal で、お使いのアプリケーション ゲートウェイを選びます。

  2. [バックエンド プール] で、バックエンド プールを選択します。

  3. [ターゲットの種類] で、[App Services] を選択します。

  4. [ターゲット] で、目的の App Service を選択します。

    App Service バックエンド

    Note

    このドロップダウンに表示されるのは、お使いの Application Gateway と同じサブスクリプションにある App Service だけです。 Application Gateway とは異なるサブスクリプションにあるアプリ サービスを使う場合は、[ターゲット] ドロップダウンで [App Services] を選ぶ代わりに、[IP アドレスまたはホスト名] オプションを選び、アプリ サービスのホスト名 (example.azurewebsites.net) を入力します。

  5. [保存] を選択します。

App Service の HTTP 設定を編集する

カスタム ドメイン名を使って App Service バックエンドにアクセスするよう Application Gateway に指示する HTTP の設定が必要です。 HTTP 設定では、既定では既定の正常性プローブを使用します。 既定の正常性プローブでは、トラフィックが受信されるホスト名を使用して要求を転送しますが、ホスト名が明示的に定義されていないため、正常性プローブではバックエンド プールへのホスト名として 127.0.0.1 を利用します。 このため、そのホスト名として正しいカスタム ドメイン名を使用して構成されているカスタムの正常性プローブを作成する必要があります。

ここでは、HTTPS を使ってバックエンドに接続します。

  1. [HTTP 設定] で、HTTP の既存の設定を選ぶか、新しく追加します。
  2. HTTP の設定を新しく作成するときは、名前を指定します
  3. 使用するバックエンド プロトコルとして、ポート 443 を使う HTTPS を選びます
  4. 証明書が既知の機関によって署名されている場合は、[既知の CA 証明書を使用する] で [はい] を選びます。 または、バックエンド サーバーの認証証明書または信頼されたルート証明書を追加します
  5. [新しいホスト名でオーバーライドする] は、必ず [いいえ] に設定します
  6. [カスタム プローブ] のドロップダウンで、カスタム HTTPS 正常性プローブを選びます。

オーバーライドなしを使用して App Service バックエンドに対してカスタム ドメインを使用するように HTTP 設定を構成する

HTTP リスナーを構成する

トラフィックを受け入れるには、リスナーを構成する必要があります。 これについて詳しくは、「Application Gateway リスナーの構成」をご覧ください。

  1. [リスナー] セクションを開き、[リスナーの追加] を選ぶか、既存のものをクリックして編集します
  2. 新しいリスナーの場合: 名前を指定します
  3. [フロントエンド IP] で、リッスンする IP アドレスを選びます
  4. [ポート] で [443] を選びます
  5. [プロトコル] で [HTTPS] を選びます
  6. [証明書の選択] で、[キー コンテナーから証明書を選択する] を選びます。 詳しくは、Key Vault の使用に関する記事をご覧ください。マネージド ID を割り当てて、Key Vault への権限を提供する方法について、詳しく説明されています。
    1. 証明書の名前を指定します
    2. マネージド ID を選びます
    3. 証明書を取得するキー コンテナーを選びます
    4. 証明書を選択する
  7. [リスナーの種類] で [基本] を選びます
  8. [追加] をクリックしてリスナーを追加します

HTTPS トラフィックのリスナーを追加する

要求のルーティング規則を構成する

以前に構成したバックエンド プールと HTTP の設定を使用すると、リスナーからトラフィックを取得し、HTTP の設定を使ってバックエンド プールにそれをルーティングするよう、要求ルーティング規則を設定できます。 このためには、既存のルーティング規則にまだバインドされていない HTTP または HTTPS リスナーを使用できることを確認します。

  1. [規則] で、クリックして新しい "要求ルーティング規則" を追加します
  2. 規則の名前を指定します
  3. 既存のルーティング規則にまだバインドされていない HTTP または HTTPS リスナーを選びます
  4. [バックエンド ターゲット] で、App Service が構成されているバックエンド プールを選びます
  5. Application Gateway が App Service バックエンドへの接続に使用する必要がある HTTP 設定を構成します
  6. [追加] を選んでこの構成を保存します

構成されている HTTP 設定を使用して、リスナーから App Service バックエンド プールへの新しいルーティング規則を追加する

テスト

これを行う前に、バックエンドの正常性が正常と表示されていることを確認します。

[バックエンド正常性] セクションを開き、[状態] 列に HTTP 設定とバックエンド プールの組み合わせが "正常" と示されていることを確認します。

Azure portal でバックエンドの正常性を確認する

次に、Application Gateway とバックエンドの App Service の両方に関連付けたカスタム ドメインを使って、Web アプリケーションを参照します。

アクセスの制限

これらの例でデプロイした Web アプリでは、インターネットから直接アクセスできるパブリック IP アドレスを使用します。 これは、新機能について学習するときや新しいことを試すときに、トラブルシューティングを行うのに役立ちます。 しかし、機能を運用環境にデプロイする場合は、制限を厳しくする必要があります。 次のオプションを検討してください。

  • サービス エンドポインに基づくアクセス制限規則を構成します。 これにより、アプリへのインバウンド アクセスをロックして、Application Gateway を確実にソース アドレスにすることができます。
  • Azure App Service の静的 IP の制限を使います。 たとえば、アプリケーション ゲートウェイからのトラフィックのみを受信するように Web アプリを制限できます。 アプリ サービスの IP 制限の機能を使用して、アクセス権を持つ唯一のアドレスとして、アプリケーション ゲートウェイの VIP を一覧表示します。