次の方法で共有

App Service Environment で内部ロード バランサーを作成して使用する

  • [アーティクル]

重要

この記事は、Isolated App Service プランで使用される App Service Environment v2 に関するものです。 App Service Environment v1 と v2 は、2024 年 8 月 31 日の時点で廃止されます。 より強力なインフラストラクチャ上で実行できる、使いやすい新しいバージョンの App Service Environment があります。 新しいバージョンの詳細については、App Service Environment の概要に関するページから始めてください。 現在 App Service Environment v1 を使用している場合は、この記事の手順に従って新しいバージョンに移行ください。

2024 年 8 月 31 日の時点で、App Service Environment v1 および v2 は廃止された製品になるため、これらのワークロードに対してはサービス レベル アグリーメント (SLA) とサービス クレジットが適用されなくなります。 App Service Environment v1 および v2 ハードウェアの廃止が開始されており、これが使用中のアプリやデータの可用性とパフォーマンスに影響を及ぼす場合があります。

お客様は、App Service Environment v3 への移行を迅速に完了する必要があります。これを行わないと、アプリとリソースが削除される場合があります。 Microsoft では、インプレース移行機能を使用して、残っている App Service Environment v1 と v2 の自動移行をベストエフォートで試みますが、自動移行後のアプリケーションの可用性については、いかなる主張および保証も行いません。 移行を完了し、ニーズに合わせて最適な App Service プラン SKU を選択するには、手動による構成が必要になる場合があります。 自動移行を実行できない場合、使用中のリソースと関連するアプリ データは削除されます。 これらの極端なシナリオを両方とも回避するために、今すぐ対処することを強くお勧めします。

時間的猶予が必要な場合は、移行を完了するための一回限りの 30 日間の猶予期間を設定することができます。 この猶予期間の詳細と要求方法については、「猶予期間の概要」を確認した後、Azure portal に移動し、各 App Service Environment の [移行] ブレードにアクセスしてください。

App Service Environment v1/v2 の廃止に関する最新情報については、App Service Environment v1 と v2 の廃止に関する更新情報を参照してください。

Azure App Service Environment は、Azure 仮想ネットワーク (VNet) 内のサブネットに Azure App Service をデプロイしたものです。 App Service Environment (ASE) をデプロイするには、次の 2 つの方法があります。

  • 外部 IP アドレスの VIP を使用する。外部 ASE と呼ばれます。
  • 内部 IP アドレスの VIP を使用する。内部エンドポイントは内部ロード バランサー (ILB) であるため、ILB ASE と呼ばれます。

この記事では、ILB ASE を作成する方法について説明します。 ASE の概要については、「App Service Environment の概要」をご覧ください。 外部 ASE を作成する方法については、[外部 ASE の作成] [MakeExternalASE] を参照してください。

概要

ASE は、インターネットにアクセスできるエンドポイント、または VNet の IP アドレスを使用してデプロイできます。 IP アドレスを VNet のアドレスに設定するには、ASE を ILB でデプロイする必要があります。 ASE を ILB でデプロイする際は、使用する ASE の名前を指定する必要があります。 ASE の名前は、ASE 内のアプリのドメイン サフィックスで使用されます。 ILB ASE のドメイン サフィックスは <ASE 名>.appserviceenvironment.net です。 ILB ASE 内で作成されるアプリは、パブリック DNS 内には配置されません。

以前のバージョンの ILB ASE では、ドメイン サフィックスと既定の証明書を HTTPS 接続用に指定する必要がありました。 ドメイン サフィックスは ILB ASE の作成時に収集されなくなり、既定の証明書も収集されなくなっています。 現在 ILB ASE を作成する際は、Microsoft が提供する、ブラウザーによって信頼された証明書が既定で使用されます。 ASE でアプリにカスタム ドメイン名を設定し、それらのカスタム ドメイン名に証明書を設定することは、まだ可能です。

ILB ASE を使用すると、次のようなことができます。

  • サイト間接続または ExpressRoute でアクセスするクラウドでイントラネット アプリケーションを安全にホストできます。
  • WAF デバイスを使用してアプリを保護できます。
  • パブリック DNS サーバーに示されていないクラウドでアプリケーションをホストできます。
  • インターネットから分離されたバックエンド アプリを作成して、ご使用のフロントエンド アプリを安全に統合できます。

