Azure App Service Environment を使用したエンタープライズデプロイ

Microsoft Entra ID

Azure Application Gateway

Azure App Service

Azure Firewall

Azure Virtual Network

Azure Private Link

この参照アーキテクチャは、App Service Environment バージョン 3 を使用する一般的なエンタープライズワークロードを示しています。また、ワークロードのセキュリティを強化するためのベストプラクティスについても説明します。

Note

App Service Environment バージョン 3 は、このアーキテクチャの主要なコンポーネントです。バージョン 3 が利用可能になりました。バージョン 1 と 2 は、 2024 年 8 月 31 日に廃止されます。

GitHub logo このアーキテクチャの参照実装は、GitHub で入手できます。

アーキテクチャ

Diagram that shows an architecture for an App Service Environment deployment.

このアーキテクチャの Visio ファイルをダウンロードします。

ワークフロー

App Service Environment バージョン 3 には以前のバージョンよりも利点のある異なる機能があります。詳しくは、「機能の違い」を参照してください。 App Service Environment は、次の 2 つの方法でデプロイできます。

パブリック IP アドレスを持つ外部 App Service Environment として
内部ロードバランサー (ILB) に属する内部 IP アドレスを持つ内部 App Service Environment として

この参照アーキテクチャは、ILB App Service Environment とも呼ばれる内部 App Service Environment 内にエンタープライズ Web アプリケーションをデプロイします。シナリオで次の行為が必要な場合は、ILB App Service Environment を使用します。

セキュリティが強化されたイントラネットアプリケーションをクラウド上でホストし、サイト間 VPN または Azure ExpressRoute を介してアクセスします。
Web アプリケーションファイアウォール (WAF) を使用して、アプリの保護レイヤーを提供します。
パブリック DNS サーバーに示されていないクラウドでアプリケーションをホストできます。
インターネットから分離されたバックエンドアプリを作成して、ご使用のフロントエンドアプリを高度な安全性で統合できます。

App Service Environment は常に企業の仮想ネットワーク内の自身のサブネットにデプロイする必要があります。これによって、送受信トラフィックを厳しく管理できるようになります。このサブネット内では、App Service アプリケーションは 1 つ以上の App Service プラン内にデプロイされます。これは、アプリケーションを実行するために必要な物理的なリソースの集合です。複雑さやリソース要件に応じて、App Service プランを複数のアプリケーション間で共有できます。このリファレンス実装では、プライベート API および関数と相互に作用する Voting App という名前の Web アプリをデプロイします。また、複数のアプリケーションのデプロイを実施するための Test App という名前のダミーの Web アプリケーションもデプロイします。 App Service アプリケーションはそれぞれ自身の App Service プランにホストされ、必要に応じて、それぞれ個別にスケールできます。スケーリングのニーズや、ストレージやコンピューティングなど、これらのホストされたアプリケーションが必要とするすべてのリソースは、App Service Environment インフラストラクチャによって完全に管理されます。

この実装における簡単な投票アプリケーションを使用すると、ユーザーは既存のエントリを表示したり、新しいエントリを作成したり、既存のエントリに投票したりできます。エントリや投票の作成や取得には、Web API が使用されます。データ自体は、SQL Server データベースに格納されます。非同期データ更新を実施するために、Web アプリは、Service Bus インスタンス内に新たに追加された票を待ち行列に入れます。この関数は、待ち行列に入った票を選び、SQL データベースを更新します。 Web アプリでブラウザーに表示するために取得するモックアップ広告の格納には、Azure Cosmos DB が使用されます。アプリケーションは、Azure Cache for Redis を使用して、キャッシュ管理を行います。自身のサブネットで App Service Environment と同じ仮想ネットワークへの設定を可能にする、Premium レベルの Azure Cache for Redis が使用されます。これによって、セキュリティが強化され、キャッシュから隔離されます。

Web アプリケーションは、Application Gateway を介してインターネットにアクセスできる唯一のコンポーネントです。インターネットクライアントからは API と関数にはアクセスできません。受信トラフィックは、Application Gateway で設定された WAF によって保護されます。

