We are currently in the process of moving our entire infrastructure to a different region in Azure. When we first started no datacenter were available in Canada (East), so we went with an hybrid stack Website in Azure (US-East) and a Virtual Machine hosting our DB in the required province. We had an OK experience, but some errors occurred once in a while. With the new datacenter being up and running for a while now in Canada, our client has decided to make the move
Previous Production Setup:
Current Production Setup
We have, of course, already sent out a maintenance email to our clients in order to NOT disrupt their work. Our full infrastructure is created using custom ARM templates and we have everything in place to move our data.
We wanted to do most of the operations before the planned shutdown, some were easily done while others demanded some investigation or just had to be done when the old production was down and the new one was up.
I was responsible for the DNS, Domain Name (in Azure) and SSL, you know the fun ones!! It turned out OK in the end, besides the SSL config from Let’s Encrypt everything else was done prior to the maintenance window:
- TTL of our site was lowered to 10 minutes two days prior
- Registered the domain name in our new production site using TXT entries
- Added the Let’s encrypt extension in the new production while copying the correct values in my Application Settings
Like I mentioned the SSL config using Let’s Encrypt with the extension will generate a certificate once it communicated with the site for which the cert is required, in our case that was already setup and traffic was already transferred to https so that had to wait until the new prod was up anyways.
Once the production site was taken offline everything else went almost smoothly (it never does). The cert was installed by running the extension, the TTL was increased as well as redirected to the proper AppService, and we just went our merry way.
So you are all setup with your production website using continuous deployment from your master branch and everything, but you are still stuck with this <yourappname>.azurewebsites.net URL and would now like to have it use your well thought of custom domain name. It’s fairly easy provided you have access to your DNS registry.
Brand new website
When your site is new it’s pretty simple:
- In the Azure portal in your website blade:
- Click on custom domains then Add hostname
- enter the hostname you wish
- if you click validate now it will fail
In your DNS registry you must now add new CNAME entry that will point from your desired hostname to your <yourappname>.azurewebsites.net once that is done you can now click on validate and your good to go
Existing website without traffic disruption
This one is pretty simple but not much broadcasted. It’s basically the same procedure as a new website, but in your DNS you must add a TXT entry with a value of awverify.<your desired hostname> that points to your <yourappname>.azurewebsites.net. Once this entry has been added in your DNS you can now validate your hostname in azure and it will work. The only caveat is that your website must not be in the same resource group as the one that already exists otherwise you may experience errors when trying to validate the host name.
I know this subject has been covered extensively, but I wanted to do a simple how to, for the fact that it is … simple.
New Azure Website
In Azure when creating a new CUSTOM website, you will find a checkbox at the bottom "Publish from source control"…check it. This will give you the option of choosing your source control provider, after choosing your provider depending, on which on it is (in my case Github or Bitbucket), then select the repository and then you must select which branch you want this website to be on.
If by mistake you chose the quick create …no worries goto Existing website.
From the dashboard of an existing website look for "Set up deployment from source control", click it. You will then have to choose which one is your provider, depending on which it is (in my case Github or Bitbucket), then select the repository and then you must select which branch you want this website to be on.
Once your website is setup for source control deployment, ANY commit that you do in this repositor/branch will now trigger a deployment of your website.
This Saturday (June 7 2014), I will take part in the azure camp redux hosted by the Montreal .NET community. You don’t need to be a member and the entire camp (a full day with donuts and pizza) is free. We will be focusing on the Web Sites module of Azure. You can register here or go straight to the Montreal .NET community for more info and upcoming presentation