Azure Websites Application Insights - switching config - azure

I have an Azure Website. For the sake of this question, the production version of the website runs on example.com, and a test version of the website runs on sandbox.example.com.
The only difference between the two is that they have different configuration.
At present, they are running under different websites, and I deploy the same website to each azure website via git.
I'd like to separate out the Application Insights data. Is there a technique or process that anyone uses - apart from editing the ApplicationInsights.config file in the sandbox environment post deploy?
Or would using a deployment slot handle this in some way?

There was a new blog post about exactly this today: Application Insights Support for Multiple Environments, Stamps and App Versions.
The destination of the telemetry is determined by the instrumentation
key (iKey), which is sent along with every telemetry message. In the
Application Insights portal, similar events and metrics with the same
iKey are aggregated to give you charts of average durations, event
counts, the sum of users, and so on. The iKey appears in two places in
your project. One is in ApplicationInsights.config:
<InstrumentationKey>94843456-2345-3456-4567-324562759284</InstrumentationKey>
If your application has web pages, the iKey also appears in a script
in the head of every web page. Usually, it’s only coded once in a
master page such as Views\Shared\_Layout.cshtml.
To direct telemetry to different application resources, we can create
several resources with different iKeys. Then we only have to change
the iKeys in the application at each transition in its lifecycle –
along with other configuration data such as connection strings,
certificates, and subscriptions.
The article then goes on how to do this in code, confg, etc:
1) Add iKey as a property in Web.config:
2) Instead of using the iKey from ApplicationInsights.config, we’ll
set it in the code. In global.asax.cs.
To avoid confusion, remove the <InstrumentationKey> node from
ApplicationInsights.config.
3) Configure the web pages to pick up instrumentationKey: "#Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey". This is
the script usually found in View\Shared\_Layout.cshtml.
4) Don’t forget to update your Web.config with appropriate iKey
configuration during the deployment process. You might devise a way of
setting it appropriately as part of your build, but I’ll leave that to
you.

Found this semi-related question: How to support multiple Azure subscriptions for a single application with application insights this is for using by cloud services, and it works!
Microsoft.ApplicationInsights.Extensibility.TelemetryConfiguration.Active.InstrumentationKey = ConfigurationManager.AppSettings["appInsightsKey"];
I have done this in my unity registertypes method, it works there.

In the Azure portal for websites, on the config tab there is a section called App Settings. You can put your different configuration settings here. When publishing, azure will inject those settings into web.config.
Then just use WebConfigurationManager.AppSettings as you would normally and it will pull the injected values.

Related

Managing Azure Web Site Configutation

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.

How to share app settings between multiple Azure websites

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.

Is it possible to update configuration settings programmatically?

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.

Changing/retrieving configuration settings on role start (Azure)

I'm trying to make a service to more easily configure configuration values on Azure applications. Right now, if I want to change a setting that it the same over 7 different environments, I have to change it in 7 different .cscfg files.
My thought is I can create a webservice, that the application will query for its configuration values. The webservice will look in a storage place, like Azure Tables, and return the correct configuration values.
I've been able to integrate this into a deployment script pretty easily (package the app, get the settings, change the cscfg file, deploy). The problem with that is every time you want to change a setting, you have to redeploy.
Finally the question - Is there a way I can retrieve the configuration settings after the application starts, on role start? It would of course need a base set of settings for the app to start. Retrieving the settings from the web service on application start would be good. Any way that I don't have to redeploy the application and that it will retrieve them automatically will work.
Thanks in advance!
Just use the .cscfg for the minimum set (common to all environment) of configurable settings. The use your web services for rest of the configurations. And don't modify your .cscfg. Just have a settings provider that retrieves settings from web service (via polling or message signalling - pub/sub model). And have a reinitialize settings procedure in place for this settings provider and all the services/components that rely on configurable settings.

Deploying and maintaining multiple copies of the same web application at different URLs on Azure

I'm currently investigating the possibility of my company using Azure.
Our current hosting situation that we run ourselves involves a separate site in IIS for each of our clients, each one having a virtual directory to the CMS we've built with ASP.Net web forms. We can update the contents of that virtual directory, which then provides the latest version of our CMS to all our clients at once.
I'm not looking to recreate that exact situation in Azure, but I am instead interested in figuring out how to create a single Web application in Visual Studio, publish that application to Azure in such a way that multiple sites (that I've specified) are created on Azure. Then I would like to be able to make changes to that application, and publish it again in a such a way that all the sites for it get updated all together, without requiring something be done manually per site/client.
The closest explanation I've found is this one:
http://www.wadewegner.com/2011/02/running-multiple-websites-in-a-windows-azure-web-role/
That gets me close, but what I don't understand is that when I publish this application to Azure, I still only see one application / URL available in the Azure management console. Shouldn't the extra "Site" node result in a different site being available when I publish it? Why doesn't it? Is there a completely separate way to accomplish this that I'm not using?
When you look at the management console you're seeing the web roles that you have deployed, not the sites that are part of that web role which is why you're only seeing one. As long as you've followed the instructions correctly, then yes, you do have two sites running. The catch is that you can only access the main site through that default URL. Presuming you have urls that look like customer1.mysite.com and customer2.mysite.com, you need to make sure you've set these as the host headers in the sub sites and then change your DNS so both of these domains point to URL you can see in the portal (e.g. mysite.cloudapp.net).
When considering a multi-tenant solution, ideally you should design your web-application as a single website that is capable of responding to multiple tenants (each of your customers), as opposed to creating a website/web-application for each one of them. This makes updates across the system manageable.
Your web-application can partition and identity different tenants based on several options such as part of the url (e.g myapp/tenant1 vs myapp/tenant2) or via a host header (e.g. tenant1.myapp.cloudapp.net vs tenant2.myapp.cloudapp.net)
HTH

Resources