Ansible

How it works

Ansible runs from a control node and connects to managed nodes, normally over SSH for Linux and over WinRM for Windows. There is no agent to install or maintain. Linux targets generally need a suitable Python interpreter, because most modules run on the managed node.

The main building blocks are:

• Inventory: the list of hosts, organised into groups, either as a static file or generated dynamically from a cloud provider.
• Playbooks: YAML files describing which tasks run on which hosts.
• Modules: the units of work, such as installing a package, copying a file or managing a service.
• Roles: reusable bundles of tasks, templates, variables and handlers.
• Handlers: tasks that run only when notified by a change, for example restarting a service after its configuration file changes.

Most modules are designed to be idempotent: they check the current state and change something only when it differs from the desired state, so repeated runs converge on the same result. Not every task is idempotent, especially raw shell commands, so these need conditions such as creates or changed_when.

A practical example

Ad hoc commands that ensure a web server is installed and running on every host in the web group:

ansible web -i inventory.ini -b -m ansible.builtin.package -a "name=nginx state=present"
ansible web -i inventory.ini -b -m ansible.builtin.service -a "name=nginx state=started enabled=true"

The same two modules would normally be written as tasks in a playbook and run with ansible-playbook. Running either form a second time should report no changes, which is idempotency in practice.

Common mistakes

• Using command or shell where a purpose built module exists, which loses idempotency and reporting.
• Storing secrets in plain text variables rather than using Ansible Vault or an external secrets manager.
• Writing one very large playbook instead of small, tested roles.
• Skipping --check and linting before running against production.
• Hard coding host addresses instead of using inventory groups and variables.

When to use it and when not to

Ansible suits server configuration, patching, application deployment and orchestrating steps across tiers. For creating cloud resources such as networks and databases, a declarative provisioning tool like Terraform is usually a better fit, and the two are commonly combined. Ansible is also less suited to continuously reconciling Kubernetes state, where GitOps tools do that job.

See our Ansible configuration management service and the Ansible technology page.

See also

• Terraform
• Infrastructure as Code