We're using Azure App Service with slot deployments and we see unexpected behaviour when swap is performed.
We are trying to prevent CMS content sync on staging (which has DatabaseMode: ReadOnly
slot setting) during every slot swap.
We suspect that maybe additional restart takes place before settings are applied?
Host Environment: Azure App Service (with slots)
Appsettings:
Staging:
- WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: 1
- DatabaseMode: ReadOnly (Slot specific)
- other
Live:
- WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG: 1
- other
Both Staging and Live slots use same databases, Staging has readOnly enabled using App service App settings. DatabaseMode: ReadOnly works on the slot (prevents sync in our case), even if staging is restarted, we confirmed that.
During deployment: https://docs.microsoft.com/en-us/azure/app-service/deploy-staging-slots#what-happens-during-a-swap
We deploy to staging and trigger swap immediately.
What we see:
- New version is deployed to staging - app restarts, content does not sync (good)
- Swap starts, live settings are applied to staging - app restarts, content syncs (good)
- Swap takes place
- Staging settings are applied to 'old live' - app restarts, content syncs (bad), even though (DatabaseMode: ReadOnly) is applied as sticky staging setting.
- Swap completes
- Staging slot has DatabaseMode: ReadOnly enabled, further manual restarts do not sync content.
Is there any lesser known action that takes place during the swap which we don't know about which can cause a restart before staging settings are applied? Or what else could be causing this?
There is of course an option that CMS not picking up the value or smth, we're looking into it separately, but this happens only during restarts while swapping so would like to understand everything what happens from Azure side and be sure whether it is Azure problem or not