無効な機能

ILB ASE を使用する際に実行できないことがいくつかあります。

  • IP ベースの TLS/SSL バインドを使用します。
  • 特定のアプリへの IP アドレスの割り当て。
  • Azure Portal からのアプリの証明書の購入と使用。 証明書は、証明機関から直接入手して、アプリで使用できます。 Azure Portal では入手できません。

ILB ASE を作成する

ILB ASE を作成するには、「Azure Resource Manager テンプレートを使用して ASE を作成する」を参照してください。

Note

App Service Environment の名前は、36 文字以下にする必要があります。

ILB ASE 内にアプリを作成する

通常 ASE 内にアプリを作成するのと同じ方法で、ILB ASE 内にアプリを作成します。

  1. Azure portal で、 [リソースの作成]>[Web]>[Web アプリ] の順に選択します。

  2. アプリの名前を入力します。

  3. サブスクリプションを選択します。

  4. リソース グループを選択または作成します。

  5. [発行]、[ランタイム スタック]、[オペレーティング システム] を選択します。

  6. 既存の ILB ASE の場所を選択します。

  7. App Service プランを選択または作成します。

  8. [確認と作成] を選択し、準備ができたら [作成] を選択します。

Web ジョブ、関数および ILB ASE

関数と Web ジョブはどちらも ILB ASE 上でサポートされますが、それらとポータルを連動するには、SCM サイトへのネットワーク アクセスが必要です。 つまり、お使いのブラウザーが、仮想ネットワーク内のホストまたは仮想ネットワークに接続しているホストに存在する必要があります。 ILB ASE で使用しているドメイン名が appserviceenvironment.net で終わらない場合は、お使いのブラウザーで、SCM サイトで使用されている HTTPS 証明書を信頼する必要があります。

DNS の構成

外部 ASE を使用する場合、ASE で作成されたアプリは Azure DNS で登録されます。 外部 ASE には、アプリを公開するための追加の手順はその後ありません。 ILB ASE を使う場合は、独自の DNS を管理する必要があります。 これは、独自の DNS サーバーで、または Azure DNS プライベート ゾーンを使用して行うことができます。

ILB ASE を使用して独自の DNS サーバーで DNS を構成するには、次の操作を行ってください。

  1. <ASE 名>.appserviceenvironment.net 用のゾーンを作成する
  2. そのゾーンに、ILB の IP アドレスに * を指定する A レコードを作成する
  3. そのゾーンに、ILB の IP アドレスに @ を指定する A レコードを作成する
  4. <ASE 名>.appserviceenvironment.net に scm という名前のゾーンを作成する
  5. scm ゾーンに、ILB の IP アドレスに * を指定する A レコードを作成する

Azure DNS プライベート ゾーンで DNS を構成するには、次の操作を行ってください。

  1. <ASE 名>.appserviceenvironment.net という名前の Azure DNS プライベート ゾーンを作成する
  2. そのゾーンに、ILB の IP アドレスに * を指定する A レコードを作成する
  3. そのゾーンに、ILB の IP アドレスに @ を指定する A レコードを作成する
  4. そのゾーンに、ILB の IP アドレスに *.scm を指定する A レコードを作成する

ASE の既定のドメイン サフィックスの DNS 設定では、アプリがこれらの名前によってのみアクセスできるように制限されていません。 ILB ASE では、アプリの検証なしでカスタム ドメイン名を設定できます。 その後、contoso.net という名前のゾーンを作成する場合は、ILB IP アドレスを指すようにすることができます。 カスタム ドメイン名はアプリ要求に対して機能しますが、scm サイトでは使用できません。 scm サイトは、<appname>.scm.<asename>.appserviceenvironment.net でのみ使用できます。

