インプレース移行機能を使用した App Service Environment v3 への移行

[アーティクル]
07/24/2024

Note

この記事で説明する移行機能は、App Service Environment v1 と v2 から App Service Environment v3 へのインプレース (同じサブネット) の自動移行に使用されます。 30 日の猶予期間を要求していない場合は、猶予期間の概要に関する記事を確認した後、Azure portal にアクセスし、各 App Service Environment の [移行] ブレードに移動して、猶予期間を要求してください。

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

App Service では App Service Environment v1 および v2 の App Service Environment v3 への移行を自動化できます。さまざまな移行オプションがあります。移行パスのデシジョンツリーを確認して、自分のユースケースに最適なオプションを決定します。 App Service Environment v3 には、以前のバージョンとは異なる特長と機能が備わっています。予期しないアプリケーションの問題が発生するリスクを軽減するため、移行前に App Service Environment v3 でサポートされている機能を確認してください。

インプレース移行機能は、同じサブネット内の既存の App Service Environment をアップグレードすることで、App Service Environment v3 への移行を自動化します。この移行オプションは、ネットワーク構成への変更を最小限に抑えて App Service Environment v3 に移行したいお客様に最適です。また、約 1 時間のアプリケーションのダウンタイムにも対応できる必要があります。ダウンタイムをサポートできない場合は、サイドマイグレーション機能または手動移行オプションに関する情報を参照してください。

重要

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

サポートされるシナリオ

現時点では、次のリージョンでの App Service Environment v3 への移行はインプレース移行機能でサポートされていません。

21Vianet が運用する Microsoft Azure

中国東部 2
中国北部 2

次の App Service Environment 構成は、インプレース移行機能を使用して移行できます。この表は、既存の App Service Environment に基づいてインプレース移行機能を使用する際の App Service Environment v3 構成を示しています。サポートされているすべての App Service 環境は、環境がゾーン冗長性をサポートするリージョンにある限り、インプレース移行機能を使用してゾーン冗長 App Service Environment v3 に移行できます。移行プロセス中にゾーンの冗長性を構成できます。

構成	App Service Environment v3 構成
App Service Environment v2 で内部ロードバランサー (ILB)	ILB App Service Environment v3
外部 (パブリック IP を使用した ELB/インターネット接続) App Service Environment v2	ELB App Service Environment v3
カスタムドメインサフィックスが設定されている ILB App Service Environment v2	カスタムドメインサフィックスが設定されている ILB App Service Environment v3
ILB App Service Environment v1	ILB App Service Environment v3
ELB App Service Environment v1	ELB App Service Environment v3
カスタムドメインサフィックスが設定されている ILB App Service Environment v1	カスタムドメインサフィックスが設定されている ILB App Service Environment v3
ゾーン固定 App Service Environment v2	オプションのゾーン冗長構成を使用した App Service Environment v3

新しい App Service Environment v3 でカスタムドメインサフィックスを使用する必要があり、現在使用していない場合は、移行が完了したらいつでもカスタムドメインサフィックスを構成できます。詳細については、「App Service Environment のカスタムドメインサフィックスを構成する」を参照してください。

Azure portal で App Service Environment に移動し、左側の [設定] の下にある [構成] を選択すると、App Service Environment のバージョンを確認できます。また、Azure Resource Explorer を使用して、App Service Environment の kind プロパティの値を確認できます。

インプレース移行機能の制限

インプレース移行機能を使用する場合の制限は次のとおりです。

新しい App Service Environment v3 は、古い環境に使用されていた既存のサブネット内になります。
App Service Environment が配置されているリージョンを変更することはできません。
ELB App Service Environment を、ILB App Service Environment v3 に移行することはできません。またその逆もできません。
既存の App Service Environment でカスタムドメインサフィックスを使用している場合は、移行プロセス中に App Service Environment v3 のカスタムドメインサフィックスを構成する必要があります。
- カスタムドメインサフィックスを使用しない場合は、移行が完了すると削除できます。

