How can we improve Azure Cloud Services (Web and Worker Role)?

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.

450 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AdamPAdamP shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →
    Piotr WójcickiPiotr Wójcicki shared a merged idea: Make link to staging deployment same every time  ·   · 

    15 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Alan ParrAlan Parr commented  ·   ·  Flag as inappropriate

        The staging environments for websites have behaviour that would seem to fit this use case.
        Could the websites implementation be ported over to Cloud Services? Would that be less work than reimplementing the feature from scratch?

      • Steve ColeSteve Cole commented  ·   ·  Flag as inappropriate

        We use a multi-tenancy website. In order to check our websites (all within a single web role) on staging, we need to be able to visit the sites using real domain names that have preconfigured DNS entries. Without a consistent IP or site URL we are unable to do this.

      • Paul TurnerPaul Turner commented  ·   ·  Flag as inappropriate

        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.

      • HaddicusHaddicus commented  ·   ·  Flag as inappropriate

        @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

      • BarendBarend commented  ·   ·  Flag as inappropriate

        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.

      • JasonJason commented  ·   ·  Flag as inappropriate

        They could just use staging.[Choosen DNS Name].cloudapp.net instead of using a guid

      • Derek GabrielDerek Gabriel commented  ·   ·  Flag as inappropriate

        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.

      • JasonJason commented  ·   ·  Flag as inappropriate

        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!

      • RobinDotNetRobinDotNet commented  ·   ·  Flag as inappropriate

        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.

      Feedback and Knowledge Base