I have a Web site running on Azure App Services. It has a WebJob that deploys with it, and thus gets put in it's App_data folder once deployed.
If I FTP to the wwwroot/app_data folder of my site once deployed, the app.config file has none of the configured settings that I set up in the "Application Settings Blade" in the Azure portal. The settings are changed in my web.config for the Website though.
The most curious thing is that when I run the WebJob, the log output indicates that the correct settings are being used!!
So as per my title, does the WebJob use the App.Settings file once deployed or does it use some kind of in-memory copy of the app-settings from the azure portal, or does it use what is in the web.config of the website?
Just to pre-emt a possible question, I know that the app.settings gets renamed to myappname.exe.config
Here is how it works:
Azure doesn't run your WebJob in-place, but instead copies it to a temp folder (to avoid locking it in-place when it runs).
As part of this copying process, the App Settings are transformed in the temp files. That's why you don't see the changes in the config file.
Azure listens to file changes in your WebJob files, so if you modify your config file, Azure copies/transforms the files again and restarts the WebJob.
Mark Seeman elaborates on this:
As far as I can tell, it attempts to read configuration settings in this prioritized order:
1.Try to find the configuration value in the Web Site's >online configuration (see below).
2.Try to find the configuration value in the .cscfg file.
3.Try to find the configuration value in the app.config file or web.config file.
(Read the whole investigation here: http://blog.ploeh.dk/2014/05/16/configuring-azure-web-jobs/)
David Ebbo answer is perfectly right.
Just wanted to state that you can also run web jobs in place by a using a parameter in settings.job:
{
"is_in_place": true
}
Details can be found in Kudu docs:
https://github.com/projectkudu/kudu/wiki/WebJobs#webjob-working-directory
Related
Can I host a web application created on .net core 2.1 with sql server as database to azure web app service using CI tools / MS WebDeploy?
The following points I want to take care:
The application is using file system for temp storage and file storage
Deployment should be managed by some CI tools such as jenkins
After deployment, the app settings file should be modified with some keys/server details
Log files(stored on app root) should be accessible by application administrator
Is there a way to create a virtual directory same as in IIS and upload the files using FTP or similar protocols..?
All your doubts about deploying .net core 2.1 web app are achievable.
Suppose our projects are all completed and uploaded to github.
Questions and explanations about your concerns：
About the connection configuration using the database, you can directly configure it in web.config. If you are using azure sql server, find the connection string, set up the firewall, and pass the SSMS test, you can test the connection in the code. It can also be added in the Configuration -> Application settings -> Connection strings in the portal. After the addition, the priority is higher than the configuration in web.config, which will override the configuration and not modify the web.config file.
Regarding the use of file storage, you can use azure storage services or not. Looking specifically at the business, for example, very small pictures, documents and other files can be stored in the current program running directory, which is consistent with the original development at the code level. When publishing, you need to include the MyFiles file in the publishing process, or wait for the publishing to be completed and add folders manually in kudu, or the program can judge. It is recommended to use the program to judge that the subsequent program upgrade will not lose data.
The confidential information in the app settings file can actually be configured in web.config or appsetting.json. Make sure that the offline project is running properly when you are debugging locally, and then you can publish it. The rest is configured in the portal as in the first explanation.
The Log Files file storage can fully achieve the effect you want. It should be enough to set the owner permissions of this app services. For details, please refer to the official documentation.
Virtual directories and virtual applications, I have a better answer in another post here, you can refer to it.
Steps：
First of all, we can create a web app in portal and select .net core 2.1. Create appservices, and click Deployment Center when finished.
Follow the prompts step by step, and wait until the Action in github is completed, and the release is successful.
I'm hosting a website on Azure using an App Service. Suddenly one of the .config files (I have both a Web.config and a Config.config file) went missing and the website stopped working.
When I deploy the website to Azure for some reason the Config.config file is not included (even though I set it to be copied always) and I have to add it manually afterwards. But there were no recent deploys for that website, so I have no explanation for how that file suddenly disappeared and caused the website to crash.
I was wondering if there is any way to pin down the exact moment when the file was deleted and what caused it to be deleted (if a certain user deleted it or something like that)? A Git-like history for the files hosted in the Azure App Service, if you will...
I am not sure if you enabled the Web server logging in your web app in the portal -> App Service logs like below.
If you enabled it, the log will send to your storage blob container which you configured. If not, I suppose you may could not find the log.
For example, I delete the file test.js in the kudu console wwwroot of my web app, you could find the log in the storage like below.
For more details about app service logs, you could check this doc(the doc has not been updated for three years, something is different from that currently).
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.
I have a temporary "uploaded images" folder that resides on a webapp that periodically needs to culled of old images. I'd like the clean up task to be done via a continuous webjob. Is it possible to manipulate a folder on the webapp that the web job is deployed to via the webjob without essentially ftping to the webapp? ie. by the very nature of its deployment, can the webjob access the webapp and its files
Absolutely. A WebJob can access all the Web App's files. Specifically, the WebJob can look under %HOME%\site\wwwroot to find the Web App's files. And presumably you have your upload folder somewhere under that.
You can use Kudu Console to get a sense of the file structure.
In the "on premise" world, when creating an application like a Windows Service I'd classically use an App.config file to store a variety of configuration information about the application, from database connection strings to WCF endpoint information.
In the Azure Worker Role world, I am now presented with .cscfg files which are said to contain information "for the role".
I don't understand whether these files are there to supplement the configuration of the application, or replace App.config files entirely. How do these two files work to configure Azure Worker roles?
Very Basic Explanation:
Conceptually they're the same. In a traditional application, you use app.config file to define various settings related to the application (in appSettings section). Similarly, you use cscfg file to define various settings related to your cloud application (in ConfigurationSettings section). Like app.config file, you get to define other things (e.g. number of instances of your cloud application) in the cscfg file.
If you want, you can still define some of the settings in app.config file but one thing to keep in mind is that app.config file gets "packaged" and deployed and in order to change the settings, you would have to repackage your application and deploy it. However you could change the settings in a cscfg file on the fly using either the portal or Service Management API without having to repackage and redeploy the application. For example consider the scenario where you're defining the database connection string in settings file. If you specify that in app.config, in order to change it you would need to make change in app.config file --> Build the application --> publish the application. Where as in case of a cscfg file, you would just change this value in the portal.
For Web/Worker Roles the traditional configuration files (app/web.config) will keep working like they do on an on-premises deployment. But it's important to know that this file is included in the Service Package, meaning it's part of the deployment.
This means you can't change the settings you have in your app/web.config without redeploying your application. The ServiceConfiguration.cscfg on the other hand is something which is defined at Cloud Service deployment slot level, next to the actual Service Package. This means you can change this configuration file without having to redeploy your application. These settings can also be accessed from your application by calling RoleEnvironment.GetConfigurationSettingValue (similar to ConfigurationManager.AppSettings).
If you consider building an application that works both on-premises and in Windows Azure, consider using the Microsoft.WindowsAzure.ConfigurationManager package. Which automatically chooses the cscfg or app/web.config based on where your application runs.
Tip: By subscribing to the RoleEnvironment.Changing/Changed event you can intercept changes to this configuration file. You can handle this to update the web.config in code for example (explained here).