AUTOMATION

WITH
ANSIBLE

1
About Instructor IT Industry Experience – 13 Years

Passion – Online Job Oriented

Certified Courses

Teaching Over to 25000 Students

Shikhar Verma
2
Prerequisites

▪ PC or Laptop with internet Connection

▪ RHEL6,7,8 or CentOS,VMware Workstation & Oracle

VirtualBox

▪ Red Hat Certified System Administrator (RHCSA)

Certification or equivalent experience.

3
Audience

▪ Any Graduate, B.Tech or Students willing to start their career as

Automation Engineer.

4
About Course Module

▪ 8-9 Hours of Video Contents

▪ Theoretically Sessions covered with Practice Lab Sessions

▪ 30 days money back guarantee

5
 Introduction
✓ Ansible is a simple IT automation platform that makes your applications and systems
easier to deploy.
✓ Ansible can help you with configuration management, application deployment & task
automation as shown below:

▪ Configuration of servers
▪ Application deployment
▪ Continuous testing of already install application
▪ Provisioning
▪ Orchestration
▪ Automation of tasks

6
 What is Ansible

✓ Ansible is an open-source software provisioning, configuration management, and application-

deployment tool. It runs on many Unix-like systems, and can configure both Unix-like systems as well
as Microsoft Windows.

✓ Ansible was originally written by Michael DeHaan, the creator of the Cobbler provisioning application.
Ansible has been widely adopted, because it is simple to use for system administrators. Developers
ease into using Ansible because it is built on Python.

✓ Ansible is included as part of the Fedora distribution of Linux, owned by Red Hat, and is also available
for Red Hat Enterprise Linux, CentOS, Debian, Scientific Linux, Oracle Linux via Extra Packages for
Enterprise Linux (EPEL).

7
 What is Ansible
✓ Ansible's architecture is agentless. Work is pushed to remote hosts when Ansible executes. Modules
are the programs that perform the actual work of the tasks of a play. Ansible is immediately useful
because it comes with hundreds of core modules that perform useful system administrative work.

✓ Instead of writing custom, individualized scripts, system administrators create high-level plays in
Ansible. A play performs a series of tasks on the host, or group of hosts, specified in the play. A file
that contains one or more plays is called a playbook.

8
 Ansible Limitations
✓ Ansible can add packages to an installation, but it does not perform the initial installation of the
system. Every system can start with a minimal installation, either via Kickstart or a base cloud starter
image, then use Ansible for further configuration.

✓ Although Ansible can remediate configuration drift, it does not monitor for it.

✓ Ansible does not track what changes are made to files on the system, nor does it track what user or
process made those changes.

9
10
11
Linux, HP-UX,
Solaris, AIX,
zLinux, CentOS
Windows etc

12
 Important Points

• It is a free open source software.

• Agent-less – No need for agent installation.
• Phython/yaml based.
• Highly flexible and configuration management of systems.
• Large number of ready to use modules for system management.
• Custom modules can be added if needed.
• Configuration roll-back in case of error .
• Simple and human readable.
• Implement Sudo passwd, so that normal needs password to elevate his privilege.

13
Ansible Server – ansibleser.example.com
Managed Hosts – client1, client2, client3

14
Ansible Components
Host Custom
Core Modules
Inventory Modules

Ansible
Configuration

Connection
Playbooks Plugins
Plugins

15
 Role and requirements for the control node

➢ System administrators log in and initiate all Ansible operations from the control node. Ansible software is installed on
the control node.Ansible configuration files are also maintained on the control node.

➢ A machine acting as a control node must have Python 2.6 or 2.7 installed.This includes Linux, OS/X, and any BSD
based Unix system.Windows is not supported for the control node at this time.

16
 Role and requirements for the Managed Hosts

➢ A managed host is a system that Ansible logs into, installs modules, and executes remote commands to
perform configuration tasks. Other names for a managed host include managed node and remote node.

➢ Ansible uses SSH to communicate with managed hosts, so SSH must be installed and configured to allow
incoming connections. Managed hosts must have Python 2.4 or later installed to run Ansible, which includes
Red Hat Enterprise Linux 5, 6, and 7 hosts.

➢ The python-simplejson package must also be installed on Red Hat Enterprise Linux 5 managed hosts. It is not
required on Red Hat Enterprise Linux 6 and 7 managed hosts, since Python 2.5 (and newer versions) provide
its functionality by default.

17
 ❑Ansible Host Inventories

➢ Host Inventory defines which hosts Ansible manages. Hosts may belong to groups which are typically used to identify
the hosts' role in the datacenter.A host can be a member of more than one group.

➢ [webservers]
localhost ansible_connection=local
web1.example.com
web2.example.com:1234 ansible_connection=ssh ansible_user=ftaylor
[db-servers]
web1.example.com
db1.example.com

18
❑Customizing Ansible

19
Ansible Server – ansibleser.example.com
Managed Hosts – client1, client2, client3

20
 ❑Customizing Ansible

✓ The behavior of an Ansible installation can be customized by modifying settings housed in

▪ ansible's configuration file (/etc/ansible/ansible.cfg).

