6

既存のアプリをAzureに移行することを検討しています。1つのWebロールにMVCアプリがあり、別のWebロールにいくつかのWCFサービスがあります。ライブの場合、サイトはに住みhttp://www.myapp.com、サービスはでサービスhttp://api.myapp.comを指すように構成されたMVCアプリでになりますhttp://api.myapp.com。

問題は、アプリをAzureの「ステージ」構成にプッシュするときです。私の理解では、ステージにプッシュするたびに、サービスは新しいURL（のようなランダムなものhttp://4aa5ae2071324585ba5a902f4242a98c.cloudapp.net/）で動作します。この場合、MVCアプリがサービスのURLを検出するための最良の方法は何ですか？

1つのオプションは、のようなdnsエントリを設定し、http://stage.api.myapp.comステージにプッシュするたびに新しいAzureステージングURLを指すようにDNS CNAMEレコードを更新することですが、...うん。

もう1つのオプションは、ステージにプッシュし、サービスの新しいURL、MVCロールの各インスタンスへのRDCを取得し、構成を手動で更新することです。また、うん。

これを行う簡単な方法はありますか？PowerShellのようなものを使用して上記の手順の一部を自動化できることは知っていますが、これを簡単にする何かがAzureフレームワークに組み込まれていることを本当に望んでいます。そんな標準的なシナリオのようです。

4

2 に答える 2

6

ステージングURLが何であるかを動的に検出する唯一の方法は、インスタンスに自身のdeploymentIDをチェックさせることです。ここでは、MVCWebサイトとWCFサービスが同じ展開にあると想定しています。RoleEnvironment.DeploymentIDを確認すると、これがステージングで使用される「ランダムな」URL（つまり、http：// [deploymentID] .cloudapp.net）に正確に対応していることがわかります。

クライアント側でChannelFactoryを動的に作成している限り、独自のDeploymentIDを取得してステージングURLを見つけることができるはずです。

もちろん、これはステージングで展開された場合にのみ役立ちます。単にプロダクションスロットを使用してみませんか？その名前は安定しており、その名前または設定したCNAME（より可能性が高い）に依存できます。いつでも複数のホストされたサービス（dev、QA、prodなど）を使用して、それらの本番スロットを使用することができます。

于 2011-07-16T20:44:47.870 に答える
4

@dunnryが示唆していることをしないでください！Azureには、問題を解決するエンドポイントの非常に優れた概念があります。また、RoleEnvironmentクラスからこの情報にアクセスできます。

クライアントからエンドポイントを取得する方法については、私のブログ投稿をご覧ください。重要な部分は、WCFサービスがリッスンする内部エンドポイントを作成することです。ただし、これには必ずしも新しい役割は必要ありません。個人的には、元のWebの役割と一緒にIISでホストし、信頼性を向上させるためにこれらの役割を2つ持つことをお勧めします。

このように、デプロイメントが何であるかは関係ありません。サービス通信は、ステージングであろうと本番であろうと、そのデプロイメント内で行われるためです。

于 2011-07-17T11:06:42.100 に答える