Application configuration management is about the configuration that an application depends on at runtime, which is different from the static configuration of a project. This article is a summary drawn from real development work, offered for your reference; discussion is welcome too.
1. About Configuration Management
1.1 Terminology
- Configuration item
A single key=value pair
- Configuration set
A collection of configuration items, key1=value, key2=value2
- Configuration instance
A complete set of configuration items that an application can use directly.
1.2 What Configuration Management Does
- Version control
Track versions of the configuration items, configuration sets, and configuration instances you create, and support operations such as rollback.
- Change control
Control, operate on, classify, and record changes to configuration.
- Configuration audit
Review configuration for consistency, conformance to conventions, and correctness.
1.3 Why Configuration Management Is Hard
During iterative development, configuration can be changed by anyone, at any time, from anywhere. At different times, at different levels of an application’s topology, and by different people, configuration items, configuration sets, and configuration instances may all be modified. We need a flexible approach that supports these complex scenarios.
Configuration is complex, sensitive, and high-impact. A single configuration instance may hold hundreds of configuration items, including sensitive information such as accounts and passwords, and a wrong configuration can take an entire service offline.
Flexibility in configuration management and constraints on configuration instances are the two sides a configuration management product has to balance. How to satisfy all the usage scenarios while using certain constraints to prevent some mistakes from happening is the hard part of configuration management.
2. Common Configuration Management Models
2.1 The CICO Model
The CICO model focuses mainly on version control of individual files: files are versioned and stored in a repository.
- The user must checkout a file to access it
- A modified file is checked in to the repository, producing a new version
2.2 The Organization Model
Configuration under the organization model consists of two parts:
- The system model, which lists all the components that make up the system
- Version selection rules, which specify the version of each component that makes up the configuration
2.3 The Long Transaction Model
The long transaction model treats configuration management as a transaction a developer performs on configuration. A series of change results generates a series of configuration versions, which we call a development path.
2.4 The Change Set Model
The change set model describes configuration as a baseline plus a set of change sets. The baseline can be understood as a milestone version: the endpoint of one iteration and the starting point of the next.
3. A New Configuration Management Model
3.1 The Problem We Ran Into
Models such as CICO come from fairly old papers and books, and they cannot be applied directly when building a PaaS platform to manage configuration.
Take the CICO model: it uses SVN and GIT to manage files, but it never emphasizes that configuration is stored in files, or what those files actually refer to. The organization model, by contrast, looks more like configuration management for a large PaaS platform made up of several sub-modules, each with its own independent configuration β a shape suited to managing the application configuration of a group of microservices.
3.2 The Assembly Model
The old models cannot satisfy the PaaS platform scenario, but they do offer some inspiration. If we generalize physical components into elements, the organization model can evolve into the assembly model. As shown below:
Configuration instance = default configuration set + environment configuration set + cluster configuration set
Using the definition of the application topology, and based on the level the application belongs to, we define a set of priority relationships and merge the configuration sets defined at each level into a single configuration instance.
The assembly model produces a configuration instance by assembling several elements, but different configuration instances of the same application may contain different sets of Keys. That variance raises the cost of configuration management and also increases the risk of configuration errors, and it cannot directly satisfy the constraint on configuration completeness.
3.3 The Template Model
Starting from the requirement for completeness, and inspired by the change set model, we arrive at the template model. As shown below:
The template model requires defining a template for the configuration instance. Following the structure of the application topology, several change sets are formed and applied over the configuration instance template to produce the final configuration instance.
The template model strengthens the constraints on the Keys of a configuration instance and guarantees strong consistency, which avoids incidents caused by a missing Key.
But strong consistency constraints also come at the cost of flexibility, so they need to be used together with the publish state of configuration items and configuration sets.
