Vous êtes sur la page 1sur 36

Ansible

Go directly to project site


1 / 36

Whatisitandwhy
shouldIbeusingit?

2 / 36

What
is
it?

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 and
update your applications
Automate in a language that approaches plain English,
using SSH
No agents to install on remote systems

3 / 36

What
is
it?
Why
use
it?

Ansible as a project dislikes complexity


Simplicity is relevant to all sizes of environments and
users of all types
It's not meant to be a tool you should have to obsess
over, and it believes "perfect is the enemy of good" in
many cases. Therefore the learning curve is really
fast.
No coding, instructions are plain YAML
Ansible is appropriate for managing small setups as
well as enterprise environments with many
thousands.

4 / 36

Setupthecontrolmachine

5 / 36

Setup
the
control
machine

Ansible uses python2.7 and SSH to communicate with


your remote systems
Have python2.7 installed
Use SSH keys for your authentication:
ssh-agent bash
ssk-keygen
ssh-add ~/.ssh/id_rsa
ssh-copy-id -i /root/.ssh/id_rsa root@localhost

Install required packages


apt-get install python-pip
apt-get install python-dev

Work in a virtualenv
pip install virtualenv
virtualenv myproject
cd myproject
. bin/activate
pip install ansible

6 / 36

Yourfirstcommands

7 / 36

Your
first
command

Ansible requires an inventory file


echo "localhost" > ansible_hosts

Ping all hosts in your inventory file


ansible all -m ping -i ansible_hosts

Congratulations. Youve just contacted your nodes with


Ansible:
localhost | success >> {
"changed": false,
"ping": "pong"
}

8 / 36

Your
first
commands
Examine
the
command
line

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 Ansibles
inventory file. "all" is a special word to work with all
the hosts at the same time.
-m

will accept a correct module name (e.g., "ping").


Ansible ships with a module library but you can write
your own module too. Modules are idempotent,
meaning they will seek to avoid changes to the system
unless a change needs to be made. The (long) list of
modules can be found here.
-i

The name of the inventory file.


9 / 36

Theinventoryfile

10 / 36

The
inventory
file

The format for ansible_hosts is an INI-like format and


looks like this:
[webservers]
localhost
[dbservers]
one.example.com
two.example.com
three.example.com

The things in brackets are group names, which are used in


classifying systems and deciding what systems you are
controlling at what times and for what purpose.
It is ok to put systems in more than one group, for
instance a server could be both a webserver and a
dbserver.

11 / 36

Modules

12 / 36

Modules

Ansible ships with a number of modules.


Users can also write their own modules.
Each module supports taking arguments. Nearly all
modules take key=value arguments, space delimited.
Some modules take no arguments, and the
command/shell modules simply take the string of the
command you want to run.
Most used modules
apt -- Add/Remove packages le
command -- Execute any shell command
service -- Start/Stop/Enable services
copy -- Copy a le from source to destination on host
file -- Create directories, symlinks, change permissions
template -- Copy, but with variable substitution in le
Example:
ansible all -m apt -i ansible_hosts -a "name=apache2 state=present"
ansible all -m service -i ansible_hosts -a "name=apache2 state=started"

13 / 36

Playbooks

14 / 36

Playbooks

Playbooks are Ansibles configuration, deployment,


and orchestration language. They can describe a set of
connected actions in a general IT process.
If Ansible modules are the tools in your workshop,
playbooks are your design plans.
Playbooks are expressed in YAML format (see YAML
Syntax) 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.
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 youll want to reuse files and
start to organize things.

15 / 36

Playbook
Example

Write an inventory file


echo localhost > ansible_hosts

Open a file named playbook.yml


--- hosts: all
vars:
http_port: 80
remote_user: root
tasks:
- name: ensure apache2 is installed
apt: name=apache2 state=present

Run your playbook:


ansible-playbook -i ansible_hosts playbook.yml

16 / 36

Test passed:
PLAY [test]
************************************************************
TASK: [ensure apache2 is installed]
******************************************
ok: [localhost] => {"changed": false}
PLAY RECAP
************************************************************
localhost : ok=2 changed=0 unreachable=0 failed=0

17 / 36

PlaybookRolesandIncludeActions

18 / 36

Playbook
Roles
and
Include
Actions

A playbook that includes a role:


- hosts: webservers
vars:
http_port: 80
remote_user: root
roles:
- webservers

Roles are ways of automatically loading certain variables,


tasks, templates, handlers based on a known file structure.
Grouping content by roles also allows easy sharing of roles
with other users. Example role structure:
ansible_hosts
webservers.yml
roles/
webservers/
files/
templates/
tasks/
handlers/
vars/
defaults/
meta/

19 / 36

Playbook
Roles
and
Include
Actions

