- 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-foobar/ ├── defaults │ └── main.yml ├── vars │ └── main.yml ├── files | └── foobar.txt ├── handlers │ └── main.yml ├── meta │ └── main.yml ├── tasks │ └── main.yml └── templates └── foobar.conf.j2