Ansible Basics

Automation that's idempotent

Ansible is automation built on SSH. It connects to managed hosts via SSH and runs commands directly — no agent software needed on the targets. You write playbooks (YAML files describing desired state), and Ansible converges machines toward that state. Run a playbook twice and the second run does nothing if everything's already correct — that's idempotence, the property that makes Ansible safe to re-run.

The mental model

Inventory — your list of hosts (you have one already at ~/.fleet/all.txt).
Modules — building blocks: ping, command, copy, file, apt, brew, service, git, etc. Each one is idempotent.
Playbook — YAML describing a multi-step task ("install these packages, copy these files, restart this service").

Why Ansible over shell scripts

A shell script tells the machine what to do. A playbook describes what state to be in. The first runs commands; the second checks state and acts only if needed. Re-running an idempotent playbook is safe; re-running a script that creates files might make duplicates, restart services unnecessarily, or fail on the second pass.

Code

Install and try ad-hoc commands·bash

# Install
brew install ansible
# or
pip install ansible

# Test connectivity to all hosts
ansible all -m ping -i ~/.fleet/all.txt

# Run an arbitrary command
ansible all -a 'uptime' -i ~/.fleet/all.txt

# Just one group (an inventory file with [groups] supports this)
ansible workstations -a 'df -h /' -i inventory.ini

Inventory file format·ini

# inventory.ini — instead of plain ~/.fleet/all.txt
[workstations]
office
server
music
worker

[laptops]
macbook
pro2024
pro2023
air

[other]
mini

[all_macs:children]
workstations
laptops
other

Exercise

Install Ansible (brew install ansible). Test reachability across the fleet: ansible all -m ping -i ~/.fleet/all.txt. Every host should reply with pong. Now ansible all -a 'uptime' -i ~/.fleet/all.txt. Compare the output formatting to bash loops — Ansible's structured output is what makes it scale.