App Service Environment v3 は、現在の App Service Environment v1 または v2 で使用できる次の機能をサポートしていません。

アプリに IP ベースの TLS/SSL バインドを構成する。
仮想ネットワーク内の構成済みのカスタム DNS サーバーで特定の名前を解決できない場合、App Service Environment v3 は Azure DNS にフォールバックされません。この動作が必要な場合は、パブリック DNS へのフォワーダーがあることを確認するか、カスタム DNS サーバーの一覧に Azure DNS を含めます。

インプレース移行機能では、次のシナリオがサポートされていません。ご使用の App Service Environment がこれらカテゴリの 1 つに該当する場合は、手動移行オプションに関するページを参照してください。

クラシック仮想ネットワークの App Service Environment v1
IP SSL アドレスが設定されている ELB App Service Environment v2
IP SSL アドレスが設定されている ELB App Service Environment v1
文字制限を満たしていない名前を持つ App Service Environment。ドメインサフィックスを含む名前全体を、64 文字以下にする必要があります。たとえば、ILB の my-ase-name.appserviceenvironment.net と ELB の my-ase-name.p.azurewebsites.net は 64 文字以内にする必要があります。文字制限を満たしていない場合は、手動で移行する必要があります。 App Service Environment 名の具体的な文字制限は次のとおりです。
- ILB App Service Environment の名前の文字制限: 36 文字
- ELB App Service Environment の名前の文字制限: 42 文字

App Service プラットフォームで、インプレース移行のサポートを確認するために、App Service Environment を見直します。シナリオがすべての検証チェックに合格しない場合、現時点では、インプレース移行機能を使用して移行することはできません。環境が異常な状態や中断状態にある場合、必要な更新を行うまで移行することができません。

注意

App Service Environment v3 では IP SSL はサポートされていません。 IP SSL を使用する場合は、App Service Environment v3 に移行する前に、すべての IP SSL バインディングを削除する必要があります。すべての IP SSL バインディングが削除されると、移行機能によって環境がサポートされます。

トラブルシューティング

ご使用の App Service Environment が検証検査に合格しないか、正しくない順序で移行ステップを試みた場合、次のいずれかのエラーメッセージが表示される可能性があります。

エラーメッセージ	説明	推奨
移行は ARM VNET の ASE でのみ呼び出すことができます。この ASE はクラシック VNET 内にあります。	クラシック VNet 内の App Service Environment は、インプレース移行機能を使用して移行することはできません。	手動移行のオプションのいずれかを使用して移行します。
ASEv3 の移行はまだ準備ができていません。	基になるインフラストラクチャは、App Service Environment v3 をサポートする準備ができていません。	すぐに移行する場合は、手動移行のオプションのいずれかを使用して移行します。それ以外の場合は、ご利用のリージョンでインプレース移行機能が使用できるようになるまで待ちます。
この ASE で移行を呼び出すことはできません。移行に関するサポートにお問い合わせください。	この App Service Environment を移行するには、サポートに依頼する必要があります。この問題は、この環境で使用するカスタム設定が原因である可能性があります。	サポートケースを開き、サポートに問い合わせて問題を解決します。
いずれかのサイトで IP SSL が有効になっている場合に、移行を呼び出すことができません。	IP SSL が有効になっているサイトが存在する App Service Environment は、移行機能を使って移行できません。	App Service Environment 内のすべてのアプリから IP SSL を削除して、移行機能を有効にします。
IP アドレスを生成する前に、完全な移行を呼び出すことができません。	このエラーは、移行前の手順を完了する前に移行しようとすると表示されます。	移行を試みる前に、移行前の手順がすべて完了していることを確認してください。移行に関する詳細なガイドを参照してください。
この ASE については、ASEv3 への移行が許可されていません。	移行機能を使用して移行することができません。	手動移行のオプションのいずれかを使用して移行します。
サブスクリプションに App Service Environment が多すぎます。さらに作成する場合は、事前に一部を削除してください。	App Service Environment のサブスクリプションのクォータがいっぱいになりました。	不要な環境を削除するか、サポートに連絡してオプションを確認します。
`<ZoneRedundant><DedicatedHosts><ASEv3/ASE>` はこの場所では利用できません。	このエラーは、App Service Environment を移行しようとしているリージョンで、要求した機能の 1 つがサポートされていない場合に表示されます。	すぐに移行する場合は、手動移行のオプションのいずれかを使用して移行します。それ以外の場合は、移行機能でこの App Service Environment 構成がサポートされるまで待ちます。
アクティブなアップグレードが完了するまで、この ASE で移行を呼び出すことはできません。	プラットフォームのアップグレード中に App Service Environment を移行することはできません。 Azure portal からアップグレードの優先順位を設定できます。アップグレードには、App Service Environment のサイズ (インスタンス/コアの数) に応じて 8 から 12 時間、またはそれ以上かかります。	アップグレードが完了するまで待ってから移行します。
進行中の App Service Environment 管理操作。	App Service Environment は管理操作中です。これらの操作には、デプロイやアップグレードなどのアクティビティを含めることができます。移行は、これらの操作が完了するまでブロックされます。	これらの操作を完了したら、移行できます。
移行は、このサブスクリプションでは利用できません。	この App Service Environment を移行するには、サポートに依頼する必要があります。	サポートケースを開き、サポートに問い合わせて問題を解決します。
InteralLoadBalancingMode は現在サポートされていません。	現時点では、InternalLoadBalancingMode が特定の値に設定された App Service Environment は、移行機能を使用して移行することができません。 InternalLoadBalancingMode は、Microsoft チームが手動で変更する必要があります。	サポートケースを開き、サポートに問い合わせて問題を解決します。移行を許可するために InternalLoadBalancingMode の更新をリクエストします。

インプレース移行機能を使用した移行プロセスの概要

インプレース移行は一連の手順で構成されており、これらの手順は順序に従って実行する必要があります。キーポイントは、ステップのサブセットで示されます。これらの手順で何が起きるのか、環境とアプリにどのような影響があるのかを理解することが重要です。次の情報を確認し、移行の準備ができたら、ステップバイステップガイドの説明に従います。

App Service Environment のインプレース移行機能を使って移行がサポートされていることを検証する

プラットフォームにより、インプレース移行機能を使って App Service Environment を移行できることが検証されます。 App Service Environment がすべての検証チェックに合格しない場合、現時点では、インプレース移行機能を使って移行することはできません。検証失敗の考えられる原因の詳細については、トラブルシューティングのセクションを参照してください。環境が異常な状態や中断状態にある場合、必要な更新を行うまで移行することができません。インプレース移行機能を使って移行できない場合は、手動移行オプションに関する記事を参照してください。

この検証では、App Service Environment が移行に必要な最小限のビルド上にあるかどうかも確認されます。このビルドは、プラットフォームの定期的なアップグレード/メンテナンスサイクルでデプロイされる標準ビルドよりも新しい場合があります。最新のバグ修正と機能強化を確実に使用できるように、最小限のビルドは定期的に更新されます。 App Service Environment が最小限のビルド上にない場合は、手動でアップグレードを開始する必要があります。このアップグレードは App Service Environment には影響しない標準プロセスですが、アップグレードの進行中に App Service Environment をスケーリングすることや変更することはできません。アップグレードが完了するまでは移行できません。アップグレードが完了するまでに 8 時間から 12 時間、環境の規模によってはそれ以上かかる場合があります。移行に特定の期間を計画する場合は、計画した移行時間の 24 時間から 48 時間前に検証チェックを実行して、アップグレードが必要な場合に時間を確保する必要があります。

新しい App Service Environment v3 用の IP アドレスを生成する

プラットフォームによって、新しい受信 IP (ELB App Service Environment を移行する場合) と新しい送信 IP アドレスが作成されます。これらの IP が作成されている間、既存の App Service Environment でのアクティビティは中断されませんが、既存の環境のスケーリングや変更はできません。このプロセスの完了には約 15 分かかります。