✓ privilege_escalation section in the ansible.cfg configuration file by adding the following entry.
▪ [privilege_escalation]

✓ Enable privilege escalation by adding the become setting and configuring it as True.
▪ become=True

21
 ❑Customizing Ansible

✓ Set the privilege escalation to use sudo by adding the become_method setting and configuring it as sudo.
▪ become_method=sudo

✓ Set the privilege escalation user by adding the become_user setting and configuring it as root.
▪ become_user=root

✓ Enable password prompting during privilege escalation by adding the become_ask_pass setting and configuring it as
True.
▪ become_ask_pass=True

22
 ❑Command & Shell Module

✓ The command module allows administrators to quickly execute remote commands on managed
hosts. These commands are not processed by the shell on the managed hosts. As such, they cannot
access shell environment variables or perform shell operations such as redirection and piping.

✓ For situations where commands require shell processing, administrators can use the shell module.

✓ The following example illustrates the difference between the command and shell modules. If an
attempt is made to execute the bash built-in, set, with these two modules, it will only succeed with
the shell module.

23
 ❑Command & Shell Module

[student@demo ~]$ ansible localhost -m command -a set

localhost | FAILED | rc=2 >>
[Errno 2] No such file or directory

[student@demo ~]$ ansible localhost -m shell -a set

localhost | SUCCESS | rc=0 >>
BASH=/bin/sh
BASHOPTS=cmdhist:extquote:force_fignore:hostcomplete:interact
ive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()

24
❑Customizing Ansible

Lab Session

25
 ❑Implementing Playbooks

✓ Goal: Write Ansible plays and execute a playbook.

❑ Objective

▪ Write YAML files.

▪ Implement Ansible playbooks.
▪ Write and execute a playbook.

26
 ❑Implementing Playbooks

✓ Playbooks are the files where Ansible code is written. Playbooks are written in YAML format.
Playbooks are one of the core features of Ansible and tell Ansible what to execute.

✓ Ansible uses YAML syntax for expressing Ansible playbooks because it is very easy for humans to
understand, read and write than other common data formats like XML or JSON.

✓ Each playbook is an aggregation of one or more plays in it. Playbooks are structured using plays.
There can be more than one play inside a playbook.

27
 ❑Implementing Playbooks

✓ YAML SYNTAX

▪ YAML files optionally begin with a three dash start of document marker and are optionally
terminated with a three dot end of file marker.

▪ ---
▪ ...output omitted...
▪ ...

28
 ❑Implementing Playbooks
✓ YAML SYNTAX

---
- hosts: dev
become: true
become_user: root
tasks:
- name: run the script
script: /home/sverma/ansible/scr.sh
when: ansible_distribution == "RedHat" and ansible_distribution_major_version == '7'

29
 Introduction to modules

▪ Modules are programs that Ansible uses to perform operations on managed hosts. They are ready-to-
use tools designed to perform specific operations. Modules can be executed from the ansible
command line or used in playbooks to execute tasks. When run, modules are copied to the managed
host and executed there.

▪ Ansible comes packaged with over 500 modules available for use. These prepackaged modules can be
used to perform a wide range of tasks, such as cloud, user, package, and service management.

30
 Introduction to modules
✓ There are three types of Ansible modules:

▪ Core modules are included with Ansible and are written and maintained by the Ansible development team.
Core modules are the most important modules and are used for common administration tasks.

▪ Extras modules are currently included with Ansible but may be promoted to core or shipped separately in
the future.They are generally not maintained by the Ansible team but by the community.Typically, these
modules implement features for managing newer technologies such as OpenStack.

▪ Custom modules are modules developed by end users and not shipped by Ansible. If a module does not
already exist for a task, an administrator can write a new module to implement it.

31
 Introduction to modules

✓ Core and Extras modules are always available. Ansible looks for custom modules on the control
node in directories defined by the $ANSIBLE_LIBRARY environment variable

▪ #library = /usr/share/my_modules/

✓ On Red Hat Enterprise Linux 7,8 systems, modules are installed in the below location:

▪ /usr/lib/pythonx.x/site-packages/ansible/modules directory.

32
 Introduction to modules
✓ Module categories

▪ For better organization and management, Ansible modules are grouped into the following functional
categories.

▪ Module categories

• Cloud • Files • Notification

• Packaging • Source Control • System
• Utilities • Web Infrastructure • Windows
• Clustering • Inventory • Messaging • Monitoring
• Network • Commands • Database

33
❑Modules

Lab Session

34
 Introduction to modules

✓ Writing a playbook

▪ If multiple tasks are desired, the same syntax is repeated for each task.

tasks:
- name: first task
service: name=httpd enabled=true
- name: second task
service: name=sshd enabled=true
...output omitted...
- name: last task
service: name=sshd enabled=true

35
 Writing a playbook
✓ Important

❑ When possible, try to avoid the command, shell, and raw modules in playbooks because these take arbitrary
commands, it is very easy to write non-idempotent playbooks with these modules.

❑ For example, this task using the shell module is not idempotent. Every time the play is run, it will rewrite
/etc/resolv.conf even if it already consists of the line "nameserver 192.0.2.1".

