find a location for property in a new city

Monday, 14 November 2011

VIP swap with different endpoints in Azure

Attempting to Swap VIPs from the Azure Management Portal can return an message "Windows Azure cannot perform a VIP swap between deployments that specify different endpoint ports" when trying to Swap VIPs between a staging and production environment with different endpoints.

Say you have a web role deployed to Azure and it is currently in production. It has one instance and one endpoint of http on port 80. You then publish a new web role to staging that is also one instance but this time it has an https endpoint on port 443.

Both will work as usual however when you come to swap the VIPs over you will recieve the error "Windows Azure cannot perform a VIP swap between deployments that have a different number of endpoints" preventing you from putting your new site into production.

Is there a way around this?

I tried a few different tactics. I tried doing a straight upgrade to production (since I have tested the same deployment in staging) but this failed for the same reason as above.

I tried changing my new package to have the original http endpoint on port 80 as well as the new endpoint on port 443. This didn't work either. All this experimenting takes time so I thought I would save you the hassle and just tell you that neither of these work!

The only way(?)

The only way I found to get your new site into production is (you guessed it) delete the old site that is to be replaced (scary!), and then click "Swap VIP". You will experience down time for somewhere between 2 and 3 minutes so pick the least destructive time to do this.

Note: Please please test the new site that on staging thoroughly as you just deleted the production package and so it will take a long time to get back!

Follow britishdev on Twitter

2 comments:

  1. That's really scary.

    I guess the only other way to mitigate the downtime is to use a DNS alias to access the web role (www.myapp.com -> myapp.cloudapp.net), deploy to a different role on production and then point the DNS alias to the new web role (www.myapp.com -> myappssl.cloudapp.net), after a couple of days when DNS propagate you can delete the old role.

    Ciao,
    Giorgio

    ReplyDelete
  2. We get around this by giving up the Swap VIP and just having two different hosted services, each with one Production deployment. One is our staging and one is production. Locally, we have two Azure projects for each environment.

    ReplyDelete