コンポーネント

次のサービスは、このアーキテクチャで App Service Environment をロックダウンする上で重要です。

Azure Virtual Network または VNet は、企業が所有するプライベートの Azure クラウドネットワークです。強化されたネットワークベースのセキュリティと分離を提供します。 App Service Environment は、エンタープライズ所有の仮想ネットワークのサブネットに App Service をデプロイします。これにより、ネットワークセキュリティグループとプライベートエンドポイントを使用して、企業はネットワーク空間とそれにアクセスするリソースを厳密に制御できるようになります。
Application Gateway は、アプリケーションレベルの Web トラフィックロードバランサー、TLS/SSL オフロード、WAF を備えています。パブリック IP アドレスでリッスンし、ILB App Service Environment のアプリケーションエンドポイントにトラフィックをルーティングします。これはアプリケーションレベルのルーティングであるため、同じ ILB App Service Environment 内の複数のアプリケーションにトラフィックをルーティングすることができます。詳細については、「Application Gateway の複数サイトのホスト」を参照してください。
Azure Firewall は、Web アプリケーションからの送信トラフィックを制限するために使用されます。 App Service Environment が必要とするプライベートエンドポイントチャネルとルートテーブルを通過しない送信トラフィックは、ファイアウォールサブネットに送られます。わかりやすくするために、このアーキテクチャでは、サービスサブネット上のすべてのプライベートエンドポイントを構成します。
Microsoft Entra ID を使用すると、Azure のリソースおよびサービスへのアクセス権とアクセス許可を管理できます。 "マネージド ID" はサービスとアプリに ID を割り当て、その ID は Microsoft Entra ID によって自動的に管理されます。これらの ID は、Microsoft Entra 認証をサポートする任意のサービスを認証するために使用できます。これにより、これらのアプリケーションの資格情報を明示的に構成する必要がなくなります。このアーキテクチャでは、Web アプリにマネージド ID を割り当てます。
Key Vault には、アプリケーションで必要なシークレットと資格情報が格納されます。本オプションは、アプリケーションにシークレットを直接格納する場合に使用します。
GitHub Actions は、このアーキテクチャの継続的インテグレーションと継続的デプロイ機能を提供します。 App Service Environment は仮想ネットワークの内部にあるため、仮想マシンを仮想マシン内部のジャンプボックスとして使用して、App Service プランにアプリケーションをデプロイします。このアクションにより、仮想ネットワークの外部にアプリがビルドされます。セキュリティを強化し、RDP/SSH 接続をシームレスにするには、Azure Bastion をジャンプボックスとして使用することをご検討ください。

マルチサイトの構成

Diagram that shows a multi-site deployment.

このアーキテクチャの Visio ファイルをダウンロードします。

内部 App Service Environment は、HTTP エンドポイントを使用して複数の Web アプリケーションと API をホストできます。 ILB IP は Microsoft Azure Virtual Network 内からしかアクセスできないため、これらのアプリケーションはパブリックインターネットからロックダウンされます。 Application Gateway は、これらのアプリケーションを選択的にインターネットに公開するために使用されます。 App Service Environment は、各 App Service アプリケーションに <default-appName>.<app-service-environment-domain>.appserviceenvironment.net として既定の URL を割り当てます。 App Service Environment ドメイン名を App Service Environment ILB IP アドレスにマップするプライベート DNS ゾーンが作成されます。これにより、カスタム DNS を使用して仮想ネットワーク内のアプリケーションにアクセスすることを回避できます。

