I am deploying a Nuxt application with Appveyor over Azure App Service Zip Deploy, but I am having trouble with the full deployment process being incredibly slow (Around 30+ minutes).
It seems that the whole build process is going as it should, but zipping the files takes around a minute or two (106 MB), and the file is successfully being pushed to the app service within a reasonable amount of time. However the incredible waiting time is at the Site Under Construction white page stage, taking down the whole website with it.
Does anyone have any tips to speed up this process besides upgrading
the App Service plan?
Is there any way to avoid the blank Site Under Construction page?
For example, is there a way to unzip to another folder and move the
files after everything is done so I would get minimal downtime on
the website?
You can add WEBSITE_RUN_FROM_PACKAGE=1 app settings
This option will deploy your app service to read only file system (read-only wwwroot folder, other folders are available for write operations)
Please take into account if you set this variable on ci/cd tool side probably the first time it won't apply because app settings are passed after zip deployment
And regarding the second questions. I guess it could be fixed by another app settings SCM_CREATE_APP_OFFLINE=0 (it should update your app without bringing it offline)
Related
I have a couple of small web apps hosted in Azure. I am using a shared app service, not VMs. Recently Azure has started showing warnings that I need to reduce my app's usage of temporary files on workers.
The link from the message doesn't provide anything useful for resolving this.
After restarting the app, the problem has gone away. Seems that temporary apps were cleared by doing a restart.
I am not sure what generated 179GB of temporary files and how I can reduce this. What should I look for? I am not explicitly storing anything in temporary files in code, data is stored in the database, so not sure what to look for.
The temp file usage is probably caused by one of your app that keeps creating temp files without cleaning them up. Restarting cleans up everything, but it's likely going to grow back over time if your app keeps doing the same thing.
There is no single solution to fix this. You'll need to figure out what causes this is your app logic, and change it to better clean up after itself.
Apologies if this question has already been answered. I've tried looking around, but may not have done a great job!
My azure deployment consists of 4 web sites deployed from VSTS that all share common web assets hosted on an Azure CDN. I would like to create a single "build" (or release) in VSTS so that I can build all the client-assets at once and deploy them to the CDN endpoint as well as the 4 running app services for fallback.
My initial approach used FTP tasks for the web servers. This worked but took almost an hour to ftp 500+ files to each website. I then attempted the approach mentioned here. Though I was able to zip up the assets, my drop file had the structure of:
- assets
- WebAssets.zip
Eg. "WebAssets.zip" was just a compressed copy of "assets" and I was unable to deploy this file to the proper location on the websites, "/site/wwwroot/wwwroot".
Is there a better way to copy these assets to each web service? Here is the structure of the "ftp" version of copying the assets:
Any help or direction pointing would be appreciated.
Update: just wanted to clarify that the current process does indeed work. It just takes between 30min and an hour to complete. I just want to make sure I am doing it correctly and that there is not a better way.
With Azure App Service Deployment task, you need to check Publish using Web Deploy option if you want to extract the zip folder.
On the other hand, to improve the performance, you can setup a private build agent that has the high performance (e.g. Network, Memory, CPU)
Deploy an agent on Windows
I 've found out that Azure websites (trial version) doesn't autostart my node sever process (it starts only when I load the url in the web browser); and that when there are no requests in a while, the process is killed.
I mean, when I git push my server, I would like it to start running immediately and continuously.
I read (here, for example) that this might have to do with the way iisnode manages azure websites, and that I can't do anything to change it. Is this the actual way Azure websites work? Is there any way I can deal with this?
Thanks in advance,
Bruno.
You've find the answer. There is no other answer.
The process termination because of inactivity comes from IIS - there is Idle Timeout setting. Which to my knowledge is not configurable in Azure Web Sites (at least not Free tier). Check out also this SO question and its answer to get better understanding on why you can't change this timeout on the FREE and STANDARD tiers.
And here is an interesting workaround to avoid this idle timeout. Actually if you use technique, you will also have kind-of "auto start", in terms that when your scheduler hits your site after a new deployment, it will "boot up".
This can get a little complicated, but if you don't want to use their 5-min ping service, you can keep these always on by doing the following:
Create an app setting on your website configuration tab within the portal:
WEBSITE_PRIVATE_EXTENSIONS and give it a value of 1
Create a text file named applicationhost.xdt and populate it with:
<?xml version="1.0"?><configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform"><system.applicationHost><applicationPools><add name="DefaultAppPool" managedRuntimeVersion="v4.5" startMode="AlwaysRunning"><processModel identityType="ApplicationPoolIdentity" /></add></applicationPools></system.applicationHost></configuration>
ftp into your website and create a folder on the root directory called Site Extensions. (there should now be 3 folders in your root: LogFiles, site, & SiteExtensions)
Create another folder within 'Site Extensions', named ASPLimits
Upload the applicationhost.xdt into the ASPLimits folder
Restart your website using the portal
I'm brand new to Azure. I'm trying to get a Cloud Service running with 3 web roles.
Last night I created the .cspkg and .cscfg files, exported the certificates and uploaded everything to Azure manager. The manager said my Cloud Service was successful, however for the last 10 hours when I click on "Cloud Services" in the manager it shows my service, but it says "Creating" with wait gif under "SERVICE STATUS".
Is it really still creating? Or did it fail? Is it possible to view more detailed information about the creation process and/or any log files?
Thanks,
Something "bad" has happened. Service Spin up time should be at most a few minutes.
I've seen it take up to 10-15 minutes depending on the hosting center and the number of scaled instances that need to come up but 10 hrs something has definitely gone wrong.
I would delete the service and start again. If you experience the same problem, have a look in your service start up code and make sure that there's no exceptions/infinite loops, other problems in there that might be causing problems.
It may miss any assembly references. If you included any assembly references(packages that are not part of .net) then please ensure that its copy to local attribute is set to true.
I've got a TFS build set up to build and deploy a web application. I'm passing in the MSDeploy parameters via the TFS build definition's MSBuild arguments. First time round this is working fine. When someone accesses the web app, one of the controls (Microsoft charting control) generates a couple of files in an empty directory I've added to the solution.
When I go to rebuild (or continuous integration is triggered) the next build will usually fail because it can't delete one of the generated files. When I try and manually delete the file it tells me that IIS worker process is using it and it can't be deleted.
Now to get the build building I'd have to manually restart IIS every time, which is not desirable with CI in mind. I've taken a look through Microsoft.Web.Publishing.Tasks.dll and there's nothing there to restart IIS using MSDeploy.
At the moment I'm thinking that adding stubs of the temporary files in the solution might be a resolution (maybe MSDeploy will be able to close the process if the file is a permanent part of the deployment) or I could do some unpleasantness with Exec in the solution file to get an IIS reset.
It's probably a long shot but has anyone come up against this and found a nice solution?
You could use MSBuild Extension Pack to stop the application pool automatically before deployment. There are several tasks in the MSBuild.ExtensionPack.Web namespace to manage IIS, such as stopping and starting an application pool, deleting an application, etc.