完了すると、App Service Environment v3 で今後使用される新しい IP が提供されます。新しい IP は既存の環境には影響しません。既存の環境で使用されている IP は、移行ステップで既存の環境がシャットダウンされるまで、引き続き使用されます。

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

新しい IP が作成されると、インターネットパブリックアドレスへの新しい既定の送信が作成されます。移行の準備として、外部ファイアウォール、DNS ルーティング、ネットワークセキュリティグループ、およびこれらの IP に依存するその他のリソースを調整できます。 ELB App Service Environment の場合、新しい受信 IP アドレスも作成されます。これは、Traffic Manager や Azure Front Door などのサービスを使用して新しいエンドポイントを設定するときに使用できます。新しい App Service Environment v3 に関連付けられている IP アドレスの変更の影響を受けるリソースをすべて更新する作業は、ユーザーが行う必要があります。必要な更新がすべて完了するまでは、次のステップに進まないでください。この手順は、App Service Environment v3 に移行する際にAzure Load Balancer のポート変更でポート 80 を使用するようになった場合などに、インバウンドおよびアウトバウンドネットワークの依存関係の変更を確認するのにもお勧めです。

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

App Service Environment v3 では、それが含まれているサブネットで、Microsoft.Web/hostingEnvironments の単一の委任が必要です。 App Service Environment のサブネットが委任されていない、または別のリソースに委任されている場合、移行は成功しません。

インスタンスサイズの変更の確認

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

リソースにロックがないことを確認する

仮想ネットワークロックによって、移行中のプラットフォーム操作がブロックされます。仮想ネットワークにロックがある場合は、移行する前にそれらのロックを削除する必要があります。移行が完了したら、必要に応じてロックを再度追加することができます。ロックは、サブスクリプション、リソースグループ、リソースの 3 つの異なるスコープに存在することができます。親スコープでロックを適用すると、そのスコープ内のすべてのリソースは同じロックを継承します。サブスクリプション、リソースグループ、またはリソースのスコープでロックが適用されている場合は、移行前に削除する必要があります。ロックとロックの継承の詳細については、「リソースをロックしてインフラストラクチャを保護する」を参照してください。

移行をブロックする Azure ポリシーがないことを確認する

Azure Policy を使用して、リソースの作成と特定のプリンシパルへの変更を拒否できます。 App Service Environment の作成またはサブネットの変更をブロックするポリシーがある場合は、移行する前に削除する必要があります。移行が完了したら、必要に応じてポリシーを再度追加できます。 Azure Policy の詳細については、Azure Policy の概要に関するページを参照してください。

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 でカスタムドメインサフィックスを使用している場合は、新しい App Service Environment v3 用にカスタムドメインサフィックスを構成するように求められます。カスタムドメイン名、マネージド ID、証明書を提供する必要があります。要件、詳細な手順、ベストプラクティスなど、App Service Environment v3 カスタムドメインサフィックスの詳細については、「App Service Environment のカスタムドメインサフィックスを構成する」を参照してください。使用しなくなった場合でも、新しい環境のカスタムドメインサフィックスを構成する必要があります。移行が完了すると、必要に応じてカスタムドメインサフィックス構成を削除できます。

移行にカスタムドメインサフィックスを含めた場合、App Service Environment v3 では、App Service Environment v1 または v2 の場合と同様に、カスタムドメインは、ポータルの [概要] ページの [要点] セクションに表示されません。代わりに、App Service Environment v3 の場合は、[カスタムドメインサフィックス] ページに移動して、カスタムドメインサフィックスが正しく構成されていることを確認できます。また、App Service Environment v2 では、カスタムドメインサフィックスがある場合、既定のホスト名にはカスタムドメインサフィックスが含まれており、APP-NAME.internal.contoso.com 形式になります。 App Service Environment v3 では、既定のホスト名は常に既定のドメインサフィックスを使用し、APP-NAME.ASE-NAME.appserviceenvironment.net の形式になります。この違いは、App Service Environment v3 では、ユーザーがカスタムドメインサフィックスを追加したときに既定のドメインサフィックスが維持されるためです。 App Service Environment v2 では、ドメインサフィックスは 1 つだけです。