Application Gateway は、リスナーが、ゲートウェイの IP アドレスへの要求を HTTPS ポートでリッスンするように構成されています。わかりやすくするために、この実装ではパブリック DNS 名の登録は使用されません。任意に選択した URL を Application Gateway IP にポイントするように、コンピューター上の localhost ファイルを変更する必要があります。わかりやすくするために、リスナーは自己署名証明書を使用してこれらの要求を処理します。 Application Gateway には、App Service アプリケーションの既定の URL ごとにバックエンドプールがあります。ルーティング規則は、リスナーをバックエンドプールに接続するように構成されています。ゲートウェイと App Service Environment 間の接続を暗号化するかどうかを決定する HTTP 設定が作成されます。これらの設定は、バックエンドプールから選択されたホスト名を使用して受信 HTTP ホストヘッダーを上書きするためにも使用されます。この実装では、既定の App Service Environment アプリケーションの URL に対して作成された既定の証明書を使用します。この証明書はゲートウェイによって信頼されています。要求は、対応するアプリケーションの既定の URL にリダイレクトされます。仮想ネットワークにリンクされているプライベート DNS は、この要求を ILB IP に転送します。その後、App Service Environment は要求されたアプリサービスに転送されます。 App Service Environment アプリケーション内のすべての HTTP 通信は、プライベート DNS を経由します。リスナー、バックエンドプール、ルーティング規則、HTTP 設定は、各 App Service Environment アプリケーションの Application Gateway で構成する必要があります。

appgw. json と dns. json を確認し、これらの構成が複数のサイトを許可できるようにする方法を理解してください。 testapp という名前の Web アプリは、この構成を実施するために作成された空のアプリケーションです。これらの JSON ファイルには、デプロイスクリプト commands_std.azcli からアクセスします。また、これらのファイルは commands_ha.azcli によってもアクセスされます。これは、高可用性マルチサイト App Service Environment デプロイを行うために使用されます。

シナリオの詳細

Azure App Service は、Web アプリケーション、API アプリケーション、関数、モバイルアプリケーションなどの Azure 上の様々なアプリケーションをホストするのに使用される PaaS サービスです。 App Service Environment を使用すると、企業は自社の Azure Virtual Network にあるサブネットに App Service アプリケーションをデプロイし、クラウドワークロードのための分離された、高度にスケーラブルな専用の環境を提供できます。

考慮事項

以降の考慮事項には、ワークロードの品質向上に使用できる一連の基本原則である Azure "Well-Architected Framework" の要素が組み込まれています。詳細については、「Microsoft Azure Well-Architected Framework」を参照してください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。詳細については、「セキュリティの重要な要素の概要」を参照してください。

App Service 環境

内部 App Service Environment は、パブリックインターネットから非表示になっている企業の仮想ネットワークにデプロイされます。これにより、企業は Web API や関数などのバックエンドサービスをネットワークレベルでロックダウンできます。 HTTP エンドポイントを使用する App Service Environment アプリケーションには、仮想ネットワーク内から ILB 経由でアクセスできます。 Application Gateway は、ILB を介して Web アプリケーションに要求を転送するように構成されています。 Web アプリケーション自体は、ILB を通じて API にアクセスします。重要なバックエンドコンポーネント、つまり、API と関数は、実質的にパブリックインターネットからアクセスできません。

既定の証明書は、App Service Environment によって割り当てられた既定のドメイン名について、各 App サービスに対して作成されます。この証明書は、ゲートウェイとアプリケーションの間のトラフィックのセキュリティを強化することができ、特定のシナリオで必要になる場合があります。これらの証明書は、クライアントブラウザーでは表示されません。 Application Gateway で構成された証明書にのみ応答できます。

Application Gateway

リファレンス実装では、Application Gateway を appgw.bicep 内にプログラムによって構成します。ファイル commands_std.azcli は、ゲートウェイをデプロイするときに、この設定を使用します。

az deployment group create --resource-group $RGNAME --template-file templates/appgw.bicep --parameters vnetName=$VNET_NAME appgwSubnetAddressPrefix=$APPGW_PREFIX appgwApplications=@appgwApps.parameters.json
APPGW_PUBLIC_IP=$(az deployment group show -g $RGNAME -n appgw --query properties.outputs.appGwPublicIpAddress.value -o tsv)

暗号化

Application Gateway での TLS 終了とエンドツーエンド TLS の概要で説明しているように、Application Gateway は Transport Layer Security (TLS)/Secure Sockets Layer (SSL) を使用して、Web ブラウザからのすべてのトラフィックを暗号化および保護することができます。暗号化は、次の方法で構成できます。

