How to manage configuration files in microservice architecture among multiple deployment environments?

Question

I'm looking for a way to manage configuration files for multiple modules in a large system using microservice architecture (.NET Core).

Currently we have 5 modules and counting. Each module comprises 2 projects (say UI and API). Each project has different configuration for 3 environments Dev, Staging, Production.

5 modules x 2 projects x 3 environments = 30 configuration files.

Many of the projects need the same configuration values repeated verbatim for all development environments (for example where a shared package requires configuration).

Much of the time the same configuration is required for each project and environment, but sometimes it varies and sometimes it is completely project specific.

This is only going to get worse. More modules will be added and the configuration files will get bigger. A solution I'm mulling over is to write a script that does a find and replace in all configuration files based on a master configuration file that has all values for all projects and environments.

But even this seems daunting as I'm not yet sure how I'd layout the master configuration file or make it clear which configuration keys belonged to which projects.

This is becoming very difficult to manage and I'd like to know if anyone has a good process for managing this?

Answer 1

Common configuration is anathema in microservices architecture. The entire point is that they're suppose to be discrete, self-contained units of functionality. If one or more are doing the same thing(s), then you haven't properly subdivided your domain.

The one exception to this is instrumentation: logging, profiling, tracing, etc. If that is what you're talking about here, then there's a number of ways you can handle it.

1. You can have a separate configuration source for your instrumentation, which doesn't even need to be local to the project. For example, you can create a file like instrumentation.json, put it in a common shared location, and then in Program.cs:

   CreateDefaultWebBuilder()
       ConfigureAppConfiguration(builderContext, config) =>
       {
           config.AddJsonFile(@"\\path\to\instrumentation.json", optional: false, reloadOnChange: true)
        })
        .Run();
   

   You can even have environment specific JSON for the instrumentation:

   IHostingEnvironment env = builderContext.HostingEnvironment;
   config.AddJsonFile($@"\\path\to\instrumentation.{env.EnvironmentName}.json", optional: true, reloadOnChange: true)
   

2. Docker has its own configuration/secrets setup, which you can use to set environment variables or basically however you want to provide it to the app. See: https://docs.docker.com/engine/swarm/secrets/

3. You can use an distributed configuration source like Azure Key Vault. If you don't want to use that specifically, something like SQL Server or Redis would work just as well, but you'd have to either create custom configuration providers for those or source existing third-party libraries.

Answer 2

Try out https://microconfig.io

It is designed exactly for managing microservice configuration with multiple environments.