Introduction to Ansible (Pycon7 2016)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible: automazione IT vocata al Cloud
Ivan Rossi (BioDec.com)
Pycon sette, 2016-04-16
Ivan Rossi (BioDec.com) Ansible: automazione IT vocata al Cloud Pycon sette, 2016-04-16 1 / 40

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Main features
“Ansible is a radically simple IT automation platform that makes your
applications and systems easier to deploy….”
Avoid writing scripts or custom code to deploy/update applications
No agents to install on remote systems (SSH + python)
Ansible project dislikes complexity
“perfect is the enemy of good”: the learning curve is really fast.
Code is YAML
appropriate for managing small-medium setups
some enterprise environments with many thousands.
Acquired by RedHat in October 2015.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Why Ansible is suited to the Cloud
Major Configuration management tools
Tool Style Push/pull Agent?
Cfengine Declarative Pull Yes
Puppet Declarative Pull Yes
Chef Imperative Pull Yes
Salt Declarative* Both Yes*
Ansible Imperative Push No
Ansible is suited to the immutable/disposable infrastructure approach

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Quoting…
“People often ask me how does Ansible compete with other configuration
management tools? We don’t, we compete with Bash.”
-- Greg DeKoenigsberg,
CfgMgmtCamp 2016, Gent (BE), 2016-02-02

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Setup overview
Setup overview

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Setup overview
Setup the control machine
Ansible uses python2.7 and SSH to communicate
On the managed systems.
1 Have python2.7 installed
2 SSH key-based authentication:
ssh-copy-id -i /root/.ssh/admin_id_rsa root@localhost

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Setup overview
On the control machine
1 Install Python and required packages
apt-get install python-pip
apt-get install python-dev
2 Install Ansible
Pro tip: work in a virtualenv
pip install virtualenv
virtualenv myproject
cd myproject
. bin/activate
pip install ansible

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Simple parallel execution

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Your first commands
1 Create basic inventory file
echo "localhost" > ansible_hosts
2 Ping all hosts in your inventory file
ansible all -m ping -i ansible_hosts
Congratulations. You’ve just contacted your nodes with Ansible.
localhost | success >> {
"changed": false,
"ping": "pong"
}

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Command-line example
ansible all -m ping -i ansible_hosts
all Ansible works against multiple systems in your infrastructure
at the same time. It does this by selecting portions of
systems listed in the inventory file. “all” is a special keyword
to work with all the hosts at the same time.
-m accepts a correct module name (e.g., “ping”).
-i The name of the inventory file.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
The inventory file
The format for ansible_hosts is an INI-like format and looks like this:
[webservers]
localhost
one.example.com
[dbservers]
one.example.com
two.example.com
three.example.com
In brackets are group names, used to group and classifying systems. It is
OK to put systems in more than one group.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Modules
Ansible ships with a large module library
Modules are idempotent, usually.
Users can write their own modules (in Python)
Frequently used modules
package Add/Remove packages file (many formats)
command Execute any shell command
service Start/Stop/Enable services
copy Copy a file from source to destination on host
template generate a file from a Jinja2 template
Example:
ansible all -m apt -a "name=apache2 state=present"
ansible all -m service -a "name=apache2 state=started"

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Ansible programming

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Playbooks
Playbooks are the configuration, deployment, and orchestration
language.
They can describe a set of connected actions in a general IT process.
If modules are the tools, playbooks are your design plans.
Playbooks are expressed in YAML format and have a minimal syntax
Tries not to be a programming language, but a model of a
configuration or a process.
Each playbook is composed of one or more ‘plays’ in a list.
While it is possible to write a playbook in one very large file, eventually
you’ll want to reuse components (roles, more later)

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Playbook example
Write an inventory file
echo localhost > ansible_hosts
a playbook (named playbook.yml)
---
- hosts: all
vars:
http_port: 80
remote_user: root
tasks:
- name: ensure apache2 is installed
apt: name=apache2 state=present

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Run your playbook:
ansible-playbook -i ansible_hosts playbook.yml
Playbook output
PLAY [test]
*************************************************************
TASK: [ensure apache2 is installed]
*******************************************
ok: [localhost] => {"changed": false}
PLAY RECAP
*************************************************************
localhost : ok=2 changed=0 unreachable=0 failed=0

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Variables and Facts
Variables
Variables should always start with a letter.
Variables can be defined in many places (pros & cons..)
in inventory, playbook, include, command line
priority rules are… involved.
Facts
A type of variable that are discovered at a run time, not set by the
user. Very useful for dynamic configuration
Facts are returned by the setup module, which is executed at the
beginning of a playbook by default and made available as variables.
the hostname of the system: {{ ansible_hostname }}

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Roles and Include Actions
A playbook can includes a role:
- hosts: webservers
vars:
http_port: 80
remote_user: root
roles:
- webservers
Roles allow the automatic loading the definitions of variables, tasks,
templates, handlers, given a standard layout. Grouping content by roles
allows easy sharing of playbooks too.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Example role structure:
ansible_hosts
webservers.yml
roles/
webservers/
files/
templates/
index.html.j2
tasks/
main.yml
handlers/
vars/
main.yml
defaults/
meta/

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Role hierarchy:
If roles/x/[tasks,handlers,vars,meta]/main.yml exists:
[tasks,handlers,vars,meta] listed therein will be added to the play
Any [copy, script, template, include] directive can reference files in
respective roles directory without having to path them
To create a standard-compliant role
ansible-galaxy init --offline test-role

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
ansible-galaxy
“It is the Ansible’s official community hub for finding, downloading, rating,
and sharing Ansible roles…”
ansible-galaxy install username.rolename
You can use ansible-galaxy to start a project of your own
ansible-galaxy init --offline test-role
Many many projects
Many many duplicates
Quality from excellent through broken to horribly dangerous

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Ansible 2.0 has arrived
Task Blocks
Error Reporting Improvements
Run time evaluation of tasks: new strategy plugin
200 new modules
new OpenStack modules
expand Amazon Web Services support
improve Docker modules
expand Microsoft support

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
New 2.0 features
Task Blocks: Write less
Consecutive tasks can be grouped under a common name. This
feature allows to apply directives at the block level, like:
when condition
error handling (new block/rescue/always directives)
set user
Error Reporting Improvements: Maybe you mean…
Clearer identification of errors by printing line and file responsible for
playbook failure with suggestions for fixes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
New 2.0 features
Run time evaluation of tasks: Speed up execution
A new strategy plugin has been added. The canonical way to run tasks
adopted by Ansible is “linear”. Now a “free” workflow is available,
which allows each host to process its list of tasks as quickly as possible
(still in-order) without waiting for all other hosts.
- hosts: all
strategy: free
tasks:
...

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible programming
Known Issues with Ansible 2.0
Dynamic Include Problems
Tags on tasks are not seen until the include is processed. Tags should
be specified only at “include” level
Handlers in includes will not be seen. Handlers should avoid using
includes
Ansible 2.0 does not currently raise an error if a non-existent tag is
specified via –tags or –skip-tags
Plugin API Changes
Callback, connection, cache and lookup plugin APIs have changed.
Existing plugins might require modification to work with the new
versions

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible and the Cloud

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible and Amazon Web Services (AWS)
Other Clouds
Other Cloud providers are supported too, but AWS is king…
AWS Control
Ansible contains many modules for controlling AWS services. All of the
modules require recent versions of boto. You need this Python module
installed on your control machine.
pip install boto
Boto is a Python interface to AWS API, and allows dynamic inventory.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Ansible and AWS security
To access AWS services one needs a set of credentials:
ssh key
access_id
secret_key
Set your access_id and secret_key in a “vars” file, then source it:
export BOTO_CONFIG=/path/boto.conf
export EC2_INI_PATH=/path/ec2.ini
export AWS_ACCESS_KEY_ID=EXAMPLEKEY
export AWS_SECRET_ACCESS_KEY=ThisIsAnExample
export AWS_DEFAULT_REGION=region
PLEASE DO NOT SHARE KEYS ON GITHUB

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
AWS Dynamic inventory
$ ./plugins/inventory/ec2.py --list
{
"_meta": {
"hostvars": {
"ec2_architecture": "x86_64",
...
}
}
"ec2": [
"ec2-name.region.compute.amazonaws.com"
...
]
}

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Now you are Elastic
$ ansible all -i ./plugins/inventory/ec2.py -m ping --user=adm
ec2-name.region.compute.amazonaws.com | success >> {
"changed": false,
"ping": "pong"
}

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Manage your AWS nodes with ansible

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Create and start nodes
- name: Creates aws-nodes
hosts: all
connection: local
remote_user: admin
tasks:
- name: Create and launch instance
ec2:
key_name: "{{ ssh-key }}"
instance_type: "{{ instance }}"
image: "{{ image_id }}"
region: "{{ region }}"
state: present
count: 3
wait: yes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Stop nodes
- name: Stop aws servers
connection: local
remote_user: root
vars:
- region: region_name
tasks:
- name: Stop instances
ec2:
state: stopped
instance_ids: "{{ec2_id}}"
To see your instances being stopped.
$ ansible-playbook -i plugins/inventory/ec2.py demo-stop.yml

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Provision nodes
Provision your nodes
Install apache on remote AWS hosts
$ ansible all -m apt -i plugins/inventory/ec2.py -a
"name=apache2 state=present" --user=admin --become=sudo
"changed": true,
"stderr": "",
"stdout": "Reading package lists...
Building dependency tree...
Reading state information...
...
Setting up apache2"

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Delete nodes
$ ansible-playbook -i plugins/inventory/ec2.py demo-terminate.
$ cat demo-terminate.yml
- name: Delete aws servers
remote_user: root
vars:
- region: region_name
tasks:
- name: Delete hosts
ec2:
instance_ids: "{{ ec2_id }}"
state: absent
wait: yes

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Cloudformation: one-shot AWS infrastructure
AWS Cloudformation is a service to easily and repeatably provision
an AWS infrastructure (instances, VPCs, security groups…).
The infrastructure objects and relations are modeled in a JSON file
called “template”.
Using the template a “stack” is instantiated. A “stack” is “a
collection of AWS resources you create and delete as a single unit.”
N.B.notice the “delete”: think “immutable infrastructure”…

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Launching stacks with Ansible
The Ansible “cloudformation” module launches a Cloudformation stack.
Once the stack template is created, an Ansible task can provision it:
- cloudformation:
aws_access_key: "{{ AwsAccessKey }}"
aws_secret_key: "{{ AwsSecretKey }}"
stack_name: "{{ CloudFormationStackName }}"
state: present
region: "{{ AwsRegion }}"
disable_rollback: false
template_url: "https://s3-{{ AwsRegion }}.amazonaws.com/om
register: stack
NOTE: the returning “stack” variable let us to retrieve information about
the resources instantiated in order to perform other actions on them.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Pythonic template by Trophospere
The JSON template can grow to be really messy. A Python library called
Troposphere may make the cloudformation model description easier to
manage
>>> from troposphere import Ref, Template
>>> import troposphere.ec2 as ec2
>>> t = Template()
>>> instance = ec2.Instance("myinstance")
>>> instance.ImageId = "ami-951945d0"
>>> instance.InstanceType = "t1.micro"
>>> t.add_resource(instance)
<troposphere.ec2.Instance object at 0x101bf3390>
>>> print(t.to_json())
{
"Resources": {
"myinstance": {
"Properties": {Ivan Rossi (BioDec.com) Ansible: automazione IT vocata al Cloud Pycon sette, 2016-04-16 38 / 40

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Thank you
Thank you

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Thank you
Contacts
Ivan Rossi email: ivan@biodec.com
twitter: @rouge2507
BioDec www.biodec.com

Introduction to Ansible (Pycon7 2016)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (15)

Similar to Introduction to Ansible (Pycon7 2016)

Similar to Introduction to Ansible (Pycon7 2016) (20)

Recently uploaded

Recently uploaded (20)

Introduction to Ansible (Pycon7 2016)