<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-playbook</title><linkrel="stylesheet"href="./docbook-xsl.css"type="text/css"/><metaname="generator"content="DocBook XSL Stylesheets V1.75.2"/></head><body><divxml:lang="en"class="refentry"title="ansible-playbook"lang="en"><aid="id459632"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-playbook — run an ansible playbook</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible-playbook <filename.yml> … [options]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible playbooks</strong></span> are a configuration and multinode deployment system. Ansible-playbook is the tool
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-playbook</title><linkrel="stylesheet"href="./docbook-xsl.css"type="text/css"/><metaname="generator"content="DocBook XSL Stylesheets V1.75.2"/></head><body><divxml:lang="en"class="refentry"title="ansible-playbook"lang="en"><aid="id530459"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-playbook — run an ansible playbook</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible-playbook <filename.yml> … [options]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible playbooks</strong></span> are a configuration and multinode deployment system. Ansible-playbook is the tool
used to run them. See the project home page (link below) for more information.</p></div><divclass="refsect1"title="ARGUMENTS"><aid="_arguments"></a><h2>ARGUMENTS</h2><divclass="variablelist"><dl><dt><spanclass="term">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible</title><linkrel="stylesheet"href="./docbook-xsl.css"type="text/css"/><metaname="generator"content="DocBook XSL Stylesheets V1.75.2"/></head><body><divxml:lang="en"class="refentry"title="ansible"lang="en"><aid="id303813"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible</title><linkrel="stylesheet"href="./docbook-xsl.css"type="text/css"/><metaname="generator"content="DocBook XSL Stylesheets V1.75.2"/></head><body><divxml:lang="en"class="refentry"title="ansible"lang="en"><aid="id345285"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
If writing a module in Python and you have managed nodes running
Python 2.4 or lower, this is generally a good idea, because
json isn't in the Python standard library until 2.5.::
try:
import json
except ImportError:
import simplejson as json
You should also never do this in a module::
print "some status message"
Because the output is supposed to be valid JSON. Except that's not quite true,
but we'll get to that later.
Conventions
-----------
As a reminder from the example code above, here are some basic conventions
and guidelines:
* Include a minimum of dependencies if possible. If there are dependencies, document them at the top of the module file
* Modules must be self contained in one file to be auto-transferred by ansible
* If packaging modules in an RPM, they only need to be installed on the control machine and should be dropped into /usr/share/ansible. This is entirely optional.
* Modules should return JSON or key=value results all on one line. JSON is best if you can do JSON. All return types must be hashes (dictionaries) although they can be nested.
* In the event of failure, a key of 'failed' should be included, along with a string explanation in 'msg'. Modules that raise tracebacks (stacktraces) are generally considered 'poor' modules, though Ansible can deal with these returns and will automatically convert anything unparseable into a failed result.
* Return codes are actually not signficant, but continue on with 0=success and non-zero=failure for reasons of future proofing.
* As results from many hosts will be aggregrated at once, modules should return only relevant output. Returning the entire contents of a log file is generally bad form.
Shorthand Vs JSON
-----------------
To make it easier to write modules in bash and in cases where a JSON
module might not be available, it is acceptable for a module to return
key=value output all on one line, like this. The Ansible parser
will know what to do.::
somekey=1 somevalue=two favcolor=red
If you're writing a module in Python or Ruby or whatever, though, returning
JSON is probably the simplest way to go.
Sharing Your Module
```````````````````
If you think your module is generally useful to others, Ansible is preparing
an 'ansible-contrib' repo. Stop by the mailing list and we'll help you to
get your module included. Contrib modules can be implemented in a variety
of languages. Including a README with your module is a good idea so folks
can understand what arguments it takes and so on. We would like to build
up as many of these as possible in as many languages as possible.
`Ansible Mailing List <http://groups.google.com/group/ansible-project>`_
Getting Your Module Into Core
`````````````````````````````
High-quality modules with minimal dependencies
can be included in the core, but core modules (just due to the programming
preferences of the developers) will need to be implemented in Python.
Stop by the mailing list to inquire about requirements.
