1 つの Windows Azure クラウド サービス アプリケーションを複数のデータ センターに展開する場合、どのような方法が推奨されますか?
すべてのデータ センターで既存のアプリを保留にし、展開が完了したら再度有効にする必要がありますか? または、これを行うより良い方法はありますか？
理想的には、Windows Azure クラウド プロジェクトの構成ファイルにデータ センターのリストを設定して、1 回の発行操作中にアプリが複数のデータ センターに同時にアップロードされるようにしたいと考えています (たとえば、米国中北部、西ヨーロッパなど)。および東アジアのデータセンター)。
あなたが説明したことには、カスタム展開ロジックが少し必要になります。PowerShell とWindows Azure Management Cmdletsに慣れることをお勧めします。PowerShell でパッケージ化されたデプロイ方法の例は、Githubで入手できます。
ホストされているサービスごとに異なる引数を持つ同じ PowerShell スクリプトを使用して、各データセンター (つまり、複数のデータセンター) にある各ホスト サービスのステージング スロットに Azure パッケージとサービス構成ファイルをアップロードします。ステージング スロットのデプロイのステータスをポーリングし、READY ステータスになるまで待機するカスタム待機ロジックが必要です。これが完了すると、VM の準備ができたことがわかります。アプリケーションの読み込みが速い場合は、PowerShell を使用して VIP スワップを実行することもできます。
これを達成するために必要な PowerShell コマンドは次のとおりです。
これをビルドした場合でも、同期が取れなくなる可能性があることに注意してください。そのため、新しいデプロイは常に、基礎となるデータ ストレージ システム/スキーマと逆方向にする必要があります。
これには、 Windows Azure Service Management REST APIを使用することをお勧めします。PowerShell は、複数のデプロイに対して反復的で遅くなる傾向があります (つまり、同じパッケージであっても、デプロイごとにパッケージがストレージにアップロードされます)。Windows Azure ServiceManagement Sampleに、REST API の使用に関する優れた完全な例があります。同様の状況に合わせてこのサンプルを拡張しました。同じコード ベースを使用する 45 以上のマイクロサイトがあり、REST API を使用して各サービス インスタンスに非同期的にデプロイします。パッケージを Azure Blob にアップロードし、Blob URL を使用して各サービスの非同期更新をトリガーします。REST API を使用すると、ビルド サーバーまたは Azure Worker ロールから更新を実行できます。