Dal caos all’automazione di sistemi e infrastrutture IT con Ansible

Denis Maggiorotto 
Sunnyvale S.r.l.
21/05/2020
Dal caos all'automazione
di sistemi e infrastrutture IT con Ansible

Table of contents
Introduction
Ansible commands
Introducing modules
Working with the inventory
Ansible playbooks
Reusing logic with Ansible Roles
Sharing Roles on Ansible Galaxy
Custom module development
Ansible and Docker
Real 3 tiers architecture demo

About Ansible
“Ansible is a universal language, unraveling
the mystery of how work gets done. Turn
tough tasks into repeatable playbooks. Roll
out enterprise-wide protocols with the push of
a button. Give your team the tools to
automate, solve, and share”
“Simple, agentless IT automation
that anyone can use”
by
“Automate: deploy apps.
Manage systems. Crush
complexity”
“Accelerate: solve problems
once and share the results
with everyone”
“Collaborate: break down
silos, create a culture of
automation”
“Integrate: automate the
technologies you already use”

Populate the inventory
user@mgmt:/$ vi /etc/ansible/hosts
[groupA]
host1
[groupB]
host2
hostN

First Ansible commands (ad-hoc)
# reboot all servers in the groupA
user@mgmt:/$ ansible groupA -a "/sbin/reboot"
# reboot all servers in the groupA in 12 parallel forks
user@mgmt:/$ ansible groupA -a "/sbin/reboot" -f 12
# reboot all servers in the groupA impersonating another user
user@mgmt:/$ ansible groupA -a "/sbin/reboot" -u anotheruser

Commands using Ansible modules
"
user@mgmt:/$ ansible groupA -m ping
# as bruce
user@mgmt:/$ ansible groupA -m ping -u bruce
# as bruce, sudoing to root
user@mgmt:/$ ansible groupA -m ping -u bruce --sudo
# as bruce, sudoing to batman
user@mgmt:/$ ansible groupA -m ping -u bruce --sudo --sudo-user batman
# With latest version of ansible `sudo` is deprecated so use become
# as bruce, sudoing to root
user@mgmt:/$ ansible groupA -m ping -u bruce -b
# as bruce, sudoing to batman
user@mgmt:/$ ansible groupA -m ping -u bruce -b --become-user batman
Modules in ad-hoc commands are speciﬁed with -m ﬂag

Get help for each module
"
Documentation for each module (in this case yum) can be
accessed from the command line with the ansible-doc
tool:
user@mgmt$ ansible-doc yum
For a list of all available modules, see Module Index, or run the
following at a command prompt:
user@mgmt$ ansible-doc -l

Modules idempotency
# not idempotent, it overwrites ~/.zshrc any time is run
user@mgmt:/$ ansible groupA -m command -a "cp ~/.oh-my-zsh/
templates/zshrc.zsh-template ~/.zshrc"
Modules should be idempotent*, and should avoid making any changes if
they detect that the current state matches the desired ﬁnal state**.

*An operation is idempotent if the result of performing it once is exactly the
same as the result of performing it repeatedly without any intervening
actions.

**You have to follow this rules invoking your commands or within you
Playbooks
user@mgmt:/$ ansible groupA -m command -a "creates=~/.zshrc cp
~/.oh-my-zsh/templates/zshrc.zsh-template ~/.zshrc"
hostA | SUCCESS | rc=0 >>
skipped, since ~/.zshrc exists

The inventory ﬁle can be in one of many formats, depending on the
inventory plugins you have. For this example, the format for /etc/ansible/
hosts is an INI-like (one of Ansible’s defaults) and looks like this:
user@mgmt:/$ cat /etc/ansible/hosts
mail.example.com
[webservers]
foo.example.com
bar.example.com
[dbservers]
one.example.com
two.example.com
user@mgmt:/$ cat /home/user/inventory.yaml
---
all:
hosts:
mail.example.com:
children:
webservers:
hosts:
foo.example.com:
bar.example.com:
dbservers:
hosts:
one.example.com:
two.example.com:
A YAML version would look like:

