220 lines
6.9 KiB
Markdown
220 lines
6.9 KiB
Markdown
Ansible
|
|
=======
|
|
|
|
Ansible is a extra-simple tool/API for doing 'parallel remote things' over SSH -- whether
|
|
executing commands, running "modules", or executing larger 'playbooks' that
|
|
can serve as a configuration management or deployment system.
|
|
|
|
While [Func](http://fedorahosted.org/func), which I co-wrote,
|
|
aspired to avoid using SSH and have it's own daemon infrastructure,
|
|
Ansible aspires to be quite different and more minimal, but still able
|
|
to grow more modularly over time. This is based on talking to a lot of
|
|
users of various tools and wishing to eliminate problems with connectivity
|
|
and long running daemons, or not picking tool X because they preferred to
|
|
code in Y. Further, playbooks take things a whole step further, building the config
|
|
and deployment system I always wanted to build.
|
|
|
|
Why use Ansible versus something else? (Fabric, Capistrano, mCollective,
|
|
Func, SaltStack, etc?) It will have far less code, it will be more correct,
|
|
and it will be the easiest thing to hack on and use you'll ever see --
|
|
regardless of your favorite language of choice. Want to only code plugins
|
|
in bash or clojure? Ansible doesn't care. The docs will fit on one page
|
|
and the source will be blindingly obvious.
|
|
|
|
Design Principles
|
|
=================
|
|
|
|
* Dead simple setup
|
|
* Super fast & parallel by default
|
|
* No server or client daemons; use existing SSHd
|
|
* No additional software required on client boxes
|
|
* Modules can be written in ANY language
|
|
* Awesome API for creating very powerful distributed scripts
|
|
* Be usable as non-root
|
|
* Create the easiest config management system to use, ever.
|
|
|
|
Requirements
|
|
============
|
|
|
|
For the server the tool is running from, *only*:
|
|
|
|
* paramiko
|
|
* python 2.6 (or the 2.4/2.5 backport of the multiprocessing module)
|
|
* PyYAML (only if using playbooks)
|
|
|
|
Optional -- If you want to push templates, the nodes need a template library,
|
|
which for bonus points you can install with ansible! Easy enough.
|
|
|
|
* python-jinja2
|
|
|
|
Inventory file
|
|
==============
|
|
|
|
To use ansible you must have a list of hosts somewhere. The default inventory host list (override with -l) is /etc/ansible/hosts and is a list of all hostnames to manage with ansible, one per line. These can be hostnames or IPs.
|
|
|
|
Example:
|
|
|
|
abc.example.com
|
|
def.example.com
|
|
192.168.10.50
|
|
192.168.10.51
|
|
|
|
This list is further filtered by the pattern wildcard (-p) to target
|
|
specific hosts. This is covered below. You can also organize groups of systems by having multiple inventory files (i.e. keeping webservers different from dbservers, etc)
|
|
|
|
Massive Parallelism, Pattern Matching, and a Usage Example
|
|
==========================================================
|
|
|
|
Reboot all web servers in Atlanta, 10 at a time:
|
|
|
|
ssh-agent bash
|
|
ssh-add ~/.ssh/id_rsa.pub
|
|
ansible -p "atlanta-web*" -f 10 -n command -a "/sbin/reboot"
|
|
|
|
Other than the comamnd module, though, ansible modules are not scripts. They make
|
|
the remote system look like you state, and run the commands neccessary to get it
|
|
there.
|
|
|
|
[Read the manpage](https://github.com/mpdehaan/ansible/blob/master/docs/man/man1/ansible.1.asciidoc)
|
|
|
|
File Transfer
|
|
=============
|
|
|
|
Ansible can SCP lots of files to lots of places in parallel.
|
|
|
|
ansible -p "web-*.acme.net" -f 10 -n copy -a "/etc/hosts /tmp/hosts"
|
|
|
|
Templating
|
|
==========
|
|
|
|
JSON files can be placed for template metadata using Jinja2. Variables
|
|
placed by 'setup' can be reused between ansible runs.
|
|
|
|
ansible -p "*" -n setup -a "favcolor=red ntp_server=192.168.1.1"
|
|
ansible -p "*" -n template -a "src=/srv/motd.j2 dest=/etc/motd"
|
|
ansible -p "*" -n template -a "src=/srv/ntp.j2 dest=/etc/ntp.conf"
|
|
|
|
Need something like the fqdn in a template? If facter or ohai are installed, data from these projects
|
|
will also be made available to the template engine, using 'facter_' and 'ohai_'
|
|
prefixes for each.
|
|
|
|
Git Deployments
|
|
===============
|
|
|
|
Deploy your webapp straight from git
|
|
|
|
ansible -p "web*" -n git -a "repo=git://foo dest=/srv/myapp version=HEAD"
|
|
|
|
Take Inventory
|
|
==============
|
|
|
|
Run popular open-source data discovery tools across a wide number of hosts.
|
|
This is best used from API scripts that want to learn about remote systems.
|
|
|
|
ansible -p "dbserver*" -n facter
|
|
ansible -p "dbserver"" -n ohai
|
|
|
|
Other Modules
|
|
=============
|
|
|
|
See the library directory for lots of extras. There's also a manpage,
|
|
[ansible-modules(5)](https://github.com/mpdehaan/ansible/blob/master/docs/man/man5/ansible-modules.5.asciidoc) that covers all the options they take. You can
|
|
read the asciidoc in github in the 'docs' directory.
|
|
|
|
Playbooks
|
|
=========
|
|
|
|
Playbooks are particularly awesome. Playbooks can batch ansible commands
|
|
together, and can even fire off triggers when certain commands report changes.
|
|
|
|
They are the basis for a really simple configuration management system, unlike
|
|
any that already exist, and one that is very well suited to deploying complex
|
|
multi-machine applications.
|
|
|
|
An example showing just once pattern in a playbook is below. Playbooks can contain
|
|
multple patterns in a single file.
|
|
|
|
---
|
|
- pattern: 'webservers*'
|
|
comment: webserver setup steps
|
|
hosts: '/etc/ansible/hosts'
|
|
tasks:
|
|
- name: configure template & module variables for future template calls
|
|
action: setup http_port=80 max_clients=200
|
|
- name: write the apache config file
|
|
action: template src=/srv/templates/httpd.j2 dest=/etc/httpd.conf
|
|
notify:
|
|
- restart apache
|
|
- name: ensure apache is running
|
|
action: service name=httpd state=started
|
|
handlers:
|
|
- name: restart apache
|
|
- action: service name=httpd state=restarted
|
|
|
|
See the playbook format manpage -- [ansible-playbook(5)](https://github.com/mpdehaan/ansible/blob/master/docs/man/man5/ansible-playbook.5.asciidoc) for more details.
|
|
|
|
To run a playbook:
|
|
|
|
ansible-playbook playbook.yml
|
|
|
|
API
|
|
===
|
|
|
|
The Python API is pretty powerful.
|
|
|
|
import ansible.runner
|
|
|
|
runner = ansible.runner.Runner(
|
|
module_name='ping',
|
|
module_args='',
|
|
pattern='web*',
|
|
forks=10
|
|
)
|
|
datastructure = runner.run()
|
|
|
|
And returns results per host, for hosts we could contact
|
|
and also ones that we failed to contact.
|
|
|
|
{
|
|
"dark" : {
|
|
"web1.example.com" : "failure message"
|
|
}
|
|
"contacted" : {
|
|
"web2.example.com" : 1
|
|
}
|
|
|
|
}
|
|
|
|
A module can return any type of JSON data it wants, so Ansible can
|
|
be used as a framework to build arbitrary applications and very powerful
|
|
scripts.
|
|
|
|
Future plans
|
|
============
|
|
|
|
See github's issue tracker for what we're thinking about
|
|
|
|
License
|
|
=======
|
|
|
|
GPLv3
|
|
|
|
Mailing List and IRC
|
|
====================
|
|
|
|
Join the mailing list to talk about Ansible:
|
|
|
|
[ansible-project](http://groups.google.com/group/ansible-project)
|
|
|
|
irc.freenode.net: #ansible
|
|
|
|
Everyone may not always be available on IRC, for important issues/questions, use the list or file a ticket.
|
|
|
|
Author
|
|
======
|
|
|
|
Michael DeHaan -- michael.dehaan@gmail.com
|
|
|
|
[http://michaeldehaan.net](http://michaeldehaan.net/)
|
|
|
|
|