The app settings of an App Service or Function App are realized by the key-value pairs (e.g. connections strings, API endpoints, …). If we have a large Azure solution with multiple services, then maintaining all those settings throughout different environments could be challenging. A new Azure App Configuration service externalizes the app settings so they can be used more easily from a central location. All the settings are stored in one place with the possibility to query them at the app level. This blog post will show you how easily we can move our app settings to this new Azure service.
Firstly, we’ll create the App Configuration service directly from the Azure Portal. Only the name, resource group, region and subscription are required.
I’ve called my service mwappconfiguration. Note that the endpoint for this App Configuration was created. We’ll see later that by using this endpoint the application will pull its settings.
Now, let’s add some app settings to the App Configuration by using Configuration explorer.
Firstly, select the “Configuration explorer” menu and then add your first settings by selecting “+ Create” and “Key-value” submenu.
The only required parameter is the Key name. It serves as the name for key-value pair and is used to store and retrieve a corresponding value. There are two general approaches to naming keys used for configuration data: flat or hierarchical. They are similar from an application usage standpoint, but hierarchical naming is somehow easier to read, manage and use. It’s a common practice to organize keys into a hierarchical namespace by using a character delimiter, such as /
or :
. There are more information about how to design key namespaces on the Microsoft documentation site.
Let’s say that our application is named MwDemoApp and is accessing one API Endpoint. So the key names might look something like this:
MwConfigDemoApp:ApiEndpoint
As you see, there is also one optional attribute available for the key-value pair called label. The label allows you to use the same key name multiple times. It’s a kind of dimension of the key. Let’s say you want to have three different environments – Dev, Testing and Production. For those environments, you do not want to define three different key names but rather use always the same key. That’s the scenario where the label attribute is pretty useful. As you see, in my case, I’ve added 3 key-values with 1 unique key – MwDemoApp:ApiEndpoint
.
Once the keys are defined in the App Configuration they can be used in App Service, Function App or another Azure service that supports the App Configuration. It’s good to mention that every modification of the value is historized and it’s possible to get a value from a specific date and hour if necessary.
To access an App Configuration key-values, you can use its connection string, which is available in the Azure portal. However, such a connection string is considered as a secret so it needs to be stored in Azure Key Vault. Then your code must authenticate to Key Vault to retrieve them. Another way to allow Function App to access App Configuration is by using the managed identity. Let’s see how to do it.
For our demo I’ve created Function App called MwConfigDemoApp. Go to “Function app settings” and select “Identity“.
Turn the identity status to “On” and save the settings.
Then go to the App Configuration, select “Access control (IAM)” and add access role to the Function App MwConfigDemoApp.
Select the Function App and save the settings. Now our Function App has access to App Configuration.
Let’s create an Azure Function that will read from App Configuration. Create Azure Function in Visual Studio and install the following nuget packages:
Azure.Identity 1.1.1 or later
Microsoft.Extensions.Configuration.AzureAppConfiguration 3.0.1 or later
The first package allows Azure Function to connect to Azure resources with Managed Identity. The second package contains the ConfigurationBuilder class that enables you to use AppConfiguration from your code.
Now only a few lines of code are needed to access App Configuration and read our settings. So first, we’ll create ConfigurationBuilder instance and by the following options we’ll:
var builder = new ConfigurationBuilder(); // App Cofiguration builder builder.AddAzureAppConfiguration(options => { options.Connect(new Uri(Environment.GetEnvironmentVariable("AppConfigurationEndpoint")), new ManagedIdentityCredential()).Select(keyFilter: "MwConfigDemoApp:*", labelFilter: "Dev"); }); var config = builder.Build(); string apiEndpoint = config["MwConfigDemoApp:ApiEndpoint"]; // Now use apiEndpoint in HttpClient to get the data!
On the last line, we’ve extracted the endpoint value of the key “MwConfigDemoApp:ApiEndpoint” and we’re ready to use it.
Keeping and managing application settings on one secure place, mainly when working on a large scale Azure solution, is a dream feature. In the article, I’ve shown how to store and read the app settings with App Configuration. A lot of features did not fit to the scope of the article but App Configuration is very well documented (together with examples, best practices, etc.) on Microsoft documentation site.