Host Variables
Are deﬁned in the inventory ﬁle in the form of name=value
pairs
[loadbalancer]
lb01 var=value
user@mgmt:/$ ansible loadbalancer -m command -a "echo
{{var}}"
lb01 | CHANGED | rc=0 >>
value
and used later in ad-hoc commands (or playbooks)

If you are adding a lot of hosts following similar patterns, you can do this
rather than listing each hostname:
[webservers]
www[01:50].example.com
For numeric patterns, leading zeros can be included or removed, as
desired. Ranges are inclusive. You can also deﬁne alphabetic ranges:
[databases]
db-[a:f].example.com
You can also select the connection type and user on a per host basis:
[targets]
localhost ansible_connection=local
other1.example.com ansible_connection=ssh ansible_user=mpdehaan
other2.example.com ansible_connection=ssh ansible_user=mdehaan

Groups of Groups, and Group Variables
It is also possible to make groups of groups using the :children suﬃx (INI)
or children: element (YAML)
[atlanta]
host1
host2
[raleigh]
host2
host3
[southeast:children]
atlanta
raleigh
[southeast:vars]
some_server=foo.southeast.example.com
halon_system_timeout=30
self_destruct_countdown=60
escape_pods=2
[usa:children]
southeast
northeast
southwest
northwest
user@mgmt:/$ cat /home/user/inventory.yaml
all:
children:
usa:
children:
southeast:
children:
atlanta:
hosts:
host1:
host2:
raleigh:
hosts:
host2:
host3:
vars:
some_server: foo.southeast.example.com
halon_system_timeout: 30
self_destruct_countdown: 60
escape_pods: 2
northeast:
northwest:
southwest:
=

Ansible connection to targets
Ansible can connect to targets using multiple drivers (plugins)
user@mgmt:/$ ansible-doc -t connection -l
buildah Interact with an existing buildah container
chroot Interact with local chroot
docker Run tasks in docker containers
funcd Use funcd to connect to target
httpapi Use httpapi to run command on network appliances
iocage Run tasks in iocage jails
jail Run tasks in jails
kubectl Execute tasks in pods running on Kubernetes.
libvirt_lxc Run tasks in lxc containers via libvirt
local execute on controller
lxc Run tasks in lxc containers via lxc python library
lxd Run tasks in lxc containers via lxc CLI
netconf Provides a persistent connection using the netconf protocol
network_cli Use network_cli to run command on network appliances
oc Execute tasks in pods running on OpenShift.
paramiko_ssh Run tasks via python ssh (paramiko)
persistent Use a persistent unix socket for connection
psrp Run tasks over Microsoft PowerShell Remoting Protocol
saltstack Allow ansible to piggyback on salt minions
ssh connect via ssh client binary (default)
winrm Run tasks over Microsoft's WinRM
zone Run tasks in a zone instance

Ansible playbooks
Playbooks are the basis for conﬁguration management and multi-machine
deployment system

Playbooks are expressed in YAML format.

A Playbook contains one or more Plays, each Play contains one ore more
Tasks.

Ansible playbooks
Task
The goal of each Task is to execute a module, with very speciﬁc arguments.
Variables, as mentioned above, can be used in arguments to modules.
user@mgmt:/$ cat /home/user/myplaybook.yaml
---
- hosts: webservers
remote_user: root
tasks:
- name: ensure postgresql is at the latest version
yum:
name: postgresql
state: latest
- name: ensure that postgresql is started
service:
name: postgresql
state: started
The ﬁrst task installs the last version of postgresql, the second starts it

Ansible playbooks
Modules in a Task
Tasks can be declared using the legacy action: module options format
…
tasks:
action: template src=templates/foo.j2 dest=/etc/foo.conf
but it is recommended that you use the more conventional module:
options format.
…
tasks:
template:
src: template.j2
dest: /etc/foo.conf

Ansible playbooks
Running a Playbook
Now that you’ve learned playbook syntax, how do you run a playbook? It’s
simple. Let’s run a playbook from the management/control host
user@mgmt:/$ ansible-playbook /home/user/myplaybook.yaml

