IT AUTOMATION MADE EASY - INTRO
Marcelo Quintiliano da Silva
Technical Account Manager - Red Hat
marcelo.quintiliano@gmail.com

ABOUT THE MEETUP ANSIBLE SP
● A series of 50 min presentations + 10 min Q&A
● Hands On always it's possible
● Time to exchange ideas
● Suggested topics and presenters are very welcome

AGENDA
● WHAT IS ANSIBLE?
● ANSIBLE CORE COMPONENTS
● ANSIBLE CLI TIPS & TRICKS
● ANSIBLE GALAXY
● PROTECTING SENSITIVE DATA IN PLAYBOOKS
● DEMO SESSION
● ADDITIONAL REFERENCES

SIMPLE
● Human readable
automation
● No special coding skills
needed
● Tasks executed in
predefined order
Get productive
quickly
Orchestrate the App
lifecycle
More efficient and
secure
POWERFUL
● Application deployments
● Continuous delivery
● Beyond just servers
AGENTLESS
● Agentless architecture
● Uses OpenSSH and
WinRM
● No exploits or updates

IS INFRASTRUCTURE AS A CODE…
It’s a simple automation language that can perfectly describe an IT application infrastructure in Ansible Playbooks. It's also an
automation engine that runs the Ansible Playbooks.
Ansible is an open source IT configuration management, deployment, and orchestration tool, based on Python.
Designed to be minimal in nature, consistent, secure, and highly reliable, with an extremely low learning curve for administrators,
developers, and IT managers.

REQUIREMENTS
● CONTROL NODE
1. Ansible can be run from any machine with Python 2.6 or 2.7
● MANAGED NODES
1. Linux/Unix
1.1. SSH
1.2. Python 2.4 or later
1.2.1. ​If running less than Python 2.5 on the managed nodes, the package "python-simplejson" is required.
2. Windows (Ansible 1.7+) - enable and configure PowerShell remoting 3.0+ (WinRM)

HOW ANSIBLE WORKS
● Ansible works by connecting from the control node to your managed nodes and pushing out small programs, called "Ansible
modules" to them. These programs are written to be resource models of the desired state of the system.
● Ansible then executes these modules (over SSH by default) in the order they are specified in the playbook(s), and removes
them when finished.
*API - Available on
Ansible Tower

ANSIBLE USE CASES
PROVISIONING
ORCHESTRATION
CONFIGURATION
MANAGEMENT
APPLICATION
DEPLOYMENT
SECURITY &
COMPLIANCE
CONTINUOUS
DELIVERY

CORE COMPONENTS
● INVENTORIES
● MODULES
● VARIABLES
● FACTS
● PLAYS
● PLAYBOOKS
● CONFIGURATION FILES

INVENTORIES
Defines which hosts Ansible manages
Static - Defined in simple text files, a host can be member of more than one group, which is useful to identify the hosts' role in the
datacenter.
Dynamic - Generated for outside providers, some examples include pulling* inventory from a cloud provider (OpenStack, AWS, etc),
LDAP, Cobbler, or a piece of expensive enterprise CMDB software.
[webservers]
web1.example.com
web2.example.com
[dbservers]
db[0:1].example.com
[appserver]
192.168.1.[4:7]
Default location: /etc/ansible/hosts
Note: from command line Ad-hoc commands use --inventory | -i pathname to specify a different host inventory

MODULES
Small programs that comes with Ansible
"Ansible Modules" are written to be resource models of the desired state of the system. Ansible then executes these modules (over
SSH by default), and removes them when finished.
The default module library (currently v2.2.1) has 770+ modules available that allows us to manage from basic systems resources to
sophisticated ones. For example, to manage users, packages, network*, files, services, as well provision cloud instances, create
databases, and many more.
Core, extra and custom modules
● Core modules - Written and maintained by Ansible development team, they are the most important modules and are used for
common administration tasks.
● Extra modules - Generally not maintained by Ansible team but by the community, typically implementing features for
managing newer technologies.
● Custom modules - Developed by end users and not shipped by Ansible.
Idempotence - Is an important characteristic of a module, allows executing the same task multiple times without
resulting in the error state.

