Ansible

Installation
• Mainly, there are two types of machines when we
talk about deployment:
– Control machine: Machine from where we can
manage other machines.
– Remote machine: Machines which are
handled/controlled by control machine.
• There can be multiple remote machines which
are handled by one control machine. So, for
managing remote machines we have to install
Ansible on control machine.
 Control Machine Requirements
• Ansible can be run from any machine with
Python 2 (versions 2.6 or 2.7) or Python 3
(versions 3.5 and higher) installed

• Ansible can be installed on control machine

which have above mentioned requirements in
different ways. You can install the latest
release through Apt, yum, pkg, pip, OpenCSW,
pacman, etc.
 Installation on Ubuntu

• $ sudo apt-get update

• $ sudo apt-get install software-properties-common
• $ sudo apt-add-repository ppa:ansible/ansible
• $ sudo apt-get update
• $ sudo apt-get install ansible

• Check ansible is installed or not:

– $ Ansible-version
 Common Terms in Ansible
• Service/Server – A process on the machine that provides the
service

• Machine – A physical server , vm(virtual machine) or a container

• Target machine – A machine we are about to configure with Ansible

• Task – An action(run this, delete that) etc managed by Ansible.

• Playbook – the yml file where Ansible commands are written and
yml is executed on a machine.
 Ansible – Playbooks
• Playbooks are the files where Ansible code is
written. Playbooks are written in YAML
format.
• Playbooks contain the steps which the user
wants to execute on a particular machine.
• Each playbook is an aggregation of one or
more plays in it.
 Playbook Structure
• The function of a play is to map a set of instructions
defined against a particular host.
 Tags Used
• name: This tag specifies the name of the Ansible
playbook. As in what this playbook will be doing. Any
logical name can be given to the playbook.

• hosts: This tag specifies the lists of hosts or host group

against which we want to run the task. The hosts
field/tag is mandatory. It tells Ansible on which hosts to
run the listed tasks. The tasks can be run on the same
machine or on a remote machine. One can run the
tasks on multiple machines and hence hosts tag can
have a group of hosts’ entry as well.
 Tags Used
• vars: Vars tag lets you define the variables which you can
use in your playbook. Usage is similar to variables in any
programming language.

• tasks: All playbooks should contain tasks or a list of tasks to

be executed. Tasks are a list of actions one needs to
perform. A tasks field contains the name of the task. This
works as the help text for the user. It is not mandatory but
proves useful in debugging the playbook. Each task
internally links to a piece of code called a module. A
module that should be executed, and arguments that are
required for the module you want to execute.
 Tags Used
• vars: Vars tag lets you define the variables which you can
use in your playbook. Usage is similar to variables in any
programming language.

• tasks: All playbooks should contain tasks or a list of tasks to

be executed. Tasks are a list of actions one needs to
perform. A tasks field contains the name of the task. This
works as the help text for the user. It is not mandatory but
proves useful in debugging the playbook. Each task
internally links to a piece of code called a module. A
module that should be executed, and arguments that are
required for the module you want to execute.
 Ansible Roles
• Roles provide a framework for independent, or
interdependent collections of variables, tasks,
files, templates, and modules.

• In Ansible, the role is the primary mechanism for

breaking a playbook into multiple files.

• The breaking of playbook allows you to logically

break the playbook into reusable components.
 Ansible Roles
• Each role is basically limited to a particular functionality or
desired output, with all the necessary steps to provide that
result either within that role itself or in other roles listed as
dependencies.

• Roles are small functionality which can be independently

used but have to be used within playbooks.

• There is no way to directly execute a role.

• Roles have no explicit setting for which host the role will
apply to.
 Creating a New Role
• Role Structure:
– An Ansible role has a defined directory structure
with eight main standard directories.
– You must include at least one of these directories
in each role.
– You can omit any directories the role does not use.
– The role name is the directory name within the
/roles directory.
>cd ~/Ansible/roles
>sudo ansible-galaxy init <role-name>
Role Directory Structure
 Roles Directory