Ansible playbooks
Playbook output (run 1)
Given the following playbook nginx.yml
ansible@mgmt:/$ ansible-playbook /home/ansible/nginx.yml
PLAY [loadbalancer] *****************************************************
TASK [Gathering Facts] **************************************************
ok: [lb01]
TASK [Install Nginx] ****************************************************
changed: [lb01]
PLAY RECAP **************************************************************
lb01 : ok=2 changed=1 unreachable=0 failed=0
---
- hosts: loadbalancer
tasks:
- name: Install Nginx
apt: pkg=nginx state=present update_cache=true
become: yes
This will be the output

Ansible playbooks
Playbook output (run 2 to N)
Playbook idempotency example.
ansible@mgmt:/$ ansible-playbook /home/ansible/nginx.yml
PLAY [loadbalancer] *****************************************************
TASK [Gathering Facts] **************************************************
ok: [lb01]
TASK [Install Nginx] ****************************************************
ok: [lb01]
PLAY RECAP **************************************************************
lb01 : ok=2 changed=0 unreachable=0 failed=0

Ansible playbooks
Deﬁning a handler
Handler runs if the corresponding task triggers them
ansible@mgmt:/$ vi /home/ansible/nginx.yml
---
tasks:
- name: Install Nginx
apt: pkg=nginx state=present update_cache=true
become: yes
notify:
- Start Nginx
handlers:
- name: Start Nginx
service: name=nginx state=started
become: yes

Ansible playbooks
Loops (through map collection)
Often you’ll want to do many things in one task, such as create a lot of
users, install a lot of packages, or repeat a polling step until a certain result
is reached.

To save some typing, repeated tasks can be written in short-hand like so:
ansible@mgmt:/$ vi /home/ansible/create_users.yml
---
tasks:
- name: add several users
user:
name: "{{ item.name }}"
groups: "{{ item.group }}”
state: present
loop:
- { name: 'testuser1', group: 'wheel' }
- { name: 'testuser2', group: 'root' }

Ansible playbooks
Using facts (introducing Conditionals)
 
After having gathered the fact ansible_distribution on the target system, Ansible
knows when to execute apt-get install apache2 or yum install httpd
ansible@mgmt:/$ vi /home/ansible/apache.yml
---
tasks:
- name: install apache (apt)
when: ansible_distribution == "Ubuntu"
apt:
name: apache2
state: present
- name: install apache (yum)
when: ansible_distribution == "CentOS"
yum:
name: httpd
state: present

Ansible playbooks
Blocks
Blocks allow for logical grouping of tasks and in play error handling. Most of what
you can apply to a single task (with the exception of loops) can be applied at the
block level, which also makes it much easier to set data or directives common to
the tasks.
tasks:
- name: Install Apache
block:
- yum:
name: "{{ item }}"
state: installed
with_items:
- httpd
- memcached
- template:
src: templates/src.j2
dest: /etc/foo.conf
- service:
name: bar
state: started
enabled: True
when: ansible_facts['distribution'] == 'CentOS'
become: true
become_user: root
In the example, each of the
3 tasks will be executed
after appending the when
condition from the block
and evaluating it in the
task’s context. Also they
inherit the privilege
escalation directives
enabling “become to root”
for all the enclosed tasks.

Ansible playbooks
Error Handling
The tasks in the block would execute normally, if there is any error the rescue
section would get executed with whatever you need to do to recover from the
previous error.
tasks:
- name: Attempt and graceful roll back demo
block:
- debug:
msg: 'I execute normally'
- name: i force a failure
command: /bin/false
- debug:
msg: 'I never execute, due to the above task failing,
:-('
rescue:
- debug:
msg: 'I caught an error'
- name: i force a failure in middle of recovery! >:-)
command: /bin/false
- debug:
msg: 'I also never execute :-('
always:
- debug:
msg: "This always executes"
The always section runs
no matter what previous
error did or did not occur
in the block and rescue
sections.

Ansible playbooks
Privilege escalation
For example, to manage a system service (which requires root privileges) when connected as a
non-root user (this takes advantage of the fact that the default value of become_user is root):
- name: Ensure the httpd service is running
service:
name: httpd
state: started
become: yes
To run a command as the apache user:
- name: Run a command as the apache user
command: somecommand
become: yes
become_user: apache

Why Roles
Roles are ways of automatically loading certain vars_ﬁles, tasks, and handlers
based on a known ﬁle structure. Grouping content by roles also allows easy
sharing of roles with other users.

