ansible/rst/index.rst

136 lines
6.3 KiB
ReStructuredText
Raw Normal View History

2012-03-21 02:12:35 +01:00
.. image:: http://ansible.github.com/mpd_rings.jpg
2012-03-10 00:51:06 +01:00
:height: 225
:width: 300
:alt: ""
:target: http://photos.michaeldehaan.net/infrared/h3d850bdf#h3d850bdf
.. image:: http://ansible.github.com/mpd_tunnel.jpg
2012-03-10 00:51:06 +01:00
:height: 225
:width: 337
:alt: ""
:target: http://photos.michaeldehaan.net/favorites/h2428aca7#h2428aca7
.. image:: http://ansible.github.com/mpd_tubes.jpg
:height: 225
:width: 225
:alt: ""
:target: http://photos.michaeldehaan.net/ncsu/h3b63b68e#h3b63b68e
2012-03-07 17:35:18 +01:00
Introducing Ansible
===================
2012-03-07 17:35:18 +01:00
2012-03-18 18:03:45 +01:00
Ansible is a radically simple deployment, model-driven configuration management,
and command execution framework. Other tools in this space have been too
2012-03-09 20:39:29 +01:00
complicated for too long, require too much bootstrapping, and have too
much learning curve. Ansible is dead simple and painless to extend.
For comparison, Puppet and Chef have about 60k lines of code.
2012-03-18 18:03:45 +01:00
Ansible's core is a little over 1000 lines.
2012-03-09 20:39:29 +01:00
2012-03-18 18:03:45 +01:00
Ansible isn't just for idempotent configuration -- it's also great for ad-hoc
tasks, quickly firing off commands against nodes. See :doc:`examples`.
Where Ansible excels though, is expressing complex multi-node
2012-03-18 18:03:45 +01:00
deployment processes, executing ordered sequences on
different sets of nodes through :doc:`playbooks`. Playbooks contain one or
more plays, each executed against a different batch of nodes. Think about
webservers, database servers, and backend servers in a multi-node web environment. A play could address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
version of software if required.
Multi-machine software deployment is poorly solved by most systems management tools -- often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.
Other deployment oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts. Ansible playbooks -- having been designed with this problem in mind -- are good at both deployment & idempotent configuration, meaning you don't have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc), and performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required -- while avoiding the problem of fragile scripting that assumes certain starting
or ending states.
2012-03-09 20:39:29 +01:00
Ansible is also unique in other ways. Extending ansible does not require programming in any particular language -- you can write :doc:`modules` as idempotent scripts or programs that return simple JSON. Ansible is also pragmatic, so when you need to, it's also trivially easy to just execute useful shell commands.
2012-03-09 20:39:29 +01:00
2012-03-18 18:17:25 +01:00
Why use Ansible versus something else? (Puppet, Chef, Capistrano, etc?) Ansible will have far
2012-03-09 20:39:29 +01:00
less code, it will be (by extension) 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.
Systems management doesn't have to be complicated. Ansible's docs
will remain short & simple, and the source will be blindingly obvious.
We've learned well from "Infrastructure is Code". Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project -- bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.
2012-03-07 17:35:18 +01:00
Architecture
````````````
.. image:: http://ansible.github.com/ansible_arch2.jpg
:alt: "Architecture Diagram"
2012-03-31 16:48:37 +02:00
:width: 800
:align: center
2012-03-07 17:35:18 +01:00
2012-03-18 18:08:45 +01:00
Features
````````
2012-03-07 17:35:18 +01:00
* Dead simple setup
* Super fast & parallel by default
2012-03-08 19:36:47 +01:00
* No server or client daemons; use existing SSHd out of the box
2012-03-07 17:35:18 +01:00
* No additional software required on client boxes
2012-03-18 18:03:45 +01:00
* Can be easily run from a checkout, no installation required
2012-03-18 18:08:45 +01:00
* Modules are idempotent, but you can also easily use shell commands
2012-03-07 17:35:18 +01:00
* Modules can be written in ANY language
* Awesome API for creating very powerful distributed scripts
2012-03-18 18:03:45 +01:00
* Does not have to run remote steps as root
2012-03-18 18:08:45 +01:00
* Pluggable transports (SSH is just the default)
* Source host info & variables from files or external software
* The easiest config management system to use, ever.
2012-03-07 17:35:18 +01:00
2012-03-10 04:49:30 +01:00
Resources
`````````
2012-03-07 17:35:18 +01:00
Your ideas and contributions are welcome. We're also happy to help
2012-03-09 20:39:29 +01:00
you with questions about Ansible.
2012-03-08 20:07:13 +01:00
2012-03-08 19:53:48 +01:00
* Visit the `project page <https://github.com/ansible/ansible>`_ on Github
2012-03-21 02:04:47 +01:00
* View the `issue tracker <https://github.com/ansible/ansible/issues>`_
2012-04-01 04:31:42 +02:00
* See the presentation on `Speakerdeck <http://speakerdeck.com/u/mpdehaan/p/ansible>`_
2012-03-21 02:04:47 +01:00
* Visit the `Google Group <http://groups.google.com/group/ansible-project>`_
2012-03-22 01:42:31 +01:00
* Chat on `FreeNode <http://webchat.freenode.net/?channels=ansible>`_
2012-03-08 19:53:48 +01:00
2012-03-21 02:04:47 +01:00
.. raw:: html
<img src="http://groups.google.com/intl/en/images/logos/groups_logo_sm.gif" height=30 width=140 alt="Google Groups">
<br/>
<b>Subscribe to Ansible Project</b>
<br/>
<form action="http://groups.google.com/group/ansible-project/boxsubscribe">
<br/>
Email: <input type=text name=email>&nbsp;&nbsp;<input type=submit name="sub" value="Subscribe">
<br/></br>
</form>
<br/>
Contents
========
2012-03-07 17:35:18 +01:00
.. toctree::
:maxdepth: 3
gettingstarted
patterns
2012-03-09 04:50:00 +01:00
examples
2012-03-07 17:35:18 +01:00
modules
YAMLSyntax
2012-03-07 17:35:18 +01:00
playbooks
api
moduledev
faq
2012-03-07 17:35:18 +01:00
man
2012-03-08 19:53:48 +01:00
About the Author
````````````````
2012-03-10 04:58:17 +01:00
Ansible was originally developed by `Michael DeHaan <http://michaeldehaan.net>`_ (`@laserllama <http://twitter.com/#!/laserllama>`_), a Raleigh, NC
2012-03-19 01:41:38 +01:00
based software developer and architect. He created the popular
DevOps program `Cobbler <http://cobbler.github.com/>`_.
2012-03-09 20:39:29 +01:00
Cobbler is used to deploy mission critical systems all over the
planet, in industries ranging from massively multiplayer gaming, core
internet infrastructure, finance, chip design, and more. Michael also
2012-03-19 01:41:38 +01:00
helped co-author `Func <http://fedorahosted.org/func/>`_, a precursor to Ansible, which is used to
2012-03-09 20:39:29 +01:00
orchestrate systems in lots of diverse places. He's worked on systems
software for IBM, Motorola, Red Hat's Emerging Technologies Group,
2012-03-10 04:58:17 +01:00
Puppet Labs, and rPath. Reach Michael by email `here <mailto:michael.dehaan@gmail.com>`_.