2
  1. ドキュメントによると、Azure SDK 1.5 より前では、Web ロールのデプロイは同じ IP アドレス (127.0.0.1) に割り当てられ、Web ロールを区別するために異なるポート番号が使用されていました。この動作は今戻っていますか? ポート番号が異なる同じ IP アドレスで Web ロールがデプロイされていることに気付きました。

  2. マシンの再起動後にアプリを初めて実行すると、一貫してポートの再マッピングが発生します。さらに調査したところ、以下のことに気付きました。

    • Compute Emulator を終了せずにマシンを再起動すると、以前にデプロイされた Web ロールのポートが解放されません。マシンの再起動後、以下の netstat の出力を見つけます。これにより、コンピューティング エミュレーターは csdef で言及されているポート (8070) をビジーとして検出し、次のデプロイでの再マッピングを検討します。たとえば、コンピューティング エミュレーターを終了するか、再起動する前にコマンドラインから csrun.exe removeall/clean/shutdown を実行すると、サービスのデプロイに使用されたすべてのポートが解放されます。

netstat -aon | 検索文字列 8070

プロト ローカル アドレス 外部アドレス 状態 PID

TCP 0.0.0.0:8070 0.0.0.0:0 リッスン 4

TCP [::]:8070 [::]:0 リスニング 4

TASKLIST /FI "PID eq 4"

イメージ名 PID セッション名 セッション番号 メモリ使用量

システム 4 サービス 0 288 K

  • Azure SDK 2.5 の上記のシナリオでは、このポートの再マッピングが原因で、予期されたアドレス (ip:port) でサービスを利用できません。Azure SDK 2.1 でも再マッピングが行われていますが、影響を受けるのはプライベート ポートのみであり、アプリはパブリック ポートが変更されずに動作していました。しかし、Azure SDK 2.5 では、パブリック ポートが再マップされ、アプリ エラーが発生しました。Azure SDK 2.1 と 2.5 の両方で、以下の csrun.exe /run [pack details] のスクリーン キャプチャを見つけます。

2.1 と 2.5 の Azure SDK の csrun の比較

この問題を解決するための解決策をお勧めしますか?

4

1 に答える 1