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

Note

この記事で説明する移行機能は、App Service Environment v1 と v2 から App Service Environment v3 へのインプレース (同じサブネット) の自動移行に使用されます。 サイド バイ サイド移行機能の情報をお探しの場合は、「サイド バイ サイド移行機能を使用した 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 プラットフォームで、インプレース移行のサポートを確認するために、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 が現在のビルドにない場合、移行ページにアクセスするとアップグレードが開始されることがあります。 アップグレードが完了するまで待ってから移行します。
進行中の App Service Environment 管理操作。 App Service Environment は管理操作中です。 これらの操作には、デプロイやアップグレードなどのアクティビティを含めることができます。 移行は、これらの操作が完了するまでブロックされます。 これらの操作を完了したら、移行できます。
移行は、このサブスクリプションでは利用できません。 この App Service Environment を移行するには、サポートに依頼する必要があります。 サポート ケースを開き、サポートに問い合わせて問題を解決します。
InteralLoadBalancingMode は現在サポートされていません。 現時点では、InternalLoadBalancingMode が特定の値に設定された App Service Environment は、移行機能を使用して移行することができません。 InternalLoadBalancingMode は、Microsoft チームが手動で変更する必要があります。 サポート ケースを開き、サポートに問い合わせて問題を解決します。 移行を許可するために InternalLoadBalancingMode の更新をリクエストします。
移行が無効です。 移行を成功させるには、ASE を最新のビルドにアップグレードする必要があります。 ASE を今すぐアップグレードします。 プラットフォームのアップグレードが完了したら、数時間後にもう一度移行をお試しください。 App Service Environment が、移行に最低限必要なビルドではありません。 アップグレードが開始されます。 App Service Environment に影響はありませんが、アップグレードの実行中に App Service Environment をスケーリングしたり変更したりすることはできません。 アップグレードが完了するまで移行することはできません。 アップグレードが完了するまで待ってから移行します。

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

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

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 ManagerAzure Front Door などのサービスを使用して新しいエンドポイントを設定するときに使用できます。 新しい App Service Environment v3 に関連付けられている IP アドレスの変更の影響を受けるリソースをすべて更新する作業は、ユーザーが行う必要があります。 必要な更新がすべて完了するまでは、次のステップに進まないでください。 この手順は、App Service Environment v3 に移行する際にAzure Load Balancer のポート変更でポート 80 を使用するようになった場合などに、インバウンドおよびアウトバウンド ネットワークの依存関係の変更を確認するのにもお勧めです。

重要

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

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 の移行は無料です。 インプレース移行機能を使用すると、移行プロセス中にシャットダウンするとすぐに、以前の 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 に移行するか、あるいは保持する必要があるリソースまたはデータをすべて保存またはバックアップしてください。

次のステップ