Ansible.

A playbook is the YAML file you run, and it holds one or more plays in order. A play maps a group of hosts to the tasks that run on them, and sets how those tasks run. A task is one unit of work that calls a single Ansible module, such as yum or service.

A play's hosts line picks machines from the inventory, and play keywords such as become or vars apply to every task in it. A playbook with two plays can set up the web servers first and the databases second.

By default, Ansible runs each task on every host in the play before it starts the next task.

# Playbook
- name: Web server setup          # Play 1
  hosts: webservers
  tasks:
    - name: Install Apache        # Task 1
      yum:
        name: httpd
        state: present
    - name: Start Apache          # Task 2
      service:
        name: httpd
        state: started

An inventory lists the hosts Ansible manages and sorts them into groups that playbooks target by name, such as webservers. There are two types.

A static inventory is a file you write by hand, in INI or YAML. Groups can hold other groups, as production does here.

[webservers]
web1.example.com
web2.example.com

[databases]
db1.example.com ansible_host=192.168.1.100
[production:children]
webservers
databases

Here is the same webservers group in YAML.

all:
  children:
    webservers:
      hosts:
        web1.example.com:
        web2.example.com:

A dynamic inventory builds the host list at run time from a source such as AWS, Azure or GCP. It suits the cloud, where hosts come and go. Ansible recommends inventory plugins for this over the older inventory scripts. A script can use any language that prints the hosts and groups as JSON.

Ansible facts are details Ansible collects about each managed host, such as its OS, hardware and network configuration. By default, the setup module gathers them at the start of every play. You read them from ansible_facts, or as top-level variables with an ansible_ prefix. Installed packages are not part of the default facts. The package_facts module collects those when you need them.

Facts let one playbook adapt to each host.

- name: Display OS information
  debug:
    msg: "This host runs {{ ansible_distribution }} {{ ansible_distribution_version }}"
- name: Conditional based on facts
  yum:
    name: httpd
    state: present
  when: ansible_os_family == "RedHat"

You can also set facts of your own. set_fact sets them for the rest of the run.

- name: Set custom fact
  set_fact:
    custom_variable: "custom_value"

When a play never reads facts, set gather_facts: false on the play. It skips the gathering step, which speeds up runs on large inventories.

- name: Disable fact gathering
  hosts: webservers
  gather_facts: false

Agentless means Ansible installs nothing permanent on the managed nodes it controls. The control node connects to each managed node over SSH and pushes small programs called modules. It runs them there, then removes them when they finish. Windows nodes usually connect over WinRM instead.

A Linux or Unix managed node needs only Python and a user account Ansible can log in with over SSH. There is no daemon to install, upgrade or secure on every node.

Puppet works the other way. Each managed node runs a Puppet agent that pulls a compiled catalog from a primary server and applies it. That pull model corrects drift on every agent run, but every node needs the agent installed and maintained.

Ansible pushes changes when you run a playbook, so changes happen when you choose. ansible-pull inverts this, so each node fetches playbooks from Git and runs them itself, usually from cron.

An ad-hoc command is a one-off, while a playbook is reusable. The ad-hoc command runs one module against a set of hosts, straight from the command line with the ansible tool. The playbook is a YAML file of ordered plays and tasks. You run it with ansible-playbook and keep it in version control.

# Check that every web server responds
ansible webservers -m ansible.builtin.ping
# Restart a service on all of them, with sudo
ansible webservers -m ansible.builtin.service -a "name=httpd state=restarted" --become
# Reboot a group of servers
ansible atlanta -a "/sbin/reboot"

-m picks the module and -a passes its arguments. Without -m, Ansible runs the command module.

Use ad-hoc commands for quick, one-off jobs, such as checking connectivity or rebooting a group of servers. They are fast to type but not reusable.

Use a playbook for anything you will repeat or review. It chains many tasks with variables, handlers and roles, and it runs the same way every time. Both call the same modules, so an ad-hoc command that works turns into a playbook task almost word for word.

ansible.cfg sets Ansible's defaults for a project, such as the inventory path, the remote user and how many hosts to run at once. Ansible reads only the first config file it finds, in this order:

1. The file named in the ANSIBLE_CONFIG environment variable
2. ansible.cfg in the current directory
3. ~/.ansible.cfg in your home directory
4. /etc/ansible/ansible.cfg

The others are ignored, not merged. So keep an ansible.cfg in each project's root and run Ansible from there, and every teammate gets the same settings.

[defaults]
inventory = ./inventory
remote_user = deploy
forks = 20

[privilege_escalation]
become = true

Two catches. Ansible skips an ansible.cfg in a world-writable current directory, because another user could plant one there. And config settings have the lowest precedence: an ANSIBLE_ environment variable overrides the file, and command-line options, playbook keywords and variables override both.

Encrypt secrets with Ansible Vault, keep them out of task output with no_log, and keep the vault password out of the repository. Vault encrypts a whole file or a single variable, so the encrypted content can sit in source control beside the playbooks. When a playbook runs, you supply the vault password and Ansible decrypts what it needs.

# Encrypt a file
ansible-vault encrypt secrets.yml

# Decrypt a file
ansible-vault decrypt secrets.yml

# Edit encrypted file
ansible-vault edit secrets.yml

# Run playbook with vault password
ansible-playbook site.yml --ask-vault-pass

# Use vault password file
ansible-playbook site.yml --vault-password-file .vault_pass

Encrypting only the sensitive values keeps the rest of a vars file readable in code review.

# vars.yml
username: john
password: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  66386439653762356265343432393730...

Four habits keep it safe:

• Keep the vault password in a file only its owner can read, set with chmod 600, and never commit it.
• Use a separate vault file for each environment, each with its own password.
• Encrypt only the sensitive variables, not entire playbooks.
• Add no_log: true to tasks that handle secrets. Vault protects data only at rest, so a decrypted value would otherwise show up in output and logs.

When many teams share secrets or rotate them often, fetch them at run time from an external manager such as HashiCorp Vault instead.