I have a windows azure web role (web api) cloud service that until now had endpoints 80 and 443 exposed to the external load balancer. I have a team city configuration that builds the project and deploys the produced package to the staging environment of a specific cloud service. I then use the staging environment to warmup and test the deployment and if everything is ok I swap the cloud service environments with no downtime. A typical azure cloud service deployment scenario.
What I am trying to achieve now is hide the two endpoints of the web api from the internet, using an internal load balancer, and expose them using a reverse proxy (nginx) that will run in a separate cloud service that will expose ports 80 and 443. Problem is that if in my configuration I define that the endpoints will be internally load balanced like so:
<Endpoints>
<InputEndpoint name="HttpIn" protocol="http" port="80" loadBalancer="apiILB" />
</Endpoints>
and
<LoadBalancers>
<LoadBalancer name="apiILB">
<FrontendIPConfiguration type="private" subnet="Subnet-1" staticVirtualNetworkIPAddress="10.0.1.111" />
</LoadBalancer>
</LoadBalancers>
I can only deploy this once as it creates an internal load balancer that holds the assigned ip. Thus my whole workflow of using staging to test, warmup and swap will not work anymore. So if I deploy this to cloudservice1 production environment and then try to deploy a latter version on the staging environment I get an error that the ILB ip is taken (very reasonable) and cannot deploy.
Workaround 1: Do not assign a static ip to the load balancer and let it get the next available one.
Problem:
I am not sure if it would work if I did not assign the ip statically but it wouldn't help as I would need to have a static ip to assign to the nginx reverse proxy to forward requests to.
Workaround 2: Upgrade the deployment in place thus overwriting the previous deployment
Problem:
Upgrading the deployment in place will have the known disadvantages like not being able to warm up before going live, something might go wrong and there is no undo etc, so it is not an option.
Workaround 3: Change the static IP per deployment by altering csfcg files during the teamcity build process.
Problem:
Changing the static IP per deployment also sounds like a complicated process that will be hidden inside teamcity configurations and will need the nginx proxy configuration to be updated by hand after every new deployment.
I am thinking that the scenario I am trying to accomplish is very common and there should be a concise way of continuous deploying using a reverse proxy and internally load balanced cloud services, but I cannot find any documentation/examples on this.