ゲートウェイで終了した暗号化 この場合のバックエンドプールは、HTTP に対して構成されています。ゲートウェイで暗号化が停止し、ゲートウェイとアプリケーションサービス間のトラフィックは暗号化されません。暗号化は CPU を集中的に使用するため、バックエンドで暗号化されていないトラフィックによってパフォーマンスが向上し、証明書の管理が大幅に単純化されます。これにより、ネットワーク構成のバックエンドがセキュリティで保護されるため、適度なレベルのセキュリティが提供されます。
エンドツーエンド暗号化。特定のセキュリティやコンプライアンスの要件など、一部のシナリオでは、ゲートウェイとアプリケーションの間でトラフィックを暗号化する必要がある場合があります。これを行うには、HTTPS 接続を使用し、バックエンドプールで証明書を構成します。

このリファレンス実装では、Application Gateway に自己署名入り証明書を使用します。運用環境のコードの場合、証明機関によって発行された証明書を使用する必要があります。サポートされている証明書の種類の一覧の場合、「TLS 終了でサポートされる証明書」を参照してください。ゲートウェイによって終了される暗号化を作成する方法については、「Azure portal を使用して TLS ターミネーションでアプリケーションゲートウェイを構成する」を参照してください。 appgw.bicep 内の次のコード行は、プログラムでこれを構成します。

          httpListeners: [for item in appgwApplications: {
          name: '${appgwListenerName}${item.name}'
          properties: {
            frontendIPConfiguration: {
              id: '${appgwId}/frontendIPConfigurations/${appgwFrontendName}'
            }
            frontendPort: {
              id: '${appgwId}/frontendPorts/port_443'
            }
            protocol: 'Https'
            sslCertificate: {
              id: '${appgwId}/sslCertificates/${appgwSslCertificateName}${item.name}'
            }
            hostName: item.hostName
            requireServerNameIndication: true
          }
        }]

リファレンス実装では、Application Gateway と App Service Environment 上の Web アプリ間のトラフィックに対するエンドツーエンド暗号化を示します。既定の SSL 証明書が使用されます。この実装のバックエンドプールは、Web アプリケーションに関連付けられている既定のドメイン名で上書きされたホスト名を使用して、HTTPS トラフィックをリダイレクトするように構成されています。 Microsoft によって発行されるため、Application Gateway は、既定の SSL 証明書を信頼します。これらの構成が行われる方法の詳細については、「Application Gateway を使用した App Service の構成」を参照してください。 appgw.bicep の次のコードは、これがリファレンス実装でどのように構成されているかを示しています。

        backendHttpSettingsCollection: [for item in appgwApplications: {
        name: '${appgwHttpSettingsName}${item.name}'
        properties: {
          port: 443
          protocol: 'Https'
          cookieBasedAffinity: 'Disabled'
          pickHostNameFromBackendAddress: true
          requestTimeout: 20
          probe: {
            id: '${appgwId}/probes/${appgwHealthProbeName}${item.name}'
          }
        }
      }]

Web アプリケーションファイアウォール

Application Gateway 上の Web アプリケーションファイアウォール (WAF) は、SQL インジェクションなどの悪意のある攻撃から Web アプリケーションを保護します。また、リアルタイムログを使用して攻撃を監視するために、Azure Monitor とも統合されています。「Azure portal を使用して Web アプリケーションファイアウォールのあるアプリケーションゲートウェイを作成する」で説明しているように、WAF をゲートウェイで有効にする必要があります。リファレンス実装は、次のスニペットを使用して、プログラムによって appgw.bicep ファイルで WAF を有効にします。

        webApplicationFirewallConfiguration: {
        enabled: true
        firewallMode: 'Detection'
        ruleSetType: 'OWASP'
        ruleSetVersion: '3.0'
      }

Virtual Network

