ANSIBLE USER TRAINING

BVS DEPARTMENT
VINOTHKUMAR S
SEP 8, 2020

CONFIDENTIAL | Copyright © ANRITSU

 Goal: Ansible for the Absolute Beginner

• This presentation is developed with basic and simple

examples, so that any user who has no knowledge
on ansible, should be able to understand it.
• With this presentation each beginner should do the
following.
• Able to install ansible software
• Able to write few plays and execute them
• Able to understand important features of ansible
• Able understand complex playbooks with roles.

CONFIDENTIAL | Copyright © ANRITSU

2
Agenda
• What is Ansible?
• Ansible Architecture
• Introduction to Inventory, ansible.cfg, Playbook, Roles.
• Ansible – Adhoc commands
• Ansible plays (File Creation, File Copy, Pkg installation)
• Ansible Conditions
• Ansible Loops
• Ansible tags
• Ansible privilege escalations
• Ansible Handlers

CONFIDENTIAL | Copyright © ANRITSU

3
Agenda continuation…
• Ansible Roles
• Ansible flags
• Ansible gather Facts
• Ansible Template
• Ansible VAULT
• Ansible Galaxy
• Ansible in MasterClaw
• MasterClaw Architecture
• Ansible commands

CONFIDENTIAL | Copyright © ANRITSU

4
What is Ansible?
• Ansible is a simple automation tool that can Execute
tasks on one or many hosts
• It’s an automation engine that runs play books
• Ansible is a simple agentless idempotent task
automation tool
• Secure SSH-based connection
• Human Readable format
• Ansible’s main goals are simplicity and ease-of-use. It
also has a strong focus on security and reliability,
featuring a minimum of moving parts

CONFIDENTIAL | Copyright © ANRITSU

5
What is Ansible?
• It can configure systems, deploy software and
orchestrate advanced tasks such as continuous
deployment or zero downtime rolling upgrades
• Brings in Standardization for doing configuration
management of IT systems
• Instead of writing custom scripts, system administrators
can create high level plays in Ansible

CONFIDENTIAL | Copyright © ANRITSU

6
ANSIBLE - Installation
• Prerequiste
• Currently Ansible can be run from any machine with
Python 2 (version 2.7) or Python 3 (versions 3.5 and
higher) installed
• yum install <ansible-version> – Install the latest version
• Once installed, Ansible does not add a database, and
there will be no daemons to start or keep running. You
only need to install it on one machine (which could easily
be a laptop) and it can manage an entire fleet of remote
machines from that central point.
• Once ansible is installed it will act as a control node.

CONFIDENTIAL | Copyright © ANRITSU

7
YAML - YAML Ain't markup language
• YAML is the abbreviated form of “YAML Ain’t markup
language” is a data serialization language which is
designed to be human -friendly and works well with other
programming languages for everyday tasks.

• Why YAML?
• YAML was specifically created to work well for common
use cases such as configuration files, log files and cross
language sharing files and data sharing.
• YAML data is portable between programming languages
• Easily readable by humans
• Ease of implementation and usage
CONFIDENTIAL | Copyright © ANRITSU
8
ANSIBLE - ARCHITECTURE

CONFIDENTIAL | Copyright © ANRITSU

9
 Ansible Architecture
• Two Types of machine in Ansible Architecture –
• Control Node – Ansible S/W is installed on control node and all of
its components are maintained on it
• Managed hosts – These are the hosts that Ansible manages. No
need for Ansible to be installed on these hosts
• Hosts Inventory
• The managed hosts are listed in a text file on the Control Node
• Host names or IP addresses can be mentioned
• System Administrators log on to the Control Node , launch Ansible ,
providing the playbook to executed and a target host to manage
• Ansible works by connecting to your nodes and pushing out small
programs, called “Ansible Modules” to them.
• Ansible then executes these modules (over SSH by default) and
removes then when finished.