.<asename>.appserviceenvironment.net という名前のゾーンはグローバルに一意です。 2019 年 5 月より前のユーザーは、ILB ASE のドメイン サフィックスを指定できました。 ドメイン サフィックスで .contoso.com を使用した場合は、scm サイトが含まれていることになります。 このモデルには、既定の TLS/SSL 証明書の管理、scm サイトでのシングル サインオンの欠如、ワイルドカード証明書の使用要件といった課題がありました。 ILB ASE の既定の証明書アップグレード プロセスも中断され、アプリケーションが再起動されました。 これらの問題を解決するため、ILB ASE の動作が、ASE の名前と Microsoft の所有するサフィックスに基づくドメイン サフィックスを使用するように変更されました。 ILB ASE の動作の変更は、2019 年 5 月以降に作成された ILB ASE にのみ影響します。 既存の ILB ASE では、引き続き ASE の既定の証明書とその DNS 構成を管理する必要があります。

ILB ASE で発行する

作成されるすべてのアプリにはエンドポイントが 2 つあります。 ILB ASE には、" <アプリ名>.<ILB ASE ドメイン> " と " <アプリ名>.scm.<ILB ASE ドメイン> " があります。

SCM サイト名をクリックすると、Azure Portal 内の Kudu コンソールに移動します。これは、高度なポータルと呼ばれます。 Kudu コンソールでは、環境変数の表示、ディスクの確認、コンソールの使用などができます。 詳しくは、Azure App Service の Kudu コンソールに関するビデオをご覧ください。

インターネット ベースの CI システム (GitHub や Azure DevOps など) は、ビルド エージェントがインターネットにアクセス可能であり、かつ ILB ASE と同じネットワーク上に存在すれば、引き続き機能します。 したがって、Azure DevOps の場合、ビルド エージェントが ILB ASE と同じ VNET 上に作成されていれば (サブネットは異なっていてもかまいません)、Azure DevOps git からコードをプルして ILB ASE にデプロイできます。 独自のビルド エージェントを作成しない場合は、プル モデルを使用している CI システム (Dropbox など) を使用する必要があります。

ILB ASE 内のアプリには、その ILB ASE の作成時に使用されたドメインが、発行エンドポイントとして使用されます。 このドメインは、アプリの発行プロファイルとアプリのポータル ブレード ( [概要]>[要点] 、 [プロパティ] など) に表示されます。 ILB ASE のドメイン サフィックスが " <ASE 名>.appserviceenvironment.net" で、アプリの名前が mytest である場合、FTP では "mytest.<ASE 名>.appserviceenvironment.net" となり、MSDeploy のデプロイでは mytest.scm.contoso.net となります。

WAF デバイスを使用して ILB ASE を構成する

Web アプリケーション ファイアウォール (WAF) デバイスを ILB ASE と組み合わせることで、指定したアプリだけをインターネットに公開し、それ以外は VNet 内からしかアクセスできないようにすることができます。 これにより、セキュリティで特に保護された多層アプリケーションを構築できます。

WAF デバイスを使用して ILB ASE を構成する方法の詳細については、App Service 環境での Web アプリケーション ファイアウォールの構成に関するページを参照してください。 この記事では、Barracuda 仮想アプライアンスを ASE と使用する方法について示します。 Azure Application Gateway を使用する方法もあります。 Application Gateway は OWASP コア ルールを使用して、その背後に置かれたすべてのアプリケーションのセキュリティを確保します。 Application Gateway について詳しくは、「Web アプリケーション ファイアウォール (WAF)」をご覧ください。

2019 年 5 月より前に作成された ILB ASE

2019 年 5 月より前に作成された ILB ASE では、ASE の作成中にドメイン サフィックスを設定する必要がありました。 また、そのドメイン サフィックスに基づいた既定の証明書をアップロードする必要もありました。 さらに、古い ILB ASE では、その ILB ASE 内のアプリを使用して Kudu コンソールにシングル サインオンすることはできませんでした。 古い ILB ASE 向けに DNS を構成するときは、ドメイン サフィックスと一致するゾーン内にワイルドカードの A レコードを設定する必要があります。 カスタム ドメイン サフィックスを使用して ILB ASE を作成または変更するには、2019 より前の Azure Resource Manager テンプレートと API バージョンを使用する必要があります。 最後のサポート API バージョンは 2018-11-01 です。

はじめに