As we know, we can store configuration settings in App Configuration Service in the form of key-value pairs. We can also apply labels to each key value pair. In this article, we are going to have a look at how labels can be used to store environment specific key value pairs.
Why environment specific settings are needed ?
Many times, the application may use different configurations in different environments. One of the simplest example is – the database connection string. Each environment would have a its own specific database instance. The dev environment’s application should connect with dev environment’s database. Similarly, test environment’s application should connect with test environment’s database. So, the application has a single key, but it’s value is supposed to vary based on which environment is asking for key.
Similarly, some feature flags may also have different values in different environments. Some features which are still under development, may be disabled on production, but they may be enabled on dev environment.
We can use labels for this purpose. We can define multiple keys with different value. Each of the key will have a label specifying the environment in which the value should be used.
Let’s take an example !
Let’s say, we have an ASP .NET Core API application. The API application connects with App Configuration Service for reading the configuration settings. Let’s say there is a setting for log level,
TestApi:LogLevel. The log level is supposed to have different value on different environments
- On Development environment, the log level should be
- On Staging environment, the log level should be set to
- On Production environment, the log level should be set to
In addition to this environment specific setting, there are supposed to be some other configuration settings which are not specific to environment.
Let’s say, our application needs another setting, let’s say the application wants to call a third party API. The third party API would be stored in the App Configuration Service. Let’s say the setting name is
For the sake of demo, the application will read the keys and return the key and value as output.
Create Azure App Configuration Service
We will need an instance of Azure App Configuration Service. You can refer this article to create one using Azure Portal. Alternatively, you can run the bicep script from this article to create one for you. Refer my GitHub repository to create the resource if you want to use the Bicep files. This bicep file will also add some key value pairs.
Add the key value pairs needed for our demo.
- Key = TestApi:ApiEndpointUrl, Value set to some URL, without any label
- Key = TestApi:LogLevel, Value = Debug, Label = Development
- Key = TestApi:LogLevel, Value = Information, Label = Staging
- Key = TestApi:LogLevel, Value = Warning, Label = Production
Create ASP .NET Core API Project
You can create a new project and then configure it to connect with our newly created Azure App Configuration service. Refer this article to create the new project.
Or you can also use the API project from my GitHub repository.
New Controller and New Action !
Now, let’s add a new controller, let’s say,
SettingsController.cs. Add a new GET action, which will return the above mentioned two settings. The
IConfiguration object should be injected in this controller. The complete code is shown in the snippet given below.
Program.cs file, we need to modify the
AddAzureAppConfiguration call a bit.
- The connection string of Azure App Configuration Service should be read from the environment variable
- Then the
AddAzureAppConfigurationshould take Action parameter as input.
In this Action parameter, we have to make three different method calls:
- Connect, which takes connection string as input. It is needed to make connection with Azure App Configuration instance
- Select, this first call takes two input parameters, the setting prefix which we have set to be “TestApi:*” with null label. It loads configuration values with no label.
- Another Select call, this time as well, there are two parameters. The first parameter is again prefix of the settings which we have set to be “TestApi:*“. But this time, we are passing environment name as second parameter. So, any setting with TestApi: prefix and whose label is matching with environment name, will be fetched. These environment-specific values override any corresponding values with no label. You don’t need to define environment-specific values for every key.
Add a reference to the Microsoft.Extensions.Configuration.AzureAppConfiguration namespace in order to access the KeyFilter and LabelFilter classes.
Run and Verify
Now, we need to run and verify that our setup works. It’s easy ! We can run the project from Visual Studio. The launchsettings.json file contains profiles and for each profile, there is a collection of environment variables. We can set
ASPNETCORE_ENVIRONMENT variable to three different values,
After changing the value, we can run the API and then try to call the GET settings endpoint. The LogLevel value will vary every time the environment variable is changed, but the ApiEndpointUrl value will not change as it does not have any label.
So, we have successfully shown how the environment specific settings can be used. I hope you find this information helpful. Let me know your thoughts.