ansible/README.md

205 lines
6 KiB
Markdown
Raw Normal View History

2012-02-23 20:17:24 +01:00
Ansible
=======
Ansible is a extra-simple tool/API for doing 'parallel remote things' over SSH -- whether
executing commands, running declarative 'modules', or executing larger 'playbooks' that
can serve as a configuration management or deployment system.
2012-02-23 20:17:24 +01:00
2012-02-24 03:47:31 +01:00
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.
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
=================
2012-02-23 20:17:24 +01:00
2012-02-23 20:28:39 +01:00
* Dead simple setup
2012-02-23 20:40:17 +01:00
* Super fast & parallel by default
2012-02-23 20:28:39 +01:00
* No server or client daemons, uses existing SSHd
2012-02-23 20:40:17 +01:00
* No additional software required on client boxes
2012-02-24 03:47:31 +01:00
* Everything is self updating on the clients
* Encourages use of ssh-agent
* Plugins can be written in ANY language
* API usage is an equal citizen to CLI usage
* Can be controlled/installed/used as non-root
2012-02-23 20:17:24 +01:00
Requirements
============
2012-02-23 20:28:39 +01:00
For the server the tool is running from, *only*:
2012-02-23 20:40:17 +01:00
* python 2.6 -- or the 2.4/2.5 backport of the multiprocessing module
* PyYAML (install on 'overlord' if using playbooks)
2012-02-23 20:28:39 +01:00
* paramiko
2012-02-23 20:17:24 +01:00
Optional -- If you want to push templates, the nodes need:
* python-jinja2
2012-02-23 20:17:24 +01:00
Inventory file
==============
2012-02-24 03:47:31 +01:00
The inventory file is a required list of hostnames that can be
potentially managed by ansible. Eventually this file may be editable
via the CLI, but for now, is edited with your favorite text editor.
2012-02-23 20:40:17 +01:00
2012-02-24 03:47:31 +01:00
The default inventory file (-H) is /etc/ansible/hosts and is a list
2012-02-23 20:28:39 +01:00
of all hostnames to target with ansible, one per line. These
can be hostnames or IPs
2012-02-23 20:17:24 +01:00
Example:
abc.example.com
def.example.com
192.168.10.50
192.168.10.51
2012-02-23 20:17:24 +01:00
This list is further filtered by the pattern wildcard (-P) to target
specific hosts. This is covered below.
2012-02-23 20:17:24 +01:00
2012-02-23 22:32:58 +01:00
You can organize groups of systems by having multiple inventory
files (i.e. keeping webservers different from dbservers, etc)
Command line usage example
2012-02-23 20:17:24 +01:00
==========================
Run a module by name with arguments
2012-02-23 20:40:17 +01:00
* ssh-agent bash
* ssh-add ~/.ssh/id_rsa.pub
* ansible -p "*.example.com" -n modName -a "arg1 arg2"
2012-02-23 20:17:24 +01:00
API Example
===========
2012-02-24 04:47:03 +01:00
The API is simple and returns basic datastructures. Ansible will keep
track of which hosts were successfully contacted seperately from hosts
that had communication problems. The format of the return, if successful,
is entirely up to the module.
2012-02-23 20:17:24 +01:00
2012-02-25 07:00:37 +01:00
import ansible.runner
2012-02-24 05:29:34 +01:00
runner = ansible.runner.Runner(
2012-02-23 22:32:58 +01:00
pattern='*',
2012-02-24 03:47:31 +01:00
module_name='inventory',
module_args='...'
2012-02-23 22:32:58 +01:00
)
data = runner.run()
2012-02-23 20:17:24 +01:00
2012-02-25 07:00:37 +01:00
data is a dictionary:
{
2012-02-24 04:47:03 +01:00
'contacted' : {
'xyz.example.com' : [ 'any kind of datastructure is returnable' ],
'foo.example.com' : [ '...' ]
},
2012-02-24 04:47:03 +01:00
'dark' : {
'bar.example.com' : [ 'failure message' ]
}
}
2012-02-23 20:17:24 +01:00
2012-02-23 22:32:58 +01:00
Additional options to Runner include the number of forks, hostname
2012-02-24 03:47:31 +01:00
exclusion pattern, library path, arguments, and so on.
2012-02-24 04:47:03 +01:00
2012-02-24 03:47:31 +01:00
Read the source, it's not complicated.
2012-02-23 20:17:24 +01:00
Patterns
========
To target only hosts starting with "rtp", for example:
2012-02-24 03:47:31 +01:00
* ansible -p "rtp*" -n command -a "yum update apache"
2012-02-23 20:17:24 +01:00
Parallelism
===========
Specify the number of forks to use, to run things in greater parallelism.
* ansible -f 10 "*.example.com" -n command -a "yum update apache"
2012-02-23 20:17:24 +01:00
2012-02-23 20:28:39 +01:00
10 forks. The default is 3. 5 is right out.
File Transfer
=============
2012-02-23 22:32:58 +01:00
Ansible can SCP lots of files to lots of places in parallel.
2012-02-24 03:47:31 +01:00
* ansible -p "web-*.acme.net" -f 10 -n copy -a "/etc/hosts /tmp/hosts"
2012-02-24 03:47:31 +01:00
Ansible Library (Bundled Modules)
=================================
2012-02-23 20:17:24 +01:00
See the example library for modules, they can be written in any language
and simply return JSON to stdout. The path to your ansible library is
specified with the "-L" flag should you wish to use a different location
2012-02-24 03:47:31 +01:00
than "/usr/share/ansible". This means anyone can use Ansible, even without
root permissions.
There is potential for a sizeable community to build
2012-02-25 23:31:23 +01:00
up around the library scripts, and you can easily write your own.
2012-02-23 20:17:24 +01:00
2012-02-25 23:31:23 +01:00
Current modules include:
2012-02-23 21:31:35 +01:00
2012-02-23 23:19:06 +01:00
* command -- runs commands, giving output, return codes, and run time info
* ping - just returns if the system is up or not
* facter - retrieves facts about the host OS
* ohai - similar to facter, but returns structured data
* copy - add files to remote systems
2012-02-25 23:31:23 +01:00
* setup - pushes key/value data onto the system for use in templating
* template - takes a local template file and saves a templated version remotely
Service, package, and user modules, supporting puppet-like ensure semantics
are coming soon.
2012-02-23 22:32:58 +01:00
Playbooks
=========
2012-02-25 23:31:23 +01:00
Playbooks are particularly awesome. Playbooks can batch ansible commands
together, and run some commands only when ansible modifies certain higher
level resources -- such as restarting apache when a configuration file is
replaced. They generate detailed reports of what happend on each node.
See examples/playbook.yml for what the syntax looks like.
To run a playbook:
ansible -r playbook.yml
An ansible-playbook CLI command is pending. Until then, remember that when
using playbooks, the pattern and host list options come from the playbook
and are ignored. Other options still apply.
2012-02-23 20:17:24 +01:00
Future plans
============
2012-02-25 23:31:23 +01:00
* see github's issue tracker for what we're thinking about
2012-02-23 22:32:58 +01:00
License
=======
* MIT
2012-02-23 20:17:24 +01:00
Mailing List
============
2012-02-25 15:41:30 +01:00
* [ansible-project](http://groups.google.com/group/ansible-project)
2012-02-23 20:17:24 +01:00
Author
======
2012-02-24 03:47:31 +01:00
Michael DeHaan -- michael.dehaan@gmail.com
2012-02-23 20:28:39 +01:00
2012-02-24 03:47:31 +01:00
[http://michaeldehaan.net](http://michaeldehaan.net/)
2012-02-23 20:28:39 +01:00