-
Notifications
You must be signed in to change notification settings - Fork 653
WEBSITE_RUN_FROM_PACKAGE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING Best Practices
Often times, we got complaints why my DevOps deployment with RunFromPackage failed intermittently or why the deployment was successful but my app doesn't find the expected deployed content. Below should help isolate one common problem.
App Service provides a file system (back by storage) out of the box for users's web apps. It is a network shared file system allowing multiple instances (in case more than one instances in an App Service Plan) to access the same content.
There are 2 AppSettings that alters the typical file system.
Instead of typical file layout, all artifacts are kept in one zip file. This zip file is virtualized as a typical file system to the app. This setting impacts both deployment (ZipDeploy) behavior to keep the deployed zip file as is (no extracting) and runtime (the zip file virtualization). The advantage is a faster, more reliable and more atomic deployment (no partial files being changed during runtime, no file locked or in-use issue).
This switches from App Service file system to user's provided Azure Files - common scenario for Azure Functions. The advantage is there is no downtime during App Service infrastructure upgrade. One can also achieve better performance with higher SKU Azure Files.
It is strongly recommended that this setting to be set at web app creation and immutable thru out the lifetime of a web app. In fact, there is no scenario that one would need to change this setting occasionally or especially during deployment. Modifying this will cause the deployment and app to behavior incorrectly, guaranteed downtime and data loss perception (deployed files are not where they are expected) - imagine swapping a hard drive while a computer is running.
Most of the times, the users don't do intentionally but rather by mistake due to the nature of AppSettings api. The api requires the payload to contains all necessary settings and every api call the new set will replace the existings one entirely. There is no partial remove or patch support with existing AppSettings. For instance, if one want to add a new setting, one needs to get existing set, add to that collection and update as a whole.
When setup DevOps pipeline with RunFromPackage option, for every run, DevOps will automatically add WEBSITE_RUN_FROM_PACKAGE=1 to the current AppSettings collection. As part of the pipeline, user often provides script/template to create/update the site and its AppSettings. If user misses to include this as well, it creates a situation as if the setting is removed and re-added back for every run. This leads to file system being changed during deployment and a common source of transient issue if not missing deployed content altogether.
Mitigation: Make sure the template or script include WEBSITE_RUN_FROM_PACKAGE=1 if DevOps's RunFromPackage is selected and vice versa.
There are two ways to provide AppSettings - in Site and SiteConfig resources in ARM template. Often times, AppSettings in one place contains WEBSITE_RUN_FROM_PACKAGE or WEBSITE_CONTENTAZUREFILECONNECTIONSTRING but not the others. When ARM template run, it creates a situation as if the setting is removed and re-added back (or vice versa). Again this is undesirable and lead to issues.
Mitigation: Make sure only one place in the template contains all the AppSettings (preferrably at Site resource to ensure correct settings on site creation). If multiple - make sure they are consistent especially WEBSITE_RUN_FROM_PACKAGE and WEBSITE_CONTENTAZUREFILECONNECTIONSTRING settings.