インプレース移行機能を使って App Service Environment v1 と v2 を App Service Environment v3 に移行する

[アーティクル]
05/21/2024

Note

この記事で説明する移行機能は、App Service Environment v1 と v2 から App Service Environment v3 へのインプレース (同じサブネット) の自動移行に使用されます。サイドバイサイド移行機能の情報をお探しの場合は、「サイドバイサイド移行機能を使用した App Service Environment v3 への移行」を参照してください。手動移行オプションの情報をお探しの場合は、手動移行のオプションに関する記事をご覧ください。適切な移行オプションの決定については、「移行パスのデシジョンツリー」をご覧ください。 App Service Environment v3 の詳細については、App Service Environment v3 の概要に関する記事を参照してください。

インプレース移行機能を使用することで、App Service Environment v1 と v2 を App Service Environment v3 に自動的に移行することができます。移行プロセスの詳細と、お使いの App Service Environment によって現時点で移行がサポートされるかどうかを確認するには、インプレース移行機能の概要に関する記事を参照してください。

重要

予期しない問題を回避するために、運用環境を移行する前に開発環境に対してこの機能を使用することをお勧めします。この記事または機能に関するフィードバックがありましたら、ページの下部にあるボタンを使用してご提供ください。

前提条件

App Service Environment v3 への移行がアプリケーションに及ぼす影響について理解していることを確認してください。移行プロセスを確認して、プロセスのタイムラインと、ユーザーによる操作が必要になるタイミングを理解してください。また、FAQ も確認してください。ここには、疑問に対する回答が示されている可能性があります。

お使いの仮想ネットワーク、リソースグループ、リソース、またはサブスクリプションがロックされていないことを確認します。ロックは、移行中にプラットフォームの操作をブロックします。

サブネットの変更や Azure App Service リソースの作成など、移行に必要なアクションをブロックしている Azure ポリシーがないことを確認します。リソースの変更や作成をブロックするポリシーにより、移行が停止したり失敗したりする可能性があります。

移行中はスケーリングがブロックされるため、移行を開始する前に、環境を目的のサイズにスケーリングする必要があります。移行後に環境をスケーリングする必要がある場合は、移行が完了したらそれを行うことができます。

インプレース移行エクスペリエンスには Azure portal を使用することをお勧めします。移行に Azure CLI を使用する場合は、Azure REST API を呼び出すことになるため、ここに書かれている手順を順番通りそのまま実行してください。これらの API 呼び出しを行うには、Azure CLI を使用することをお勧めします。その他の方法に関する情報については、「Azure REST API リファレンス」を参照してください。

このガイドに従うには、Azure CLI をインストールするか、Azure Cloud Shell を使用して Bash シェルを使用します。

Note

このガイドに記載されているコマンドを実行するには、Bash シェルを使用することをお勧めします。コマンドは、PowerShell の規則やエスケープ文字と互換性がない場合があります。

1. App Service Environment ID を取得する

以下のコマンドを実行して、App Service Environment ID を取得し、それを環境変数として保存します。名前とリソースグループのプレースホルダーは、移行したい App Service Environment の値に置き換えます。仮想ネットワークと App Service Environment が同じリソースグループ内にある場合、ASE_RG と VNET_RG は同じです。

ASE_NAME=<Your-App-Service-Environment-name>
ASE_RG=<Your-ASE-Resource-Group>
VNET_RG=<Your-VNet-Resource-Group>
ASE_ID=$(az appservice ase show --name $ASE_NAME --resource-group $ASE_RG --query id --output tsv)

2.移行がサポートされていることを検証する

次のコマンドにより、お使いの App Service Environment が移行をサポートしているかどうかを確認します。エラーが発生した場合、または App Service Environment が異常または停止状態の場合は、移行できません。表示される可能性のあるエラーメッセージの説明については、「トラブルシューティング」のセクションを参照してください。お使いの環境でインプレース移行機能を使った移行がサポートされていない場合、またはインプレース移行機能を使用せずに App Service Environment v3 に移行する場合は、手動での移行オプションに関する記事を参照してください。このコマンドは、App Service Environment が移行でサポートされているビルドバージョンにあることも検証します。 App Service Environment がサポート対象のビルドバージョンにない場合は、自分でアップグレードを開始する必要があります。環境のサイズによっては、8 から 12 時間以上かかる場合があります。移行前のアップグレードの詳細については、「App Service Environment のインプレース移行機能を使って移行がサポートされていることを検証する」を参照してください。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=validation"

