Configuration management
Configuration management (CM) is the discipline of keeping the configuration of systems under control: knowing what state each system is supposed to be in, recording how it got there, and reproducing that state consistently across hosts and environments. In software operations the term most often refers to the automated configuration of servers and services – declaring the desired state of a machine in code and having a tool converge the machine toward that state, rather than logging in and configuring it by hand.
Manual configuration drifts. Two servers built by different people on different days end up subtly different, and those differences become the source of hard-to-diagnose production faults. Configuration management tools address this by making the desired configuration version controlled, declarative, and automatically applied. The same configuration recipe can be applied to a development laptop, a staging cluster, and a production fleet, so that environments behave the same way.
The classical generation of CM tools – Chef, Puppet, Ansible, and SaltStack – emerged to manage long-lived servers. They model the system as a set of resources (packages, files, services, users) and either enforce the desired state continuously (Chef, Puppet, Salt) or apply it imperatively on demand (Ansible). Recipes, manifests, playbooks, and states are all expressions of the same idea: configuration expressed as code that can be reviewed, tested, and replayed.
Containerization and container orchestration shifted the emphasis. A container image bakes its own configuration in at build time, and an orchestrator such as Kubernetes takes responsibility for converging the cluster toward a declared desired state. Runtime configuration that still needs to vary between deploys – credentials, feature toggles, environment-specific endpoints – is supplied separately through mechanisms like Kubernetes ConfigMaps and Secrets, following the 12-factor app principle that config lives in the environment, not in the artifact.
Configuration management overlaps with infrastructure as code (IaC), and the two terms are sometimes used interchangeably. The distinction is one of scope. Configuration management concerns the state of machines and services that have already been provisioned. IaC extends the same declarative, version-controlled approach to provisioning the infrastructure itself – networks, load balancers, storage, compute instances – before anything is configured on it. Tools like Terraform and Pulumi sit primarily on the IaC side, while Chef, Puppet, and Ansible sit primarily on the CM side.
Configuration management is a foundational practice of DevOps and a precondition for reliable CI/CD. When infrastructure configuration is repeatable and checked in, a deployment pipeline can tear down and rebuild whole environments on every change, which is what makes continuous deployment safe to attempt at all.