Ansible Tutorial: Anatomy of Ansible playbook defined!

• 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 playCode language: PHP (php)

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:

Code language: PHP (php)

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.Code language: PHP (php)

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

Rajesh Kumar

I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.

I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.