Introducing Ansible

Introducing Ansible
Francesco Pantano
francesco.pantano@opmbx.org
March 7, 2016

#Outline
1 A day in the life of a sysadmin
2 Automation
3 Introducing Ansible
4 Ansible Playbooks: beyond the Basics
5 Roles and Includes
6 Automating Your Automation
A day in the life of a sysadmin 2/32

The timeline
”We have the misfortune to be living in the present. In the future,
of course, computers will be smart enough to just ﬁgure out what
we want, and do it. Until then, we have to spend a lot of time
telling the computer things it should already know.”

Keeping the conﬁguration synchronized

Repeating changes across many servers
The command to create a new user account is slightly different for
Red Hat Linux from the equivalent command for Ubuntu, for
example. Solaris is a little different again.
Each command is doing basically the same job, but has differences
in syntax, arguments, and default values.

Self-updating documentation
A new sysadmin joins your organization, and he needs to know
where all the servers are, and what they do. Even if you keep
scrupulous documentation, it can’t always be relied on.
The only accurate documentation, in fact, is the servers
themselves. You can look at a server to see how it’s configured,
but that only applies while you still have the machine. If something
goes wrong and you can’t access the machine, or the data on it,
your only option is to reconstruct the lost configuration from
scratch.
Wouldn’t it be nice if you had a configuration document which was
guaranteed to be up to date?

Version control, history, continuous integration

#Outline
2 Automation
Automation 8/32

Why Automation?
Fast deployment time
It’s cheap and ﬂexible
Scalability and support
Standard environments
Automation as a standardized approach
IT automation is a standard approach that
combines multi-node software deployment,
ad-hoc task execution and conﬁguration
management.
Automation 9/32

The Automation environment
Automation 10/32

IT Automation: Terminology
Idempotence: the ability to run an operation which produces the
same result whether run once or multiple times
Inventory: hosts file that defines:
the description of the nodes that can be
accessed
the IP address or hostname of each node
nodes group to run a different set of
tasks
nodes parameters such as username,
password or ssh keys
Playbooks: they express configurations, deployment and
orchestration in Ansible. Each Playbook maps a group of hosts to
a set of roles. Each role is represented by calls to Ansible call tasks.
Automation 11/32

#Outline
2 Automation
Introducing Ansible 12/32

Quick Start
Linux - run natively e.g. on a Fedora/RHEL/CentOS:
yum -y install ansible
Debian or Ubuntu
sudo apt-add-repository -y ppa:ansible/ansible
sudo apt-get update
sudo apt-get install -y ansible
Verify your installation
$ ansible –version
ansible 2.0.1.0
config file = /etc/ansible/ansible.cfg
configured module search path = Default w/o overrides

The inventory ﬁle
Where it is located
/etc/ansible/hosts
What is the format
[mailservers]
mail.example.com
[webservers]
foo.example.com ansible ssh user = user001
bar.example.com ansible ssh private key ﬁle =
/.ssh/ansible key001
[dbservers]
one.example.com
two.example.com
db-[a:f].example.com

The inventory file
I can define a group of machines
# Group ’multi’ with all servers
[multi:children]
vm01
vm02
# Variables that will be applied to all servers
[multi:vars]
ansible ssh user=user001
ansible ssh private key file = /.ssh/pkey
..available parameters
https://docs.ansible.com/ansible/intro inventory.html

The Ansible command line
ansible-playbook
Execute a playbook
ansible-galaxy
Roles management
ansible example -a ”free -m” -u [username]
Run the free command on the example domain
ansible example -m ping -u [username]
Run the ping command on the example domain
ansible atlanta -m copy -a ”src=/etc/hosts
dest=/tmp/hosts”
File copy using the copy module
ansible all -m user -a ”name=foo password=’crypted
password here’”
User and group management

Your ﬁrst Ansible playbook
Host section
It is related to a section of the inventory ﬁle described above
---
- 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
Vars Section
Variables used to the tasks in order to parametrize something

Your ﬁrst Ansible playbook
Task section
Groups of tasks that are performed on a certain set of hosts to
allow them to fulﬁll the function you want to assign to them.
Notify section
This is not an internal Ansible command, it is a reference to a
handler, which can perform certain functions when it is called from
within a task.
Handlers section
Handlers are just like tasks, but they only run when they have been
told by a task that changes have occurred on the client system.
Run the playbook
ansible-playbook playbook.yml

#Outline
2 Automation
Ansible Playbooks: beyond the Basics 19/32