Example project structure:
ansible@control:~$ ansible-galaxy init test-role-1
ansible@control:~$ tree test-role-1
test-role-1
├── README.md
├── defaults
│ └── main.yml
├── files
├── handlers
├── meta
├── tasks
├── templates
├── tests
│ ├── inventory
│ └── test.yml
└── vars

Using Roles
The classic way to use roles is via the roles: option for a given play:
---
- hosts: webservers
roles:
- common
- webservers
- test-role-1

Sharing roles on Ansible Galaxy
Galaxy, is a free site for ﬁnding,
downloading, and sharing
community developed roles.
Downloading roles from Galaxy is a
great way to jumpstart your
automation projects.

You can also use the site to share
roles that you create. By
authenticating with the site using
your GitHub account, you’re able to
import roles, making them available
to the Ansible community. Imported
roles become available in the
Galaxy search index and visible on
the site, allowing users to discover
and download them.
https://galaxy.ansible.com

Downloading roles
Use the ansible-galaxy command to download roles from the Galaxy website
ansible@control:~$ ansible-galaxy install <<username>>.<<role_name>>
Be aware that by default Ansible downloads roles to the path specified by the
environment variable ANSIBLE_ROLES_PATH. This can be set to a series of
directories (i.e. /etc/ansible/roles:~/.ansible/roles), in which case the first writable path
will be used. When Ansible is first installed it defaults to /etc/ansible/roles, which
requires root privileges.

You can override this by setting the environment variable in your session, defining
roles_path in an ansible.cfg file, or by using the –roles-path option. The following
provides an example of using –roles-path to install the role into the current working
directory:
ansible@control:~$ ansible-galaxy install --roles-path . geerlingguy.apache

Installing versioned roles
ansible@control:~$ ansible-galaxy install geerlingguy.apache,v1.0.0
You can install a speciﬁc version of a role from Galaxy by appending a
comma and the value of a GitHub release tag. For example:
It’s also possible to point directly to the git repository and specify a branch
name or commit hash as the version. For example, the following will install
a speciﬁc commit:
ansible@control:~$ ansible-galaxy install git+https://github.com/geerlingguy/ansible-role-
apache.git,0b7cd353c0250e87a26e0499e59e7fd265cc2f25

Searching for roles
ansible@control:~$ ansible-galaxy search elasticsearch --author geerlingguy
Found 2 roles matching your search:
Name Description
---- -----------
geerlingguy.elasticsearch Elasticsearch for Linux.
geerlingguy.elasticsearch-curator Elasticsearch curator for Linux.
Search the Galaxy database by tags, platforms, author and multiple keywords. For
example:

Authenticate with Galaxy
ansible@control:~$ ansible-galaxy login
ansible-galaxy login
We need your GitHub login to identify you.
This information will not be sent to Galaxy, only to api.github.com.
The password will not be displayed.
Use --github-token if you do not want to enter your password.
Github Username: dsmith
Password for dsmith:
Successfully logged into Galaxy as dsmith
Using the import, delete and setup commands to manage your roles on the Galaxy website requires
authentication, and the login command can be used to do just that. Before you can use the login command, you
must create an account on the Galaxy website.

The login command requires using your GitHub credentials. You can use your username and password, or you
can create a personal access token. If you choose to create a token, grant minimal access to the token, as it is
used just to verify identify.

The following shows authenticating with the Galaxy website using a GitHub username and password:

Import a Role into Galaxy
The import command requires that you ﬁrst authenticate using the login command. Once authenticated you can
import any GitHub repository that you own or have been granted access.

Use the following to import to role:
ansible@control:~$ ansible-galaxy import github_user github_repo
Successfully submitted import request 41
Starting import 41: role_name=myrole repo=githubuser/ansible-role-repo ref=
Retrieving GitHub repo githubuser/ansible-role-repo
Accessing branch: master
Parsing and validating meta/main.yml
Parsing galaxy_tags
Parsing platforms
Adding dependencies
Parsing and validating README.md
Adding repo tags as role versions
Import completed
Status SUCCESS : warnings=0 errors=0

Hostname: control01

IP:192.168.135.10
Hostname: github.com

