Configuration Management Automation

Configuration management automation ensures that every server in your fleet is configured identically, every time, without manual intervention. It solves the “works on my machine” problem at the infrastructure level by codifying server state and making it reproducible, auditable, and version-controlled.

Tool Comparison

Feature	Ansible	Chef	Puppet	SaltStack
Architecture	Agentless (SSH)	Agent + server	Agent + server	Agent + master
Language	YAML (playbooks)	Ruby (recipes)	Puppet DSL (manifests)	YAML (states)
Learning curve	Low	High	Medium	Medium
Push vs. Pull	Push	Pull	Pull	Both
Best for	Ad-hoc + orchestration	Complex infrastructure	Large fleet management	High-speed execution
Community	Largest	Large	Large	Medium
Cloud-native fit	Excellent	Good	Good	Good

When Ansible Wins

Ansible dominates in cloud-native environments because it requires no agent installation, uses SSH (already available), and its YAML syntax is readable by non-specialists. For immutable infrastructure (containers, serverless), Ansible handles the provisioning step that Terraform orchestrates.

Inventory Management

Approach	How It Works	Best For
Static inventory	INI or YAML file listing hosts	Small, stable fleets
Dynamic inventory	Script queries cloud provider API	Cloud environments (AWS, Azure, GCP)
Service discovery	Consul, etcd, or cloud tags	Dynamic container environments
Hybrid	Static for core, dynamic for cloud	Mixed environments

Idempotency: The Core Principle

Idempotent (correct):
    - Ensure nginx is installed                 → installs only if missing
    - Ensure config file has these contents     → updates only if different
    - Ensure service is running                 → starts only if stopped

Non-idempotent (dangerous):
    - Run "apt-get install nginx"               → may fail if already installed
    - Run "echo config >> /etc/nginx.conf"      → appends duplicate lines
    - Run "service nginx restart"               → restarts even if unnecessary

Configuration Drift Detection

Method	How	Frequency
Config management dry-run	Ansible `--check`, Puppet `--noop`	Daily
Infrastructure scanning	AWS Config, Azure Policy	Continuous
Custom scripts	Compare actual vs. expected state	Scheduled
Compliance tools	InSpec, OpenSCAP	Weekly

Drift Remediation Strategies

Strategy	When to Use	Risk
Auto-remediate	Low-risk configs (NTP, DNS, agents)	Low
Alert and investigate	Security configs, access controls	None (manual)
Rebuild	Immutable infrastructure, containers	None (replace instead of fix)
Ignore	Known acceptable deviations	Documented exceptions only

Role/Cookbook Structure (Ansible Example)

roles/
├── common/                  # Base configuration for all servers
│   ├── tasks/main.yml       # Install packages, configure NTP, set hostname
│   ├── handlers/main.yml    # Service restart handlers
│   ├── templates/           # Jinja2 templates for config files
│   ├── files/               # Static files to copy
│   └── defaults/main.yml    # Default variables (overridable)
├── webserver/               # Nginx/Apache configuration
├── database/                # PostgreSQL/MySQL setup
├── monitoring/              # Prometheus agent, log shipping
└── security/                # Firewall rules, SSH hardening, fail2ban

Secrets Management

Approach	Tool	Best For
Encrypted variables	Ansible Vault, Chef Encrypted Data Bags	Simple secrets
External secrets manager	HashiCorp Vault, AWS Secrets Manager	Dynamic secrets, rotation
Environment variables	CI/CD injection	Build-time secrets
SOPS	Mozilla SOPS	Git-committed encrypted files

Anti-Patterns

Anti-Pattern	Problem	Fix
Non-idempotent tasks	Re-running breaks servers	Use modules/resources that check state first
Secrets in plaintext	Exposed in version control	Ansible Vault, external secrets manager
No dry-run testing	Untested changes applied to production	Always `--check` before `--apply`
Snowflake servers	Each server configured differently	Full configuration-as-code, immutable where possible
No drift detection	Servers diverge from defined state	Scheduled dry-runs + alerting on differences
Running as root	Privilege escalation risk	Use become/sudo only when necessary

Checklist

:::note[Source] This guide is derived from operational intelligence at Garnet Grid Consulting. For infrastructure automation consulting, visit garnetgrid.com. :::