We have an Azure Function v3 instance on a Consumption plan which includes a staging slot to reduce downtime during deployments.
Our deployment process is:
We are using Azure Pipelines to deploy the code, .NET Core 3.1, to the staging slot; here is the YAML definition for this step:
- task: AzureFunctionApp@1
displayName: 'Deploy to Staging Slot'
inputs:
azureSubscription: '****'
appType: functionApp
appName: '****'
package: '$(System.ArtifactsDirectory)/Build.zip'
deployToSlotOrASE: true
slotName: 'staging'
resourceGroupName: '****'
I have disabled all the steps after this one and run ONLY this step. Once the step completes in Azure Pipelines, the main app, i.e. the production slot, restarts and I start receiving 503 Service Unavailable for about 5 seconds followed by a cold start.
What I don't understand is how deploying the code to the staging slot without swapping can cause a restart on the production slot.
I have made sure that auto-swap is disabled, so that's not the case.
How can it be explained and fixed? We are trying to remove the 503 entirely and have zero-downtime deployments.
Update: I have already tried adding WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG to both staging and production slot. Didn't make a difference.
We had an identical issue. Even if our deployment would only deploy the ZIP (so no resource deployment), we could reproduce this issue. All the recommended settings, such as WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG and WEBSITE_RUN_FROM_PACKAGE were already part of the application configuration, all other settings were equal for both slots, and no sticky settings.
The problematic setting in our situation was WEBSITE_CONTENTSHARE. Together with WEBSITE_CONTENTAZUREFILECONNECTIONSTRING, these settings are necessary for storing the function app code and configuration in event-driven scaling plans (such as consumption plan).
Per documentation, WEBSITE_CONTENTSHARE needs to be unique. It can be removed from the ARM template, in which case a value will be auto-generated. Check the application configuration in the Azure Portal (or Kudo) for both slots, to make sure that this setting has unique values.
If the value of this setting is not unique, it will affect the 'scaling' of the production slot, because both slots now share the same code and configuration. This seems to be the cause of a restart of the production slot when the code is deployed to the staging slot.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With