- name: Non-idempotent approach with shell module

shell: echo "nameserver 192.0.2.1" > /etc/resolv.conf

36
 Writing a playbook
✓ The following example will not rewrite the file /etc/resolv.conf if it already consists of the right content:
- name: Idempotent approach with copy module
copy:
dest: /etc/resolv.conf
content: "nameserver 192.0.2.1\n"

▪ The copy module is special-purpose and can easily test to see if the state has already been met, and if it has will make
no changes.

▪ Idempotent playbooks can be run repeatedly to ensure systems are in a particular state without disrupting those
systems if they already are.

37
 Writing a playbook

▪ If multiple tasks are desired, the same syntax is repeated for each task.

tasks:
- name: first task
service: name=httpd enabled=true
- name: second task
service: name=sshd enabled=true
...output omitted...
- name: last task
service: name=sshd enabled=true

38
❑Writing a playbook

Lab Session

39
❑Implementing Multi tasks in Playbook

Lab Session
Package Installation (Apache/FTP)

Client1 1. Mount OS Media Drive

2. Create local repository
3. Install required Packages
Ansible Server 4. Enabled the service
5. Start the Service
Client2

40
 Managing Variables

✓ Ansible supports variables that can be used to store values that can be reused throughout files in an entire Ansible
project.

✓ Variables provide a convenient way to manage dynamic values for a given environment in your ansible project. Some
examples of values that variables might contain include.

▪ Users to create
▪ Packages to install
▪ Services to restart
▪ Files to remove

41
 Managing Variables
✓ Naming variables
➢ Variables have names which consist of a string that must start with a letter and can only contain letters, numbers, and
underscores.

✓ Defining variables
➢ Variables can be defined in a variety of places in an Ansible project. However, this can be simplified to three basic
scope levels:

• Global scope:Variables set from the command line or Ansible configuration

• Play scope:Variables set in the play and related structures
• Host scope:Variables set on host groups and individual hosts by the inventory, fact gathering, or registered tasks

42
 Managing Variables
✓ Variables in playbooks

➢ When writing playbooks, administrators can use their own variables and call them in a task.

➢ For example, a variable web_package can be defined with a value of httpd and called by the yum module in order to
install the httpd package as shown in next slide.

43
Managing Variables

44
 Managing Variables
✓ Host Variables and Group Variables

➢ Inventory variables that apply directly to hosts fall into two broad categories: host variables that apply to a specific
host, and group variables that apply to all hosts in a host group or in a group of host groups. Host variables take
precedence over group variables, but variables defined by a playbook take precedence over both.

➢ This is a host variable, ansible_user, being defined for the host demo.example.com.

▪ [servers]
▪ demo.example.com ansible_user=joe

45
 Managing Variables
✓ Host Variables and Group Variables

46
 Ansible facts
➢ Ansible facts are variables that are automatically discovered by Ansible from a managed host.

➢ Facts are pulled by the setup module and contain useful information stored into variables that administrators can
reuse. Ansible facts can be part of playbooks, in conditionals, loops, or any other dynamic statement that depends on
a value for a managed host;

❑ For example:

▪ A server can be restarted depending on the current kernel version.

▪ Users can be created depending on the host name.

47
 Ansible facts
✓ Ansible facts are a convenient way to retrieve the state of a managed node and decide which action to take based on
its state. Facts provide information about

▪ The host name

▪ The kernel version
▪ The network interfaces
▪ The IP addresses
▪ The version of the operating system
▪ Various environment variables
▪ The number of CPUs
▪ The available or free memory

48
 Ansible facts
✓ The following shows some of the facts Ansible gathered from a managed node:

❑ [user@demo ~]$ ansible demo1.example.com -m setup

49
 Conditionals
✓ Ansible can use conditionals to execute tasks or plays when certain conditions are met. For example, a conditional
can be used to determine the available memory on a managed host before Ansible installs or configures a service.

➢ The following examples illustrate some ways in which conditionals can be used by Ansible.

❑ A hard limit can be defined in a variable (for example, min_memory) and compare it against the available memory on
a managed host.

❑ Ansible facts can be used to determine the managed host network configuration and decide which template file to
send (for example, network bonding or trunking).

50
 Conditionals
✓ The When Statement

❑ 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, or it could be something like performing
some cleanup steps if a filesystem is getting full.

51
 Loops in Ansible

- yum:
name: postfix
state: latest

- yum:
name: dovecot
state: latest

52
Loops in Ansible

53
Loops in Ansible

54
Loops in Ansible

✓Practice Lab Session

55
 Ansible Handlers
✓ A Handler is exactly the same as a task, but it will run when called by another task. A Handler will take an action
when called by an event it listens for.

56
57
Conditionals

58
 Patching On Linux Servers using Ansible

Patching
▪ Verify the Application/Database processes are running or not.
▪ Decision point to start patching.
▪ Copy the required Repo file to the Managed host.
▪ Upgrade the Kernel or Packages.
▪ Check if reboot is required after kernel update.
▪ Reboot the system.
▪ Wait for few minutes, so that server should come up after reboot.
▪ Debug a message with new kernel version

59