Ansible

Ansible Tutorial: Anatomy of Ansible playbook defined!

August 18, 2022 Leave a Comment
  • 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
Rajesh Kumar
Follow me
Latest posts by Rajesh Kumar (see all)
Subscribe
Notify of
guest
0 Comments
Inline Feedbacks
View all comments
0
Would love your thoughts, please comment.x
()
x