サイドバイサイド移行機能を使用して App Service Environment v2 を App Service Environment v3 に移行する

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

Note

この記事で説明する移行機能は、App Service Environment v2 から App Service Environment v3 へのサイドバイサイド (異なるサブネット) の自動移行に使用されます。

インプレース移行機能の情報をお探しの場合は、「インプレース移行機能を使用した App Service Environment v3 への移行」を参照してください。手動移行オプションの情報をお探しの場合は、手動移行のオプションに関する記事をご覧ください。適切な移行オプションの決定については、「移行パスのデシジョンツリー」をご覧ください。 App Service Environment v3 の詳細については、App Service Environment v3 の概要に関する記事を参照してください。

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

重要

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

前提条件

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

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

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

App Service Environment v3 は仮想ネットワーク内の別のサブネット内に作成されるため、App Service Environment v3 のサブネット要件を満たすサブネットがお使いの仮想ネットワーク内で利用できることを確認する必要があります。既存の App Service Environment があるサブネットと通信できるサブネットを選ぶ必要があります。 2 つのサブネット間の通信をブロックするものがないことを確認します。利用できるサブネットがない場合は、移行する前に作成する必要があります。新しいサブネットを作成するには、仮想ネットワークのアドレス空間の拡大が必要な場合があります。詳しくは、仮想ネットワークとサブネットの作成に関する記事をご覧ください。

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

Azure REST API を呼び出すので、以下で説明する手順を書かれているとおりの順序で行ってください。これらの API 呼び出しを行うには、Azure CLI を使用することをお勧めします。その他の方法に関する情報については、「Azure REST API リファレンス」を参照してください。

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

Note

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

重要

移行時に、Azure portal に App Service Environment とアプリについて誤った情報が表示される場合があります。 Azure portal の移行エクスペリエンスではサイドバイサイド移行機能を使用できないため、アクセスしないでください。 Azure CLI を使用して移行の状態を確認することをお勧めします。移行またはアプリの状態についてご質問がある場合は、サポートにお問い合わせください。

1. 新しい App Service Environment v3 用のサブネットを選択する

App Service Environment v3 内で、App Service Environment v3 のサブネット要件を満たすサブネットを選びます。選んだサブネットの名前を後でわかるようにしておきます。このサブネットは、既存の App Service Environment が含まれるサブネットとは異なっている必要があります。

2. 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)

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

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

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=Validation&api-version=2022-03-01"

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

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

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigrationUpgrade&api-version=2022-03-01"

4. 新しい App Service Environment v3 用のアウトバウンド IP アドレスを生成する

お使いのリージョンとゾーン冗長の選択に関する次の詳細を含む、zoneredundancy.json という名前のファイルを作成します。

{
    "location":"<region>",    
    "Properties": {
        "zoneRedundant": "<true/false>"
    }
}

既存の環境がゾーン冗長をサポートしているリージョンにある場合は、新しい App Service Environment v3 ゾーン冗長を作成できます。ゾーン冗長は、zoneRedundant プロパティを true に設定して構成できます。ゾーン冗長は省略可能な構成です。この構成は、新しい App Service Environment v3 の作成時にのみ設定でき、後で削除することはできません。

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

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=PreMigration&api-version=2022-03-01" --body @zoneredundancy.json

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

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

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

az rest --method get --uri "${ASE_ID}/configurations/networking?api-version=2022-03-01" --query properties.windowsOutboundIpAddresses

5.依存リソースを新しいアウトバウンド IP で更新する

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

6.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

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

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

ロックは、サブスクリプション、リソースグループ、リソースという 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 リファレンス」を参照してください。

8.構成を準備する

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

Note

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

前に選んだサブネットの識別など、これらの構成を設定するには、実際のシナリオに基づく次の詳細を指定して、parameters.json という名前のファイルを作成します。新しい App Service Environment v3 用に選んだ新しいサブネットを必ず使ってください。この機能を移行に適用しない場合は、カスタムドメインサフィックスのプロパティは含めないでください。 zoneRedundant プロパティの値に注意し、アウトバウンド IP 生成ステップで使ったものと同じ値に設定します。 ゾーン冗長には、アウトバウンド IP 生成ステップで使ったものと同じ値を使う必要があります。

カスタムドメインサフィックスなしで移行する場合は、次のコードを使います。

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>"
    }
}

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

{
    "Properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourcegroups/asev3-migration/providers/Microsoft.ManagedIdentity/userAssignedIdentities/ase-managed-identity"
        }
    }
}

カスタムドメインサフィックスの構成にシステム割り当てマネージド ID を使っている場合は、次のコードを使います。

{
    "properties": {
        "VirtualNetwork": {
            "Id": "/subscriptions/<subscription-id>/resourceGroups/<resource-group-name>/providers/Microsoft.Network/virtualNetworks/<virtual-network-name>/subnets/<subnet-name>"
        },
        "zoneRedundant": "<true/false>",
        "customDnsSuffixConfiguration": {
            "dnsSuffix": "internal.contoso.com",
            "certificateUrl": "https://contoso.vault.azure.net/secrets/myCertificate",
            "keyVaultReferenceIdentity": "SystemAssigned"
        }
    }
}

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

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