Playing with variables
---
- hosts: example
vars:
foo: bar
tasks:
# Prints "Variable ’foo’ is set to bar".
- debug: msg="’foo’ is set to {{ foo }}"
Variables always begin with a letter ([A-Za-z]), and can include
any number of underscores ( ) or numbers ([0-9]).
Variables can be passed in via the command line, when calling
ansible-playbook, with the –extra-vars option:
ansible-playbook example.yml –extra-vars ”foo=bar”

Registering/Accessing variables
Send a command and register the result...
name: Get the value of the environment variable we just added.
shell: ”source /.bash proﬁle && echo $ENV VAR”
register: foo
..and then use it as before
- name: Print the value of the environment variable.
debug: msg = ”The variable is {{ foo.stdout }}”

Per-play environment variables
# Set to ’absent ’ to disable proxy:
proxy_state: present
# In the ’tasks ’ section of the playbook:
- name: Configure the proxy.
lineinfile:
dest: /etc/ environment
regexp: "{{ item.regexp }}"
line: "{{ item.line }}"
state: "{{ proxy_state }}"
with_items:
- {regexp:"^http_proxy=",line:"http_proxy=http :// example -proxy :80/"}
- {regexp:"^https_proxy=",line:" https_proxy =https :// example -proxy :443/"}
- {regexp:"^ftp_proxy=",line:"ftp_proxy=http :// example -proxy :80/"}
Doing it this way allows me to conﬁgure whether the proxy is
enabled per-server, and with one play, set the http, https, and ftp
proxies. You can use a similar kind of play for any other types of
environment variables you need to set system-wide.

#Outline
2 Automation
Roles and Includes 23/32

Roles and Includes
Ansible is very ﬂexible when it comes to organizing your tasks in
more eﬃcient ways so you can make your playbooks more
maintainable, reusable, and powerful. We are talking about:
Includes
Roles
Includes examples
handlers:
- include: included-handlers.yml
tasks:
- include: tasks/common.yml
- include: tasks/apache.yml
- include: tasks/mysql.yml

More about roles
Including playbooks inside other playbooks makes your playbook
organization a little more sane, but once you start wrapping up
your entire infrastructures configuration in playbooks, you might
end up with something resembling Russian nesting dolls. The
solution comes with the keyword: roles.
Roles provides a way to take bits of configuration and packages
and make them flexible so we can use them throughout our
infrastructure and we can include them in this way:
roles:
- yum-repo-setup
- firewall
- nodejs
- app-deploy

Role essentials
Instead of requiring you to explicitly include certain files and
playbooks in a role, Ansible automatically includes any main.yml
files inside specific directories that make up the role.
Roles structure
There are only two
directories required to
make a working role:
role name/
meta/main.yml
tasks/main.yml
Ansible will run all the tasks
defined in tasks/main.yml, you
just need to include the created
role using following syntax:
- - -
- hosts: all
roles:
- role name
Your roles can live in a couple different placesin the default global
Ansible role path configurable in /etc/ansible/ansible.cfg.

Enter Ansible Galaxy: Be social
Wouldnt it be better if people could share roles for
commonly-installed applications and services?
Helpful Galaxy commands
Some other helpful ansible-galaxy commands you might use from
time to time:
ansible-galaxy list displays a list of installed roles, with
version numbers
ansible-galaxy remove [role] removes an installed role
ansible-galaxy init can be used to create a role template
suitable for submission to Ansible Galaxy

#Outline
2 Automation
Automating Your Automation 28/32

Ansible tower
Continuous integration
It’s always a good practise use a continuous integration model
inside your infrastructure
Go Over the CLI
The business needs detailed reporting of infrastructure
deployments and failures, especially for audit purposes.
Team-based infrastructure management requires varying levels
of involvement in playbook management, inventory
management, and key and password access.
A through visual overview of the current and historical
playbook runs and server health helps identify potential issues
before they aﬀect the bottom line.
Playbook scheduling can help ensure infrastructure remains in
a known state.

Ansible tower

Thank you! Questions?
More examples at
https://github.com/ansible/

References
Ansible for DevOps
https://leanpub.com/ansible-for-devops
Ansible in Real Life
https://www.reinteractive.net/posts/167-ansible-real-life-
good-practices
Ansible Tower
https://docs.ansible.com/ansible-tower/
Oﬃcial doc
https://docs.ansible.com/

Introducing Ansible

More Related Content

What's hot

Viewers also liked

Similar to Introducing Ansible

Recently uploaded

Introducing Ansible