Configuration Options For Your Microservice In .NET Core

Configurations in .NET Core is entirely key-value based. Each registered provider load a collection of key-value pairs into one configuration instance, and you access those values via the IConfiguration interface. let’s have a look on the available configuration sources.

Files

You can load the configurations from the file system. You can load them from JSON, XML, INI and YAML files. All source except YAML are supported out of the box in .NET Core if you call CreateDefaultBuilder in your Program.cs file.

public static IHostBuilder CreateHostBuilder(string[] args) =>
   Host.CreateDefaultBuilder(args)
      ConfigureWebHostDefaults(webBuilder =>
      {
         webBuilder.UseStartup<Startup>();
      });

You can implement your custom provider to read key-value YAML configurations or use this Nuget from Andrew Lock.

Environment Variables

variables are vey helpful when you need to set values based on the hosting platform. If you are building containerized or Azure services, pushing the configurations is very easy into your hosted app. The most common environment variable developers encounter is the ASPNETCORE_ENVIRONMENT which has a default value of Production.

Command Line Arguments

This is the easiest way to pass variables into your application. dotnet ./myapp.dll "cool"

You pass as many values as you want and the Mail method will get them from the args array. It is method is handy way in local development but is not recommended production.

public class Program
{
    // command line arguments here
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }
public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();    
}

Consul

Consul is a distributed, highly available, and data center-aware solution to connect and configure applications across a dynamic, distributed infrastructure. The Key-Value Storage feature is a flexible store that enables storing the dynamic configuration, feature flagging, coordination, leader election, and more. The simple HTTP API makes it easy to use anywhere.

It is a nice candidate If you need to share configuration across multiple instances of the same service. You can integrate it easily into your application via Nuget. If you wish to combine the Consul and the built-in .NET configuration system, You should have a look here

Azure Key Vault

Think about Azure Key Vault as a mechanism for secret management. You can use Azure Key Vault as a direct configuration provider in your .NET Core applications. Additionally, you can also connect a key vault instance to your Azure App Service. By creating a connection between the two services, secrets are injected as Environment Variables and are accessible at run time.

Conclusion

.NET built-in configuration providers are a great start. JSON provider is suitable for multiple use cases both in development and production. Injecting environment variables are a good choice for both Docker and Azure apps. Azure key Vault and Consul are advanced use case -scaling up- where you want to store the configurations in a centralized store and share them between multiple instances or containers.