このステップには 3 から 6 時間かかります。その間に、アプリケーションのダウンタイムはありません。この手順では、既存の App Service Environment のスケーリング、デプロイ、変更はブロックされます。

次のコマンドを実行して移行を始めます。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=HybridDeployment&api-version=2022-03-01" --body @parameters.json

移行の状態を確認するには、次のコマンドを実行します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

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

次のコマンドを実行して、新しい環境の詳細を取得します。

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

重要

移行時や MigrationPendingDnsChange ステップ時に、Azure portal に App Service Environment とアプリについて誤った情報が表示されます。 Azure CLI を使用して移行の状態を確認します。移行またはアプリの状態についてご質問がある場合は、サポートにお問い合わせください。

Note

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

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

10。新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

移行プロセスのこの段階では、2 つの App Service 環境が存在しています。アプリは両方の環境で実行されています。新しい App Service Environment v3 用の新しい IP インバウンドアドレスを使うように、依存リソースを更新する必要があります。内部に接続している (ILB) App Service Environment の場合は、新しいインバウンド IP アドレスを指すようにプライベート DNS ゾーンを更新する必要があります。

新しい App Service Environment v3 の新しい受信 IP アドレスを取得するには、お使いの App Service Environment ロードバランサーの種類に対応する、次のコマンドを実行します。必要な更新を行うのはユーザーの責任です。

ILB App Service Environment の場合、次のコマンドを実行してプライベート受信 IP アドレスを取得します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.internalInboundIpAddresses

ELB App Service Environment の場合、次のコマンドを実行してパブリック受信 IP アドレスを取得します。

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.networkingConfiguration.externalInboundIpAddresses

11.顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

このステップでは、新しい App Service Environment v3 をテストして検証できます。既定では、トラフィックは App Service Environment v2 のフロントエンドに送信されます。 ILB App Service Environment v3 を使用している場合、プライベート DNS ゾーンを新しい受信 IP アドレスで更新することで、App Service Environment v3 フロントエンドをテストできます。 ELB App Service Environment v3 を使用している場合、テストのプロセスは特定のネットワーク構成に依存します。 ELB 環境をテストする簡単な方法の 1 つは、新しい App Service Environment v3 の受信 IP アドレスを使用するようにホストファイルを更新することです。個々のアプリにカスタムドメインが割り当てられている場合は、その DNS を更新して新しい受信 IP をポイントするようにすることもできます。この変更をテストすることで、移行の最終段階で古い App Service Environment が削除される前に、App Service Environment v3 を完全に検証することができます。問題なくアプリにアクセスできるということは、移行を実行する準備ができていることを意味します。

アプリが期待どおりに動作することを確認したら、次のコマンドを実行して、顧客のトラフィックを新しい App Service Environment v3 にリダイレクトできます。このコマンドは、古い環境も削除します。この手順を完了するには 14 日かかります。この手順を 14 日以内に完了しなかった場合、移行は自動的に App Service Environment v2 に戻されます。この手順を完了するために 14 日以上必要な場合、サポートにお問い合わせください。

問題が見つかった場合、またはこの時点で移行をそれ以上続けないことにした場合は、サポートに連絡して移行を元に戻してください。移行を元に戻す必要がある場合は、DNS 変更コマンドを実行しないでください。詳しくは、移行を元に戻す方法に関する記事をご覧ください。

az rest --method post --uri "${ASE_ID}/NoDowntimeMigrate?phase=DnsChange&api-version=2022-03-01"

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

az rest --method get --uri "${ASE_ID}?api-version=2022-03-01" --query properties.subStatus

この手順では、CompletingMigration の状態が表示されます。 MigrationCompleted の状態になると、トラフィックリダイレクトの手順が実行されて移行が完了します。

次のステップ

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

App Service Environment v3 のネットワーク

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

次の方法で共有

サイドバイサイド移行機能を使用して App Service Environment v2 を App Service Environment v3 に移行する

前提条件

1. 新しい App Service Environment v3 用のサブネットを選択する

2. App Service Environment ID を取得する

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

4. 新しい App Service Environment v3 用のアウトバウンド IP アドレスを生成する

5.依存リソースを新しいアウトバウンド IP で更新する

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

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

8.構成を準備する

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

10。新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

11.顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

次のステップ

フィードバック

その他のリソース

次の方法で共有

サイド バイ サイド移行機能を使用して App Service Environment v2 を App Service Environment v3 に移行する

前提条件

1. 新しい App Service Environment v3 用のサブネットを選択する

2. App Service Environment ID を取得する

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

4. 新しい App Service Environment v3 用のアウトバウンド IP アドレスを生成する

5.依存リソースを新しいアウトバウンド IP で更新する

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

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

8.構成を準備する

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

10。新しい App Service Environment v3 のインバウンド IP アドレスを取得し、依存リソースを更新する

11.顧客トラフィックのリダイレクト、App Service Environment v3 の検証、移行の完了

次のステップ

フィードバック

その他のリソース

サイドバイサイド移行機能を使用して App Service Environment v2 を App Service Environment v3 に移行する