-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Discussion] Run From Package: a new way to deploy your Azure Web Apps and Function Apps (in Preview) #32
Comments
Sounds great!
|
@Suchiman great questions:
|
It's cool feature.
|
Does it re-pull the zip file from the specified location on restart or scale out? Just wondering if we need to worry about the SAS URL expiring. |
@davidebbo Will/is there be an option in the kudu API to do this kind of deploy this? to get a 202 or 200 if
|
This is a great feature! Thank you! Is there some guidance for how this changes what should be deployed for your app? For example, I'm assuming that the zip file should include the |
Is there any way to set the appropriate environmental variable from a visualstudio.com build? If so, this should be able to be automated now since you can already zip up the source. |
Alternatively, can this be used with git deploy? e.g. Zip file is returned to git, auto-deploys to environment; ZIP variable points to the file path where the Zip sits in the environment? |
@shibayan Deploying completing is basically equivalent to the site restarting after changing an App Setting. If something goes wrong during zip download, you'll see a file called "FAILED TO DOWNLOAD ZIP FILE.txt" in wwwroot from Kudu with error details. There is no strict size limit, but it does use the local storage, so in Free/Shared/Consumption really large zips could hit the limit. The tooling part like Azure CLI is something that would come later and build on top of it. |
@anthonychu Yes, it does repull the zip each time. So:
|
@devlead Note that the zip is not uploaded a part of deployment, but instead that happens at runtime. There is no deployment per se, other than setting the App Setting. Potentially, Kudu could build the zip from a source project, and do the upload. Though that does raise some questions about it needing write access to the blob storage. |
@martinpeck Yes, it should absolutely include the node_module folder, and basically everything your app needs at runtime. Think of it this way: if you were to deploy via good ol' FTP, you'd copy a bunch of files. That exact same bunch of files is what you want in your zip. |
@securityvoid similar to previous comments. Basically, right now we just have the low level intrinsic that knows how to handle the App Setting pointing to a zip. There can be all kind of deployment workflows built on top of that to create the zip, host it and set the App Setting. I don't know VSTS well, but presumably it's flexible enough that you could be this today with enough custom build logic. |
@davidebbo Thank-you for the response. I'm going to play around with this some. As long as the variable supports pointing to the local file-path there are a lot of work flows that might work here. This should be a great feature! FYI, in case someone is looking how to set an environment variable from VSTS: |
How would this zip contain node_modules that were built to be compatible with the environment? If I am on a mac and build a node module that uses gyp or is anything other than simple js, and deploy that zip, there is no way it is going to be compatible. |
@davidebbo I get that, but just setting the setting doesn't guarantee the web app can access the zip file. If an api could provide at least some minimal validation, that would give more confidence in the deployment. And epic if an api could "like" the zip deploy api wait and give a 2xx when web is up or error if failed, that would give immediate feedback to fail or retry from CI. |
@tony-gutierrez Personally I would build and deploy from CI which would be using a Windows agent. |
@tony-gutierrez Yes, that's true. This issue also exists today if you use FTP or msdeploy. The only case where it doesn't exist is when doing Kudu git deployment, since that has a build step that restores packages. There is also the possibility of solving this via a CI server like VSTS. In such world
So it may be that 'raw' Run-From-Zip' is a little too low level in some scenarios if used by itself. But the right tooling can make it work correctly (but really, this is no different from msdeploy/FTP today). |
@devlead yes, I think this is something that can be built on top of the low level intrinsics. In fact, you could easily write a command line tool that takes the zip, uploads it to blob, sets the URL, and hits the Web App to make sure everything works. |
@davidebbo but how does hitting the web app make sure everything works? Since its async, it sounds like it would need a |
@Suchiman is is no different from changing an App Setting in App Service today. You have FOO=1 and change it to FOO=2, and it can take 10 or 20 seconds before the change is live. The very same applies here. |
@davidebbo Not really the answer i hoped for but i guess i can put a |
@Suchiman Why not simply return the environmental variable that points to the zip? If its the new value, you know the new release is in place. Then you don't need anything specifically in the release. |
@securityvoid mh interesting trick, cool yeah that should work, thanks 👍 |
@securityvoid @Suchiman one small twist is that if you have multiple instances, they will not necessarily all big ready at the exact same time. So you might still want to wait a few seconds even if one instance tells you it's ready. |
@dfinke Yep, that's a known issue in the Functions Runtime (not in this new feature) that just got fixed. Until the fix is deployed, just make sure to include a host.json at the root of your zip. It should just contain |
@davidebbo Thanks, yup, I just included it, was coming back to delete my comment and saw your response. This is pretty sweet and will simply function app DevOps. |
I've been having issues on one of my sites as well. Same setup, zip push/run from package coming from AppVeyor. It looks as if the site's not being warmed up before swapping because when I hit the site after a deploy it takes forever to respond and then I usually get a 500 error. After restarting the site it starts up pretty quickly and is fine until the next deploy. This all seemed to start after I migrated the site to .net core on February 17th. Prior to that I didn't have any issues. |
@xt0rted That is exactly my issue, thanks for sharing! It does seem like a timing issue where it doesn't wait long enough before starting up. |
Hi @PaitoAnderson and @xt0rted, could you please email me with your site names? I'm trying to repro your issue. Thanks! |
Today I use a .deployment file to set a target other then wwwroot so I can have two applications on the same webapp instance (API + web).
Does RUN FROM PACKAGE uses the .deployment file or it's restricted to the wwwroot destination? |
@JasonFreeberg We're also seeing weird issues with Run From Package when auto-scale scales up a busy site. Today we were brought completely offline with the site moaning about precompilation:
It looks like the app service can't load the precompiled assemblies even though they look to be there when you view through kudu and everything worked perfectly for 3 days prior to this with no new deployment happening. Happy to work with you offline to fix as Azure support have not been much help. |
@thecontrarycat @JasonFreeberg We also saw some issues with this on the weekend with our Asia site- it scales twice a day, at the start and the end of the "busy" period- but while scaling up last Sunday our site became unavailable- we had to scale it up and down again to get it to come back in. |
Hi everyone (@thecontrarycat, @Shawson) We are rolling out a fix for this. It will be deployed to all regions by 4/4. Please reply to this thread if the issue is still happening on or after April 5th. Thank you! |
I'm trying to use this new deployment method from a pipeline, but it kills the app. After deployment, the WEBSITE_RUN_FROM_PACKAGE is set to 1 and the app returns 500 The logs are completely unhelpful. |
Do you have |
@thecontrarycat no, i do not have that option set |
@carbonrobot If you turn on the live log stream in Azure, do you get any more details on the 500 error? |
@JasonFreeberg Did this happen? We are still getting the issue. It seems to be related to having precompilation enabled during deployment. App crash or Autoscale during busy periods gives "blah.cshtml' has not been pre-compiled, and cannot be requested" errors and completely takes the site down until restart. |
Still getting a 500 after a website is deployed. |
One issue we ran into was that when using Azure Devops action for deploying, we had some post-deployment scripts, however for some reason, there is nothing in the wwwroot folder except a I thought it would take a while for the folder to be mounted, so I put some Also, the docs say this feature is for function apps and only Windows, however we are using it for Linux Web Apps and it seems to work, so they need to be updated I believe. |
Does the folder where the zip file reside gets cleaned up by Kudu, or does it grow and grow? Could i potentially end up with a folder that exceeds the diskspacea available? |
@mslot - The home/data/SitePackages directory is treated like any other directory. The directory does not have any special restrictions on file counts or size. If the directory grows it will consume your storage, like any other directory. |
@JasonFreeberg I'm not sure that is correct - App Service has limits on the size of application storage. See the "storage" line in this table. |
So basically we have to make some kind of job that empty the zip folder, so it doesnt grow so large that a deployment fails because of no storage. We have standard plan, and I think it implies 50 gb of storage. Over time this will break deployments, because of storage gets filled. |
Has anyone else had issues where their site doesn't come online cleanly after routine maintenance when using WEBSITE_RUN_FROM_PACKAGE? I ran the site diagnostic tool and it gave me the following messages. After I got looking to the app, even simple static page requests were returning 500 errors which persisted until I rebooted the app. The note about the 'file server' suggests using the
|
@ jonarmstrong Correct - the local cache is imcompatible with this - see: projectkudu/kudu#2955 I'm at this point now, and I'm not sure how best to proceed, I've been running local cache for years, but it seems if I want to deploy via azure pipelines (which in turn uses zip deploy / run from package) then I need to turn this off 🤔 |
This is a follow-up to my post on 11/23/2019. I've since dug a little deeper and realize I have the same problem was impacting @PaitoAnderson & @xt0rted. My apps are also using the @JasonFreeberg Was there every a resolution to this? I have three apps which currently have bad instances because of this exact issue. The only way to resolve the issue is to restart the app and hope it comes back up. It has been plaguing my app reliability for months now. Below are stack traces from 2 of the 3 failing web sites Instance - RD501AC561D51E
@ 2020-02-16T09:48:18
Instance - RD501AC56B00BE
@ 2020-02-16T07:20:21
|
@jonarmstrong Did you ever figure out a solution or get any help? I'm having same issue with the assertion failure error as well. |
@katiep23 Regretfully, I've yet to receive any feedback or support about this particular issue. |
I know this issue is closed, but its 2022 and we are facing this exact issue with seemingly random FileLoadExceptions that require manually restarting the app. Did anyone ever figure out a solution that doesn’t require manual intervention? |
@ttrushin I recommend filing a ticket through Azure support. |
Please use this issue to discuss Azure/app-service-announcements#84
The text was updated successfully, but these errors were encountered: