What happens under the hood when webapp restarted from Azure portal?
Let say if there is a change in connection string or other appsettings in an MVC.NET application, I can access the live webconfig file, save and restart the service. After the service restarted I would find that change has been updated. Therefore I am asking does at restart time application build or how the change take effect?
Sure, Restarts on an App Service can be triggered either manually or by configuration changes. See below configuration changes which trigger some sort of restart.
It is important to be aware that any config changes in sections such as the ones listed below can trigger a restart.
For more details on Restart operations see this detailed blog.
Related
I have an App Service deployed on three different regions (exact same code). My services needs to syncup some files at run-time and put them in the local cache of the app service.
For convenience, I have placed the files under the wwwroot folder. This is because when a new deployment happens, I want them to be gone too.
The thing is that in two of the three App Services, every time that a folder gets created under the wwwroot, the App Domain restarts and it breaks the functionality of the service. For the third service, the App Domain does not restart at all and requests to it work well. I know that changes in the wwwroot folder may trigger an App Domain recycle but don't get why it only happens in two of the regions.
Is there any configuration that might affect the behavior and how/when the App Domain gets restarted?
I also tried to add below on the web.config of my service but then the service doesn't even load up.
<httpRuntime fcnMode="Disabled" />
I got that information from this thread: Azure Websites AppDomain many restarts
Deployment pretty much does only one thing: it deploys files into the wwwroot folder. It never directly does anything to restart the App.
This is true whether you use Visual Studio deployment (msdeploy), git/GitHub/etc deployment, FTP, or manually copy some files over using Kudu Console.
The key word above is directly, meaning the deployment doesn't make any magic API calls that cause a site restart. However, in some cases, the act of deploying files into wwwroot can cause some form of restart. In that sense, the deployment is indirectly causing a restart, but it really knows nothing about it. It's up to the Application's runtime to react to file change notifications and do what it thinks is right.
For more details, you could refer to this article.
You can optionally use the configSource attribute to reference external configuration files that do not cause a restart when a change is made. For more information, see configSource in General Attributes Inherited by Section Elements.
Currently when pushing updates via our CI/CD pipeline to the Azure Web Apps the nodes are being forcefully rebooted by azure once the configuration changes are completed.
Has anyone come across a way where you can apply a configuration (web.config or other) changes to the web app in a single slot configuration with out the forced restart?
As Fabrizio Accatino said, when you touch the web.config, IIS automatically restarts the app domain.
If you do this to avoid downtime, you could add a deployment slot and publish your newest project to it. When you want to publish your project to production environment,you can swap them.For more details, refer to this article.
If downtime is your concern, it looks like MS starts up another container when you hit Save in the application settings blade, and then transfers all new requests over to the new container. The old container is given 2 min to complete all requests, and is then shut down.
https://social.msdn.microsoft.com/Forums/azure/en-US/f15b207b-c063-46e5-b87a-2b157641c8c4/does-changing-an-app-setting-and-saving-restart-the-app?forum=windowsazurewebsitespreview
I tested this on a Web App by repeatedly hitting an endpoint for 30 seconds while I changed an application setting and hit save. I saw the application start, but did not see any timeouts, only 200 OKs.
FYI my web app only used a single slot.
We have a website running as a web-app service on Azure. Our CM environment stalls and needs restarted periodically.
While we investigate the cause of this, I'd like to set the application pool to refresh overnight. I can't find anything in the portal to indicate how or where this is done. Can anyone help?
The Kudu service allows you to setup auto healing based on rules for memory, requests, or status code. To get to the dashboard navigate to https://[Your Azure App Name].scm.azurewebsites.net and then click on Tools -> Support and then turn on Autoheal, click Update and then optionally add any rules that make sense.
For more details, check out the blog post Auto Heal your Azure Web App.
You can assign a webjob to your service where you can upload a zipped .bat file and schedule it to run using a cron job
I THINK something like this should do it
azure webapp restart --resource-group xxx --name xxx
But, don't really want to mess about too much with our live environment.
The Kudu solution looks like the one we are going to go with. But, not until we take a good look at the perfomance/analytics. We definitely have a memory leak on the go somewhere
I am trying to deploy my app to an Azure WebApp slot but it seems that the file (Microsoft.Data.Edm.dll) it is trying to update is locked even though I have manually stopped the WebApp. I got the following error while deploying my app.
Web deployment task failed. (Web Deploy cannot modify the file 'Microsoft.Data.Edm.dll' on the destination because it is locked by an external process. In order to allow the publish operation to succeed, you may need to either restart your application to release the lock, or use the AppOffline rule handler for .Net applications on your next publish attempt. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_FILE_IN_USE.)
I tried on both VSTS web deploy task and manual deploy from Visual Studio, it returns me the same error message. I tried restarting the WebApp, setting the COR_ENABLE_PROFILING = 0 then 1 too but again, same error. The last resort that I didn't try is delete the WebApp and recreate again.. but i would like to know if there are other suggestions first before I do this desperate measure.
Thank you in advanced.
Restarting works better, stop just stops the http listener, restart restarts the running proces
Please try to use Resources explorer portal to full stop your web app. In this way, we can delete some locked files via FTP without anything running. For more details about how to full stop your web app, please refer to this article
As of time of this writing, if you are using Azure DevOps (VSTS) to deploy your application, you can select "Run From Package" in the "Azure App Service Deploy" task/step - this is available in version 4 of the task, under the "Additional Deployment Options" node.
This deployment option eliminates file locking issues as it provides atomicity, in that the application is pointed to the new zip file rather than deploying a bunch of loose files under wwwroot, some of which may be locked.
It provides you with a number of other benefits that you can read about it if you search and read about the feature.
HTH
I have a question about Remote Desktop deployment on Azure Cloud Application.
First of all I published my app via visual studio.Everything is working.
Yesterday I connected with remote desktop to my azure app and changed some attributes in my web.config files.
First thing : My cloud app is getting so slowly so I think IIS restart etc. but I don't know why my site is coming slowly ?
Second thing : Today when I enter to my app , I can't see my changes and when I check it via remote desktop all my changed things are roll back. Why ?
Do I have to all my deployment via Visual Studio ?
How is staying my deployment in Azure machines ? This machine is sometimes changing or never change when I delete it ?
Thanks,
This is not the expected way to change the settings. Azure is free to relocate your instance to another VM or restart it in-place and erase all your local changes.
So if you want to do some permanent changes you have to do them locally, build the service package and deploy the new package to Azure. This way Azure will have an updated package and your changes will persist.
If you want to change something frequently you have to use the <ConfigurationSettings> node of the service configuration. Your code will have to query the setting and react accordingly. If you want some activity triggered when the service configuration is changed your code has to handle the RoleEnvironment.Changing event.
You cannot make changes in the VM directly, because these changes are not persisted (as you have already noticed). The VM can be recycled and restored at any moment. So you have to make changes by applying them locally and redeploy the site.