ネットワークセキュリティグループは、仮想ネットワーク内の 1 つ以上のサブネットに関連付けることができます。これらは、様々な Azure リソース間のトラフィックフローを許可または拒否するセキュリティ規則です。本アーキテクチャでは、サブネットごとに個別のネットワークセキュリティグループが関連付けられます。これにより、そのサブネットに含まれるサービスに従って、サブネットごとにこれらの規則を微調整できます。たとえば、App Service Environment サブネットのネットワークセキュリティグループの ase.bicep ファイルと、Application Gateway サブネットのネットワークセキュリティグループの appgw.bicep ファイルのにおけるの "type": "Microsoft.Network/networkSecurityGroups" の構成を参照してください。

プライベートエンドポイントを使用することで、プライベートネットワーク経由でクライアントと Azure サービスの間でセキュリティが強化された接続が可能になります。 Azure サービスにプライベートにアクセスできる IP アドレスが提供され、Azure Private Link リソースへのセキュリティが強化されたトラフィックが有効になります。このプラットフォームではネットワーク接続が検証されます。指定されたプライベートリンクリソースに到達する接続のみを許可します。プライベートエンドポイントでは、ネットワークセキュリティグループ、ユーザー定義ルート、アプリケーションセキュリティグループなどのネットワークポリシーがサポートされます。セキュリティを強化するには、それらをサポートするすべての Azure サービスに対してプライベートエンドポイントを有効にする必要があります。その後、パブリックアクセスを無効にし、パブリックインターネットからのアクセスを効果的にブロックすることで、仮想ネットワーク内のサービスのセキュリティを向上させることができます。このアーキテクチャでは、Azure Service Bus、SQL Server、Key Vault、Azure Cosmos DB をサポートをするサービスに対してプライベートエンドポイントが構成されます。構成は、privatendpoints.bicep で確認できます。

プライベートエンドポイントを有効にするには、プライベート DNS ゾーンも構成する必要があります。詳細については、「Azure プライベートエンドポイントの DNS 構成」をご覧ください。

ファイアウォール

Azure Firewall とプライベートエンドポイントは相互に補完します。プライベートエンドポイントは、仮想ネットワークから送信されたトラフィックのみを許可することで、リソースを保護するのに役立ちます。 Azure Firewall を使用すると、アプリケーションからの送信トラフィックを制限できます。プライベートエンドポイントのトラフィックを含め、すべての送信トラフィックが、ファイアウォールサブネットを通過するようにすることをお勧めします。これにより、送信トラフィックの監視が強化されます。わかりやすくするために、この参照アーキテクチャでは、ファイアウォールサブネットではなく、サービスサブネット上のすべてのプライベートエンドポイントを構成します。

Azure Firewall を App Service Environment と統合する方法については、「App Service Environment に合わせて Azure Firewall を構成する」を参照してください。プライベートエンドポイントと仮想ネットワークルートテーブルを経由しないトラフィックは、ファイアウォールによって監視およびゲート管理されます。

Microsoft Entra ID

Microsoft Entra ID には、アプリケーションを認証し、リソースへのアクセスを承認するためのセキュリティ機能が用意されています。このリファレンスアーキテクチャでは、Microsoft Entra ID の 2 つの主要な機能 (マネージド ID と Azure ロールベースのアクセス制御) を使用します。

クラウドアプリケーションでは、クラウドサービスに対する認証に必要な資格情報をセキュリティで保護する必要があります。資格情報は、開発者のワークステーションに一切表示されないか、ソース管理でも確認されないことが理想的です。 Azure Key Vault は、資格情報やその他のシークレットを安全に保管する方法を提供しますが、アプリケーションは、Key Vault に対して認証を行い、それらを取得する必要があります。 Azure リソース用マネージド ID は、Microsoft Entra ID で自動的に管理される ID を Azure サービスに提供します。この ID を使用すると、アプリケーションに資格情報がなくても、Key Vault など、Microsoft Entra 認証をサポートするサービスに対する認証を行うことができます。

Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、Azure リソースへのアクセスを管理します。これには次のものが含まれます

アクセス権を持つエンティティ: ユーザー、管理対象 ID、セキュリティプリンシパル。
アクセスの種類: 所有者、共同作成者、読者、閲覧者、管理者。
アクセスの範囲: リソース、リソースグループ、サブスクリプション、管理グループ。

