What is the best way to manage your environment specific app settings in Azure?

user_7916691 0
Viewed 523

My current setup stores the environment specific application settings within a section the ARM parameter files. So, the structure of ARM parameters files looks something like this:

{
  "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentParameters.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "deploymentSpecificValues": {
      "value": {
        "subscriptionId": "0ce7bbfc-9fa4-46b5-8f38-303db907fd89",
        "environmentName": "dev",
        "azureBlobUri": "https://mytestblob.blob.core.windows.net/"
      }
    },
    "regions": {
      "value": [
        {
          "location": "West US",
          "additionalRegionData": "abc"
        },
        {
          "location": "West US 2",
          "additionalRegionData": "pqr"
        }
      ]
    },
    "webAppInfo": {
      "value": {
        "appName": "mytestapp",
        "appSettings": {
          "SqlServerConnectionString": "mySqlServerConnectionString",
          "Service1Url": "https://www.service1url.com",
          "Service2Url": "https://www.service2url.com"
        }
      }
    },
    "sku": {
      "value": "Dynamic"
    }
  }
}

Notice the appSettings located under the webAppInfo node of the above code. Each environment has it's own parameters file like the above. I believe that the number of appsettings can keep growing with time and it might clutter the parameters files.

Questions:

  1. Is this the best practice to manage appsetting?
  2. If the answer to the above question is a no, then what's the best practice to handle the appsettings in such scenarios?
azure-resource-manager azure-web-app-service azure configuration
2 Answers

A couple thoughts:

  • What you're doing is fine, but you're right in that 1) it could get unwieldy in param files and 2) generally these param files are in source control, so make sure what you have in there, should be in source.
  • Check to see if there are values that you can get from the deployment at deployment time, e.g. subscriptionId can be returned from the subscription() function (assuming you want the id of the subscription you are deploying to).

There are two resources in Azure that you can use to store "config" - you can use them slightly differently.

  1. KeyVault can store arbitrary strings (e.g. blobs of json) securely and they can be dynamically referenced (via parameters) at deployment time.

https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/key-vault-parameter

  1. App-Config is a resource to store config values for just such an occasion - you can pull values out of the config store using the listKeyValue() template function

https://docs.microsoft.com/en-us/azure/azure-app-configuration/quickstart-resource-manager https://github.com/Azure/azure-quickstart-templates/tree/master/101-app-configuration

That help?

user_49621300

Yes, I think this is a good practice to manage appsettings in ARM template like this.

But if you just want to add/update a setting, it is recommended to use azure portal or Azure CLI.

Reference:

az webapp config appsettings

user_105049990
Related