Azure Web Slots
Azure deployment slots. 20 hours ago 4 min read. Azure Deployment Slots is a feature that allows Web Apps, API Apps and Function Apps to run different instances of their application at the same time (known as slots). Slots are exposed via a publicly available endpoint. One instance is always mapped to the production slot, and you. A/B Testing for Azure Web Apps. Once I've got a slot or two set up and running a version of my app, I can do A/B testing if I'd like. I can set up a feature that was called 'Testing in Production' and is now 'Traffic Routing' and tell Azure what percentage of traffic goes to prod and what goes to staging.
Azure Development Slots
This post explains some of the not so well-known features and configurations settings of the Azure App Service deployment slots. These can be used to modify the swap logic as well as to improve the application availability during and after the swap. Here is what you can do with them:
- If this is the case, should the queue connectionstring be moved from app.config into Azure Website config so my Staging and Production slots can run on different queues? Azure azure-web-app-service azure.
- Web App with custom Deployment slots This template provides an easy way to deploy a web app with custom deployment slots on Azure Web Apps. Is this page helpful?
Swap based on the status code
During the swap operation the site in the staging slot is warmed up by making an HTTP request to its root directory. More detailed explanation of that process is available at How to warm up Azure Web App during deployment slots swap. By default the swap will proceed as long as the site responds with any status code. However, if you prefer the swap to not proceed if the application fails to warm up then you can configure it by using these app settings:
WEBSITE_SWAP_WARMUP_PING_PATH: The path to make the warm up request to. Set this to a URL path that begins with a slash as the value. For example, “/warmup.php”. The default value is /.WEBSITE_SWAP_WARMUP_PING_STATUSES:Expected HTTP response codes for the warm-up operation. Set this to a comma-separated list of HTTP status codes. For example: “200,202” . If the returned status code is not in the list, the swap operation will not complete. By default, all response codes are valid.
You can mark those two app setting as “Slot Settings” which would make them remain with the slot during the swap. Or you can have them as “non-sticky” settings meaning that they would move with the site as it gets swapped between slots.
Minimize random cold starts
In some cases after the swap the web app in the production slot may restart later without any action taken by the app owner. This usually happens when the underlying storage infrastructure of Azure App Service undergoes some changes. When that happens the application will restart on all VMs at the same time which may result in a cold start and a high latency of the HTTP requests. While you cannot control the underlying storage events you can minimize the effect they have on your app in the production slot. Set this app setting on every slot of the app:
Azure Web Slots Online
WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: setting this to “1” will prevent web app’s worker process and app domain from recycling when the App Service’s storage infrastructure gets reconfigured.
The only side effect this setting has is that it may cause problems when used with some Windows Communication Foundation (WCF) application. If you app does not use WCF then there is no downside of using this setting.
Control SLOT-sticky configuration
Originally when deployment slots functionality was released it did not properly handle some of the common site configuration settings during swap. For example if you configured IP restrictions on the production slot but did not configure that on the staging slot and then performed the swap you would have had the production slot without any IP restrictions configuration, while the staging slot had the IP restrictions enabled. That did not make much sense so the product team has fixed that. Now the following settings always remain with the slot:
- IP Restrictions
- Always On
- Protocol settings (Https Only, TLS version, client certificates)
- Diagnostic Log settings
- CORS
If however for any reason you need to revert to the old behavior of swapping these settings then you can add the app setting WEBSITE_OVERRIDE_PRESERVE_DEFAULT_STICKY_SLOT_SETTINGS to every slot of the app and set its value to “0” or “false”.
swap Diagnostics detector
If a swap operation did not complete successfully for any reason you can use the diagnostics detector to see what has happened during the swap operation and what caused it to fail. To get to it use the “Diagnose and solve problems” link in the portal:
From there click on “Check Swap Operations” which will open a page showing all the swaps performed on the webapp and their results. It will include possible root causes for the failures and recommendations on how to fix them.
I have a handful of web projects that I maintain. Some of these are sites like the one for my films (Hello World Film and Don't Worry, I'm Fine) but some others are community projects like Atlanta Code Camp. I've battled with the best way to develop and deploy these projects for quite a while.
The problem has been that for a long time I've just been checking into a main branch in Git and publishing that on every check-in. That's caused me some down time over the years. Maybe with these small projects it doesn't matter, but I like to keep these up (especially this blog) so I wanted to make a change that would address it.
First thing I did was create a branch in Git for working on the project. I thought about doing Pull Requests but since I'm the only dev on most of these, it felt a little to over-complicated. So instead I have a branch I call 'next' that I do active development into:
I've set up an Action to automatically build and deploy the project on every build. If you're curious how to do this in GitHub Actions, see my blog post about it.
The difference here is that on every 'Next' deployment I'm building a 'next' container. If we look in Azure container registry, we can see that there are tags for latest (my released version) and next (my test version):
With that in place, let's look at slots. Azure slots are a way to have multiple versions of your site running at once. One reason for this is what we're using it for. You can have a separate versions for testing, development, etc. Another common reason is to support A/B testing. It allows you to swap slots instantly (to prevent downtime) for those different scenarios. Let's see what it looks like.
In the App Service for this blog, there is an item for 'Deployment Slots':
Opening this you may get the dreaded 'You're not paying enough for this project' notification:
But if you're on a Standard (or better), you'll be greeted by this page:
Note that your main site is already running as the first 'slot'. It's your 'production' slot and 100% of the traffic is going to it. You can add a new slot and this will make a copy of your project, but it's a completely separate (but related) App Service.
Note: you can use this whether you're using containers or not. Just in this example I'm using container deployment
Let's create a new slot. Click on the 'Add Slot' button:
Enter a name for the slot and Click Add (you can clone the settings from the original site if you are using settings). Each slot gets it's own App Service so separate settings and configuration.
The name of the slot becomes a new AzureWebSites.net address so you can view it directly using that domain. For my use, I use the 'sitename.azurewebsites.net' address as my testing address.
Azure Web Slots Free
Once you have a slot configured, it'll look like this:
While, in my case, I'm always leaving the traffic to the main site at 100%, you could also use it to do A/B testing by having two versions of the site running and sharing the traffic to test how well the sites compare.
Now that I have the slot, I just configure it to use my testing (or next) container:
This image is doing a lot of heavy lifting. Note on the top-right that this is showing that it is an App Service Slot. So while it is an App Service it it's own right, it's related to the main App Service.
By looking at the container settings, I'm setting the container to use a 'next' tag so that this is the test version of this blog. I can view it and be sure that I didn't break anything. Now I'm ready to push this to the live version.
To do this, I go back into GitHub and create a Pull Request:
Once I merge the changes from my 'next' branch to 'main', the GitHub actions take over and create a new 'latest' version of my container.
You can see my actions and source code for this blog if you're curious how it works:
Is this something like what you're already doing in real production environments?