App Service Environment v3 への移行

前の手順を完了後、できるだけ早く移行を続行する必要があります。

重要

移行中はスケーリングがブロックされるため、移行を開始する前に環境を目的のサイズにスケーリングする必要があります。自動スケーリングを有効にしている場合に、移行の開始前にスケーリングイベントが発生した場合は、スケーリングイベントが完了するまで待って移行を開始する必要があります。この問題を回避するには、移行を開始する前に自動スケーリングを無効にする必要があります。移行後に環境をスケーリングする必要がある場合は、移行が完了したらそれを行うことができます。

App Service Environment v2 から v3 への移行には、3 - 6 時間のサービス期間が必要です。 v1 から v3 への移行の環境サイズに応じて、最大 6 時間のサービス期間が必要です。まれなケースですが、サービスチームによる手動の介入が必要な場合は、サービス時間帯が延長される可能性があります。移行中は、スケーリングと環境の構成がブロックされ、次のイベントが発生します。

既存の App Service Environment がシャットダウンされ、新しい App Service Environment v3 に置き換えられます。
App Service Environment 内のすべての App Service プランが、Isolated から Isolated v2 レベルに変換されます。
App Service Environment 上のアプリがすべて一時的にダウンする。 この期間中に、約 1 時間のダウンタイムを想定しておく必要があります。
- ダウンタイムをサポートできない場合は、サイドバイサイドの移行機能または移行の代替手段に関する情報を参照してください。
App Service Environment で使用されているパブリックアドレスは、IP 生成手順の際に生成された IP に変更されます。

移行プロセス中は、次の状態が表示されます。

Status	説明
移行を検証し、準備しています。	プラットフォームが、移行のサポートを検証し、必要な検査を実行しています。
App Service Environment v3 インフラストラクチャをデプロイしています。	App Service Environment v3 インフラストラクチャをプロビジョニングしています。
インフラストラクチャの完了を待機しています。	プラットフォームが、新しい移行を検証し、必要な検査を実行しています。
ネットワークを設定しています。移行のダウンタイム期間が開始されました。アプリケーションにはアクセスできません。	プラットフォームが、古いインフラストラクチャを削除し、すべてのアプリを新しい App Service Environment v3 に移行しています。アプリはダウンしていて、トラフィックを受け入れていません。
移行後の検証を実行しています。	プラットフォームが、移行が成功したことを確認するために必要な検査を実行しています。
移行の最終処理を行っています。	プラットフォームが移行の最終処理を行っています。

IP 生成手順と同様に、このプロセスの実行中も、App Service Environment のスケーリングと変更はできず、アプリのデプロイもできません。移行が完了すると、古い App Service Environment にあったアプリは、App Service Environment v3 で実行されます。

インプレース移行機能を使用する

前提条件

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 が移行用にサポートされているビルドバージョンにあることを検証します。

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"

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

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

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. 仮想ネットワークにロックがないことを確認する

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

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

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 がカスタムドメインサフィックスを使用している場合は、移行プロセス時に新しい 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

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

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

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

"インプレース" 移行オプションを選択して、インプレース移行プロセスを開始します。サイドバイサイド移行のオプションを選択すると、その移行プロセスのドキュメントへ移動します。インプレース移行機能を使用したい場合は、サイドバイサイド移行オプションを選択しないでください。

移行オプションを含むテーブルを示すスクリーンショット。

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

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

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

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

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

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

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

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

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

[確認] ボタンを選択して、移行の一環として、App Service プランが Isolated から対応する Isolated v2 レベルに変換されていることを確認します。

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

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

