Best practice for minimizing downtime when deploying Azure Web Apps

Question

I have an App Service Plan, and in this plan I have deployed 5 components of my solution as Web Apps. I use 'Release Management' in Azure DevOps to deploy code to these apps.

To minimise downtime during deployment, I deploy to staging slots first, and then swop the staging slots into production slots to complete deployment.

I have configured App Service Warmup (as detailed here ) to call an endpoint that will 'warm up' the application during the slot swapping process.

This seems to work, but I have two issues:

1. Even though the warmup has run, the first request made to the app after slot swapping takes a long time. I suspect that this is due to the production slot having a 'sticky / slot settings', which as I understand it necessitates an app restart. To test this, I removed the slot settings, but the delay is still there.

2. The applications are dependent on each other, and the slot swapping (even though kicked off in parallel in Azure DevOps), is not guaranteed to complete at the same time, which means that it is possible for newer code to be interacting with old code. While we can engineer around this, this is not optimal.

From my investigations so far, the only way I can think of to work around these issues is to spin up a second app service plan, and configure traffic manager to sit in front of the two service plans. When deploying, I will prioritise one of the service plans while I deploy to the other service plan, and once that is complete divert traffic to the newly deployed service plan while upgrading the other, and then balancing the traffic between the two again once both are on the same code level.

What is the current 'best practice' for zero downtime deployments when using WebApps in Azure?

Is the duplicated service plan with traffic manager a viable option, and if not, what would you suggest?

Answer 1

Follow these more best practice recommendation.

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.

MINIMIZE RANDOM COLD STARTS

• 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.

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#prevent-cold-start

CONTROL SLOT-STICKY CONFIGURATION

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”.

https://ruslany.net/2019/06/azure-app-service-deployment-slots-tips-and-tricks/#slot-sticky-config

Answer 2

I would suggest to use Local cache in conjunction with Deployment Slots to prevent any downtime.

Add the sticky app setting WEBSITE_LOCAL_CACHE_OPTION with the value Always to your Production slot . If you're using WEBSITE_LOCAL_CACHE_SIZEINMB , also add it as a sticky setting to your Production slot .

• Create a Staging slot and publish to your Staging slot. You typically don't set the staging slot to use Local Cache to enable a seamless build-deploy-test life-cycle for staging if you get the benefits of Local Cache for the production slot.

• Test your site against your Staging slot .

• When you are ready, issue a swap operation between your Staging and Production slots.

• Sticky settings include name and sticky to a slot. So when the Staging slot gets swapped into Production , it inherits the Local Cache app settings . The newly swapped Production slot will run against the local cache after a few minutes and will be warmed up as part of slot warmup after swap. So when the slot swap is complete, your Production slot is running against the local cache .

Refer the Azure Best Practice Document:

https://docs.microsoft.com/en-us/azure/app-service/deploy-best-practices

https://docs.microsoft.com/en-us/azure/app-service/overview-local-cache

Answer 3

I utilise the "Swap with Preview" feature before warming the sites.

The main problem with swapping slots is that the worker processes are restarted when you swap. This means the sites need to be re-warmed.

When you use Swap with Preview the worker processes are restarted but the swap does not complete, meaning you can warm the sites accordingly. Once you are happy with your testing and performance you simply "Complete Swap" and the sites will respond the same.