3

During the deployments, occasionally I experienced issue with files being in use by App Service and thus not overwritten with newer versions.

There are multiple recommendations to overcome this problem:

  • Run your app from the ZIP package directly
  • Stop your app or enable offline mode for your app during deployment (using App_Offline.htm)
  • Deploy to a staging slot with auto swap enabled.

I am exploring the local cache option, to fix a different problem, and it is not compatible with running from ZIP feature, as discussed here and here

If I understand correctly, when using local cache, the ZIP with code is deployed to Storage Account, and then is loaded into memory on App Service restart.

Does this mean, the issue with locked files is eliminated by using local cache, since the code is not run from the same place where it's deployed to?

  • Created a support ticket in Azure, asking the same question. So far, I have not received any useful response. Support is sending links about ZIP deployments and Local cache. According to them, local cache does not solve the problem with locked files, but without explanation. Also, there were no comments on compatibility for these two features. Will update the ticket once I learn more. – Alex Jun 15 at 22:18
  • Support confirmed incompatibility of Local Cache and Run From Package features. – Alex Jun 16 at 19:01
  • I reviewed the configuration on my end. Production slot of App Service has Local Cache enabled. Staging slot, however, has Local Cache disabled, as recommended in Microsoft documentation. This means, the apps in Staging run directly from the durable shared content store, meaning there can be file locks. My impression is, if I deployed directly to Production slot with Local Cache, then locking wouldn't be an issue. But in my scenario, I will be introducing App_Offline.html file when deploying to Staging to avoid file locking. – Alex Jun 16 at 19:07
1

The answer is no, if you are using the recommended setup, which is:

  • App Service should have Staging and Production slots
  • Staging slot has Local Cache disabled
  • Production slot has Local Cache enabled
  • The following settings are configured as "Slot setting" aka "Sticky setting" - WEBSITE_LOCAL_CACHE_OPTION, WEBSITE_LOCAL_CACHE_SIZEINMB
  • The code is deployed to Staging slot
  • Staging slot is swapped with Production slot

For deployments to Staging, I created the following steps:

  1. Shut down Staging slot by introducing App_Offline.htm (POST to SCM URI or can be part of artifact being deployed)
  2. Wait for slot to stop before cleaning (probe the URL of Staging slot)
  3. Cleanup wwwroot (post to SCM URI) - this is to clean unused files. Deployments are not incremental, so if it's important to have clean old files, you can introduce this step.
  4. Deploy to Staging slot using az webapp deployment source config-zip
  5. Remove App_Offline.htm (POST to SCM URI)

For swapping slots:

  1. Check Staging slot is up and ready (probe the URL of Staging slot) - this one is useful when triggering deployment environments in Atlassian Bamboo when deployed to Staging. You need to wait for Staging to be up and loaded before swapping, otherwise issues may occur
  2. Swap the slots using az webapp deployment slot swap

If you deploy directly to Production slot, and restart it right after (because of Local Cache enabled), then yes, there should be no file locks when using this method. But this creates the downtime during deployment, in contrast with deployments to Staging slot and swapping it with Production.

| improve this answer | |
  • If you have WEBSITE_LOCAL_CACHE_OPTION set to Always for the Production slot only but then deploy to staging using az webapp deployment source config-zip and swap with Production -- wouldn't you then run into the aforementioned incompatibility between WEBSITE_RUN_FROM_PACKAGE=1 and WEBSITE_LOCAL_CACHE_OPTION=Always as detailed in the links in the original post? Basically, when these two configuration values are present, it causes the app to crash shortly after startup as it attempts to write to its local filesystem which is now readonly due to running from a zip package. – Mushkov Sep 1 at 20:49
  • @Mushkov In my environment I stopped using WEBSITE_RUN_FROM_PACKAGE=1 because it's incompatible with WEBSITE_LOCAL_CACHE_OPTION=Always . The point of WEBSITE_RUN_FROM_PACKAGE=1 in my case was avoiding file locks. Instead, I introduced App_Offline.htm to gracefully stop the staging slot before deploying to it. I hope my comment makes sense, if not, please let me know and I will elaborate on it. – Alex Sep 2 at 22:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.