App Service Environmentは、Azure Virtual Network インスタンスとサブネットと統合されるAzure App Serviceのシングルテナント デプロイです。 このシナリオでは、システムの唯一のユーザーである分離された環境で Web アプリをホストできます。 デプロイするアプリは、App Service Environmentの仮想ネットワーク サブネットに適用されるネットワーク機能の対象となります。 Web アプリがネットワーク機能にアクセスするために、他の機能は必要ありません。
App Service Environmentで Web アプリを作成する場合は、少し異なるアプローチで標準の作成プロセスに従います。
- Web アプリのリージョンでは、アプリのデプロイに地理的な場所を選択するのではなく、App Service Environmentを選択します。
- App Service Environment の新しい App Service プランでは、アイソレート v2 価格ティアを選択します。
この記事では、Azure ポータルの手順に従って、App Service Environmentで App Service Web アプリを作成する方法について説明します。
[前提条件]
アプリサービス環境 (App Service Environment)。 新しい環境を作成するには、「
Quickstart: App Service Environment の手順に従います。アプリを作成するときは、Windowsと Linux のアプリは同じApp Service Environmentにできますが、同じ App Service プランに含めることはできません。
Web アプリを作成する
Azure ポータルで、App Service Environmentに Web アプリを作成します。
Azure ポータルにサインインします。
[ リソースの作成] を選択し、リソースの一覧で Web アプリ を見つけて、[ 作成] を選択します。
[ Web アプリの作成 ] ウィンドウが開き、[ 基本 ] タブが表示されます。
[ 基本 ] タブで、サブスクリプションを選択 します。
既存の リソース グループ を選択するか、[ 新しい インスタンスの新規作成] を選択します。
新しい Web アプリの名前を入力 します 。
App Service Environmentで App Service プランを選択した場合、アプリのドメイン名には、App Service Environmentのドメイン名が反映されます。 たとえば、アプリ
zava-hosted-web-appと App Service Environmentzava-app-service-envrionment-1の場合、アプリのドメイン名はzava-hosted-web-app-zava-app-service-envrionment-1.appserviceenvironment.netです。アプリの要件に応じて、 発行、 ランタイム スタック、 オペレーティング システム の設定を構成します。
[リージョン] 設定では、ドロップダウン リストを使用して選択します。
既存のApp Service Environmentを使用するには、ドロップダウン リストの App Service Environment v3 セクションで環境を選択します。
新しいApp Service Environmentを作成するには、ドロップダウン リストの Regions セクションでリージョンを選択します。 リージョンを選択すると、Create Web App ペインに、新しいApp Service Environmentの構成オプションを含むセクションが追加されます。 この手順の後半で、新しい環境の手順を完了します。
[リージョン] リストをフィルター処理して、環境とリージョンの両方の一覧に一致する項目を表示できます。 この例では、カナダと一致するようにリストをフィルター処理 します。
[価格プラン] オプションには、App Service プラン名とプランの価格レベルを指定します。
App Service Linux プランの場合は、ドロップダウン リストを使用して既存のプランを選択するか、[ 新規作成 ] を選択して新しいプランを作成します。
価格プラン レベルでは、既存プランを選択した場合、現在のプランの価格レベルが値として設定されます。
新しい App Service プランを作成する場合は、ドロップダウン リストを使用して、レベル のサイズを選択します。 一覧には 、人気のあるプランが表示されます。 アプリに対して選択できる SKU は、 Isolated v2 価格 SKU のみです。
[ 価格プランの探索 ] を選択して、プランの機能を比較できます。 次の図は、価格プランと機能の例を示しています。 [ App Service の価格プランの選択 ] ウィンドウで、一覧からプランを選択し、[選択] を 選択します。
“<c1><c0><sb0>Azure ポータルにおける App Service プランの価格レベル、その機能およびハードウェアを示すスクリーンショットです。</sb0></c0></c1>”
新しい App Service プランの作成には約 20 分かかります。
新しい App Service プランの作成の一環として新しいApp Service Environmentを作成する場合は、次のApp Service Environment設定を構成します。
App Service Environment の名前を入力します。
仮想 IP の種類 (内部または外部) を選択します。 この設定の詳細については、「 アプリのアクセス レベルを計画する」を参照してください。
Azure ポータルで新しい App Service Environment を構成する方法を示すスクリーンショット [Web アプリの作成] ウィンドウで [ネットワーク] タブに切り替えて、設定を構成します。
新しいApp Service Environmentを作成する場合:
- デプロイに使用する Virtual Network と Subnet を特定します。 既存のリソースを選択することも、新しいインスタンスを作成することもできます。
DNS 設定を構成します。 システムがApp Service Environmentの仮想ネットワークで DNS を構成する場合は、Azure DNSプライベート ゾーンを選択します。
DNS を手動で構成する場合は、[手動] を選択 します。 デプロイが完了したら、構成を変更して 独自の DNS サーバーを使用するかAzure DNSプライベート ゾーンを指定できます。
受信 IP アドレスの設定を構成します。 [ 自動 ] (サブネットのシステム割り当て IP アドレス) または [手動] (任意の IP アドレスを入力) を選択します。
デプロイに既存のApp Service Environmentを使用している場合は、必要に応じて Virtual ネットワーク統合 オプションを構成します。
(省略可能)アプリの要件に応じて、[ Web アプリの作成 ] ウィンドウの残りのタブのオプションを構成します。 ほとんどの設定は既定で無効になっています。
- Deployment: 継続的デプロイ、認証、およびGitHub設定を構成します。
- Monitor + Secure: Azure Monitor の Application Insights または Microsoft Defender for Cloud を使用します。
- タグ: アプリのタグを定義します。
新しいApp Service Environmentを作成する場合は、Hosting タブの設定も確認します。
[Review + create](レビュー + 作成) を選択します。 Web アプリの構成が正しいことを確認し、[ 作成] を選択します。
スケーリング オプションを確認する
すべての App Service アプリは、App Service プランで実行されます。 App Service Environment に App Service プランが存在し、App Service プランにアプリが存在します。 アプリをスケールするときは、App Service プラン、および同じプラン内のすべてのアプリをスケールすることになります。
App Service プランをスケーリングすると、必要なインフラストラクチャが自動的に追加されます。 インフラストラクチャの追加中は、スケール操作に時間の遅延があることに注意してください。 たとえば、App Service プランをスケーリングするときに、同じオペレーティング システムとサイズの別のスケール操作が実行されている場合、要求されたスケールが開始されるまで数分の遅延が発生することがあります。
1 つのサイズとオペレーティング システムでのスケール操作は、サイズとオペレーティング システムの他の組み合わせのスケーリングには影響しません。 たとえば、Windows I2v2 App Service プランをスケーリングする場合、Windows I3v2 App Service プランへのスケール操作がすぐに開始されます。 スケーリングにかかる時間は、通常 15 分未満ですが、最大で 45 分かかる場合があります。
マルチテナント App Service シナリオでは、共有リソースのプールをすぐにサポートできるため、スケーリングは即時に行われます。 App Service Environmentはシングルテナント サービスであるため、共有バッファーはなく、リソースはニーズに基づいて割り当てられます。
アプリのアクセス レベルを計画する
内部仮想 IP (VIP) を持つApp Service Environmentでは、アプリの作成に使用されるドメイン サフィックスは <app-service-environment-name>.appserviceenvironment.net です。
zava-environment という名前のアプリをホストする hosted-web-app という名前のApp Service Environmentの場合は、次の URL を使用して環境に到達します。
hosted-web-app.zava-environment.appserviceenvironment.nethosted-web-app.scm.zava-environment.appserviceenvironment.net
内部 VIP を使用するApp Service Environmentでホストされているアプリには、同じ仮想ネットワーク内にいる場合、またはその仮想ネットワークに接続している場合にのみアクセスできます。 同様に、発行は、同じ仮想ネットワーク内にいるか、その仮想ネットワークに接続している場合にのみ可能です。
外部 VIP を使用するApp Service Environmentでは、アプリの作成に使用されるドメイン サフィックスは <app-service-environment-name>.p.azurewebsites.net です。 もし zava-environment という名前の App Service Environment が hosted-web-app という名前のアプリをホストしている場合、次の URL を使用して環境にアクセスします。
hosted-web-app.zava-environment.p.azurewebsites.nethosted-web-app.scm.zava-environment.p.azurewebsites.net
scm URL を使用して Kudu コンソールにアクセスするか、Web デプロイを使用してアプリを発行します。 詳細については、「Azure App Service の
DNS を構成する
App Service Environmentが外部 VIP で作成された場合、アプリは自動的にパブリック DNS に配置されます。 App Service Environmentが内部 VIP で作成されている場合は、DNS を手動で構成することが必要になる場合があります。
アプリを作成するときに、Azure DNSプライベート ゾーンの自動構成>
DNS を手動で構成する場合は、次のセクションで説明するように、独自の DNS サーバーを使用するか、プライベート ゾーンAzure DNS構成する必要があります。
App Service Environmentの IP アドレスは、Azure ポータルで確認できます。
Azure ポータルで、アプリのApp Service Environmentの Overview ページに移動します。
左側のメニューで、[>IP アドレス] を選択します。
[IP アドレス] ページには、受信 IP アドレスと送信 IP アドレスが表示されます。
独自の DNS サーバーを使用する
独自の DNS サーバーを使用する場合は、以下のレコードを追加します。
DNS サーバーで、App Service Environment の名前を持つ
<app-service-environment-name>.appserviceenvironment.netを作成します。 この手順の後の手順では、このゾーンを ゾーン メインと見なします。zone-main に
Aレコードを作成し、アスタリスク*(ワイルドカード表記) をApp Service Environmentで使用する受信 IP アドレスを指すようにします。Aレコードを zone-main に作成し、「@」記号@の表記をあなたの App Service Environment で使用されている受信 IP アドレスに向けます。という名前
scm内にゾーンを作成します。Aレコードをscmゾーンに作成し、アスタリスク*（ワイルドカード表記）を、App Service Environment が使用する受信アドレスを示すように設定します。
Azure DNS プライベート ゾーンで DNS を構成する
Azure DNSプライベート ゾーンで DNS を構成するには:
Azure Private DNS ゾーン リソースを作成します。 App Service Environmentの
<app-service-environment-name>.appserviceenvironment.netという名前。 この手順の後の手順では、このゾーンを ゾーン メインと見なします。アスタリスク
A(ワイルドカード表記) を受信 IP アドレスにポイントする レコードを*に作成します。受信 IP アドレスに at 記号
A表記をポイントする レコードを@に作成します。Aゾーン表記を受信 IP アドレスにポイントする レコードをゾーン*.scmに作成します。
App Service Environmentの既定のドメイン サフィックスの DNS 設定では、アプリへのアクセスが指定した値のみに制限されることはありません。 App Service Environment内のアプリに対して検証を行わなくても、カスタム ドメイン名を設定できます。 後で zava-new-zone.net という名前のゾーンを作成する場合は、受信 IP アドレスをポイントできます。
カスタム ドメイン名は、アプリ要求に対して機能します。 カスタム ドメイン サフィックス証明書に scm のワイルドカード SAN が含まれている場合、カスタム ドメイン名は scm サイトでも機能します。
*.scmレコードを作成し、それを受信 IP アドレスに向けます。
Web アプリを発行する
Web アプリは、次のいずれかの方法で発行できます。
- Web デプロイ
- 継続的インテグレーション (CI)
- Kudu コンソールでのドラッグ アンド ドロップ。
- Visual Studio、Eclipse、IntelliJ IDEA などの統合開発環境 (IDE)
内部 VIP App Service Environmentでは、公開エンドポイントは受信アドレス経由でのみ使用できます。 受信 IP アドレスへのネットワーク アクセス権がない場合、そのApp Service Environmentにアプリを発行することはできません。 IDEは、App Service Environmentの受信アドレスへのネットワークアクセスが必要であり、それに直接発行することができます。
他の変更がなければ、GitHubやAzure DevOpsなどのインターネットベースの CI システムは、内部 VIP App Service Environmentでは機能しません。 発行エンドポイントはインターネットにアクセスできません。 仮想ネットワークにセルフホステッド リリース エージェントをインストールすることで、Azure DevOpsから内部 VIP App Service Environmentへの発行を有効にすることができます。
Web アプリのストレージを構成する
App Service Environment内のすべてのアプリに対して 1 TB のストレージがあります。 Isolated 価格 SKU における App Service プランには、ストレージ容量が 250 GB の制限があります。 App Service Environmentでは、App Service プランごとに最大 1 TB の制限まで、250 GB のストレージが追加されます。 App Service プランは 4 つより多くできますが、1 TB の制限を超える他のストレージはありません。
App Service Environmentを監視する
Microsoft は、App Service Environment v3 のプラットフォーム インフラストラクチャを監視および管理し、必要に応じてスケーリングします。 顧客は、App Service プランと実行中の個々のアプリのみを監視し、適切なアクションを実行する必要があります。 シナリオをサポート するために、監視用の診断設定を構成 できます。
Azure ポータルでは、App Service Environmentのメトリックをいくつか確認できます。 ただし、これらのメトリックは、App Service Environment v1 と 2 つのリソースを対象とします。 App Service Environment v3 リソースのメトリックは表示されません。 以前のバージョンのApp Service Environmentについては、App Service Environmentの概要の機能の違いを確認してください。
ログ記録のシナリオとメッセージを確認する
Azure Monitorと統合して、ログをAzure Storage、Azure Event Hubs、またはAzure Monitorログに送信できます。
次の表に、ログに記録できるシナリオとメッセージを示します。
| App Service Environmentの状態 | メッセージ |
|---|---|
| サブネットはほぼ満杯 | The specified App Service Environment is in a subnet that is almost out of space. There are {0} remaining addresses. Once these addresses are exhausted, the App Service Environment will not be able to scale. |
| インスタンスの制限に近い環境 | The specified App Service Environment is approaching the total instance limit of the App Service Environment. It currently contains {0} App Service Plan instances of a maximum 200 instances. |
| 環境が中断されました | The specified App Service Environment is suspended. The App Service Environment suspension may be due to an account shortfall or an invalid virtual network configuration. Resolve the root cause and resume the App Service Environment to continue serving traffic. |
| アップグレードが開始されました | A platform upgrade to the specified App Service Environment has begun. Expect delays in scaling operations. |
| アップグレードの完了 | A platform upgrade to the specified App Service Environment has finished. |
| App Service プランの作成 | メッセージ |
|---|---|
| Started | An App Service plan ({0}) creation has started. Desired state: {1} I{2}v2 workers. |
| 完了 | An App Service plan ({0}) creation has finished. Current state: {1} I{2}v2 workers. |
| 失敗 | An App Service plan ({0}) creation has failed. This may be due to the App Service Environment operating at peak number of instances, or run out of subnet addresses. |
| スケーリング操作 | メッセージ |
|---|---|
| Started | An App Service plan ({0}) has begun scaling. Current state: {1} I(2)v2. Desired state: {3} I{4}v2 workers. |
| 完了 | An App Service plan ({0}) has finished scaling. Current state: {1} I{2}v2 workers. |
| 中断 | An App Service plan ({0}) was interrupted while scaling. Previous desired state: {1} I{2}v2 workers. New desired state: {3} I{4}v2 workers. |
| 失敗 | An App Service plan ({0}) has failed to scale. Current state: {1} I{2}v2 workers. |
診断ログを有効にする
Web アプリの診断ログを有効にするには、次の手順に従います。
Azure ポータルで、Web アプリの Overview ページに移動します。
左側のメニューで、 監視>Diagnostic 設定を選択します。
[ 診断設定 ] ページで、[ 診断設定の追加] を選択します。
Azure portal でApp Service Environmentのスクリーンショットで、[診断設定の追加] を選択する方法を示します。 [ 診断設定 ] ウィンドウで、ログ統合の 診断設定名 (
networking-logsなど) を指定します。希望のログを選択して構成してください。 この例では、[ App Service Platform Logs] を選択します。
お好みの宛先を選択します。
診断にメトリック データを含める場合は、[ メトリック] を選択します。
保存を選びます。
[ 診断設定] ページが更新され、一覧に追加された新しいログが表示されます。
Azure Monitor ログと統合する場合は、App Service Environment ポータルから Logs を選択し、AppServicePlatformLogs に対するクエリを作成することで、ログを確認できます。 ログは、App Service Environmentにログをトリガーするイベントがある場合にのみ出力されます。 App Service Environmentにそのようなイベントがない場合、ログは収集されません。 ログの例をすばやく確認するには、App Service プランを使用してスケーリングを実行します。 その後、 AppServicePlatformLogs に対してクエリを実行して、生成されたログを確認できます。
アラート ルールの作成
Web アプリのログに対するアラートを作成するには、「ログ検索アラート ルールの作成または編集 - Azure Monitor」の詳細な手順に従います。
ホストされた Web アプリのアラート ルールを作成する基本的な手順を次に示します。
Azure ポータルで、App Service Environmentの Monitoring>Alerts ページに移動し、アラート ルール を選択します。
Scope タブで、Scope レベルがサブスクリプションに設定されていることを確認し、Azure Monitor ログ ワークスペースに Resource を設定します。
[ 条件 ] タブで、ルールのクエリを指定し、条件を構成します。
カスタム ログ検索を使用するようにシグナル名を設定します。 [ ログ ] ウィンドウが開きます。
[ ログ ] ウィンドウで、アラートのクエリを作成します。 たとえば、「
AppServicePlatformLogs | where ResultDescription contains 'has begun scaling'」のように入力します。 定義済みのクエリから始めて、必要に応じて変更することもできます。 クエリを保存します。アラート ロジック グループのしきい値など、ルールのその他の条件を構成します。
[ 詳細 ] タブで、ルールの詳細を指定します。
プロジェクトの 詳細については、 サブスクリプション と リソース グループ が想定どおりに指定されていることを確認します。
アラート ルールの詳細については、ルールの重大度とリージョンを選択し、新しいアラートの名前を入力します。
ログ クエリ ID の場合は、ログ クエリの実行時に使用する ID を選択します。
(省略可能)必要に応じて 詳細オプション を構成します。
(省略可能) [アラート ルールの作成 ] ウィンドウの残りのタブでオプションを構成します。
アクション: アクション グループを追加または作成します。 アクション グループでは、電子メールや SMS メッセージの送信など、アラートへの応答を定義します
タグ: Web アプリアラートルールのタグを定義します。
[Review + create](レビュー + 作成) を選択します。 アラートの構成が正しいことを確認し、[ 作成] を選択します。
内部暗号化を構成する
App Service Environment システム内で内部コンポーネントや通信を確認することはできません。 より高いスループットを実現するために、内部コンポーネント間の暗号化は既定では有効になっていません。 トラフィックは監視とアクセスにアクセスできないため、システムはセキュリティで保護されています。
データ パスの完全な暗号化に関するコンプライアンス要件がある場合は、次の機能を有効にすることができます。
Azure ポータルで、App Service Environmentの Overview ページに移動します。
左側のメニューで、[設定]>[構成] を選択します。
App Service Environment Configuration ペインで、Internal encryption チェックボックスをオンにし、Apply を選択します。
このオプションは、内部ネットワーク トラフィックを暗号化し、ページファイルとワーカー ディスクも暗号化します。
Important
暗号化を有効にすると、システムのパフォーマンスに影響する可能性があります。 変更が完全に反映されるまで、App Service Environmentは不安定な状態になります。 更新するインスタンスの数によっては、変更の完全な反映が完了するまでに数時間かかることがあります。
App Service Environmentを使用している間は、暗号化を有効にしないでください。 環境の使用中に暗号化を有効にするには、操作が完了するまでトラフィックをバックアップに転送します。
アップグレードの基本設定を構成する
複数の App Service 環境がある場合は、1 つ以上を他の環境より前にアップグレードする必要があります。
環境ごとに、[ アップグレード] 基本設定 を構成します。
Azure ポータルで、App Service Environmentの Overview ページに移動します。
左側のメニューで、[設定]>[構成] を選択します。
App Service Environment の構成 パネルで、アップグレードの設定を選択します。
Automatic: 選択内容に従ってApp Service Environmentを自動的にアップグレードします。
-
None: (既定) リージョンのアップグレード プロセス中に自動的にアップグレードされます。 -
Early: リージョン内の他のリソースと比較して優先順位が高い状態で自動的にアップグレードします。 -
Late: リージョン内の他のリソースと比較して優先順位が低い状態で自動的にアップグレードします。
-
手動 アップグレードが利用可能になったときに通知を受け取り、15 日以内にプロセスを開始します。 15 日後、アップグレードはリージョン内の他の自動アップグレードと共に行われます。 詳細については、「App Service Environment の計画メンテナンスにおけるアップグレード設定」を参照してください。
変更を保存するには、[ 適用] を選択します。
Azure portal で App Service Environment のアップグレード設定を示すスクリーンショット
この機能は、複数の App Service Environment がある場合に最も役に立ちます。アップグレードをシーケンス処理することでメリットがある場合があります。 たとえば、開発とテストの App Service Environment を早期にアップグレードするように設定し、運用 App Service Environment を後でアップグレードするように設定できます。
App Service Environmentの削除
App Service Environmentを削除するには、次の手順に従います。
Azure ポータルの Overview ページの App Service Environment で、Delete を選択します。
App Service Environmentの名前を入力して削除アクションを確認し、OK を選択します。
App Service Environmentを削除すると、環境内のすべてのコンテンツとリソースも削除されます。