Ansible has four modules into this category and provide us the options to choose from while running system commands or scripts:
● Raw - Do not require Python on target/managed host
● Command - Most recommended module for executing commands on target nodes
● Shell - Runs the command through the '/ bin/sh ' shell on the target host. It is less secure than a command module (can be
affected by a shell environment)
● Script - copy and execute a script in one step on remote host
Important Note: These modules are not idempotent by default, you need to take care about his, fortunately Ansible can help you with
such task as well.
Ansible is extensible too. If you do not find a module that does the job for you, it's
easy to write one, and it doesn't have to be in Python.

VARIABLES
A convenient way to manage dynamic values for a given environment
Ansible supports variable that can be used to store values that can be reused throughout files in an entire Ansible project.
● Global scope: Variables set from the command line or Ansible configuration file.
● Play scope: Variables set in the playbook and related structures.
● Host scope: Variables set on host groups and/or individual hosts by inventory, fact gathering or registered tasks.
Example: Defining variables in a playbook (Play scope):
---
- hosts: all
vars:
user: smith
homedir: /home/smith
Note: Variables must start with a letter and can only contain letters, numbers and underscores.

FACTS
Know the facts about your hosts
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.
Fact variables can be used as part of playbooks, in conditionals, loops, or any other dynamic statement that depends on a value for a
managed host.
● Displaying facts from all hosts and store them indexed by hostname at /tmp/facts:
# ansible all -m setup --tree /tmp/facts

FACTS
Choosing what facts about your hosts you wanna see
$ ansible webserver1.local -m setup -a 'filter=ansible_dist*'
webserver1.local | SUCCESS => {
"ansible_facts": {
"ansible_distribution": "CentOS",
"ansible_distribution_major_version": "7",
"ansible_distribution_release": "Core",
"ansible_distribution_version": "7.2.1511"
},
"changed": false
}
$ ansible webserver1.local -m setup -a 'filter=ansible_all_ipv4*'
webserver1.local | SUCCESS => {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"172.16.10.101",
"192.168.121.93"
]
},
"changed": false
}

YAML
The playbook language
YAML format - a simple, human-readable, and familiar way to blueprint the infrastructure.
Users of this tool need not learn any special programming language to get started with, Ansible code is self-explanatory and
self-documenting in nature.
Playbooks are expressed in YAML format and have a minimum of syntax, which intentionally tries to not be a programming language
or script, but rather a model of a configuration or a process.
● Basic overview of correct YAML formatted file, including
lists and dictionaries:
---
# Employee records
- martin:
name: Martin D'vloper
job: Devops
skills:
- Ansible
- Docker
- tabitha:
name: Tabitha Bitumen
job: Developer
skills:
- python
- java

PLAYBOOKS
A simple + powerful automation language
A playbook consists of one or more plays, which map groups of hosts to well-defined tasks.
Plays also defines the order in which tasks are configured. This allows us to orchestrate multitier deployments.
By composing a playbook of multiple ‘plays’, it is possible to orchestrate multi-machine deployments, running certain steps on all
machines in the "webservers" group, then certain steps on the database server group, then more commands back on the webservers
group, etc.
As an orchestrate example, it is possible to create a playbook to configure the load balancers only after starting the web servers, or
perform two-phase deployment where the first phase only adds this configurations and the second phase starts the services in the
desired order.
Ansible Roles - The self-contained, portable and reusable Ansible Playbook format - While it is possible to write a playbook in one very
large file (and you might start out learning playbooks this way), eventually you’ll want to reuse files and start to organize things.

PLAYBOOKS
A simple + powerful automation language
---
- hosts: webservers
vars:
http_port: 80
max_clients: 200
remote_user: root
tasks:
- name: ensure apache is at the latest version
yum: name=httpd state=latest
- name: write the apache config file
template: src=/srv/httpd.j2 dest=/etc/httpd.conf
notify:
- restart apache
- name: ensure apache is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
- name: restart apache
service: name=httpd state=restarted
A sample playbook:

