Ansible Overview - System Administration and Maintenance

Introduction Installation Anatomy General Workﬂow Some Demo
ANSIBLE
System Administration and Maintenance
P Jishnu Jaykumar
201352005@iiitvadodara.ac.in
Indian Institute of Information Technology,
Vadodara
November 29, 2016
P Jishnu Jaykumar (201352005) @IIIT Vadodara 1/50

References
https://serversforhackers.com/
an-ansible-tutorial
https://serversforhackers.com/
running-ansible-2-programmatically
https://www.ansible.com/videos
https://github.com/lorin/ansiblebook#
ansible-up-and-running-code-samples

Outline
1 Introduction
2 Installation
3 Ansible : Anatomy
4 Ansible : General workﬂow
5 Ansible : Playbooks
6 Demo Time

Introduction

Introduction
“Ansible is a free-software platform for conﬁguring and
managing computers which combines multi-node soft-
ware deployment, ad hoc task execution, and conﬁgura-
tion management. It manages nodes over SSH.”
Ansible started as a simple side project in February of
2012 by Michael DeHaan, and its rapid growth has
been a pleasant surprise .
Nowadays, it’s development is looked after by Ansible
Inc. and Red Hat Inc.

Introduction continues...
It has a diﬀerent approach to solving the IT infrastruc-
ture and automation issues.
You need not learn any new programming language for
automating using ansible.
It uses the existing technologies like ssh and python.
To connect to remote servers that needs to be man-
aged, ansible either uses ssh for *nix based system
and winrm(windows remote management) for windows
based systems
The oﬃcial website of Ansible is www.ansible.com.

Installation

Ansible : Installation
Repositories can be updated using sudo apt-get update command.

Anatomy

Ansible : Anatomy
Ansible is comprised of two entities.
Inventory
Playbooks

Ansible : Inventory
Inventory is just a regular ﬁle located at /etc/ansible
directory with name ”hosts” (/etc/ansible/hosts).
Contains lists of hosts on which automation will be per-
formed.
Groups of hosts are delimited by [header] elements.
You can enter hostnames or ip addresses.
A hostname/ip can be a member of multiple groups.

Ansible : Inventory Examples

Hey wait !!!
Before proceeding to playbook, let’s take an
overview of how ansible works.

Ansible : General workﬂow

Ansible : Playbooks

Ansible : Playbook
A playbook is the term that Ansible uses for a conﬁgu-
ration management script.
Most of your time in Ansible will be spent writing play-
books.
Ansible playbooks are written in yaml/yml ﬁles.
YAML - Yet Another Markup Language.
Let’s take an example.

Ansible : Playbook Example
We will conﬁgure a host to run an nginx web server.
Assume that there is a [webservers] host group in the
inventory ﬁle.

True in One Place and Yes in Another
Sharp-eyed readers might have noticed that Example 1-
1 uses True in one spot in the playbook (to enable sudo)
and yes in another spot in the playbook (to update the
apt cache).
Ansible is pretty ﬂexible on how you represent truthy
and falsey values in playbooks.
Strictly speaking, module arguments (like up-
date cache=yes ) are treated diﬀerently from values
elsewhere in playbooks (like sudo: True ).

True in One Place and Yes in Another
Values elsewhere are handled by the YAML parser and
so use the YAML conventions of truthiness, which are:
YAML truthy
true , True , TRUE , yes , Yes , YES , on , On , ON ,
y , Y
YAML falsey
false , False , FALSE , no , No , NO , off , Off , OFF ,
n , N
Module arguments are passed as strings and use Ansi-
bles internal conventions, which are:
module arg truthy - yes , on , 1 , true
module arg falsey - no , off , 0 , false
According to the official Ansible documentation, use
’yes’ and ’no’ when passing arguments to ’modules’
(since thats consistent with the module documentation),
and ’True’ and ’False’ elsewhere in playbooks.

Ansible : Running the Playbook
Command : ansible-playbook web-notls.yml
Output of ansible-playbook

Ansible : Running the Playbook (Trick)

Ansible : A Look inside playbook output
You might have noticed the following lines of output
when Ansible first starts to run:
GATHERING FACTS ****************
ok: [testserver]
When Ansible starts executing a play, the first thing it
does is collect information about the server it is con-
necting to, including :
operating system is running
hostname
IP and MAC addresses of all interfaces
and so on ...
You can then use this information later on in the playbook. For example, you might need
the IP address of the machine for populating a configuration file.

Ansible : Playbooks
Playbooks Are YAML
Ansible playbooks are written in YAML syntax.
YAML is a ﬁle format similar in intent to JSON, but
generally easier for humans to read and write.
Before we go over the playbook, lets cover the concepts
of YAML that are most important for writing play-
books.

