1

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://learn.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

Aba
  • 55
  • 6

1 Answers1

0

I have gone through the above concern and to me having slot specific sticky setting should work and avoid sync with database for you. As this is application code I suggest handle it in your code with extra condition of type slot.

Now, just wanted to share some more details which you might be aware of. App settings WEBSITE_ADD_SITENAME_BINDINGS_IN_APPHOST_CONFIG=1 avoid any restart operation due to binding which in-turn makes changes to application domain. However you can try using WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG = 1 to see if that works for you.

Restart of worker process is required to take effect of below settings of destination slots. By default the restart consider completed after hitting the root of the slot "/". For better performance and avoid latency, think of having application initialization with multiple paths which might need more time or may perform cache or long execution. for e.g. web.config file looks like:

<system.webServer>
<applicationInitialization>
  <add initializationPage="/pagetowarmup1.php" />
  <add initializationPage="/pagetowarmup2.php" />
  <add initializationPage="/pagetowarmup3.php" />
</applicationInitialization>
</system.webServer>

Now is time to understand what happens with swap.

  1. Staging site(source) should get app settings and connection strings of production slot (destination) 2)Restart of source and warm up with application initialization path if provided in web.config file of source(staging).
  2. Now note that both source(staging) and destination (production) having same settings (App settings & connection strings)

I would suggest checking https://ruslany.net/2015/09/how-to-warm-up-azure-web-app-during-deployment-slots-swap/

Rohit Tatiya
  • 361
  • 2
  • 7
  • I will try out WEBSITE_SKIP_ALL_BINDINGS_IN_APPHOST_CONFIG = 1 to see if it makes any difference. as for app warmup - we looked into it and we cannot use it for syncing/preventing sync – Aba Jun 21 '21 at 11:32