4

最新の Azure デプロイをステージングから運用に切り替えた後、ステージング ワーカー ロールがキュー メッセージにアクセスできないようにする必要があります。環境がコードでステージングされているか本番環境であるかを検出することでこれを行うことができますが、ステージング環境がキューメッセージにアクセスして処理するのを防ぐ他の方法があるかどうか教えてもらえますか??

助けてくれてありがとう！マヘシュ

4

5 に答える 5

1

ステージング環境ではプライマリ ストレージ キーを使用し、運用環境ではセカンダリ ストレージ キーを使用します。VIP スワップを行うと、現在のステージング環境が使用しているストレージ キーを再生成できます。これにより、キューにアクセスするための資格情報がなくなります。

これにより、タイミングの問題が発生することに注意してください。最初にスワップを実行してからストレージ キーを変更すると、2 つの操作の間にワーカー ロールがメッセージを取得するリスクが生じます。最初にキーを変更してからスワップを行うと、本番サービスがキューからメッセージをプルしなくなる 1 ～ 2 秒が発生します。このタイミングの問題が許容できるかどうかは、サービスによって異なります。

于 2013-08-03T05:30:00.987 に答える
1

現在のインスタンスが実行されているデプロイ スロットを実際に検出できます。

本来あるべきほど簡単ではありませんが、確実に可能です。

于 2013-08-09T01:20:20.123 に答える
1

これを行うプラットフォームには何もありません。これはアプリ/コードの問題です。アプリがキューにアクセスするための資格情報 (アカウント名やキーなど) を持っている場合は、コード化されたとおりに実行されています。

于 2013-07-31T19:03:20.967 に答える
0

これが DEV/TEST 環境を PRODUCTION 環境から保護する問題である場合は、個別の Azure サブスクリプション (環境ごとに 1 つ) を検討することをお勧めします。Patterns and Practices のこのガイドでは、このアプローチの利点について説明しています。

http://msdn.microsoft.com/en-us/library/ff803371.aspx#sec29

于 2013-08-01T14:43:04.117 に答える
0

キーを再生成するというkwillの答えは良いものですが、私はこれをやってしまいました:

  1. オプション - メッセージを無視するように指示する適切な構成キーを変更してから、VM を再起動する (管理ポータルを使用するか、WaHostBootstrapper.exe を強制終了することにより) ことにより、運用ワーカー ロールがキューをリッスンするのを停止します。

  2. ステージングされた環境に公開します (これによりキューへのアクセスが開始されますが、この場合は問題ありません)

  3. ステージング <-> 本番環境を Azure 経由でスワップ

  4. もう一度公開します。今度は新しいステージング環境 (古いライブ) に公開します。

これで、最新バージョンを実行し、キューにサービスを提供する、運用ワーカー ロールとステージング ワーカー ロールの両方ができました。これは私たちにとって良いことです。2 倍のキャパシティーが得られるからです。また、ステージングが実行されているので、それを使用することもできます。

ライブに公開する方法としてのみステージングを使用することが重要です (意図されていたように) - テスト/QA の目的で、独自のストレージ アカウントとメッセージ キューを持つまったく新しい環境を作成します。

于 2014-12-04T11:42:46.113 に答える