Ansible : Playbooks YAML Basics
Start of File
YAML ﬁles are supposed to start with three dashes to
indicate the beginning of the document: - - -
However, if you forget to put those three dashes at the
top of your playbook ﬁles, Ansible wont complain.
Comments
Comments start with a number sign and apply to the
end of the line, the same as in shell scripts, Python,
and Ruby:
# This is a YAML comment

Ansible : Playbooks YAML Basics
Strings
In general, YAML strings do not have to be quoted,
although you can quote them if you prefer.
Even if there are spaces, you do not need to quote them.
For example, this is a string in YAML:
this is a lovely sentence
The JSON equivalent is: ”this is a lovely sentence”
There are some scenarios in Ansible where you will need
to quote strings. These typically involve the use of
{{ braces }} for variable substitution.

Ansible : Playbooks
Booleans
YAML has a native Boolean type, and provides you
with a wide variety of strings that can be interpreted
as true or false, which we covered in True in One Place
and Yes in Another section
For example, this is a Boolean in YAML: True
The JSON equivalent is: true

Ansible : Playbooks
Lists
YAML lists are like arrays in JSON and Ruby or lists
in Python. Technically, these are called sequences in
YAML, but call them lists here to be consistent with
the oﬃcial Ansible documentation.

Ansible : Playbooks
Dictionaries
YAML dictionaries are like objects in JSON, dictionar-
ies in Python, or hashes in Ruby. Technically, these
are called mappings in YAML, but call them dictio-
naries here to be consistent with the oﬃcial Ansible
documentation.

Ansible : Playbooks
Line Folding
When writing playbooks, you will often encounter sit-
uations where you are passing many arguments to a
module.
For aesthetics, you might want to break this up across
multiple lines in your ﬁle, but you want Ansible to treat
the string as if it were a single line.

Ansible : Playbooks
Lets take a look at our playbook from the perspective
of a YAML ﬁle.

Ansible : Playbooks
Lets take a look at our playbook from the perspective
of a JSON ﬁle.

Ansible : Playbooks
Standard

Ansible : Playbooks
Plays
Looking at either the YAML or JSON representation, it
should be clear that a playbook is a list of dictionaries.
Every play must contain:
A set of hosts to conﬁgure
A list of tasks to be executed on those hosts
Think of a play as the thing that connects hosts to tasks.

Ansible : Playbooks
Plays
In addition to specifying hosts and tasks, plays also sup-
port a number of optional settings. The three common
ones are:
Every play must contain:
name - A comment that describes what the play is
about. Ansible will print this out when the play starts
to run.
sudo - If true, Ansible will run every task by sudoing
as (by default) the root user. This is useful when man-
aging Ubuntu servers, since by default you cannot SSH
as the root user (for security users).
vars - A list of variables and values.

Ansible : Playbooks
Tasks
Tasks are like commands in shell script.

Ansible : Playbooks
Tasks
Ansible also supports an older syntax that uses action
as the key and puts the name of the module in the value.
The preceding example also can be written as:
Every task must contain a key with the name of a mod-
ule and a value with the arguments to that module. In
the preceding example, the module name is apt and the
arguments are name=nginx update cache=yes .
These arguments tell the apt module to install the pack-
age named nginx and to update the package cache (the
equivalent of doing an apt-get update ) before installing
the package.

Ansible : Playbooks
Modules
Modules are scripts that come packaged with Ansible
and perform some kind of action on a host.
Admittedly, thats a pretty generic description, but
theres enormous variety across Ansible modules.
The modules we use here are:
apt - Installs or removes packages using the apt package
manager.
copy - Copies a file from local machine to the hosts.
file - Sets the attribute of a file, symlink, or directory.
service - Starts, stops, or restarts a service.

Ansible : Playbooks Summary
To sum up, a playbook contains one or more plays.
A play associates an unordered set of hosts with an or-
dered list of task.
Each task is associated with exactly one module.

Ansible : Playbooks
Viewing Ansible Module Documentation
Ansible ships with the ansible-doc command-line tool,
which shows documentation about modules.
Think of it as man pages for Ansible modules.
For example, to show the documentation for the service
module, run:
ansible-doc <module-name>
Ansible executes a task on a host by generating a custom script based on the module name
and arguments, and then copies this script to the host and runs it.

Demo Time !!!

I have been a systems engineer, systems
administrator, a senior adviser for the
Central Intelligence Agency, a solutions
consultant and a telecommunications
information systems oﬃcer.
- Edward Snowden
Thank You.

Ansible Overview - System Administration and Maintenance

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Ansible Overview - System Administration and Maintenance (20)

More from Jishnu P (6)

Recently uploaded (20)

Ansible Overview - System Administration and Maintenance