5

Windows Azure プロジェクトで一部の構成設定をオンザフライで変更する必要があります。また、Web サービス呼び出しを介して変更する必要があります (プラットフォーム API または Azure 管理サイトを介してアプリケーションの構成を更新することは、ここではオプションではありません)。 ）。

プロジェクトには複数の Web ロールと worker ロールがあります。新しい構成が変更された場合、そのすべてが新しい構成を認識する必要があります。

構成は耐久性のあるストレージに保持され、実行時に静的変数にキャッシュされます。

私の解決策は、ロールに内部 (tcp) エンドポイントを作成し、それを使用してすべてのロールとそれらのロール内のインスタンスをループし、その場でクライアントを作成し、インスタンスに新しい設定を伝えることでした。( http://msdn.microsoft.com/en-us/gg457891とほぼ同じ)

最初に、WebRole の RoleEntryPoint で ServiceHost を開始しました...そして、通信 (正しく設定された静的変数) をステップ実行したときにすべてが正常に機能しているように見える理由に混乱しましたが、他の Web サービス呼び出しを行うと、静的変数は、私が設定したものを「忘れた」ようです。

これは、ローカルでも Azure ステージング環境でも同様でした。

この時点で、フル IIS モードを使用しているため、RoleEntryPoint と Web サービスが 2 つの別個のプロセスで実行されていることに気付きました。1 つは Azure のスタブ、もう 1 つは IIS です。

「問題ありません」と私は言いました。ServiceHost を開始するコード行を RoleEntryPoint から global.asax に移動するだけです。この時点で、ServiceHost はサイトの残りの部分と同じプロセスで開始されます。静的変数は同じものになります。

ここで問題が発生します。これは、開発環境で実行されているローカル マシンでうまく機能します。ステージングにデプロイするとすぐに、「障害状態」にあるため、サービスへの接続に使用されるチャネルを閉じることができないというエラー メールが届き始めます。

質問：

  • これを引き起こしている Azure と Dev 環境の違いは何ですか?
  • 問題を修正または回避するにはどうすればよいですか?
  • より説明的なエラーを取得する方法について、一般的なアドバイスはありますか?これを取得するには、Azure で完全な wcf 診断を有効にする必要がありますか?それとも、例外の詳細を取得できる他の方法がありますか?

ファローアップ：

リモート デスクトップを介して、いくつかの興味深いことを学びました。

  • 非 HTTP アクティベーションは、既定では Azure WebRoles にインストールされません。これは、起動スクリプトを介して克服できると思います。

    start /w pkgmgr /iu:WCF-NonHTTP-Activation;

  • IIS で Web ロールによって作成された Web サイトでは、net.tcp プロトコルが既定で有効になっていません。また、これは起動スクリプトで克服できると思います。

    %systemroot%\system32\inetsrv\appcmd.exe set app "Website Name Here" /enabledProtocols:https,http,net.tcp

締め切りにより、いくつかの回避策を一時的に実装する必要があったため、これを最後まで実行する時間がありませんでした。

このトピックに関連する便利なリンク:

http://msdn.microsoft.com/en-us/magazine/cc163357.aspx

http://forums.iis.net/t/1160443.aspx

http://msdn.microsoft.com/en-us/library/ms731053.aspx

http://labs.episerver.com/en/Blogs/Paul-Smith/Dates/2008/6/Hosting-non-HTTP-based-WCF-applications-in-IIS7/

4

2 に答える 2

1

更新 (2011 年 6 月 27 日):

驚いたことに、Microsoft の誰か (私がコメントしたブログ) が実際にこれについて答えてくれました。

Azure & WCF チームがこの投稿を更新しました。

http://blogs.msdn.com/b/windowsazure/archive/2011/06/27/hosting-services-with-was-and-iis-on-windows-azure.aspx

リンクには、これを行うために必要なすべての情報が含まれています。

そして、勝利を収めた MSFT PM の Yavor Georgiev 氏に多大な感謝を捧げます。

質問をしてからかなり時間が経ちましたが、回答がないので、これを残しましょう。

投稿のフォローアップによると、これを機能させる方法はいくつかありますが、それらは複雑で実装が困難です。

WORKER ROLES の場合、netTcpBinding は完全に機能します。ここでは問題ありません。さあ、それを使ってください。

WEB ROLES の場合、問題があります。しかし、netTcpBinding は、内部エンドポイントを公開するために使用する必要があるものです。何をすべきか？

さて、これが私がしたことです：

  • ServiceHost を使用して、RoleEntryPoint で netTcpBinding サービスを開始します。
  • SOAP / JSON / 必要なものを使用して、Web ロールに標準の WCF サービスを作成します。
  • netTcpBinding を介して要求を受信したら、それらをループバック アダプターの WCF サービスにプロキシします。
  • SSL クライアント証明書を使用して、「内部」WCF サービスを適切に保護します。

完璧ではありませんが、機能し、ひどいものではありません。

この種のことを行う必要があることは非常に一般的ではないと思います。実行時に設定を動的に変更する以外に必要な理由は思いつきません...つまり、非難していないことを意味しますこれらのサービスはクレイジーです。

もちろん、YMMVです。

于 2011-06-25T07:33:19.493 に答える
0

netshステージングのインスタンス間で HTTP を動作させるのに惨めな時間を過ごし、プロセスに HttpListener を介してリッスンする許可を与えるためにいじる必要があるように見えたときにあきらめました(おい!)。そこで、ソケット経由で TCP に切り替えました。HTTP は、このようなポイント ツー ポイント通信シナリオでオーバーヘッドを追加するだけです。

于 2011-05-23T00:03:36.037 に答える