必要なロールと各アプリケーションへのアクセスの種類を厳密に制御することで、App Service Environment アプリケーションへのアクセスをロックダウンすることができます。これにより、複数のアプリケーションを異なる開発チームの同じ App Service Environment にデプロイできます。たとえば、フロントエンドが 1 つのチームによって処理され、バックエンドが別のチームによって処理される場合があります。 Azure RBAC を使用すると、各チームが作業中のアプリケーションのアクセスを制限できます。 Azure カスタムロールを調べて、組織に適したロールを作成します。

Key Vault

一部のサービスでは、マネージド ID がサポートされていますが、Azure RBAC を使用してアプリケーションの許可を設定しています。たとえば、組み込みの Service Bus ロールと、Azure Cosmos DB での Azure RBAC を参照してください。 共同作成者アクセス権を持つ担当者がこれらのサービスをデプロイできる場合でも、サブスクリプションへの所有者アクセス権を付与する必要があります。より広範な開発者チームがデプロイスクリプトを実行できるようにする場合、次善の策としてサービスのネイティブアクセス制御ポリシーを使用することをお勧めします。

Service Bus の場合は、共有アクセス署名になります。
Azure Cosmos DB の場合はキーです。

次に、これらのアクセス制御ポリシーの接続文字列は、Key Vault に格納されます。コンテナー自体には、Azure RBAC を必要とするマネージド ID を使用してアクセスします。これらの接続文字列のアクセスポリシーを適切に設定します。たとえば、バックエンドの場合は読み取り専用、フロントエンドの場合は書き込み専用で、既定のルートアクセスポリシーは使用しません。

