And how do they differ from non-serverless plans?
Deployment slots are a great thing that offers seamless delivery to production without downtime or missing messages. And finally, slots are generally available for Azure Functions. I will explain how do they work, how they are different from classic App Service plans and mention a few scenarios.
How do they work?
So, what is happening when you swap Staging and Production slots?
- Slot specific settings are moving from Production to Staging.
- Staging application instances re-instantiated with the new parameters.
- An equal number of Staging servers started for the Production slot.
- An automatic health check performed.Azure DNS magic, routes exchanged for both containers.
Let us take for an example Serverless API application. When you deploy the new app version to a Staging slot and warmed up instances with requests, an equal number of idle servers will be spinup in the Production slot.
When there is no warm VM`s in Staging slot, no extra servers deployed in Production one.
It seems to be very straightforward and logical, but you should keep an eye on your Production upper-scale limits. For Consumption plan upper limit is 200 VM`s, and for Premium it’s 20.
These upper limits are the reason why there is only a single deployment slot option, which is restricting usage scenarios to only one(UAT or Testing) at the time.
How do they differ?
The main restrictions are a single slot and missing “Traffic Redirect” feature. The former was helpful for “testing in the production” scenario, which allows us to redirect a percentage of incoming production traffic to a selected deployment slot.
A single slot limits available usage scenarios, so you can choose which one to use at the moment. Usage scenarios can be anything from “Testing in Production” to “Load testing,” “Maintenance,” “UAT.” There are more than four slots available for non-serverless App Service plans. You can find a comparison table below.
Slots are not available for the Linux Consumption plan.
╔══════════════════════════════╦═════════════════════════════╗
║ Classic App Service plans ║ Serverless plans ║
╠══════════════════════════════╬═════════════════════════════╣
║ Up go 4(20) deployment slots ║ 1 deployment slot ║
║ Traffic redirect ║ ---- ║
║ Slot specific settings ║ Slot specific settings ║
║ Application IP range shared ║ Application IP range shared ║
║ SSL binding ║ SSL binding ║
╚══════════════════════════════╩═════════════════════════════╝Individual and shared slot settings.
Any application setting in the App Configuration section can be made bound to a slot. Options without selected checkboxes are the same for both slots.
All network settings are assigned to a particular deployment slot are swapped.
- Networking with CDN assignment and IP access restriction
- .Public certificates.
- Custom domain functionality and https oriented settings
- Authentication/Authorization settings for App Service access.
- Managed Identity to access KeyVault secrets.
- Push notifications configuration, if you are using the Event hub.
One thing to bear in mind, that Deployment slots share uploaded private x509 certificates, and there is a need to use a slot variable with certificate thumbprint value. Otherwise, it won’t be available for usage within the application.
WEBSITE_LOAD_CERTIFICATES : Cert thumbprintCustom domain names with HTTPS/TSL settings, scale setting, CORS, IP restrictions, and publishing endpoints are not swapped.
How to deploy and use it?
Fairly simple, my preferred way is to create a Function application with deployment slot via Azure CLI and then use the Azure DevOps pipeline for continuous delivery.
- Create a staging slot via Azure CLI or Portal.
- Create a managed identity and connect it to Azure KeyVault (if needed).
- Limit external slot connectivity to the dev and CD networks with IP rules.
- Configure continuous integration with Azure DevOps.
- Warm Staging slot functions manually or with this sample Link.
- Add auto-swap operation or run it manually(note below*).
- Double-check your IP restriction rules :).
az functionapp deployment slot create \
--resource-group $functionsGroupName --name $functionAppName \
--slot staging
az functionapp deployment slot swap \
--resource-group $functionsGroupName --name $functionAppName \
--slot staging --target-slot production
az functionapp identity assign -g MyResourceGroup -n TestFunctionapp
managedIdKey=$(az functionapp identity show --name TestFunctionapp \
--resource-group MyResourceGroup --query identity.principalId \
--o tsv)
echo "Managed key = " $managedIdKey
az keyvault set-policy --name YourVault --object-id $managedIdKey \
--certificate-permissions get list --key-permissions get list \
--secret-permissions get listAuto swap isn’t supported in web apps on Linux.
I prefer custom swap operation to avoid possible problems, but you can use official documentation for automation.
WEBSITE_SWAP_WARMUP_PING_PATHThe path to ping to warm up your site. Add this app setting by specifying a custom path that begins with a slash as the value. An example is /statuscheck. The default value is /.
WEBSITE_SWAP_WARMUP_PING_STATUSESValid HTTP response codes for the warm-up operation. Add this app setting with a comma-separated list of HTTP codes. An example is 200, 202. If the returned status code isn't in the list, the warmup and swap operations are stopped. By default, all response codes are valid.
Full Azure CLI code is available via GitHub.
How to use it via Azure Portal.
Please be aware, that if you create Managed Identity for deployment slots and try to add it to KeyVault via Portal, you can find it by the name below.
YourAppName/slots/StagingSlotName- Just open the app via Azure Portal and select Slots. Select + and add the name.
- Limit public access to the Staging slot.
- Create integration with preferred service.
- Perform swap operation via the portal.
Useful links.
- Microsoft docs on deployment slots.
- Deployment slots tips and tricks article.
- Video from Microsoft on slots and what usage scenarios can be useful.
- Documentation link on auto swap operation.
- Article link on most common swap failures.