CONFIDENTIAL | Copyright © ANRITSU

10
INVENTORY
• Inventory is a collection of hosts with associated data
and groupings that Ansible can connect and manage.
• Special "all" group that is implicitly defined as the sum of
all hosts in your inventory.
• The inventory file can list individual hosts or user-defined
groups of hosts. This enables you to define groups of
devices running Cent OS with similar roles upon which to
perform the same operational and configuration tasks.

CONFIDENTIAL | Copyright © ANRITSU

11
Ansible Configuration file
• Ansible supports several sources for configuring its
behavior, including an ini file named ansible.cfg,
environment variables, command-line options, playbook
keywords, and variables.
• Certain settings in Ansible are adjustable via a
configuration file called ansible.cfg file
• nearly all parameters can be overridden in ansible-
playbook or with command line flags.
• ansible will read ansible.cfg in the current working
directory

CONFIDENTIAL | Copyright © ANRITSU

12
PLAYBOOKS
• Playbooks are one of the core features of Ansible and
tell Ansible what to execute. They are like a to-do list for
Ansible that contains a list of tasks.
• Each playbook is composed of one or more ‘plays’ in a
list.
• The goal of a play is to map a group of hosts to some
well-defined roles, represented by things ansible calls
tasks. At a basic level, a task is nothing more than a call
to an ansible module.

CONFIDENTIAL | Copyright © ANRITSU

13
Ansible - Modules
• Modules are programs that Ansible uses to perform
operations on managed hosts
• Modules can be executed from Ansible command line
or used in playbook tasks
• Modules are copied to the managed hosts and are
executed from there
• Ansible comes packaged with over 400 modules
ready for use

CONFIDENTIAL | Copyright © ANRITSU

14
Playbook Structure

CONFIDENTIAL | Copyright © ANRITSU

15
ROLES
• Roles provide a framework for fully 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.
This simplifies writing complex
playbooks, and it makes them
easier to reuse.

CONFIDENTIAL | Copyright © ANRITSU

16
INCLUDES
• Include file defines a set of tasks that can be included by a
playbook, this allows sharing sets of tasks without
copy/pasting everywhere.
• enablewebservice.yml
---
- name: start and enable httpd
service:
name: httpd
state: enabled
webserver.yml
---
- name: Webserver Playbook
hosts: webservers
tasks:
- include: enablewebservice.yml
CONFIDENTIAL | Copyright © ANRITSU
17
Hands on Exercises on Ansible

CONFIDENTIAL | Copyright © ANRITSU

18
ANSIBLE – Adhoc commands
• ansible <host_grp_name> -m ping
• ansible all -a “/bin/echo hello”
• ansible <host_grp_name> -a /sbin/reboot
• ansible all -m copy -a "src=/etc/hosts
dest=/tmp/ansible/hosts“
• ansible all -m file -a "dest=/tmp/ansible/dummy.txt
state=touch mode=600 owner=mclaw group=mclaw"
• ansible all -m yum -a "name=httpd state=latest“

CONFIDENTIAL | Copyright © ANRITSU

