AzureステージングスロットでACSを使用する

Question

現在、私はMicrosoft AzureでWebアプリケーションを実装しています。私の心配は、ACSと一緒にステージングスロットを使用する方法です。

アプリケーションをステージングスロットにプッシュし、動作していることを確認してから、プロダクションにVIPスワップを行います。

このアプローチは、ACSの設定を除いて、かなり簡単です。ステージングスロットは展開中にランダムなURLを取得するため、その後ACSの設定を行う必要があります。 ACR内のWebRoleのweb.configおよびRelying Party Applicationは、新しいステージングスロットのURLで設定する必要があります。

Vittorio Bertocchiはblog postにweb.configを再デプロイせずに更新する方法を説明しています。ステージングに展開した後にACSをスクリプトで更新できると思います。

このアプローチは非常に複雑で脆いようです。私は展開プロセスのためのシンプルで強固なソリューションを探しています。私が見逃したことはありますか？

プロダクションスロットでACSの設定が非常に簡単で簡単なので、私はステージングスロットでアプリケーションのテストをスキップし、プロダクションにVIPスワップを実行するためにのみ使用します独自の「QA」ホステッドサービスでテスト済み）。

このアプローチについてどう思いますか？ Azureでホストされているサービスに違いはありますか？

Answer 1

おそらく、アプリケーションがACSにリダイレクトされたときに、戻りURLをプログラムによって設定できる可能性があります。これにより、認証後にユーザーをステージングスロットまたは本番スロットにリダイレクトします。

この質問は、レルムを設定する方法を示しますが、戻りURLがちょうど別のパラメータである：WIF cross-domain on one IIS site, dynamically setting of realm

Answer 2

私は「テスト」と呼ばれる新しいクラウドサービスを作成することによって、これを解決しました。したがって、アプリケーションをステージングスロットにプッシュすると、別のインスタンス（別のweb.configを使用）を私の「テスト」サービスのプロダクションスロットにプッシュします。 「テスト」アプリケーションが正常に動作する場合は、テストアプリを削除し、プロダクションステージングスロットをスワップします。

これは理想的な解決策ではありませんが、問題が解決する可能性があります。

Answer 3

ホストファイルエントリを使用してステージングインスタンスをテストするだけです。たとえば、あなたのサービスがmyservice.cloudapp.netでホストされているとしましょう。あなたのステージングスロットは通常[guid] .cloudapp.netのようなURLを取得しますが、パブリックVIPも得られます（サービスのダッシュボードから、またはnslookup [guid] .cloudapp.netを実行して取得できます）。ホストファイルエントリを "[Public VIP] myservice.cloudapp.net"として追加することができます。これを行うと、myservice.cloudapp.netを使用するだけでステージングインスタンスを作成でき、ACS設定を変更する必要はありません。