Understanding playbooks in Ansible

31 / Jul / 2015 by Naina Motwani 0 comments

My previous blog talks about overview of ansible, installation steps and a small demo on basic functionality of ansible.

Ref Link
Ansible-Configuration Management System

This blog will help you understand the basics of playbook and its terminologies.

Ansible Playbook

A playbook consists of simple set of steps called tasks that run on remote machines defined in inventory file. These tasks are written in simple text language(YAML), which is much easier to understand as compared to XML, JSON, etc.

YAML basics required to understand playbooks can be found in ansible documentation.

Ref Link

A playbook can have ‘n’ number of plays in a list. In the following example, the first play has set of tasks for ubuntu servers and the second for centos servers. Grouping of hosts can be done in the inventory file.

Sample inventory file


Sample playbook

1st Play
– hosts: ubuntu
sudo : yes
– name: Install Jetty
apt: pkg=jetty state=installed
– restart jetty
– name: ensure jetty is running (and enable it at boot)
service: name=jetty state=started enabled=yes
– name: restart jetty
service: name=jetty state=restarted
2nd Play
– hosts: centos
remote_user: root
– name: Install mysql
yum: pkg=mysql state=installed

Basic Terminologies

  • hosts: It can be all/ubuntu/centos(group names as defined in inventory)
  • gather_facts: Whenever ansible interacts with hosts it gathers some information about them such as distribution, os family, etc. This information is called FACTS. We can see this information by calling “setup” module from our command line(ansible hostname -m setup)
  • sudo: Some tasks like installation of packages require root access. This can be achieved by setting sudo directive as yes
  • Handlers: They will only run if a ‘notify’ directive is declared. It is useful in scenarios where a configuration file is changed multiple times and each time it requires a service to be restarted or a machine reboot is required. Handler will make sure that the service is restarted only ONCE.
  • remote_user: We can define remote_user in playbooks. It can be any username that run a set of tasks in remote machines. For eg: If we are running ansible in control node as ubuntu user and we are trying to install a package in centos machine that requires user to be root, in that case we can set remote_user directive.

Command to run ansible playbook

ansible-playbook demo.yml

where ‘demo.yml’ is playbook name

Dry Run mode

ansible-playbook demo.yml –check

This mode does not make any changes to remote machines. This only shows what changes would have been made.


In simple words, tasks can be defined as calls to ansible modules. They are executed from top to bottom. By default ansible run tasks synchronously. Synchronous tasks wait for the current task to complete before moving to the next task.

Example of synchronous Task (Default Behaviour)

– name: Install Jetty
apt: pkg=jetty state=installed
– name: Copies a file from control machine to all hosts
copy: src=/opt/sample.txt dest=/tmp/

name – We can give any descriptive name to a task
apt,copy – modules in ansible

Asynchronous Tasks

Async mode is useful in scenarios where a task takes longer than required say SSH timeout. These tasks can run in background mode and can be checked at a later point of time. We can set ‘poll’ to check the status of a task after ‘n’ number of seconds or we can also set poll to 0 where we fire a task and forget about it. By default, value of poll is 10.

Example of asynchronous Task

– name: asynchronous task example
command: /bin/sleep 20
async: 40
poll: 6


  • Modules are also called as ‘task plugins’ or ‘library plugins’
  • Module is what gets executed in each playbook task
  • All the modules and options supported by them can be found in ansible documentation
  • We can also get list of all modules from command line.

    [js]ansible-doc -l[/js]

  • Options available for each module and sample examples can be found using ansible-doc tool.

    [js]ansible-doc yum[/js]

    where yum is a module name

  • Modules are always shipped with ansible whenever it is installed.
  • Modules are idempotent in nature. It means they are safe to run again and again. They do not make changes if a desired state is already achieved.
  • In the above examples we saw modules such as apt, service, copy, etc. take key value arguments. Most modules except ‘command’ and ‘shell’ do not take key value arguments
  • For eg:
    – name: Copy properties file to hosts
    shell: mv /tmp/sample.properties /usr/share/mars.properties

  • Some modules (such as ping) donot take any arguments at all

If you want to explore more about playbooks please refer ansible documentation

Ref Link


Leave a Reply

Your email address will not be published. Required fields are marked *