次の方法で共有

移行後の変更

  • [アーティクル]

Cloud Services (クラシック) のデプロイは、Cloud Services (延長サポート) のデプロイに変換されます。 詳細については、Cloud Services (延長サポート) のドキュメントをご覧ください。

デプロイ ファイルの変更

デプロイ ファイルを Azure Resource Manager と Cloud Services (延長サポート) の要件に準拠させるため、お客様の .csdef および .cscfg ファイルが少し変更されます。 移行後に、新しいデプロイ ファイルを取得するか、既存のファイルを更新します。これは、更新または削除操作で必要になります。

  • Virtual Network では、.cscfg ファイルの NetworkConfiguration セクションのリソース名だけでなく、Azure Resource Manager の完全なリソース ID が使用されます。 たとえば、/subscriptions/subscription-id/resourceGroups/resource-group-name/providers/Microsoft.Network/virtualNetworks/vnet-name のようにします。 クラウド サービスと同じリソース グループに属している仮想ネットワークの場合は、仮想ネットワーク名のみを使用するように .cscfg ファイルを更新して戻すことができます。

  • Small、Large、ExtraLarge などの従来のサイズは、新しいサイズの名前 (Standard_A*) に置き換えられます。 サイズの名前を、.csdef ファイルで使用されている新しい名前に変更する必要があります。 詳細については、Cloud Services (延長サポート) のデプロイの前提条件に関する記事を参照してください

  • デプロイ ファイルの最新のコピーを取得するには、Get API を使用します。

クラウド サービス移行後の Azure Traffic Manager 構成の更新

Cloud Services (クラシック) を Cloud Services (延長サポート) に移行した後に、Azure Traffic Manager でのエンドポイント構成の更新または削除に関する問題が発生する可能性があります。 それは、リソース ID の同期の問題が原因です。Traffic Manager エンドポイントは Cloud Services (クラシック) の古いリソース ID を引き続き参照していますが、Cloud Services (延長サポート) のデプロイでは新しいリソース ID が設定されています。 この問題を解決するには、以下の手順に従ってください。

  1. トラフィックの一時エンドポイントを移行する: Azure Traffic Manager トラフィックをセカンダリ エンドポイントに移行します。
  2. Azure Traffic Manager でクラシック コンピューティング エンドポイントを削除する: トラフィックが一時エンドポイントに送信されるようになったら、Traffic Manager プロファイルからクラシック コンピューティング エンドポイントを削除します。
  3. Cloud Services (延長サポート) に移行する: クラウド サービス リソースを Cloud Services (延長サポート) に移行します。
  4. ATM に新しいエンドポイントを追加する: Traffic Manager プロファイルに、移行した Cloud Services (延長サポート) リソース用の新しいエンドポイントを作成します。 このエンドポイントには、移行したクラウド サービスの新しいリソース ID が設定されます。
  5. Cloud Services (延長サポート) のプライマリ エンドポイントへのトラフィックを再開する: セカンダリ エンドポイントは削除するか、低い重みに調整して構いません。 トラフィックは新しい (延長サポート) リソースに提供されます。 このプロセスにより、Traffic Manager を更新されたリソース ID に正しく合わせ、構成に関する問題でプロジェクトが遅延するのを回避することができます。

お客様のオートメーション、CI/CD パイプライン、カスタム スクリプト、カスタム ダッシュボード、カスタム ツールなどに対する変更

お客様は、新しい API とコマンドを使用してデプロイを管理するには、ツールとオートメーションを更新する必要があります。 お客様は、この変更の一環として、Azure Resource Manager や Cloud Services (延長サポート) の新機能を簡単に導入できます。

  • 移行後のリソースとリソース グループの名前の変更

  • クラウド サービスの管理とスケーリングに必要なルールとポリシーを作成し直します

    • 自動スケール ルールは移行されません。 移行後に、自動スケーリング ルールを作成し直します。
    • アラートは移行されません。 移行後に、アラートを作成し直します。
    • キー コンテナーは、アクセス ポリシーなしで作成されます。 証明書を表示または管理するために、Key Vault で適切なポリシーを作成します。 証明書は、シークレットと呼ばれるタブの設定の下に表示されます。

移行後の証明書管理の変更

証明書管理の標準的な手法として、すべての有効な .pfx 証明書ファイルが、Key Vault 内の証明書ストアに追加され、ポータル、PowerShell、REST API など、あらゆるクライアントを使用して更新が完全に行われます。

現在、Azure portal によって、必要な証明書がすべて Key Vault の証明書ストアにアップロードされているかどうかが検証され、証明書がないときは警告が出されます。 ただし、証明書をシークレットとして使用する場合、その証明書はサムプリントに対して検証できず、シークレットの追加を伴うすべての更新操作は、ポータル経由では失敗します。 お客様には、シークレットを伴う更新は、PowerShell または RestAPI を使用して続行することをお勧めします。

Visual Studio を使用した更新の変更

Visual Studio を使用して更新を直接発行した場合は、移行後、最初にご自身のデプロイから最新の CSCFG ファイルをダウンロードする必要があります。 このファイルを参照として使用し、Visual Studio プロジェクト内で現在お使いの CSCFG ファイルにネットワーク構成の詳細を追加します。 次に、ソリューションをビルドして、発行します。 この更新に対して、Key Vault と リソース グループを選択する必要があります。

次のステップ