Role hierarchy:
If roles/x/tasks/main.yml exists, tasks listed therein
will be added to the play
If roles/x/handlers/main.yml exists, handlers listed
therein will be added to the play
If roles/x/vars/main.yml exists, variables listed therein
will be added to the play
If roles/x/meta/main.yml exists, any role
dependencies listed therein will be added to the list of
roles (1.3 and later)
Any copy tasks can reference files in roles/x/files/
without having to path them relatively or absolutely
Any script tasks can reference scripts in roles/x/files/
without having to path them relatively or absolutely
Any template tasks can reference files in
roles/x/templates/ without having to path them
relatively or absolutely
Any include tasks can reference files in roles/x/tasks/
without having to path them relatively or absolutely

20 / 36

Variables

Variables should always start with a letter.


foo_port is a great variable. foo5 is fine too.
foo-port, foo port, foo.port and 12 are not valid
variable names.
Variables can be defined in many places (pros & cons..)
in inventory
in a playbook
included files
There are "facts", a type of variable that are discovered,
not set by the user. Facts are returned by the module
"setup", for example: The hostname as the system reports
it is: {{ ansible_hostname }}
registered variables (a task output)
command line (--extra-vars)

21 / 36

Variables
hierarchy

extra vars (-e in the command line) always win


then comes connection variables defined in inventory
(ansible_ssh_user, etc)
then comes "most everything else" (command line
switches, vars in play, included vars, role vars, etc)
then comes the rest of the variables defined in
inventory
then comes facts discovered about a system
then "role defaults", which are the most "defaulty" and
lose in priority to everything.

22 / 36

AnsibleandAWS

23 / 36

Ansible
and
AWS

Ansible contains a number of modules for controlling


Amazon Web Services (AWS). All of the modules require
and are tested against recent versions of boto. Youll need
this Python module installed on your control machine.
pip install boto

Static inventory or dynamic Inventory?If you use Amazon


Web Services EC2, maintaining an inventory file might not
be the best approach, because hosts may come and go
over time, be managed by external applications, or you
might even be using AWS autoscaling.

24 / 36

Ansible
and
AWS

AWS services ships with a set of credentials:


ssh key
acces_id
secret_key
Add the ssh key
ssh-add keyname

and set its name in aws-related playbooks (ansible will


look for your ssh-key in the standard path ~/.ssh/). 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
. aws-vars

25 / 36

Ansible
and
AWS

Some simple checks:


./plugins/inventory/ec2.py --list
{
"_meta": {
"hostvars": {
...
"ec2_architecture": "x86_64",
...
}
}
"ec2": [
...
"ec2-name.region.compute.amazonaws.com"
...
]
}
ansible all -i ./plugins/inventory/ec2.py -m ping --user=admin
ec2-name.region.compute.amazonaws.com | success >> {
"changed": false,
"ping": "pong"
}

26 / 36

ManageyourAWS
nodeswithansible

27 / 36

Create
and
start
a
node

demo-create.yml
- name: Creates aws-nodes
hosts: all
connection: local
remote_user: root
vars:
image_id: image-id
instance: instance-type
key_name: ssh-key
region: region-name
tasks:
- name: Create and launch instance
ec2:
key_name: "{{ ssh-key }}"
instance_type: "{{ instance }}"
image: "{{ image_id }}"
region: "{{ region }}"
state: present
count: 1
wait: yes
ansible-playbook -i aws.ini demo-create.yml

28 / 36

Stop
a
node

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

To see your instances being stopped.

29 / 36

Provision
nodes

Provision your nodes


Install apache on remote AWS hosts
./bin/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"

30 / 36

Delete
nodes

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

31 / 36

Sometools

32 / 36

Some
tools

ansible-galaxy
It is the Ansibles 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
|-- test-role
| |-- defaults
| | `-- main.yml
| |-- files
| |-- handlers
| | `-- main.yml
| |-- meta
| | `-- main.yml
| |-- README.md
| |-- tasks
| | `-- main.yml
| |-- templates
| `-- vars
|
`-- main.yml

33 / 36

Some
tools

debops
Your Debian-based data center in a box. It is a framework.
It can be installed through ansible-galaxy. It is a collection
of Ansible playbooks, scalable from one container to an
entire data center.
ansible-galaxy install debops.apt
ansible all -s -m apt -a 'update_cache=yes upgrade=yes'

34 / 36

Some
tools

epdb
epdb or pdb? The reason to use epdb over pdb is epdb
contains a remote debugging feature that can sometimes
be useful for debugging processes where you dont have
console access.
In python module write:
import epdb
epdb.serve()

Command line to execute module:


ansible --forks 1 -i ansible_hosts --module-path path
-m module_name -a ''

Command line to see breakpoint:


python -c "import epdb; epdb.connect()"

35 / 36

"Allpartsshouldgotogetherwithoutforcing.Youmust
rememberthatthepartsyouarereassemblingwere
disassembledbyyou.Therefore,ifyoucan'tgetthem
togetheragain,theremustbeareason.Byallmeans,donot
useahammer."
IBMmaintenancemanual,1925

Slideshow created using remark.


36 / 36

Vous aimerez peut-être aussi