エラーがない場合は、移行がサポートされているので、次の手順に進むことができます。

App Service Environment をサポートされているビルドバージョンにアップグレードするアップグレードを開始する必要がある場合は、次のコマンドを実行します。検証手順に失敗し、App Service Environment をアップグレードするように指示された場合にのみ、このコマンドを実行してください。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=PreMigrationUpgrade"

3.新しい App Service Environment v3 リソース用の IP アドレスを生成する

次のコマンドを実行して、新しい IP アドレスを作成します。この手順の所要時間は約 15 分です。この期間は、既存の App Service Environment をスケーリングしたり、変更を加えたりしないでください。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=premigration"

次のコマンドを実行して、このステップの状態を確認します。

az rest --method get --uri "${ASE_ID}?api-version=2021-02-01" --query properties.status

ステップが進行中の場合は、Migrating という状態が表示されます。 Ready という状態が表示されたら、次のコマンドを実行して、新しい IP を確認します。新しい IP がすぐに表示されない場合は、数分待ってから再度実行してみてください。

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2021-02-01"

Note

既知のバグにより、ELB App Service Environment の移行では、移行手順が完了すると、受信 IP アドレスが再び変更される場合があります。移行手順の完了後、新しい受信 IP アドレスで依存リソースをもう一度更新する準備をしてください。このバグは現在対応中で、できるだけ早く修正する予定です。この問題に関する質問や懸念事項がある場合、または移行プロセスに関するヘルプが必要な場合は、サポートケースを開いてください。

4. 依存リソースを新しい IP で更新する

新しい IP を使用して、リソースまたはネットワークコンポーネントをすべて更新し、移行の完了後に新しい環境が意図通りに動作するようにします。必要な更新を行うのはユーザーの責任です。

このステップで実行しておくべきこととして、App Service Environment v3 に移行する際の受信および送信ネットワークの依存関係の変更の確認があります。これらの変更には、Azure Load Balancer のポートの変更が含まれ、新しく使用されるポートは 80 です。この手順を完了するまで移行しないでください。

5. App Service Environment サブネットを委任する

App Service Environment v3 では、それが含まれているサブネットで、Microsoft.Web/hostingEnvironments の単一の委任が必要です。以前のバージョンでは、この委任は不要でした。サブネットが適切に委任されていることを確認し、必要に応じて移行前に委任を更新する必要があります。委任を更新するには、次のコマンドを実行するか、Azure portal でサブネットに移動します。

az network vnet subnet update --resource-group $VNET_RG --name <subnet-name> --vnet-name <vnet-name> --delegations Microsoft.Web/hostingEnvironments

6. 仮想ネットワークにロックがないことを確認する

仮想ネットワークロックによって、移行中のプラットフォーム操作がブロックされます。仮想ネットワークにロックがある場合は、移行する前にそれらのロックを削除する必要があります。必要に応じて、移行が完了した後にロックを追加し直すことができます。

ロックは、サブスクリプション、リソースグループ、リソースという 3 つの異なるスコープで存在する可能性があります。親スコープでロックを適用すると、そのスコープ内のすべてのリソースは同じロックを継承します。サブスクリプション、リソースグループ、またはリソースのスコープでロックが適用されている場合は、移行前にそれらを削除する必要があります。ロックとロックの継承の詳細については、「リソースをロックしてインフラストラクチャを保護する」を参照してください。

次のコマンドを使用して、仮想ネットワークに何らかのロックがあるかどうかを確認します。

az lock list --resource-group $VNET_RG --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

次のコマンドを使用して、既存のロックをすべて削除します。

az lock delete --resource-group $VNET_RG --name <lock-name> --resource <vnet-name> --resource-type Microsoft.Network/virtualNetworks