• tasks/main.yml - the main list of tasks that the role executes.
• handlers/main.yml - handlers, which may be used within or outside
this role.
• library/my_module.py - modules, which may be used within this role
• defaults/main.yml - default variables for the role. These variables
have the lowest priority of any variables available, and can be easily
overridden by any other variable, including inventory variables.
• vars/main.yml - other variables for the role
• files/main.yml - files that the role deploys.
• templates/main.yml - templates that the role deploys.
• meta/main.yml - metadata for the role, including role dependencies.
 Roles Files
• You can add other YAML files in some directories.
 Storing and finding roles
• By default, Ansible looks for roles in the following
locations:
– in collections, if you are using them
– in a directory called roles/, relative to the playbook file
– in the configured roles_path. The default search path is
~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles.
– in the directory where the playbook file is located

• If you store your roles in a different location, set

the roles_path configuration option so Ansible can find
your roles.
 Storing and finding roles
• Alternatively, you can call a role with a fully
qualified path:

---
- hosts: webservers
roles:
- role: '/path/to/my/roles/common'
 Using Roles
• You can use roles in three ways:

– at the play level with the roles option: This is the

classic way of using roles in a play.

– at the tasks level with include_role: You can reuse

roles dynamically anywhere in the tasks section of a
play using include_role.

– at the tasks level with import_role: You can reuse

roles statically anywhere in the tasks section of a play
using import_role.
 Using roles at the play level
• The classic (original) way to use roles is with
the roles option for a given play:
 Using roles at the play level
• When you use the roles option at the play level, for each
role ‘x’:
– If roles/x/tasks/main.yml exists, Ansible adds the tasks in that
file to the play.
– If roles/x/handlers/main.yml exists, Ansible adds the handlers
in that file to the play.
– If roles/x/vars/main.yml exists, Ansible adds the variables in
that file to the play.
– If roles/x/defaults/main.yml exists, Ansible adds the variables
in that file to the play.
– If roles/x/meta/main.yml exists, Ansible adds any role
dependencies in that file to the list of roles.
– Any copy, script, template or include tasks (in the role) can
reference files in roles/x/{files,templates,tasks}/ (dir depends
on task) without having to path them relatively or absolutely.
 Using roles at the play level
• When you use the roles option at the play level,
Ansible treats the roles as static imports and processes
them during playbook parsing. Ansible executes each
play in this order:
– Any pre_tasks defined in the play.
– Any handlers triggered by pre_tasks.
– Each role listed in roles:, in the order listed. Any role
dependencies defined in the role’s meta/main.yml run
first, subject to tag filtering and conditionals.
– Any tasks defined in the play.
– Any handlers triggered by the roles or tasks.
– Any post_tasks defined in the play.
– Any handlers triggered by post_tasks.
 Using roles at the play level
• You can pass other keywords to the roles option:
 Using roles at the play level
• When you add a tag to the role option,
Ansible applies the tag to ALL tasks within the
role.

• When using vars: within the roles: section of a

playbook, the variables are added to the play
variables, making them available to all tasks
within the play before and after the role.
 Including Roles: Dynamic Reuse
• You can reuse roles dynamically anywhere in
the tasks section of a play using include_role:.

• While roles added in a roles: section run

before any other tasks in a play, included roles
run in the order they are defined. If there are
other tasks before an include_role: task, the
other tasks will run first.
Including Roles: Dynamic Reuse
 Including Roles: Dynamic Reuse
• You can pass other keywords, including variables
and tags, when including roles:
 Including Roles: Dynamic Reuse
• When you add a tag to an include_role task, Ansible
applies the tag only to the include itself. This means
you can pass --tags to run only selected tasks from the
role, if those tasks themselves have the same tag as the
include statement.
 Including Roles: Dynamic Reuse
• You can conditionally include a role:
 Importing Roles: Static Reuse
• You can reuse roles statically anywhere in tasks section of
a play using import_role. The behavior is the same as
using the roles keyword.
 Importing Roles: Static Reuse
• You can pass other keywords, including variables
and tags, when importing roles.
• When you add a tag to an import_role statement,
Ansible applies the tag to all tasks within the role.