Run it twice: idempotence, roles and Vault
Well-written Ansible tasks are idempotent: running them a second time changes nothing, because the system is already in the described state. Roles package related tasks, templates and defaults for reuse, collections distribute modules and roles, and Ansible Vault encrypts secrets kept beside the playbooks.
Idempotence
A task is idempotent when running it again gives the same result without doing anything new. 'Make sure nginx is installed' installs it the first time and does nothing the second time. That is what makes it safe to rerun a playbook after a half-finished run, or every night to correct drift.
PLAY RECAP *********************************************************
web01.example.com : ok=4 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0changed=0 on a second run is the sign of a well-written playbook. If a task reports 'changed' on every run, it is probably a command or shell task. Make it honest with creates: (skip the task if a file already exists) or changed_when: (say what counts as a change), or replace it with a proper module.
- name: Unpack the release once
ansible.builtin.command:
cmd: tar -xzf /tmp/payroll-1.4.2.tar.gz -C /opt/payroll
creates: /opt/payroll/VERSIONRoles: reusable building blocks
A role packages everything for one job, such as 'nginx' or 'payroll app', in a standard folder layout, so that many playbooks can reuse it. A playbook then lists roles instead of long task lists.
| Folder in the role | Holds |
|---|---|
tasks/main.yml | The role's tasks |
handlers/main.yml | Its handlers |
defaults/main.yml | Default variables, the easiest to override |
templates/, files/ | Jinja2 templates and plain files to copy |
meta/main.yml | Information about the role and its dependencies |
Collections and Galaxy
Modules, roles and plugins are distributed as collections, named namespace.collection, such as ansible.builtin, community.general or ibm.ibm_zos_core. You install them with ansible-galaxy collection install, from Ansible Galaxy or, for certified content, from Red Hat's Automation Hub.
Secrets with Ansible Vault
Playbooks often need passwords. Ansible Vault encrypts a variables file so it can be kept in Git safely: ansible-vault encrypt group_vars/prod/secrets.yml. At run time you supply the vault password, for example with --ask-vault-pass, or a pipeline provides it from its credentials store. Never commit secrets in plain text.
What word describes a task that changes nothing when it is run a second time?
Show a hint
It starts with idem-, Latin for 'the same'.
Show the solution
Idempotent.
Examples are for learning. Run commands and jobs only on a system you are authorised to use, such as a training or test system, and never on production without approval.
Common mistakes
They hide real changes in the noise and trigger handlers needlessly. Use modules, or creates: and changed_when:.
Copies drift apart. Put shared steps in a role and reuse it.
Anyone with access to the repository can read them. Encrypt them with Vault or fetch them from a secrets manager.
What you will see at work
- A nightly run with
--checkis a cheap way to detect servers that someone changed by hand. - Most companies keep an internal set of approved roles and collections, so each team does not reinvent them.
- If a rerun of a deployment playbook reports lots of changes, something is not idempotent, and that is worth fixing before production.
Key terms
Check your understanding.
Take this lesson's quiz and save your progress. Free.