[Discussion] Announcing zipdeploy integration with Run From Package

[davidebbo]

Please use this thread to discuss Azure/app-service-announcements#110

[fiveisprime]

Is this available in all regions and OS? I tried this in west us on Linux (set the app setting then did a zip deploy) and saw the typical zip deploy output:

Cleaning up temp folders from previous zip deployments and extracting pushed zip file /tmp/zipdeploy/27jna6c3.zip (2.67 MB) to /tmp/zipdeploy/extracted
Kudu sync from: '/tmp/zipdeploy/extracted' to: '/home/site/wwwroot'

I'm super excited to see this btw 👍

EDIT: Disregard that, seems like it's Windows only. I was able to get the deploy (in only 17 seconds btw), but my site isn't running correctly.

Preparing deployment for commit id '4a8bda7fb5'.
Skipping build. Project type: Run-From-Zip
Skipping post build. Project type: Run-From-Zip
Updating D:\home\data\SitePackages\packagename.txt with deployment 20180523204729.zip

Are there limitations to how the app will be started or should this act like a typical zip deploy? My app (node.js app) doesn't appear to have been started up. The logs show HTTP GET requests and no node.js output.

EDIT2: This deployment works beautifully for Functions, but it seems to change the way the Functions show up within the app and breaks the display in the Functions extension. We'll dig into this on the extension side of things though it seems the portal doesn't correctly show the Functions either.

[davidebbo]

@fiveisprime In case others are reading this, the issue was that site needed to be restarted, due to a known issue (should be fixed within next week or so).

[JRiggenbach]

How would one enable/disable a function using the zip approach since the mount is read-only? Is the expectation that the app would have to point to a different zip that has the respective function.json with the desired function state?

[davidebbo]

@JRiggenbach in v2, disablement is done via App Settings, which are external to the zip. e.g. in a v2 app, try disabling a function, and you'll see an App Setting appear, e.g. AzureWebJobs.TimerTriggerCSharp1.Disabled=true.

[JRiggenbach]

@davidebbo Thanks for the reply. So this is type of deployment is more geared towards the v2 runtime. Unfortunately I'm not in a position to use the v2 at the moment while it is in preview. I do like this option, and might proceed with it anyway with the assumption that I'll move to v2 once it's in GA. Would there be any reason not to use this type of deployment with v1?

[davidebbo]

@JRiggenbach I can't think of a reason not to use it for v1, other than potentially the one you brought up with disablement. The underlying technology is agnostic of v1 vs v2 vs random Web App.

[phawxby]

@davidebbo is this functionality coming to Linux and if so is there an ETA?

[davidebbo]

@phawxby it is being discussed for Linux, but there is no timeline yet. @rramachand21 may be able to add more to this.

[Zenuka]

I just ran into issues with publishing a webjob. Our build is setup to create a zip file with our webjob and our release is set to upload it to the app service. I created a new release and used the defaults of the "Azure App Service Deploy (v4)"-task which, I guess, uses Run from package as default. After that I was unable to stop or delete the webjob (probably since the wwwroot has become readonly). After switching back to zip deploy everything was working again.

(edit: Should I have created a new issue instead of a comment?)

[ggirard07]

@davidebbo Can we have some guidance about whether Run From Package is a feature supported for WebJobs (instead of Functions)? What about webjob(s) "sharing" the wwwroot with another project/deployment (SPA in our case)?

I found nothing in the webjob documentation/github/stackoverflow about webjobs running from package.

[davidebbo]

@ggirard07 I'm no longer with the company, but I recall that @ahmelsayed had made some changes specifically to make WebJobs play better with Run From Package. I think there are two models for this:

• Make the webjobs part of the package. They're read-only and can only be updated with a package update.
• Use the alternate site/jobs location that allows WebJobs to be dynamically added while using a package (since wwwroot becomes read-only).

I'll let him and/or @suwatch / @ankitkumarr comment further.

[ahmelsayed]

David is right regarding the two options. Good memory David :)

Let me know if you have any other questions

[ggirard07]

Regarding option 2, how do you achieve it from an Azure DevOps release pipeline?

I currently use the AzureRmWebAppDeployment task, where I can select the deployment method to be Run From Package. But I don't see a way to define where to deploy the package on the server (site/jobs).

Also webjobs in site/jobs seems to be ordered by type (Continuous, triggered). While deploying an MSDeploy package to wwwroot with AzureRmWebAppDeployment, this is handled automatically by Web Deploy. How does this work when deploying with Run From Package? Do I need to reimplement that logic to retrieve the webjob type from the package content and deploy it to the proper location?

[ahmelsayed]

Sorry I actually re-read your original question and I think I misunderstood it initially. If you want to deploy webjobs with your application in the same zip package, you can put them in the zip file so they end up under site/wwwroot/app_data/jobs/continuous/{job-name} for continuous jobs and site/wwwroot/app_data/jobs/triggered/{job-name} for triggered jobs. Check the webjob page on the kudu wiki (https://github.com/projectkudu/kudu/wiki/WebJobs)

The wiki also explains the alternative location of site/jobs/continuous/{job-name} and site/jobs/triggered/{job-name} the purpose of these alternative locations is to allow you to use run from package for deploying your web app, but to still be able to add webjobs using the UX or after the fact. Since site/wwwroot/ becomes readonly, the uploaded webjob is saved under site/jobs. Also site/jobs has the same folder structure as app_data/jobs

[ggirard07]

@ahmelsayed Thanks for the precision, but it still does not answer about how I can deal with this now (placing the zip content to either site/jobs/continuous/{job-name} or site/jobs/triggered/{job-name}) while I am in an Azure DevOps pipeline.

The task AzureRmWebAppDeployment which is used to deploy a webapp, webjob or function does not support it.

[ahmelsayed]

I'm not sure how to achieve that using AzureRmWebAppDeployment someone from devops might know better.

from Kudu's prospective, you can do that using webjobs APIs (https://github.com/projectkudu/kudu/wiki/WebJobs-API)

[davidebbo]

This should just work if you set up your VS project to deploy your WebJobs with your app. When you do that, the built WebJobs become part of the app's artifacts, so they will naturally get bundled up in the package along with everything else. AzureRmWebAppDeployment doesn't need to know anything about WebJobs for this to work.

[ggirard07]

@davidebbo I totally forgot that webjobs could be packed directly within the API project. We did not do it at first because webjobs to deploy where selected based on the targeted environment, but this is no longer a requirement.

Another use case I have is how to use run from package when using multiple virtual applications on the same web app?