仮想ネットワークロックによって、移行中のプラットフォーム操作がブロックされます。仮想ネットワークにロックがある場合は、移行する前にそれらのロックを削除する必要があります。サブスクリプションまたはリソースグループにロックがあるかどうかを確認する方法の詳細については、「ロックの構成」を参照してください。

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

7. 構成を選ぶ

既存の環境がゾーン冗長をサポートしているリージョン内にある場合は、新しい 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」ページで確認することができます。

移行にカスタムドメインサフィックスが含まれていた場合、このドメインは 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 の移行は無料です。インプレース移行機能を使用すると、移行プロセス中にシャットダウンするとすぐに、以前の App Service Environment の課金が停止します。デプロイされるとすぐに、新しい App Service Environment v3 に対して課金が開始されます。 App Service Environment v3 の価格の詳細については、価格の詳細に関するセクションを参照してください。

以前のバージョンから App Service Environment v3 に移行する場合、毎月のコストを削減できる可能性があるシナリオを検討する必要があります。コストをさらに削減するために、予約と節約計画を検討してください。コスト削減の機会については、「App Service Environment v3 へのアップグレード後のコスト削減の機会」を参照してください。

Note

App Service プランが Isolated から Isolated v2 に変換されたため、Isolated v2 レベルでは対応するインスタンスサイズに基づきメモリと CPU が多くなることから、移行後にアプリがオーバープロビジョニングされる可能性があります。移行完了後に環境をスケーリングできる機会があります。詳細については、SKU の詳細に関するセクションを参照してください。

App Service プランをスケールダウンする

App Service Environment v3 で使用できる App Service プラン SKU は、Isolated v2 (Iv2) レベルで実行されます。コアの数と RAM の量は、Isolated レベルと比較すると、対応するレベルごとに実質的に 2 倍になります。移行すると、App Service プランは対応するレベルに変換されます。たとえば、I2 インスタンスは I2v2 に変換されます。 I2 には 2 つのコアと 7 GB RAM が搭載されていますが、I2v2 には 4 つのコアと 16 GB の RAM が搭載されています。容量要件が変わらないと予想される場合は、オーバープロビジョニング状態になり、使用していないコンピューティングとメモリに対して料金が支払うことになります。このシナリオでは、I2v2 インスタンスを I1v2 にスケールダウンし、結果的に、以前と同じようなコア数と RAM にできます。

よく寄せられる質問

