Run-From-Zip: a new way to deploy your Azure Web Apps and Function Apps (in Preview)

[davidebbo]

Quick Start

Run-From-Zip is an exciting new feature (in Preview) which lets you run a Web App or Function App by simply pointing it to a zip file containing your files.

To use it, just add an Azure App Setting called WEBSITE_USE_ZIP, and point it to your zip (typically using a storage SAS URL), e.g.

WEBSITE_USE_ZIP=https://davidebbostorage.blob.core.windows.net/content/SampleCoreMVCApp.zip?st=2018-02-13T09%3A48%3A00Z&se=2044-06-14T09%3A48%3A00Z&sp=rl&sv=2017-04-17&sr=b&sig=bNrVrEFzRHQB17GFJ7boEanetyJ9DGwBSV8OM3Mdh%2FM%3D

And that's it!

Note: the easiest way to host your zip is to put it in a Storage Blob. You can use Storage Explorer to do this. And see this doc for details on generating a SAS URL for your blob.

How this is fundamentally different from other deployment techniques

Today, App Service supports a number of different techniques to deploy your files: msdeploy (aka WebDeploy), git, FTP, VSTS, ARM and more. But all these techniques have something in common: when all is said and done, your files are deployed under your wwwroot folder (specifically d:\home\site\wwwroot).

At that point, the runtime takes over, and it is no longer relevant how the files got there. The runtime can read all those files, and run whatever logic it needs to run based on them.

But with Run-From-Zip, things are very different. There is no longer a deployment step which copies the individual files to wwwroot. Instead, you just point it to a zip file, and the zip gets mounted on wwwroot as a read-only file system.

In other word, while all the other techniques are pure deployment-time features, Run-From-Zip is much more of a runtime feature.

What are the benefits of Run-From-Zip?

Atomicity

One big benefit is that deployments become much more atomic. With all the other deployment flows, the App is running off loose files in your wwwroot, and deploying a new version means making changes (additions/deletions/updates) to those existing files, while the site is running. And if you're not careful, you could end up with locked files, and with running a half-baked app.

Of course, there are mitigations you can use today:

• App_Offline.html lets you take your app completely offline so you can update files in peace
• Site Slots let you deploy to a staging slot with no traffic, and swap to Prod when you're ready

But with Run-From-Zip, updating an app becomes as simple as pointing it to a different zip. When you do this, there is never a time where the old files conflict with the new one. Instead, there is an atomic transition between the two. Note that a site restart happens, so this can still be combined with slots if needed.

A side effect of this is that deployments via ARM templates become a lot faster, as all they need to do is update an App Setting.

Predictability

With traditional deployment techniques, it is harder to make sure that you are running the exact file set that you want. The reason is that from one deployment to the next, there are various ways that you can be left with unwanted remnants of the previous deployment. e.g. with msdeploy, you need to deal with whether you want to delete files at the destination, and whether you want to exclude some folders.

Now suppose you have an app that you need to run in multiple regions using traffic manager. You really want each region to be running the exact same files, but it is non-trivial to guarantee this.

In addition, a given running instance could be self-modifying some of its files, leading to discrepancies.

With Run-From-Zip, it is intrinsically a solved problem, because you always know that the only files your site is using are the files in your zip; nothing less and nothing more. If you use the same zip in all regions (or exact copies of it), there is no risk of them diverging.

Cold start performance

This one is particularly interesting to Azure Functions users running in Consumption mode, because cold starts are very common as your app is dynamically scaled.

Today, the cold start perf of Azure Functions is not very good when your functions are using Node and have thousands of files in npm modules.

In our tests, using Run-From-Zip in these scenarios lead to a significantly improved cold start. And we are working on further improvements that will make cold start yet faster in the future.

Versioning

As long as you keep previous versions for your zip in your Storage container, you can easily move back to a previous version by just pointing back to it.

By contrast, with other techniques it can be non-trivial to get back to the exact file set that you were at before if something goes wrong.

What are the limitations of Run-From-Zip?

It's still in Preview, and you may hit bugs!

At this point, you are encouraged to give it a try and give us feedback. But the feature is not yet production ready, and you may encounter some issues (which we'll want to hear about!).

Your site files become read-only

This actually should be viewed as a good thing. Generally, best practice dictates that you should avoid writing any files to your wwwroot folder at runtime. Instead, you should be using external mechanism like Azure Storage or a SQL database to persist any state.

With Run-From-Zip, this is strictly enforced as the wwwroot folder becomes read-only. You can still write files to the %TMP% folder if you need temporary storage. But you cannot save files to places like App_Data (but really, you shouldn't be doing that!)

There is currently no tooling support

To use the Preview today, you are responsible for creating the zip, hosting it, and pointing the App Setting to it.

While this is relatively straightforward, in the future we expect to have some tooling support to makes this more automatic from Visual Studio and other clients.

Q&A

What will my wwwroot folder look like in Kudu Console

With Run-From-Zip, if you go into your d:\home\site\wwwroot folder from Kudu Console, you will see all the files from your zip, but the whole folder will be read-only. This is the same view that your runtime will have.

What about other folders under d:\home

Run-From-Zip only affects your wwwroot folder, so the rest will continue unaffected. e.g. log files can still get created under d:\home\LogFiles.