I am migrating an existing Web Application to a Web Role. Does this mean that the web.config will be ignored?
I have connection strings, provider details, and tons of other config items in the web.config. Do I have to attempt to port all of this to the Azure ServiceConfiguration.Production.cscfg file?
In development, the Compute Emulator will not be used (since it takes so long), so we will still need the web.config files.
It depends on your use-case.
The cscfg allows you to reconfigure your WebRoles once deployed without creating a new package and redeploying/upgrading/staging+swapping. I especially think of scenarios where continuous integration is used and release procedures are no longer trivial.
If this scenario is not relevant you could just stick with the web.config and build and deploy new packages on configuration changes.
You could also selectively move items you assume that will regularly change in order to benefit from the configurability without having the effort of migrating everything.
I have used wrapper classes which abstract the configuration mechanisms (web.config app settings keys vs cscfg configurationsettings) in order to be able to use the different configuration mechanisms (e.g. check cscfg and fall back to web.config or the other way round or something along that lines).
Update: If you are using a "recent" azure SDK (1.7+) here is CloudConfigurationManager which might do most of the work for you.
Related
I am seeking the best way to handle configurations in my aspnet core applications. See below my scenario.
Currently I am using the TFS as a repository of code and as the
orchestrator of all my release definitions that goes to a webserver with IIS
I have a multitenant
application and my code currently stores in the applications
settings the configuration I have per client
appsetting.Client1.json
appsetting.Client2.json
ConnectionString is part of the variables that are stored in my appsettings.Client#.json
Now, a big problem I am seeing so far is that I am saving all configurations in my repository, and all developers have access to my PROD settings as well.(something I want to avoid, like the connectionString)
My solution so far to this problem is trying to save all sensitive configurations in the configuration variables of my IIS per client.
and avoid having them on the code directly and also as part of the configuration on the continuous integration process on the TFS, which should look only as an orchestrator. So the app should take every secret thing from IIS configuration. Which now take me to another doubt if I am doing the things right: I will not have the connectionString as a section anymore on my appSettings so I will not get them as I usually did configuration.GetConnectionString.
Should I need to consider a different approach with the resources I have?
In development, use user secrets. It's basically just JSON config, but it's stored outside your project in your user directory. That way, there's no chance of any secrets making it into your source control. You don't need to do anything special, as user secrets config is included by default. Just right-click on your project and choose "Manage User Secrets".
In production, you can use environment variables, Azure Key Vault, etc. Basically, just as with development, you want to keep the secrets external to your project and out of your source control.
Because all these settings are external, it's also a good idea to mock them up in something like appsettings.json. For example:
{
"ConnectionStrings": {
"MyConnectionString": "[CONNECTION STRING]"
}
}
Then, you actually specify the value in user secrets in development and environment variables, Azure Key Vault, etc. in production. Since appsettings.json is included first, the other config sources will override the placeholder(s) here. But, it serves to document your config, so other developers know what they need to provide.
There are probably no less than 150 different configuration options for an instance/application of Azure App Service Web Apps. This is only part of the list and each of these items have various options and inputs.
Authentication/Authorization
Application insights
Managed service identity
Backups
Networking settings
Scaling settings
WebJobs
Push
MySQL in App
easy tables
data connections
API definitions
CORS settings
... etc, etc
From a configuration management perspective, how do I either source control these settings (preferred) in a config file or use a configuration management tool to manage them?
I don't see a way to define the individual apps in an ARM template.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Per my understanding, the settings you mentioned includes the whole configurations of the web app, like Deployment slots, Backups, etc.
AFAIK, you may not be able to control them(at least like Deployment slots, Backups,etc) via the ways you mentioned.
My goal is to have a consistent and repeatable application configuration across multiple applications and prevent mistakes with manual setup.
Currently, the closest way is to clone web app, you could use it via the portal or powershell, but it could not support clone the whole configurations in the web app even if you use it.
Also note: App cloning is currently only supported for premium tier app service plans.
My company developed an Azure Resource Manager-based solution that deploys a set of resources (essentially a Storage, SQL DB and Web App), and it is already implemented as our provisioning process for new customers.
However, we are now studying the best way to perform updates, and one of the hypotheses we are considering is having a specific template that updates the binaries of this application.
The idea is to have a separate template, that only has the web app, an app host and a MSDeploy resource that gets the latest version of our package and reuploads it to that web app.
The only problem I'm seeing with this solution is the ability to handle any changes in configuration that are necessary with newer version of the binaries - we do not want users to have to re-input any parameters they placed for the original deploy (done via a Deploy To Azure button), so, any configurations will have to be performed within the application - the plan is for it to use the Microsoft.WindowsAzure.Management.WebSites library.
The major limitation with using Microsoft.WindowsAzure.Management.WebSites is that you are restricted to authenticating with either a certificate or a service principal. Ideally we would like to find a way for the updates to not need any authentication other than the one you provide when you are deploying the update.
Is there any recommendation of best practices to follow for this kind of scenario?
Thank you.
Link to the equivalent discussion on TechNet
It is possible to update only via ARM templates.
For example connection strings can be added automatically to the application settings even when creating the dependent resources themselves.
Ex. Account storage connection string.
Only first time creation of your web sites will take a bit more time, something like 30 sec.
ARM will not destroy your WebApps if they exist already. it will update only.
If there are no changes, then the deployment is very fast.
If your changes require a new Appsettings parameter, you can enter it in ARM , check in to your repository.
and next deployment will pick up and update the WebApp.
So no need for anyone to log-in and update.
Our final decision was to give up on using ARM exclusively. The Service Principal solution, through the SDK, would allow us to use a Web Job or a Site Extension to perform (automatic or prompted) updates that included configuration changes. However, it would require "too many" privileges - why would a customer trust an application that can, at will, create new resources or update existing ones to increase his Azure bill?
The decision was made to utilize Powershell only for updates - if the customer can see the scripts and authenticate himself, this is not a concern. Sadly, this increases update complexity, but we found it to be a necessary evil.
We are experimenting with deploying an MVC app as an Azure web role. Currently the app is being hosted locally on our server. It has a few appSettings in Web.Config that can be changed by the users as part of the "Administration" module of the application.
I know this isn't a good practice for Azure because there will potentially be multiple instances of the application running with multiple Web.Configs, which makes updating them all a nightmare (if not impossible). My understanding is that the ConfigurationSettings specified in the service definition should be used instead of Web.Config so that settings are defined globally in one place that all the instances of the application can access.
My question is is it possible to programmatically update ConfigurationSettings similar to the way we update Web.Config settings, or would it be better for us to move those settings into a database or something else?
Yes, but unfortunately it is definitely not simple to do.
Follow this URL: http://msdn.microsoft.com/en-us/library/windowsazure/ee460809.aspx
It talks about a Svc Management API call that you can make to read/write the Service Configuration. It is a 64-base string which you'll need to decode, find XML flags in it that you want to change and re-encode it back and send it back to the API.
Not pleasant, but doable.
Posts seem to conflict in their description of how best to get web.config settings into an Azure worker role. Some posts say you need to create WaIISHost.exe.config, set output to always then copy relevant web.config info to that file. Other posts describe creation of app.config instead of WaIISHost.exe. Which is correct?
The answer to this depends a bit on the version of the SDK you are using. First and foremost, the WaIISHost.exe.config is only applicable to Web Roles (not worker roles). Worker Roles use and continue to use app.config for their configuration settings. I am going to assume here that you are trying to configure a Web Role's RoleEntryPoint in config settings.
Now, for Web Roles: If you are using the latest SDK (1.8 at time of writing), you will find that creating a WaIISHost.exe.config file (and copy local, etc.) no longer works. Something has changed in the latest SDK and it will no longer pull those values. For earlier versions of the SDK, this is still how you do it. For the latest version (and likely next versions) 1.8, you can create an app.config. When you do that, it will actually create a file in your bin directory like "WebRoleProjectName.dll.config". You DO NOT have to create this file manually yourself and "Copy Local". Simply create the app.config like you normally would and you will find that your RoleEntryPoint in the Web Role can be configured just fine like that.
In your previous SO post, I suggested that you would need to spend some time to understand both Windows Azure websites and Windows Azure Cloud services as you are mixing together.
Like above you are mixing web and worker role together. WaIISHost.exe is the Windows Azure Web Role Host process which is responsible for loading and running your Web Role DLL. This process has nothing to do with Worker role because it is not even existing in a Windows Azure Worker Role. This process will be only available to Web Roles. And because of that your question above "WaIISHost.exe.config vs. app.config for worker role config" is irrelevant.
App.config configuration is used with both Web Role and Worker Role, however web.config is only used with your web application. So if you want to configure Roles only you can use app.config (both with web and worker role) however for web site configuration you can use web.config.
IF you just write what your final objective is in simple word, you sure will get exact assistance and suggestion on how to do it.