ansible@control:~$ tree .
.
├── github_repo_playbook.yml
└── library
├── github_repo.py
└── test_github_repo.py

https://github.com/
sunnyvale-academy/
SNY.RHT.ANS.01.01.00/
blob/master/ansible/labs/
github_module/solutions/
library/github_repo.py

ansible@control:~$ cat github_repo_playbook.yml
- hosts: localhost
vars:
- github_token: "{{ github_token }}"
- username: "{{ username }}"
- repo_name: "{{ repo_name }}"
tasks:
- name: "Create a github Repo"
github_repo:
github_auth_key: "{{ github_token }}"
name: "{{ repo_name }}"
description: "Repo {{ repo_name }} created by Ansible"
private: yes
has_issues: no
has_wiki: no
has_downloads: no
state: present

ansible@control:~$ ansible-playbook -vvv -e github_token=XXX -e username=myuser -e
repo_name=myrepo github_repo_playbook.yml
PLAY [localhost] ********************************************************************
TASK [Gathering Facts] **************************************************************
ok: [localhost]
TASK [Create a github Repo] *********************************************************
changed: [localhost]
PLAY RECAP **************************************************************************
localhost : ok=3 changed=1 unreachable=0 failed=0

Ansible and Docker
docker_container module 
ansible@control:~$ cat play.yml
---
- hosts: localhost
tasks:
- name: Create a new container
docker_container:
docker_host: tcp://10.5.5.5:2375
name: mynewcontainer
image: busybox
state: started
cpu_period: 1000 # Limit CPU CFS (Completely Fair Scheduler) period
cpu_quota: 1000 # Limit CPU CFS (Completely Fair Scheduler) quota
cpu_shares: 100 # CPU shares (relative weight).
cpuset_cpus: 1,3 # CPUs in which to allow execution 1,3 or 1-3.
ansible@control:~$ ansible-playbook play.yml
…

Ansible and Docker
Ansible within Docker container 
ansible@control01:~$ docker run --rm -it
-v ~/.ssh/id_rsa:/root/.ssh/id_rsa
-v ~/.ssh/id_rsa.pub:/root/.ssh/id_rsa.pub
-v $(pwd):/ansible/playbooks
-v /etc/ansible:/etc/ansible
-v /etc/hosts:/etc/hosts
dennydgl1/ansible-playbook -u ansible webserver.yml
1) Build the image (Dockerﬁle at https://github.com/sunnyvale-academy/
SNY.RHT.ANS.01.01.00/blob/master/docker/labs/ansible-in-docker/solutions/
Dockerﬁle)
ansible@control01:~$ docker build -t dennydgl1/ansible-playbook .
…
ansible@control01:~$ docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
dennydgl1/ansible-playbook latest d0dd5754162d About a minute ago 162MB
alpine 3.7 bc8fb6e6e49d 3 hours ago 4.21MB
2) Use Ansible within a Docker container

Hostname: app01

IP:192.168.135.111
Hostname: lb01

IP:192.168.135.101
Hostname: app02

IP:192.168.135.112
Hostname: db01

IP:192.168.135.121
Hostname: control01

IP:192.168.135.10
https://github.com/sunnyvale-
academy/SNY.RHT.ANS.01.01.00/tree/
master/ansible/labs/3-tier-arch/
solutions

lb01
app01
app02
db01
HTTP load balancer Web/app server Database
Proxy to
Proxy to
Connect to
Connect to
Access to
• Nginx
• Apache

• Demo App

• Python
• MySQL

Grazie!
www.github.com/denismaggior8
Denis Maggiorotto
denis.maggiorotto@sunnyvale.it
www.linkedin.com/in/denismaggiorotto
twitter.com/denismaggior8
www.github.com/sunnyvale-academy
www.github.com/sunnyvale-it

Dal caos all’automazione di sistemi e infrastrutture IT con Ansible

Recommended

Recommended

More Related Content

Similar to Dal caos all’automazione di sistemi e infrastrutture IT con Ansible

Similar to Dal caos all’automazione di sistemi e infrastrutture IT con Ansible (20)

More from Commit University

More from Commit University (20)

Recently uploaded

Recently uploaded (20)

Dal caos all’automazione di sistemi e infrastrutture IT con Ansible