What the term means
Every computer has a configuration: which software is installed, which versions, which settings are switched on, which accounts exist, which ports are open. For one machine, you can hold much of that in your head. For fifty or five hundred machines, you cannot.
Configuration management is the practice of defining how systems should be set up, applying that setup consistently, and keeping track of changes over time. The goal is that systems meant to be alike are alike, and that when they differ, someone knows why.
The phrase is also used in a different sense in formal service management, where it refers to keeping a record of the items an organization relies on and how they relate to each other. This article is about the practical, technical meaning: making sure the settings on your systems are what you intend them to be.
The problem: drift
Imagine two web servers installed on the same day from the same instructions. Over the following months, an administrator fixes a problem on one by editing a setting. Someone installs a tool on the other for a quick test and forgets to remove it. A security update is applied to one but is missed on the other. A year later, the two behave differently, and nobody can say exactly how.
This slow divergence is often called configuration drift. It causes real trouble:
- A change that works on one server fails on another for reasons nobody can see.
- Problems are hard to reproduce, because no two systems are truly identical.
- Security gaps appear where a setting was changed and never changed back.
- Replacing a failed server means guessing at what it was running.
Desired state
Most configuration management tools are built around one central idea: you describe the desired state, and the tool works out how to get there.
A desired-state description might say that a certain package should be installed, a certain service should be running, a certain file should contain certain settings and a certain account should not exist. It does not list the steps for achieving this. The tool checks the current state and makes only the changes needed.
This has a useful property called idempotence: running the same definition a second time changes nothing if the system already matches. That makes it safe to apply repeatedly, which is how drift gets corrected. If someone changes a setting by hand, the next run of the tool puts it back, or at least reports it.
Two common approaches
Tools in this area tend to differ in how they apply changes.
Push. A central machine connects to each target system and applies the configuration when told to. This is simple to understand and gives direct control over timing.
Pull. Each system runs a small agent that periodically contacts a central source, fetches its configuration and applies it. This scales well and corrects drift automatically between runs.
Neither is better in every situation. Organizations choose based on the size of the estate, how systems connect to the network, and how much central control they want.
Where to keep the definitions
The definitions are just text files, so they belong in version control. Doing so gives you a history of every change, the ability to review a proposed change before it is applied, and an easy way to undo a mistake. It also means the answer to “who changed this setting and why?” is written down.
This is the same discipline described in discussions of infrastructure as code. The two ideas overlap: configuration management is typically about the software and settings inside a machine, while infrastructure as code is often about creating the machines and networks in the first place. Many teams use both.
Applying changes safely
Consistency also means a mistake spreads consistently. A bad setting pushed to every server at once can cause a large outage. A few habits reduce that risk.
- Test first. Apply a change to a test environment that resembles production, and check the result.
- Roll out in stages. Apply it to a small group of systems, watch for problems, and then widen the rollout.
- Review changes. A second pair of eyes catches errors that the author misses.
- Keep changes small. Many small changes are easier to understand, and to undo, than one enormous one.
- Have a way back. Know how you would revert before you start.
These steps fit within an organization’s change management process, which can be lighter when changes are small, tested and reversible.
What to manage
It is tempting to begin by managing everything. A more realistic approach is to start with the settings that matter most and cause the most pain when they differ. Common starting points include:
- Operating system updates and patch management settings
- Installed software and its versions
- Security settings, such as firewall rules and the accounts allowed to log in
- Application settings that must match across servers
- Time settings, logging settings and monitoring agents
Secrets such as passwords and keys need particular care. They should not sit in plain text in a shared repository. Use the secret storage features of your tools or environment.
Keeping a record of what exists
Configuration management works best when you also know what you have. An inventory of systems, their owners and their purposes helps you decide what each definition should apply to. It connects naturally to asset management, since you cannot keep a device consistent if you do not know it exists. Unknown machines, sometimes called shadow IT, are a common source of drift because they never receive the standard setup.
Limits and trade-offs
Configuration management takes effort to set up, and the definitions themselves need maintenance. Some systems, such as old appliances or specialized equipment, cannot be managed this way. Over-enthusiastic correction can also cause problems if a tool silently reverses a deliberate emergency change. Teams usually handle this by agreeing that changes go through the definitions, not around them, and by recording any urgent manual fix so it can be added afterward.
For a small environment, a documented standard build and a checklist may be enough. As the number of systems grows, the case for automating the setup becomes stronger. The principle is the same at any size: write down what the system should look like, and check that it does.