9

Azure でステージング環境と運用環境を維持したいと考えています。それぞれに独自の BLOB ストレージと SQL ストレージが必要です。これを達成するための最良の方法は何ですか？ステージングと運用 SQL サーバー、および 2 つの BLOB ストレージ アカウントをセットアップしますか?

4

3 に答える 3

13

これは、本番/受け入れ/テスト環境を管理する方法です（ステージングという言葉を使用していないことに注意してください）。環境ごとに、以下を作成します（プロジェクトによって異なります）。

  • クラウドサービス
  • ストレージアカウント
  • SQL AzureServer+データベース
  • AppFabric（ACS、...）名前空間
  • 仮想マシン

したがって、 myappというアプリがあるとすると、環境は次のようになります。

  • 製造
    • クラウドサービス：myapp-prod .cloudapp.net
    • ストレージアカウント：myapp-prod
    • 1つのデータベースを含むSQLAzureServer：MyApp
  • 受け入れ
    • クラウドサービス：myapp-acce .cloudapp.net
    • ストレージアカウント：myapp-acce
    • 1つのデータベースを含むSQLAzureサーバー：MyAppAcce
  • テスト
    • ..。

そのため、すべての環境で、本番デプロイメントスロットで実行されているアプリのバージョンがあります。実稼働環境でVIPスワップを実行する場合は常に、ステージングデプロイメントスロットのみを使用します（実稼働デプロイメントスロットと実稼働環境の違いに注意してください）。

環境ごとに専用のコンポーネント（ストレージアカウントなど）がある場合、このアプローチにはいくつかの利点があります。

  • 実際のアプリケーションに影響を与えることなく、新しいリリースをテストするのは簡単です。
  • 環境ごとに異なるセキュリティを設定できます（たとえば、すべての開発者がテストストレージアカウントのキーにアクセスできます）
  • アプリケーションをテストしている場合は、長くて醜いステージングURLの代わりに、実際のURL+SSLを使用できます。
  • 各環境には専用の名前空間があるため、ACSとの統合をテストするのは簡単です。
  • Visual Studioを使用すると、環境ごとの設定を簡単に管理できます。
  • 最後になりましたが、WindowsAzureストレージのスケーラビリティの目標がストレージアカウントレベルに適用されることを知っておく必要があります。つまり、すべての環境で単一のストレージアカウントを使用する場合、ステージングで実行されているアプリでストレステストを実行しているため、本番環境でのアプリのパフォーマンスが低下する可能性があります。環境ごとにストレージアカウントを使用する場合、何かを行っても他の環境に影響を与えることはありません。
于 2012-09-20T15:34:08.173 に答える
0

本当の答えではありませんが、コメントで許可されているよりも多くの文字が必要でした:)

私も同じ問題に取り組んでいます。個別のストレージ アカウントとデータベース サーバーを用意するのが最善の方法ですが、ステージング環境または運用環境のいずれかにコードをデプロイする可能性があるため、構成ファイルから適切なストレージ アカウント/データベースを選択することが課題です。RoleInstance クラスには、ステージングと本番を区別する方法がありません。

残っている唯一のオプションは、Service Management API を呼び出して、どのストレージ アカウント/データベースを選択するかを決定することです。この方程式にもう 1 つの複雑さを加えると、VIP スワップを実行すると、ステージング スロットが突然運用スロットになり (逆も同様)、新しい環境に基づいてストレージ アカウント/データベース接続文字列を切り替える必要があります。

他の人が何をしているのか非常に興味があります。

于 2012-09-20T12:52:17.467 に答える