CONFIGURATION FILES
Modifying Ansible behavior
Certain settings in Ansible are adjustable via a configuration file. The stock configuration should be sufficient for most users, but there
may be reasons you would want to change them.
Ansible will select its configuration file from one of several possible locations on the control node, the file precedence is:
* ANSIBLE_CONFIG (an environment variable)
* ansible.cfg (in the current directory)
* .ansible.cfg (in the home directory)
* /etc/ansible/ansible.cfg
Some configuration settings are:
● inventory - Change the location of the inventory file
● become - Enables or disables privilege escalation for operations on managed hosts.
● become_user - The user account to escalate privileges to on managed hosts.
● become_method - Defines the privilege escalation method on managed hosts
Note: You can find many more options on /etc/ansible/ansible.cfg

ANSIBLE IN ACTION
Command line Tips & Tricks
$ ansible atlanta -m copy -a "src=/etc/hosts dest=/tmp/hosts"
$ ansible webservers -m yum -a "name=htop state=latest"
$ ansible webservers -m service -a "name=httpd state=restarted"
$ ansible myhost --sudo -m raw -a "yum install -y python2 python-simplejson
● Learning about modules:
● Ad-hoc commands - samples:
$ ansible-doc
Usage: ansible-doc [options] [module...]
Options:
-h, --help show this help message and exit
-l, --list List available modules
... output omitted ...
$ ansible-doc -s yum
- name: Manages packages with the `yum' package manager
action: yum
... output omitted ...

ANSIBLE IN ACTION
Command line Tips & Tricks
$ ansible-playbook --syntax-check my_playbook.yml
● Playbook syntax verification:
$ ansible-playbook --step site.yml
PLAY [Install WordPress, MariaDB, Nginx, and PHP-FPM] **************************
Perform task: TASK: setup (N)o/(y)es/(c)ontinue: y
Perform task: TASK: setup (N)o/(y)es/(c)ontinue: *******************************
TASK [setup] *******************************************************************
ok: [www01]
Perform task: TASK: common : Copy the NGINX repository definition
(N)o/(y)es/(c)ontinue:
● Reporting what changes would have occurred (Dry run) without actually execute any changes to the managed
hosts:
$ ansible-playbook -C some_playbook.yml
● Interactively running playbooks:

GALAXY
Locate and deploy Ansible roles with Ansible Galaxy

GALAXY
Command line tool
$ ansible-galaxy -h
Usage: ansible-galaxy [delete|import|info|init|install|list|login|remove|search|setup]
[--help] [options] ...
$ ansible-galaxy search 'haproxy' --platforms el
Found 50 roles matching your search:
Name Description
---- -----------
innohub-ansible.haproxy Creates an haproxy deployment
SimpliField.haproxy Setup HAProxy
kunik.haproxy install haproxy
. . . Output omitted . . .
$ ansible-galaxy init my_project
- my_project was created successfully

ANSIBLE VAULT
Protecting sensitive data in your playbooks
The vault feature can encrypt any structured data file used by Ansible. This can include “group_vars/” or “host_vars/” inventory
variables, variables loaded by “include_vars” or “vars_files”, or variable files passed on the ansible-playbook command line with “-e
@file.yml” or “-e @file.json”. Role variables and defaults are also included!
To create a new encrypted data file, run the following command:
$ ansible-vault create foo.yml
Similarly we can use edit, encrypt, decrypt and rekey, for more details on how to work with vault files, please check manual page:
$ man ansible-vault

LET'S GET ROCK
"Demo (a.k.a. getting trouble) session"

ADDITIONAL REFERENCES
Getting Started
● It's easy to get started:
Getting Started with Ansible | Ansible.com
● Want to learn more?
Ansible Resources - Whitepapers
● Using the Check Mode:
Check Mode (“Dry Run”) — Ansible Documentation
● Ansible Examples:
GitHub - ansible/ansible-examples: A few starter examples of ansible ...