configuration-management

Configuration Management

A shell script installs a package. A configuration management tool declares that the package should be installed — and then checks, every time it runs, whether that's already true before doing anything. That distinction is the entire value: a script run twice can fail or duplicate work, but a well-written playbook run a hundred times against a host that's already correct does nothing at all, safely.

Ansible, Chef, and Puppet exist to describe desired state, not a sequence of steps. The moment a task is written as an imperative command instead of a declared outcome, that guarantee is gone.

If running the same playbook twice changes anything the second time, it isn't idempotent — and if it isn't idempotent, it isn't safe to run in a hurry, which is exactly when you'll need to.

1. Write tasks that declare an outcome, not a command

command: apt-get install -y nginx runs every time, whether or not nginx is already there, and Ansible has no way to know if it changed anything. The apt or package module, by contrast, checks state first and reports back "changed" or "ok" honestly.

- name: Ensure nginx is installed and running
  apt:
    name: nginx
    state: present
- name: Ensure nginx is enabled and running
  service:
    name: nginx
    state: started
    enabled: true

• Prefer the module over the raw shell command whenever one exists for the resource type — package, file, service, user — because the module already encodes the idempotency check.
• When a shell command is unavoidable, add an explicit creates:, changed_when:, or equivalent guard so the run can still report truthfully.
• Treat every "changed" in a run against an already-configured host as a bug to investigate, not background noise.

Done when: running the playbook twice in a row against the same host reports zero changes on the second run.

2. Model the fleet as an inventory, not a list of one-off hosts

Configuration management earns its keep at scale, and that requires hosts to be grouped by role and environment so a change can target "all web servers in staging" instead of a hand-maintained list of IPs someone has to update every time a server is added or removed.