使用している App Service Environment の移行が現在サポートされていない場合は、どうしたらよいですか?
現時点では、インプレース移行機能を使用して移行することはできません。ご使用の環境がサポートされていない場合でも、すぐに移行したい場合には、手動移行オプションに関するページを参照してください。
自分に適した移行オプションを選択するにはどうすればよいですか?
移行パスのデシジョンツリーを確認して、自分のユースケースに最適なオプションを決定します。
インプレース移行機能を使用する必要があるかどうかを確認するにはどうすればよいですか?
インプレース移行機能は、ネットワーク構成に最小限の変更を加えて App Service Environment v3 に移行したいと考えていて、1 時間程度のアプリケーションダウンタイムをサポートできるお客様に最適です。ダウンタイムをサポートできない場合は、サイドマイグレーション機能または手動移行オプションに関する情報を参照してください。インプレース移行機能は、既存の環境と同じサブネットに App Service Environment v3 を作成し、同じネットワークインフラストラクチャを使用します。これらの特定の IP に依存関係がある場合は、受信および送信 IP アドレスの変更を考慮することが必要な場合があります。
移行中にダウンタイムが発生しますか?
はい。移行手順の間は 3~6 時間のサービス時間帯中に約 1 時間のダウンタイムが予想されるため、それに応じて計画しておいてください。インプレース移行機能を使用して移行中にトラフィックを転送できる別の App Service Environment がある場合は、アプリケーションのダウンタイムをなくすことができます。別の App Service Environment がなく、ダウンタイムをサポートできない場合は、サイドバイサイド移行機能または手動移行オプションに関する情報を参照してください。
移行の完了後に新しい App Service Environment でアプリを実行するために、アプリに何らかの操作を行う必要がありますか?
いいえ。古い環境で実行されていたアプリはすべて、新しい環境に自動的に移行され、以前と同様に実行されます。ユーザー入力は必要ありません。
App Service Environment にカスタムドメインサフィックスが設定されている場合はどうなりますか?
インプレース移行機能では、この移行シナリオがサポートされています。
App Service Environment がゾーン固定されている場合はどうなりますか?
ゾーン固定 App Service Environment v2 が移行機能を使用した移行のサポートシナリオになりました。 App Service Environment v3 では、ゾーンのピン留めをサポートしていません。 App Service Environment v3 に移行するとき、ゾーン冗長性構成をオプションで選択できます。
App Service Environmentに IP SSL アドレスがある場合はどうすればよいですか? IP SSL は App Service Environment v3 ではサポートされていません。移行機能またはいずれかの手動オプションを使用して、移行する前にすべての IP SSL バインディングを削除する必要があります。インプレース移行機能を使用する場合は、すべての IP SSL バインディングを削除すると、その検証検査に合格して自動の移行に進むことができます。
App Service Environment のどのプロパティが変更されますか?
App Service Environment v3 になったら、以前のバージョンと比較して、機能と機能の相違点を確認してください。 ILB App Service Environment の場合は、同じ ILB IP アドレスを保持します。インターネットに接続している App Service Environment の場合は、パブリック IP アドレスと送信 IP アドレスが変更されます。 ELB App Service Environment では、以前は受信と送信の両方に 1 つの IP が使用されていました。 App Service Environment v3 では、これらは別々になります。詳細については、App Service Environment v3 ネットワークに関するページを参照してください。 App Service Environment バージョンの完全な比較については、「App Service Environment バージョンの比較」を参照してください。
移行に失敗した場合、または移行中に予期しない問題が発生した場合はどうなりますか?
予期しない問題が発生した場合は、サポートチームを利用できます。運用環境を移行する前に、開発環境を移行することで移行プロセスについて学習し、ワークロードに与える影響を確認してください。
古い App Service Environment はどうなりますか?
インプレース移行機能を使用して App Service Environment を移行すると決定した場合は、古い環境がシャットダウンされて削除され、すべてのアプリが新しい環境に移行されます。古い環境にはもうアクセスできません。古い環境へのロールバックはできません。
App Service Environment v1/v2 リソースは 2024 年 8 月 31 日を過ぎるとどうなりますか?
2024 年 8 月 31 日の後、App Service Environment v3 に移行していない場合、App Service Environment v1/v2s とそこにデプロイされているアプリは使用できなくなります。 App Service Environment v1/v2 は、2024 年 8 月 31 日に廃止される予定の Cloud Services (クラシック) アーキテクチャで実行される App Service スケールユニットでホストされています。このため、App Service Environment v1/v2 は、その日付の後は使用できなくなります。アプリが引き続き実行されるように App Service Environment v3 に移行するか、あるいは保持する必要があるリソースまたはデータをすべて保存またはバックアップしてください。

次の手順

App Service Environment v3 ネットワーク

App Service Environment v3 の使用

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

次の方法で共有

インプレース移行機能を使用した App Service Environment v3 への移行

サポートされるシナリオ

21Vianet が運用する Microsoft Azure

インプレース移行機能の制限

トラブルシューティング

インプレース移行機能を使用した移行プロセスの概要

App Service Environment のインプレース移行機能を使って移行がサポートされていることを検証する

新しい App Service Environment v3 用の IP アドレスを生成する

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

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

インスタンス サイズの変更の確認

リソースにロックがないことを確認する

移行をブロックする Azure ポリシーがないことを確認する

App Service Environment v3 構成を選択する

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 プランをスケールダウンする

よく寄せられる質問

次の手順

フィードバック

その他のリソース

インスタンスサイズの変更の確認

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