これまでエンドポイント 80 と 443 が外部ロード バランサーに公開されていた Windows Azure Web ロール (Web API) クラウド サービスがあります。プロジェクトをビルドし、生成されたパッケージを特定のクラウド サービスのステージング環境にデプロイするチーム シティ構成があります。次に、ステージング環境を使用してデプロイのウォームアップとテストを行い、問題がなければダウンタイムなしでクラウド サービス環境を交換します。一般的な Azure クラウド サービスのデプロイ シナリオ。
私が今達成しようとしているのは、内部ロード バランサーを使用して Web API の 2 つのエンドポイントをインターネットから隠し、ポート 80 を公開する別のクラウド サービスで実行されるリバース プロキシ (nginx) を使用してそれらを公開することです。 443. 問題は、私の構成で、エンドポイントが内部的に負荷分散されるように定義すると、次のようになることです。
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" loadBalancer="apiILB" />
</Endpoints>
と
<LoadBalancers>
<LoadBalancer name="apiILB">
<FrontendIPConfiguration type="private" subnet="Subnet-1" staticVirtualNetworkIPAddress="10.0.1.111" />
</LoadBalancer>
</LoadBalancers>
割り当てられた IP を保持する内部ロード バランサーが作成されるため、これをデプロイできるのは 1 回だけです。したがって、テスト、ウォームアップ、およびスワップにステージングを使用するワークフロー全体が機能しなくなります。したがって、これを cloudservice1 運用環境にデプロイしてから、ステージング環境に新しいバージョンをデプロイしようとすると、ILB IP が取得され (非常に合理的)、デプロイできないというエラーが表示されます。
回避策 1: ロード バランサーに静的 IP を割り当てず、次に使用可能なものを取得させます。
問題：
IPを静的に割り当てなかった場合に機能するかどうかはわかりませんが、リクエストを転送するためにnginxリバースプロキシに割り当てる静的IPが必要になるため、役に立ちません。
回避策 2: 配置をアップグレードして、以前の配置を上書きする
問題：
配置を適切にアップグレードすると、ライブに移行する前にウォームアップできない、何かがうまくいかない、元に戻すことができないなどの既知の欠点があるため、オプションではありません。
回避策 3: teamcity ビルド プロセス中に csfcg ファイルを変更して、デプロイごとに静的 IP を変更します。
問題：
デプロイごとに静的 IP を変更することも、teamcity 構成内に隠される複雑なプロセスのように聞こえ、新しいデプロイのたびに手動で nginx プロキシ構成を更新する必要があります。
私が達成しようとしているシナリオは非常に一般的であり、リバース プロキシと内部的に負荷分散されたクラウド サービスを使用して継続的に展開する簡潔な方法があるはずですが、これに関するドキュメントや例は見つかりません。