サブスクリプションまたはリソースグループにロックがあるかどうかを確認するための関連コマンドについては、「ロックに関する Azure CLI リファレンス」を参照してください。

7. 構成を準備する

既存の環境がゾーン冗長をサポートしているリージョン内にある場合は、新しい App Service Environment v3 リソースをゾーン冗長にすることができます。ゾーン冗長は、zoneRedundant プロパティを true に設定することで構成できます。

ゾーン冗長は省略可能な構成です。これを設定できるのは、新しい App Service Environment v3 リソースの作成時だけです。後でこれを削除することはできません。詳細については、「App Service Environment v3 構成を選択する」を参照してください。ゾーン冗長を構成しない場合は、zoneRedundant パラメーターを含めないでください。

既存の App Service Environment がカスタムドメインサフィックスを使用している場合は、移行プロセス時に新しい App Service Environment v3 リソースのカスタムドメインサフィックスを構成する必要があります。カスタムドメインサフィックスを構成せずに、現在これを使用している場合、移行は失敗します。また、カスタムドメインサフィックスが構成されていない環境への移行時にカスタムドメインサフィックスを追加しようとした場合にも、移行が失敗します。要件、ステップバイステップの手順、ベストプラクティスなど、App Service Environment v3 カスタムドメインサフィックスの詳細については、「App Service Environment のカスタムドメインサフィックス」を参照してください。

Note

カスタムドメインサフィックスを構成する場合は、Azure キーコンテナーに対するネットワークアクセス許可を追加するときに、キーコンテナーが、ステップ 3 で生成した App Service Environment の新しい送信 IP アドレスからのアクセスを許可するようにしてください。プライベートエンドポイントを使用してキーコンテナーにアクセスする場合は、プライベートアクセスを正しく構成していることを確かめてください。

移行にカスタムドメインサフィックスが含まれておらず、ゾーン冗長を有効にしていない場合は、移行に進むことができます。

これらの構成を設定するには、実際のシナリオに基づいて次の詳細を含む parameters.json という名前のファイルを作成します。この機能を移行に適用しない場合は、カスタムドメインサフィックスのプロパティは含めないでください。この構成は移行後に元に戻すことができないため、zoneRedundant プロパティの値には注意してください。既存の App Service Environment のバージョンに基づいて、kind プロパティの値を設定します。 kind プロパティで認められる値は、ASEV1 と ASEV2 です。

カスタムドメインサフィックスを使用せずに移行を行い、ゾーン冗長を有効にする場合は、次のコードを使用します。

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true
    }
}

カスタムドメインサフィックス構成にユーザー割り当てマネージド ID を使用し、ゾーン冗長を有効にする場合は、次のコードを使用します。

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "zoneRedundant": true,
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/00000000-0000-0000-0000-000000000000/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

カスタムドメインサフィックス構成にシステム割り当てマネージド ID を使用して、ゾーン冗長を有効に "しない" 場合は、次のコードを使用します。

