- A Play performs one or more Tasks against one or more Managed Nodes.
- Each playbook is composed of one or more ‘plays’ in a list.
- A play map a group of hosts to some well defined roles, represented by tasks.
- Plays run in the order specified: top to bottom.
Example
---
- name: Start the Play # describes WHAT we are doing
- hosts: all # one or more group or host patterns
order: sorted # Host order: value can be 'inventory' ie as is in the inventory file, reverse_inventory, sorted (alpha), reverse_sorted, shuffle (random)
remote_user: yourname # or root This property was called user before Ansible 1.4
become: yes # optional
become_user: postgres # optional
gather_facts: False
order: inventory # Default
connection: local or network_cli
serial: 1 OR 30%
max_fail_percentage
strategy: free
any_errors_fatal: True
where:
--- separates play
host defines the target machines: one or more groups or host patterns, separated by colons that should match hosts in the inventory. all is a group that means all hosts in the inventory file.
remote_user, become and become_user are connection variable
remote_user defines the default logging remote user (The remote user can also be defined for a task)
gather_facts defines if fact must be gathered
become and become_user defines user escalation mechanism
gather_facts defines if fact must be gatheredgather_facts defines if fact must be gathered
order – Control the order in which hosts are run. The default is to follow the order supplied by the inventory. Possible values for order are:
inventory: The default. The order is ‘as provided’ by the inventory
reverse_inventory: As the name implies, this reverses the order ‘as provided’ by the inventory
sorted: Hosts are alphabetically sorted by name
reverse_sorted: Hosts are sorted by name in reverse alphabetical order
shuffle: Hosts are randomly ordered each run.
max_fail_percentage – max_fail_percentage can be used to abort the run after a given percentage of hosts has failed.
strategy – A strategy ships with Ansible – free – which allows each host to run until the end of the play as fast as it can.
serial – You can define how many hosts Ansible should manage at a single time by using the serial keyword. The serial directive can ‘batch’ this behaviour to a subset of the hosts, which then run to completion of the play before the next ‘batch’ starts. The serial keyword can also be specified as a percentage, which will be applied to the total number of hosts in a play, in order to determine the number of hosts per pass:
any_errors_fatal – With the ‘’any_errors_fatal’’ option, any failure on any host in a multi-host play will be treated as fatal and Ansible will exit immediately without waiting for the other hosts.
Lets understand each piece, let’s look at the overall construction of a Play.
---
- name: Start the Play # describes WHAT we are doing
hosts: application # describes WHERE we are doing it (e.g. against all application hosts)
become: false # describes HOW we are doing it (with priviledge escalation, by gather facts, serial batches, etc)
gather_facts: true
serial: 10
vars:
app_path: /opt/app
environment:
PATH: /my/folder:
pre_tasks:
roles:
tasks:
post_tasks:
Playbook – A Playbook is a file containing one or more Plays.
--
- name: Start the first Play # describes WHAT we are doing
hosts: application # describes WHERE we are doing it; what target hosts
become: false # describes HOW we are doing it (with priviledge escalation, by gather facts, serial batches, etc)
gather_facts: true
serial: 10
# vars, environment, pre_tasks, roles, tasks, post_tasks, etc.
- name: Start the second Play
hosts: webservers
become: true
gather_facts: false
serial: 5
# vars, environment, pre_tasks, roles, tasks, post_tasks, etc.
Role
role-foobar/
├── defaults
│ └── main.yml
├── vars
│ └── main.yml
├── files
| └── foobar.txt
├── handlers
│ └── main.yml
├── meta
│ └── main.yml
├── tasks
│ └── main.yml
└── templates
└── foobar.conf.j2
- Best AI tools for Software Engineers - November 4, 2024
- Installing Jupyter: Get up and running on your computer - November 2, 2024
- An Introduction of SymOps by SymOps.com - October 30, 2024