Pick a DNS name for Staging
After migrating a couple of sites to Azure the one request I have is “I want to choose my staging environment domain name (e.g. myApp.cloudapp.net)”.
I need this for several reasons:
1. SSL – The sites we deploy have SSL certificates and I want to be able to cover my staging site with a multiple domain (UUC) certificate.
2. WCF – If I have WCF services as part of my deployment, I do not know their URL (generated GUID) until after I deploy. I would like to know the WCF URLs in advance so my configuration does not have to change each time. Right now I have to deploy my WCFs separate from my other services, get the URL, then update my other deployments to this URL and then publish these services.
3. My test users need to know the test site. Each time now I have to let them know what the URL. I explain to them it is dynamically generated, but they keep asking why. I have to tell them to ignore certificate errors which is not a good habit for users to get into.
AdamP
shared this idea
8 comments
-
Paul Turner
commented
The generated GUID also poses a problem for exposing a static FederationMetadata.xml file, since you don't know the URLs required until after the deployment. It would be nice to just use "staging.myApp.cloudapp.net" as a predictable hostname.
-
Haddicus
commented
@Robin - VIP swapping is a very important feature... I wouldn't even consider that because sites would have downtime... there's a reason why there is staging and production.
I've even tried to write a onstart command to rewrite my web.config to deal with dns entries on my web.config... unfortunately same problem as here, it uses a random user to startup the role vs network service... if network service was the startup user, this could be mitigated by running a startup script to change the permissions for web.config, and then updating those values based upon data given back from the webrole itself... and dynamically creating those based upon what environment it detects (staging/production)....
I have created a new request to offer a setting to allow for network service to be the designated user for role startup: http://www.mygreatwindowsazureidea.com/forums/34192-windows-azure-feature-voting/suggestions/3100745-start-webroles-as-network-service-instead-of-rando
-
Barend
commented
What @Jason recommend is so far the best idea. We often delete our staging environments when we don't use them, so with every deployment we get issued a new GUID... Then change DNS's, even with a short TTL on the DNS it's time consuming... We all know developers don't like to wait for stuff.
-
Jason
commented
They could just use staging.[Choosen DNS Name].cloudapp.net instead of using a guid
-
Derek Gabriel commented
I don't have any problem using a cname such as beta.xxxx.com - the GUID doesn't change if you push updates for changes, only if you completely redeploy. And then it's still not a big deal, because I use a TTL of 5 minutes on the beta dns records, so I can just pop into DNS and change the VIP address. I much prefer not having the available name pool reduced by beta and test apps. The system works great as it is.
-
Jason
commented
This is especially needed if you run multiple websites within the same WebRole. You can't visit the staging website without having to map a CNAME to the newly created guid url. Very annoying!
-
Marcel Meijer commented
This is realy necessary!
-
RobinDotNet
commented
The easy way to deal with this is not to use the staging deployments for the services. Set up a new service for the staging version of each production service, and name them accordingly. For example, the production service might be TheService, and the one used for staging might be stTheService. This way, you always know the URLs. If you use VIP swaps to put your new versions in production, this won't work. Otherwise, it works perfectly.