services.bicep の次のコードは、これらのサービスのための Key Vault 構成を表示します。

      resource keyVaultName_CosmosKey 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'CosmosKey'
      properties: {
        value: cosmosName.listKeys().primaryMasterKey 
      }
    }

      resource keyVaultName_ServiceBusListenerConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusListenerConnectionString'
      properties: {
        value: listKeys(serviceBusName_ListenerSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

      resource keyVaultName_ServiceBusSenderConnectionString 'Microsoft.KeyVault/vaults/secrets@2022-07-01' = {
      parent: keyVaultName
      name: 'ServiceBusSenderConnectionString'
      properties: {
        value: listKeys(serviceBusName_SenderSharedAccessKey.id, '2021-11-01').primaryConnectionString
      }
    }

これらの接続文字列の値は、Key Vault のキーと値のペアを参照することによって、アプリケーションによってアクセスされます。これは、Voting App の次のコードに示すように、 sites.bicep ファイルで行われます。

  properties: {
    enabled: true
    hostingEnvironmentProfile: {
      id:aseId
    }
    serverFarmId: votingWebPlanName.id
    siteConfig: {
      appSettings: [
        {
          name: 'ConnectionStrings:sbConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, serviceBusSenderConnectionStringSecretName), '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:RedisConnectionString'
          value: '@Microsoft.KeyVault(SecretUri=${reference(keyVaultName_redisSecretName.id, '2022-07-01').secretUriWithVersion})'
        }
        {
          name: 'ConnectionStrings:CosmosKey'
          value: '@Microsoft.KeyVault(SecretUri=${reference(resourceId('Microsoft.KeyVault/vaults/secrets', keyVaultName, cosmosKeySecretName), '2022-07-01').secretUriWithVersion})'
        }
      ]
    }
  }

関数は、同様の方法で Service Bus リスナーの接続文字列にもアクセスします。

スケーラビリティ

スケーラブルなアプリケーションを設計する

このリファレンスアーキテクチャのアプリケーションは、使用量に基づいて個々のコンポーネントをスケールできるように構造化されています。各 Web アプリ、API、関数は、独自の App Service プランにデプロイされます。各アプリケーションでパフォーマンスのボトルネックが発生していないかどうかを監視し、必要に応じてスケールアップできます。

Application Gateway の自動スケーリング

自動スケーリングは、Azure Application Gateway V2 で有効にすることができます。これにより、トラフィックの負荷パターンに基づいて、Application Gateway をスケールアップまたはスケールダウンすることができます。このリファレンスアーキテクチャでは、ファイル appgw.bicep の autoscaleConfiguration を構成し、0 個から 10 個までの追加インスタンスの間でスケールします。詳細については、「Application Gateway と WAF v2 のスケーリング」を参照してください。

展開

この参照アーキテクチャのデプロイスクリプトは、App Service Environment、他のサービス、および App Service Environment 内のアプリケーションをデプロイするために使用されます。これらのアプリケーションをデプロイした後は、企業は、アプリケーションのメンテナンスとアップグレードのための継続的な統合とデプロイの計画を立てる必要があります。このセクションでは、開発者が App Service Environment アプリケーションの CI/CD を使用する一般的な方法をいくつか紹介します。

アプリケーションを内部 App Service Environment にデプロイできるのは、仮想ネットワーク内からのみです。 App Service Environment アプリケーションのデプロイには、次の 3 つの方法が広く使用されています。

Virtual Network 内で、手動で行う - デプロイに必要なツールを使用して、App Service Environment 仮想ネットワーク内に仮想マシンを作成します。 NSG 構成を使用して、VM への RDP 接続を開きます。コードアーティファクトを VM にコピーし、ビルドして、App Service Environment サブネットにデプロイします。これは、初期のビルドおよびテストの開発環境を設定する簡単な方法です。ただし、運用環境では、必要なデプロイスループットを拡張できないため、この方法はお勧めしません。
ローカルワークステーションからのポイント対サイト接続 - これにより、App Service Environment 仮想ネットワークを開発用コンピューターに拡張し、そこからデプロイすることができます。これは、初期開発環境をセットアップするもう 1 つの方法であり、運用環境ではお勧めしません。
Azure Pipelines: これは、仮想ネットワーク内にあるエージェントで終了する完全な CI/CD パイプラインを実装します。これは、デプロイの高スループットを要求する運用環境に最適です。ビルドパイプラインは完全に仮想ネットワークの外部に留まります。デプロイパイプラインは、構築されたオブジェクトを仮想ネットワーク内のビルドエージェントにコピーし、App Service Environment サブネットにデプロイします。詳細については、パイプラインと App Service Environment 仮想ネットワーク間の自己ホスト型ビルドエージェントに関する記事をご覧ください。

Azure Pipelines の使用は、運用環境にお勧めです。 Azure Pipelines YAML schema を使用して CI/CD をスクリプト化すると、ビルドおよびデプロイのプロセスを自動化できます。このリファレンス実装では、azure-pipelines.yml は、Web アプリケーション用の CI/CD パイプラインを実装します。 Web API には同様の CI/CD スクリプトに加えて、関数もあります。各アプリケーションの CI/CD を自動化するためにこれらを使用する方法については、「Azure Pipelines の使用」を参照してください。

一部の企業では、仮想ネットワーク内で永続的なビルドエージェントを維持したくない場合があります。その場合は、DevOps パイプライン内でビルドエージェントを作成し、デプロイが完了したら、それを破棄することができます。これにより、DevOps に別のステップが追加されますが、仮想マシンのメンテナンスの複雑さが軽減されます。 VM ではなく、ビルドエージェントとしてコンテナーの使用を検討することもできます。また、通常はストレージアカウントで 仮想ネットワークの外部に配置された ZIP ファイルからデプロイすることで、ビルドエージェントを完全に回避できます。ストレージアカウントには、App Service Environment からアクセスできる必要があります。パイプラインは、ストレージにアクセスできる必要があります。リリースパイプラインの最後には、ZIP ファイルを BLOB ストレージにドロップできます。その後、Azure App Service Environment で選択してデプロイできます。この方法の次の制限事項に注意してください。

DevOps と実際のデプロイプロセスとの間に断絶があるため、デプロイの問題を監視および追跡するときに問題が発生します。
セキュリティで保護されたトラフィックを含むロックダウンされた環境では、ストレージ上の ZIP 形式のファイルにアクセスするように規則を変更することが必要になる場合があります。
ZIP ファイルからデプロイできるようにするには、App Service Environment に特定の拡張機能とツールをインストールする必要があります。

App Service プランにアプリをデプロイするいくつかの方法については、デプロイ戦略に焦点を置いた App Service に関する記事を参照してください。

コスト最適化

コストの見積もりには、Azure 料金計算ツールをご利用ください。その他の考慮事項については、Microsoft Azure Well-Architected Framework のコストに関するセクションに説明されています。 Azure の予約には、多数の Azure リソースに対する計画を 1 年分または 3 年分コミットすることで、コストを削減する効果があります。詳細については、記事「予約の購入」をお読みください。

ここでは、このアーキテクチャで使用される重要なサービスの一部について考慮する点について説明します。

App Service Environment v3

App Service には、様々な価格オプションが用意されています。 App Service Environment は、分離 v2 サービスプランを使用してデプロイされます。このプランには、I1v2 から I6v2 までの CPU サイズに関する複数のオプションがあります。このリファレンス実装では、インスタンスごとに 3 つの I1v2 が使用されます。

Application Gateway

Application Gateway の価格には、さまざまな価格オプションが用意されています。この実装では、自動スケーリングとゾーンの冗長性をサポートする Application Gateway Standard v2 と WAF v2 SKU を使用しています。この SKU に使用される価格モデルの詳細については、「Application Gateway v2 と WAF v2 のスケーリング」を参照してください。

Azure Cache for Redis

Azure Cache for Redis の価格には、このサービスに対する様々な価格オプションが用意されています。このアーキテクチャでは、仮想ネットワークのサポートのために Premium SKU を使用します。

App Service Environment をロックダウンするために使用される他のサービスの価格ページを次に示します。

このシナリオのデプロイ

このアーキテクチャのリファレンス実装をデプロイするには、GitHub の readme を参照し、標準的なデプロイのためのスクリプトに従ってください。

共同作成者

この記事は、Microsoft によって保守されています。当初の寄稿者は以下のとおりです。

プリンシパル作成者:

Dhanashri Kshirsagar | シニアコンテンツ PM

その他の共同作成者:

Deep Bhattacharya | クラウドソリューションアーキテクト
Suhas Rao | クラウドソリューションアーキテクト

パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。

次のステップ

高可用性をサポートするためにこのアーキテクチャを拡張する方法については、「App Services Environment を使用した高可用性アプリケーションのデプロイ」を参照してください。

Azure App Service Environment を使用したエンタープライズデプロイ

アーキテクチャ

ワークフロー

コンポーネント

マルチサイトの構成

シナリオの詳細

考慮事項

セキュリティ

App Service 環境

Application Gateway

暗号化

Web アプリケーションファイアウォール

Virtual Network

ファイアウォール

Microsoft Entra ID

Key Vault

スケーラビリティ

スケーラブルなアプリケーションを設計する

Application Gateway の自動スケーリング

展開

コスト最適化

App Service Environment v3

Application Gateway

Azure Cache for Redis

このシナリオのデプロイ

共同作成者

次のステップ

フィードバック

フィードバック

その他のリソース

Azure App Service Environment を使用したエンタープライズ デプロイ

アーキテクチャ

ワークフロー

コンポーネント

マルチサイトの構成

シナリオの詳細

考慮事項

セキュリティ

App Service 環境

Application Gateway

暗号化

Web アプリケーション ファイアウォール

Virtual Network

ファイアウォール

Microsoft Entra ID

Key Vault

スケーラビリティ

スケーラブルなアプリケーションを設計する

Application Gateway の自動スケーリング

展開

コスト最適化

App Service Environment v3

Application Gateway

Azure Cache for Redis

このシナリオのデプロイ

共同作成者

次のステップ

関連リソース

フィードバック

フィードバック

その他のリソース

Azure App Service Environment を使用したエンタープライズデプロイ

Web アプリケーションファイアウォール