This is the fifth post in the series - CD of Microservices. In the previous post, we talked about environment strategy - including artifact promotion and ways to leverage modern infrastructure for dynamic environments. In this post, we will discuss configuration strategy.

Introduction

An application’s configuration is everything that is variable per deployment. If you can re-deploy the same code but switch out certain aspects (like URLs to third party services, ports etc.) these are what I mean by variables. Ideally, configuration should be stored separately from the application code.

In a system based on a microservices architecture, configuration needs to be distributed across multiple services. There are a few ways to manage configurations in a distributed way:

  • storing these application configurations in your config management system (e.g. Chef)
  • checking in application configuration files with the code,
  • or creating environment variables at deploy time.

Here are three things you should consider for your microservices configuration strategy:

1. Manage deployment configurations centrally

If you have configuration living on your CD server, the configuration tends to spread across multiple sources, e.g. Chef and CD pipelines, as a result it becomes hard to understand. One way to avoid the sprawl of configuration is to use central configuration servers like Consul for general configuration and Vault for secrets.

2. Standard process for distributing configuration

For microservices systems, one tends to have different tech stacks across the systems. If one is handling configuration differently for different stacks, then the complexity becomes hard to manage. Therefore, regardless of the tech stack of a microservice, configurations should be distributed to nodes in a standard manner. A technique we use is to make configuration available in the environment per the 12 factor app methodology. As a rule of thumb, always avoid distributing configuration files.

3. Governance policy around secrets

Secrets such as API keys, passwords, and certificates need to be accessed securely. You need a governance process to ensure secrets access is managed appropriately. One technique we recommend to store all secrets is a central secrets store. The central store gives you traceability on how and when policies were changed. That traceability goes a long way in setting up a governance process.

A tool we recommend to store secrets is the Vault by Hashicorp.

Example

This is an example of an architecture where configurations are stored centrally in a config server and updated by the CD pipeline and pushed out to service instances.

At the top there is an abstraction of the CD pipeline. This updates the config server and then the configuration from the config server is pushed to the service instances. At run time, service instances are aware of how to consume this configuration. When setting-up an architecture like this, you need to consider how many configuration servers should you have. We recommend that you have one configuration server per CD environment, or at least one for production and one for all other environments.

Summary

This is the part 5 of our CD of Microservices blog series. We have talked about configuration strategy for your CD pipeline. In the next post, we will talk about the last consideration - remediation strategies for when something goes wrong.