ansible-fleet-change

name	ansible-fleet-change
description	Use when a change must be applied to multiple hosts — write an Ansible playbook, run it with explicit authorization, log /CHANGES.md entries per host, and verify each target.
version	1.0.0
author	Hermes Agent
license	MIT
platforms	["linux"]
metadata	{"hermes":{"tags":["ansible","fleet","multi-host","automation","playbook"],"related_skills":["linux-triage","linux-change-safety"],"related_skill_classifications":{"linux-triage":"bundled","linux-change-safety":"bundled"}}}

Ansible Fleet Change

Trigger

A change is authorized for multiple hosts. Prefer Ansible over per-host SSH.

Prerequisites

• Ansible is installed on the control node and the inventory exists.
• Target systems are properly defined and accessible.
• Access is configured (SSH keys, become, etc.).
• The operator has confirmed the target group or pattern.

Workflow

1. Identify the target hosts from inventory:

   ansible <group> --list-hosts
   

   Confirm with the operator before proceeding.

2. Start with a canary host — one non-critical system:

   ansible-playbook playbooks/<change>.yml --limit <canary-host> --check
   

   Review the check output. If clean, run without --check:

   ansible-playbook playbooks/<change>.yml --limit <canary-host>
   

   Verify the result on the canary:

   ansible <canary-host> -m command -a 'systemctl is-active <service>'
   ansible <canary-host> -m shell -a 'tail -3 /CHANGES.md'
   

3. After canary success, roll to the fleet:

   ansible-playbook playbooks/<change>.yml --limit <group>
   

4. Write /CHANGES.md as a playbook task, not from memory afterward. Add to your playbook:

   - name: Log change in /CHANGES.md
     ansible.builtin.lineinfile:
       path: /CHANGES.md
       line: "{{ ansible_date_time.date }};{{ ansible_date_time.hour }}{{ ansible_date_time.minute }};BOB_HERMES_AGENT;{{ change_reason }};{{ downtime }};{{ error_description }};{{ solution_description }}"
       create: yes
       mode: '0600'
       owner: 
        
     
        
        
        
        
   

Safety rules

• --check does NOT protect command/shell/raw/script modules. Only use these during investigation if the command is provably read-only. For change playbooks, use native modules (copy, template, lineinfile, systemd, package) that respect --check.
• Always canary first. Full group roll only after the canary is verified.
• The playbook and inventory are version-controlled. Commit the playbook with a message after use:

  git add playbooks/<change>.yml
  git commit -m "feat: add playbook for <change-description>"
  

• Ansible writes to control-node files, not target files. A change to the control node (playbook, inventory) is not logged in the target's /CHANGES.md — it's logged in the control node's git history.

Pitfalls

• ansible <group> -m shell runs on the control node if the group is empty. Always --list-hosts first.
• Variable precedence: playbook vars < group_vars < host_vars < extra vars. If a value is unexpectedly overridden, check all precedence levels.
• Permissions inside a loop: become inside with_items requires become: yes on the loop task, not just on the play.
• The lineinfile create: yes option creates the file at root-owned, but with the default umask if mode is not set.

Verification

• Target list confirmed with operator
• Canary host check passed
• Fleet run completed without failures
• /CHANGES.md entries exist on each target
• Service health confirmed on all targets
• Playbook committed to version control
• Rollback playbook exists or rollback steps are documented