Azure Front Door to Support Deployments
Sadly, application deployments that require downtime of your environment are still a common practice, sometimes it is because people do not know better and sometimes because technically that is just what it is.
In those cases the question usually pops up “how do we tell our users about this?”. Take the application offline and have users run into errors? Easy, but certainly not ideal. The more common approach is to display a maintenance website to the user by configuring a DNS redirect to the maintenance page.
The issue with the DNS approach is that this redirect might not always work straight away due to DNS caching and users still get to see an error. Again, not ideal.
Azure Front Door Configuration
I have been deploying Azure Front Door for multiple customers now to achieve global load balancing, WAF and routing capabilities way beyond what Azure Traffic Manager can do.
Azure Front Door (AFD) usually has one or more backends configured that tell the resource where to route requests to.
Let’s take this over-simplified architecture here.
The frontend is configured as davidobrien.azurefd.net with one backend configured as the web servers URI hosting the web site, then there is one routing rule that points all requests to / to said backend. Easy and straight forward.
AFD will send every request to https://davidobrien.azurefd.net to the configured backend.
I have seen companies have a “spare” Virtual Machine deployed which sole purpose is to serve the maintenance web site telling users to “have patience, come back later”. That’s a pretty expensive maintenance web site.
Maintenance Web Site on Azure Storage
If you are not aware of it, Azure Storage Accounts can host and serve static html web sites. Maintenance websites, at least the ones I usually come across, are fairly static, so they are a perfect fit for being served from Azure Storage. This will be at almost no cost to you.
Bringing it all together
If you like to follow this scenario in your test environment (Note: This will cost money!) then use this template here:
All you need to do is provide the template with two parameters for the Azure Front Door and Storage Account names. This template will then deploy an Azure Front Door with one Frontend, two backend pools and one routing rule. Once deployed you will find that one backend is configured to a custom host “david-obrien.net” and another backend is configured to point to the web endpoint of the Storage Account. You now need to enable the static website support on the Storage Account and upload an index.html file to the container called $web.
You can use the following simple html for this example:
<html>
<body>
This website is under maintenance. Come back later.
</body>
</html>
The Azure Front Door designer will look something like this.
Now we can browse to the Front Door endpoint and see our app (or my blog if we didn’t change the template). For a change to the maintenance website all we need to do is point the routing rule to the maintenance backend and save the config. About a minute later this configuration change will have populated globally and we will see the maintenance site.
To change it back we only have to reconfigure the routing rule again and point it to our application’s backend. Easy as!
Do you think this is helpful? I am a big fan of Azure Front Door and are constantly being surprised by new scenarios it can help us with.