Configuration and Infrastructure Automation
Published on
Infrastructure automation contains several related responsibilities:
| Responsibility | Typical output | Examples |
|---|---|---|
| Image building | Immutable machine or container image | Packer, Docker or BuildKit |
| Provisioning | Cloud and platform resources | Terraform, OpenTofu, cloud-native templates |
| Configuration management | Host packages, files, and services | Ansible, Chef, Puppet |
| Orchestration | Desired workload placement and lifecycle | Kubernetes controllers |
| Policy | Decision about an attempted change | Organization policy, admission control, policy engines |
The boundaries can overlap. Choose a source of truth for each resource and avoid two controllers continuously fighting over the same field.
Prefer immutable replacement when it reduces configuration drift, but retain configuration management for bootstrap, legacy systems, and tasks where replacement is impractical. Make every automation path idempotent where possible, observable, versioned, and recoverable.
Continue with Infrastructure as Code for state, plans, modules, policy, drift, and break-glass reconciliation.
Last updated on