Home/Start here/Ansible

Ansible

Ansible sets up machines that already exist. It logs in, runs a list of steps, and logs out.

How it actually works

You write a file listing the steps you want carried out. Ansible connects to each machine over SSH, or WinRM for Windows, and does them in order. There is no agent to install on the machines first, which is the main reason people pick it.

- name: Make sure the log shipper is running
  hosts: web
  tasks:
    - name: Install the package
      ansible.builtin.package:
        name: rsyslog
        state: present

    - name: Write the config
      ansible.builtin.template:
        src: rsyslog.conf.j2
        dest: /etc/rsyslog.conf
      notify: restart rsyslog

Read that as a checklist. Each step describes the state the machine should be in, and Ansible works out whether anything needs doing. state: present means the package should be installed. If it already is, Ansible reports "ok" and moves on.

What a run looks like

Running the SSH quick start against one host for the first time. Output is trimmed to the lines that matter:

PLAY [Lock SSH down to keys only] *************************************

TASK [Gathering Facts] ************************************************
ok: [web-01]

TASK [Look for an authorized key on the account we connected as] ******
ok: [web-01]

TASK [Stop if there is no key, because turning off passwords would lock us out]
ok: [web-01] => {"msg": "Key found, safe to continue."}

TASK [Make sure the drop-in directory exists] *************************
ok: [web-01]

TASK [Make sure the main config reads the drop-in directory] **********
ok: [web-01]

TASK [Write the hardening settings] ***********************************
changed: [web-01]

RUNNING HANDLER [Reload sshd] *****************************************
changed: [web-01]

PLAY RECAP ************************************************************
web-01 : ok=7  changed=2  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Seven steps ran. Two changed something: the settings file was written, and that triggered the reload. Now run exactly the same thing again:

PLAY RECAP ************************************************************
web-01 : ok=6  changed=0  unreachable=0  failed=0  skipped=0  rescued=0  ignored=0

Six this time, because the reload only runs when something changed.

changed=0 on the second run is the result you want. It means the machine was already correct and Ansible did nothing. If that number stays above zero run after run, a step is redoing work every time, which usually means it is written as a raw command, which cannot check first, where a module would.

That is the whole idea behind the word idempotent, and it is what makes it safe to run this nightly across four hundred machines.

The four words you need

Why "ok" is the good result

Run a playbook and every step reports one of three things: ok means it was already correct, changed means Ansible fixed it, and failed means it could not. A second run of the same playbook should be all ok. If it keeps reporting changed on every run, a step is written badly and is redoing work each time.

That property has a name, idempotent, and it is what makes it safe to run the same playbook nightly across a whole fleet.

What Ansible is good at

• Installing and configuring software across many machines at once
• One-off fleet jobs, such as checking a setting on 400 servers before an audit
• Machines you cannot install an agent on, including network gear and appliances
• Steps that must happen in a specific order, which Terraform deliberately avoids

What to use something else for

Creating the machines. Ansible has modules that can build cloud resources, and they work, but they do not keep a record of what they made the way Terraform does. Build with Terraform, configure with Ansible.