19
ANSIBLE – PLAYS (File Creation, File Copy, Pkg
installation
• First let’s create a play, to create a file on remote
servers.
• Things to remember to create a play
• Play should start with --- (syntax for YAML)
• Play should start with hosts information
• Play should have a task
 Task should have a name
 Task should have a method
• Examples: create_file.yml

CONFIDENTIAL | Copyright © ANRITSU

20
ANSIBLE – loops
• Sometimes you will want to execute multiple action
on multiple hosts. Here action I mean a job
• If I want to execute multiple packages or execute
multiple commands, this can be simplified using
loops.
• Syntax:
• With_items : <statement>

CONFIDENTIAL | Copyright © ANRITSU

21
ANSIBLE – Conditions
• Sometimes you will want to skip a particular step on
a particular host. This could be something as simple
as not installing a certain package if the operating
system is a particular version
• It is possible to control the execution of plays using
conditions
• This is easy to do in Ansible with the when clause
• Syntax:
• When : <statement>

CONFIDENTIAL | Copyright © ANRITSU

22
ANSIBLE – Register
• Ansible registers are used when you want to capture
the output of a task to a variable. You can then use
the value of these registers for different scenarios
like a conditional statement, logging etc.
• Each registered variables will be valid on the remote
host where the task was run for the rest of the
playbook execution.
• Syntax:
• Register : <statement>

CONFIDENTIAL | Copyright © ANRITSU

23
ANSIBLE – Tags
• If you have a large playbook, it may become useful
to be able to run only a specific part of it rather than
running everything in the playbook.
• Tags can be applied to many structures in Ansible
but its simplest use is with individual tasks
• Syntax:
• tags
• Skip-tags

CONFIDENTIAL | Copyright © ANRITSU

24
Previlage escalation
• This feature allows you to ‘become’ another user,
different from the user that logged into the machine
(remote user), we call it become.
• become: yes  its set to to activate privilege escalation
• Become_user  set to user with desired privileges — the
user you become, NOT the user you login as
• become_method  which privilege escalation method
should be used
• Syntax:
• remote_user: yourname
• become: yes
• become_user: postgres
CONFIDENTIAL | Copyright © ANRITSU
25
Handlers
• Handlers are just like regular tasks in playbook but
are only run if the Task contains a notify directive
and also indicates that it changed something. If a
handler is notified by multiple tasks, it will still be
run only once. Handlers are run in the order they are
listed
Syntax:
• notify:
handler_name

• Handlers:
name: handler_name
CONFIDENTIAL | Copyright © ANRITSU
26
ANSIBLE - ROLES
• Roles provide a framework for fully independent, or
interdependent collections of variables, tasks, files,
templates, and modules
• Roles are not playbooks. 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.
Syntax for Roles creation:
• Ansible-galaxy init <role_name>

CONFIDENTIAL | Copyright © ANRITSU

27
ROLES Directory structure
 tasks - contains the main list of tasks to
be executed by the role
 handlers - contain handlers which may
be used by role or even anywhere
outside the role
 defaults - default variables for the role
 vars - other variables for the role. vars
has the higher priority than defaults
 templates - contain templates which
can be deployed via this role
 meta - defines some data/information
about this role(author, dependencies,
versions, examples, etc)
 Readme – information about the role
with description

CONFIDENTIAL | Copyright © ANRITSU

28
ANSIBLE – ROLES Definition
• Each role is a directory tree in itself. The role name is the
directory name within the /roles directory.
- hosts:Linux_OS_machine
tasks:
- import_role:
name:common
vars:
- ansible_become_user: "{{ root_user }}"
- ansible_become_pass: "{{ root_pass }}"
(OR)
- hosts: Linux_OS_machine
roles:
- {role: common, ansible_become_user: "{{ root_user }}",
ansible_become_pass: "{{ root_pass }}" }
CONFIDENTIAL | Copyright © ANRITSU
29
Ansible facts
Gather Facts
• In Ansible, Facts are nothing but information that we
derive from speaking with the remote system
• Sometime this information is required in playbook as this
is dynamic information fetched from remote systems.
Caching Facts
facts are collected on each machine and were kept in
memory for the duration of the playbook run before being
destroyed. Using caching, expiry of facts can be controlled
By default, fact_caching is set to memory but configurable
fact_caching = redis instead of memory
fact_caching_timeout = 3600 sec
CONFIDENTIAL | Copyright © ANRITSU
30
Ansible flags
any_err_fatal
Sometime it is desired to abort the entire play on failure of any
task on any host. This can be helpful in a scenario where you
are deploying any service on group of hosts and if any failure
occurred on any server should fail the entire play because we
don’t want the deployments to be partial on any server.
run_once - There are condition where we have to write our
playbook in such a way that will run some tasks or perform some
action only on single host from group. If you are thinking of
Handlers do the same thing, then its wrong.
no_log - the encrypted data is exposed in ansible_facts. To
secure or censor such information, Ansible has provide a
keyword named no_log which you can set to true to keep any
task’s information censored.
Check – check mode for ansible plays
CONFIDENTIAL | Copyright © ANRITSU
31
Ansible Template
• A template in Ansible is a file which contains all your
configuration parameters, but the dynamic values are
given as variables. During the playbook execution,
depending on the conditions like which cluster you are
using, the variables will be replaced with the relevant
values.
• The template files will usually have the .j2 extension,
which denotes the Jinja2 templating engine used.
• Jinja2 is a templating language from python.

CONFIDENTIAL | Copyright © ANRITSU

32
ANSIBLE - VAULT
• The “Vault” is a feature of Ansible that allows you to keep
sensitive data such as passwords or keys protected at
rest, rather than as plaintext in playbooks or roles. These
vaults can then be distributed or placed in source
control.
• Password can be saved in a file inside vault folder.
• ansible-vault [create|decrypt|edit|encrypt|encrypt_string|
rekey|view] [--help] [options] vaultfile.yml

CONFIDENTIAL | Copyright © ANRITSU

33
Ansible Galaxy
• Ansible Galaxy is a repository for Ansible Roles that are
available to drop directly into your Playbooks to
streamline your automation projects.
• Galaxy contains a large number of roles that are
constantly evolving and increasing.
• Ansible-galaxy –h

CONFIDENTIAL | Copyright © ANRITSU

34
Ansible in MasterClaw
Script Description
ansible Ansible executable
ansible-playbook Ansible playbook executable
do_config_check_mode.sh Starts the masterclaw configuration deploy playbook in check mode,
without applying any configuration to the target system.
do_config_deploy.sh Starts the masterclaw configuration deploy playbook.
do_config_platform_deploy.sh Starts the masterclaw platform configuration deploy playbook. Installs
CentOS updates package and hpspp.
do_roles_discovery.sh Starts the discovery of ansible roles, by scanning the repository and
extracting the roles directly from the components. (executable as root)
do_survey_all.sh Starts the masterclaw survey (using survey_inventory), showing all the
scanned configuration.
do_survey_diffs.sh Starts the masterclaw survey (using survey_inventory), showing only
the differences from the defaults provided by the application’s role.
inventory_import.sh Imports the inventory from /opt/anritsu/ansible/inventory to the Tower
GUI inventory. (only one way import, executable as root user)
scan_inventory.sh Takes a Central Server IP address as an argument, together with the
mclaw user password different from default, and generates
/opt/anritsu/ansible/survey_inventory based on CDB – Machines
information.

Imports the survey inventory from /opt/anritsu/ansible/survey_inventory

survey_inventory_import.sh: to the Tower GUI inventory. (only one way import, executable as root
user)

CONFIDENTIAL | Copyright © ANRITSU

35
MasterClaw Architecture

CONFIDENTIAL | Copyright © ANRITSU

36
MasterClaw playbooks

• Let's see few master claw plays, so that we can

understand how the existing roles/plays are written.
• Mostly Master claw does the following tasks
• Copy packages
• Download packages
• Install a master claw package
• Update config parameters
• Dynamic path
• restart services

CONFIDENTIAL | Copyright © ANRITSU

37
Ansible commands

• ansible-playbook is the command that is used to execute

a playbook
• e.g. ansible-playbook <<playbook.yaml>>
• Syntax verification
– ansible-playbook –-syntax-check <<playbook.yaml>>
• Dry Run
– ansible-playbook –C <<playbook.yaml>>
• Step Execution
– ansible-playbook --step <<playbook.yaml>>

CONFIDENTIAL | Copyright © ANRITSU

38
Thank you