{
    "type": "Microsoft.Web/hostingEnvironments",
    "name": "sample-ase-migration",
    "kind": "ASEV2",
    "location": "westcentralus",
    "properties": {
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

8.App Service Environment v3 に移行して状態を確認する

上記のすべての手順を完了したら、移行を開始できます。移行の影響を理解していることを確認してください。

このステップには、環境のサイズに応じて、v2 から v3 への移行の場合は 3 から 6 時間、v1 から v3 への移行の場合は最大 6 時間かかります。その間にアプリケーションのダウンタイムが約 1 時間あります。この手順では、既存の App Service Environment のスケーリング、デプロイ、変更はブロックされます。

ゾーン冗長を有効にしている、カスタムドメインサフィックスを構成している、あるいはその両方の場合は、次のコマンドに body パラメーターを含めます。これらの構成をいずれも移行に適用しない場合は、コマンドからこのパラメーターを削除できます。

az rest --method post --uri "${ASE_ID}/migrate?api-version=2021-02-01&phase=fullmigration" --body @parameters.json

移行の詳しい状態を確認するには、次のコマンドを実行します。状態の詳細については、移行状態の説明に関するセクションを参照してください。

最初のコマンドは、移行の操作 ID を取得します。 ID プロパティの値をコピーします。

az rest --method get --uri "${ASE_ID}/operations?api-version=2022-03-01"

次のコマンド中の操作 ID のプレースホルダーをコピーした値に置き換えます。このコマンドは、移行の詳細な状態を返します。このコマンドは、最新の状態を取得するために必要なだけ実行できます。

az rest --method get --uri "${ASE_ID}/operations/<operation-id>/details/default?api-version=2022-09-01"

Ready という状態が表示されたら、移行は完了しており、App Service Environment v3 リソースが使用できます。これで、新しい環境でアプリが実行されます。

次のコマンドを実行するか、Azure portal に移動して、新しい環境の詳細を取得します。

az appservice ase show --name $ASE_NAME --resource-group $ASE_RG

Note

既知のバグにより、ELB App Service Environment の移行では、移行手順が完了すると、受信 IP アドレスが変更される場合があります。 App Service Environment v3 の IP アドレスを確認し、IP 生成手順以降に変更があった場合は、必要な更新を行います。この問題に関する質問や懸念事項がある場合、または新しい IP の確認に関するヘルプが必要な場合は、サポートケースを開いてください。

1.移行がサポートされていることを検証する

Azure portal から、移行している App Service Environment の [移行] ページに移動します。 [移行] ページへは、App Service Environment の [概要] ページの上部にあるバナーを選択するか、左側のメニューの [移行] 項目を選択することで移動できます。

移行アクセスポイントを示すスクリーンショット。

[移行] ページでは、プラットフォームによって、お使いの App Service Environment で移行がサポートされているかどうかが検証されます。 [検証] を選択した後、検証を続行することを確認します。検証プロセスには数秒かかります。

移行の適格性を検証するためのボタンを示すスクリーンショット。

環境で移行がサポートされていない場合は、ページの上部にバナーが表示され、エラーメッセージと理由が示されます。移行が行えない場合に表示されるエラーメッセージの説明については、「トラブルシューティング」を参照してください。

現時点で App Service Environment の移行がサポートされていないか、環境が問題または中断状態の場合、移行機能を使用できません。お使いの環境でインプレース移行機能を使った移行がサポートされていない場合、またはインプレース移行機能を使用せずに App Service Environment v3 に移行する場合は、手動での移行オプションに関する記事を参照してください。

移行機能が App Service Environment をサポートしていないことを示すポータルメッセージの例を示すスクリーンショット。

App Service Environment をサポート対象のビルドバージョンにアップグレードするためにアップグレードを開始する必要がある場合は、アップグレードを開始するように求められます。環境のサイズによっては、8 から 12 時間以上かかる場合があります。 [アップグレード] を選んでアップグレードを開始します。アップグレードが完了したら、検証に合格し、移行機能を使用して移行を開始できます。

お使いの App Service Environment で移行がサポートされている場合は、プロセスの次のステップに進みます。 [移行] ページでは、移行を完了するための一連の手順のガイドが行われます。

プロセスで完了していない手順を表示するサンプル移行ページを示すスクリーンショット。

2.新しい App Service Environment v3 リソース用の IP アドレスを生成する

[新しい IP アドレスの取得] で、影響を理解していることを確認して [開始] ボタンを選択します。この手順の所要時間は約 15 分です。この間、既存の App Service Environment をスケーリングしたり、変更したりすることはできません。

3. 依存リソースを新しい IP で更新する

前のステップが終了すると、新しい App Service Environment v3 リソースの IP アドレスが表示されます。新しい IP を使用して、すべてのリソースとネットワークコンポーネントを更新し、移行の完了後に新しい環境が意図通りに動作するようにします。必要な更新を行うのはユーザーの責任です。

このステップで実行しておくべきこととして、App Service Environment v3 への移行に伴う受信および送信ネットワークの依存関係の変更の確認があります。これらの変更には、Azure Load Balancer のポートの変更が含まれ、新しく使用されるポートは 80 です。これらの更新が完了したことを確認するまで、次の手順に進まないでください。

事前移行中に生成されたサンプル IP を示すスクリーンショット。

4.App Service Environment サブネットを委任する

App Service Environment v3 では、それが含まれているサブネットに Microsoft.Web/hostingEnvironments の単一の委任があることが必要です。以前のバージョンでは、この委任は不要でした。サブネットが適切に委任されていることを確認し、必要に応じて移行前に委任を更新する必要があります。必要に応じてユーザーが確認および更新を行えるように、ポータルにはサブネットへのリンクが表示されます。

ポータルのサブネット委任を示すスクリーンショット。

5. インスタンスサイズの変更を確認する

ご利用の App Service プランは、Isolated から対応する Isolated v2 レベルに変換されます。たとえば、I2 は I2v2 に変換されます。 Isolated v2 レベルでは対応するインスタンスサイズごとのメモリと CPU が多いことから、移行後にアプリがオーバープロビジョニングの状態になる可能性があります。移行が完了した後に、必要に応じて環境をスケーリングする機会があります。詳細については、「価格の詳細」を参照してください。

移行時のインスタンスサイズの変更の確認を示すスクリーンショット。

6.仮想ネットワークにロックがないことを確認する

サブスクリプションまたはリソースグループにロックがあるかどうかを確認する方法の詳細については、「ロックの構成」を参照してください。

仮想ネットワークロックを見つけて削除する場所を示すスクリーンショット。

7. 構成を選ぶ

既存の環境がゾーン冗長をサポートしているリージョン内にある場合は、新しい App Service Environment v3 リソースをゾーン冗長にすることができます。ゾーン冗長は省略可能な構成です。これを設定できるのは、新しい App Service Environment v3 リソースの作成時だけです。後でこれを削除することはできません。詳細については、「App Service Environment v3 構成を選択する」を参照してください。

ゾーン冗長を構成したい場合は、[有効] チェックボックスを選択します。

サポートされているリージョンで App Service Environment のゾーン冗長を有効にするチェックボックスを示すスクリーンショット。

環境がゾーン冗長をサポートしていないリージョン内にある場合、チェックボックスは利用できません。ゾーン冗長 App Service Environment v3 が必要な場合は、手動移行オプションのいずれかを使用し、ゾーン冗長をサポートしているリージョンのいずれかにリソースを作成します。

既存の App Service Environment がカスタムドメインサフィックスを使用している場合は、新しい App Service Environment v3 リソースのカスタムドメインサフィックスを構成する必要があります。この状況に該当する場合は、カスタムドメインサフィックスの構成オプションが表示されます。必要な情報を提供するまで移行することはできません。

カスタムドメインサフィックスを使用したい場合で、現在それが構成されていない場合は、移行が完了した後に構成できます。要件、ステップバイステップの手順、ベストプラクティスなど、App Service Environment v3 カスタムドメインサフィックスの詳細については、「App Service Environment のカスタムドメインサフィックス」を参照してください。

Note

カスタムドメインサフィックスを構成する場合は、Azure キーコンテナーに対するネットワークアクセス許可を追加するときに、キーコンテナーが、ステップ 2 で生成した App Service Environment の新しい送信 IP アドレスからのアクセスを許可するようにしてください。プライベートエンドポイントを使用してキーコンテナーにアクセスする場合は、プライベートアクセスを正しく構成していることを確かめてください。

カスタムドメインのサフィックスを追加するためのリンクを示すスクリーンショット。

カスタムドメインサフィックスの詳細を追加すると、[移行] ボタンが利用可能になります。

構成の詳細が追加され、環境を移行する準備ができたことを示すスクリーンショット。

8. App Service Environment v3 に移行する

上記のすべての手順を完了したら、移行を開始できます。この間に何が起こるかを含め、移行の影響を理解していることを確認してください。

このステップには、環境のサイズに応じて、v2 から v3 への移行の場合は 3 から 6 時間、v1 から v3 への移行の場合は最大 6 時間かかります。この手順では、既存の App Service Environment のスケーリングと変更はブロックされます。

Note

まれなケースとして、移行を開始した後に、"App Service Environment v3 への移行が失敗しました" という通知がポータルに表示される場合があります。移行が進行している場合であっても、この通知がトリガーされる可能性のある既知のバグがあります。 App Service Environment のアクティビティログを調べて、このエラーメッセージの妥当性を確認してください。ほとんどの場合、ページを再度読み込むとイシューが解決し、エラーメッセージは表示されなくなります。エラーメッセージが引き続き表示される場合は、サポートにお問い合わせください。

移行の開始後に発生する可能性のあるエラー通知を示すスクリーンショット。

現時点では、移行の詳細な状態は、Azure CLI を使用している場合にのみ利用できます。詳細については、「App Service Environment v3 への移行の Azure CLI セクション」を参照してください。ポータルを使用して移行を行う場合でも、CLI を使用して移行の状態を確認できます。

移行が完了すると、App Service Environment v3 リソースが使用できるようになり、すべてのアプリが新しい環境で実行されます。環境のバージョンは、App Service Environment の「Configuration」ページで確認することができます。

Note

移行にカスタムドメインサフィックスが含まれていた場合、このドメインは App Service Environment v1/v2 のポータルの [概要] ページの [基本] セクションには表示されていましたが、App Service Environment v3 ではそこには表示されなくなります。 App Service Environment v3 では、代わりに、[カスタムドメインサフィックス] ページに移動して、カスタムドメインサフィックスが正しく構成されていることを確認します。構成が必要なくなった場合は、削除することも、以前に構成していない場合は構成することもできます。

App Service Environment v3 のカスタムドメインサフィックス構成のページを示すスクリーンショット。

Note

移行にカスタムドメインサフィックスが含まれている場合、既知のバグにより、移行が完了するとカスタムドメインサフィックス構成がデグレードされたと表示される場合があります。 App Service Environment は引き続き期待どおりに機能するはずです。デグレードした状態は 6 - 8 時間以内に解決するはずです。 8 時間後に構成がデグレードしている場合、またはカスタムドメインサフィックスが機能していない場合は、サポートにお問い合わせください。

デグレードされたカスタムドメインサフィックス構成のサンプルのスクリーンショット。

次のステップ

App Service Environment v3 リソースを使用する

App Service Environment v3 のネットワーク

カスタムドメインサフィックス

次の方法で共有

インプレース移行機能を使って App Service Environment v1 と v2 を App Service Environment v3 に移行する

前提条件

1. App Service Environment ID を取得する

2.移行がサポートされていることを検証する

3.新しい App Service Environment v3 リソース用の IP アドレスを生成する

4. 依存リソースを新しい IP で更新する

5. App Service Environment サブネットを委任する

6. 仮想ネットワークにロックがないことを確認する

7. 構成を準備する

8.App Service Environment v3 に移行して状態を確認する

1.移行がサポートされていることを検証する

2.新しい App Service Environment v3 リソース用の IP アドレスを生成する

3. 依存リソースを新しい IP で更新する

4.App Service Environment サブネットを委任する

5. インスタンスサイズの変更を確認する

6.仮想ネットワークにロックがないことを確認する

7. 構成を選ぶ

8. App Service Environment v3 に移行する

次のステップ

フィードバック

その他のリソース

次の方法で共有

インプレース移行機能を使って App Service Environment v1 と v2 を App Service Environment v3 に移行する

前提条件

1. App Service Environment ID を取得する

2.移行がサポートされていることを検証する

3.新しい App Service Environment v3 リソース用の IP アドレスを生成する

4. 依存リソースを新しい IP で更新する

5. App Service Environment サブネットを委任する

6. 仮想ネットワークにロックがないことを確認する

7. 構成を準備する

8.App Service Environment v3 に移行して状態を確認する

1.移行がサポートされていることを検証する

2.新しい App Service Environment v3 リソース用の IP アドレスを生成する

3. 依存リソースを新しい IP で更新する

4.App Service Environment サブネットを委任する

5. インスタンス サイズの変更を確認する

6.仮想ネットワークにロックがないことを確認する

7. 構成を選ぶ

8. App Service Environment v3 に移行する

次のステップ

フィードバック

その他のリソース

5. インスタンスサイズの変更を確認する