In Azure there's the possibility of storing the Connection Strings in the "Application Settings" section of the online portal. This overrides the value in the web.config, which is very useful.
The issue is that I am having multiple web apps in Azure that all use the same connection string, so I would like to have one common entry in the portal where I can set this and all the apps should use it. Is this intentionally not possible because is bad practice, have I missed it or is it just not possible?
Application settings are always defined for the IIS instance running behind the scenes for your application. If you have multiple web apps, then they need to have the same settings duplicated.
However, what you are looking for is known as the External Configuration Store pattern.
External Configuration Store pattern
This pattern describes the situation where you got multiple applications where each need to access the same configuration. In this pattern, this is accomplished by saving the settings externally, in e.g. an Azure Storage blob.
From the above link, highlighted your described usecase:
When to use this pattern
This pattern is useful for:
Configuration settings that are shared between multiple applications and application instances, or where a standard configuration must be
enforced across multiple applications and application instances.
A standard configuration system that doesn't support all of the required configuration settings, such as storing images or complex
data types.
As a complementary store for some of the settings for applications, perhaps allowing applications to override some or all of the
centrally-stored settings.
As a way to simplify administration of multiple applications, and optionally for monitoring use of configuration settings by logging
some or all types of access to the configuration store.
Related
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.
I have several App Services in Azure: development, test, and production. I would like to share some application settings between them like variable sets in Octopus.
Let's say I have a key A which should be same in all App Services. I would like to set its value in one place but seems that I have to configure it to each App Service. When A is changed, I have to change it to everywhere instead of having one common place to change it. Is there some way to do this?
No built-in way, app settings are part of the App Service resource.
You will need to put the settings in a common database or file.
Azure Key Vault can be used for sensitive settings and table storage/blob storage works well for other settings. Azure SQL is also an option.
Your app will then need to load these settings at startup.
This is also a documented cloud design pattern: https://learn.microsoft.com/en-us/azure/architecture/patterns/external-configuration-store
I have an application which has multiple websites, one for each logical function:
User-facing
Back end - receives web hooks etc
Other
The sites have a bunch of configuration info. appsettings variables and connection strings in common. Regardless of how I do configuration management, eg via the Azure Portal or scripted via Powershell I want to do as little repeat as possible to keep things simple and reduce opportunity for errors when deploying/ managing these configuration settings.
What recommendations are there for managing this?
I would recommend deploying the various sites using ARM Templates. You can then use the same deployment parameters for multiple sites to end up with each having the same app settings.
As an aside, please note that deployment slots do not share app settings. You have to apply them to each slot. So it's probably not a good candidate for your needs.
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.
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.