Ansible Automation

Use this for repeatable server and infrastructure operations with Ansible.

Project Fit Check

Before changing automation:

1. Read inventories, group vars, host vars, roles, collections, vault policy, runbooks, and CI jobs.
2. Identify target hosts, privilege escalation model, SSH user, environment, and whether changes are safe to run repeatedly.
3. Preserve existing variable naming, role layout, and collection versions.
4. Do not run against production without confirmation of inventory and limit.
5. Treat secrets as vault or external secret-manager material, never plain vars.

Playbook Rules

• Make tasks idempotent; repeated runs should converge without surprise.
• Use handlers for service reloads/restarts.
• Prefer modules over shell commands.
• If shell is necessary, add creates, removes, changed_when, or failed_when.
• Keep templates minimal and render from explicit vars.
• Use tags for operational subsets only when they remain safe alone.
• Scope no_log to the task that carries the secret. On a whole task it censors the failure message along with the secret, so a failed run reports nothing usable. Split it: non-secret arguments in a logged task, the secret argument in its own.

Inventory Rules

• Keep environments explicit: staging, production, homelab, or similar.
• Use group vars for shared policy and host vars for true host differences.
• Avoid embedding secrets or personal paths in inventory.
• Document required external vars and vault files.

Verification

ansible-playbook --syntax-check playbook.yml
ansible-playbook --check --diff playbook.yml
ansible-playbook --limit <safe-target> playbook.yml

Use check mode cautiously; not every module predicts changes perfectly.

Red Flags

• raw shell task where a module exists
• production inventory selected by default
• secret in plaintext YAML
• restart on every run
• unbounded hosts: all for risky changes
• task depends on local machine state without documenting it
• no_log on a task whose failure message you still need to read