<h1><aclass="toc-backref"href="#table-of-contents">API & Integrations</a><aclass="headerlink"href="#api-integrations"title="Permalink to this headline">¶</a></h1>
<h1><aclass="toc-backref"href="#table-of-contents">API & Integrations</a><aclass="headerlink"href="#api-integrations"title="Permalink to this headline">¶</a></h1>
<p>There are two major ways to use Ansible from an API perspective. The primary way
<p>There are several interesting ways to use Ansible from an API perspective. You can use
is to use the Ansible python API to control nodes. Ansible is written in its own
the Ansible python API to control nodes, you can extend Ansible to respond to various python events,
API so you have a considerable amount of power there.</p>
and you can plug in inventory data from external data sources. Ansible is written in its own
<p>Also covered here, Ansible’s
API so you have a considerable amount of power across the board.</p>
list of hosts, groups, and variables assigned to each host can be driven from
external sources. We’ll start with the Python API.</p>
<divclass="contents topic"id="table-of-contents">
<divclass="contents topic"id="table-of-contents">
<pclass="topic-title first"><cite>Table of contents</cite></p>
<pclass="topic-title first"><cite>Table of contents</cite></p>
<ulclass="simple">
<ulclass="simple">
<li><aclass="reference internal"href="#api-integrations"id="id2">API & Integrations</a><ul>
<li><aclass="reference internal"href="#api-integrations"id="id2">API & Integrations</a><ul>
<li><aclass="reference internal"href="#connection-type-plugins"id="id7">Connection Type Plugins</a></li>
</ul>
</ul>
</li>
</li>
</ul>
</ul>
...
@@ -275,12 +280,16 @@ it uses the Runner() API (with all available options) to implement the
...
@@ -275,12 +280,16 @@ it uses the Runner() API (with all available options) to implement the
command line tools <ttclass="docutils literal"><spanclass="pre">ansible</span></tt> and <ttclass="docutils literal"><spanclass="pre">ansible-playbook</span></tt>.</p>
command line tools <ttclass="docutils literal"><spanclass="pre">ansible</span></tt> and <ttclass="docutils literal"><spanclass="pre">ansible-playbook</span></tt>.</p>
</div>
</div>
</div>
</div>
<divclass="section"id="external-inventory">
<divclass="section"id="plugins-repository">
<h2><aclass="toc-backref"href="#table-of-contents">External Inventory</a><aclass="headerlink"href="#external-inventory"title="Permalink to this headline">¶</a></h2>
<h2><aclass="toc-backref"href="#table-of-contents">Plugins Repository</a><aclass="headerlink"href="#plugins-repository"title="Permalink to this headline">¶</a></h2>
<p>The remainder of features in the API docs have components available in the <aclass="reference external"href="http://github.com/ansible/ansible-plugins">ansible-plugins</a> repository. Please consult this repository for more information. Send us a github pull request if you develop any interesting features.</p>
<h2><aclass="toc-backref"href="#table-of-contents">External Inventory Scripts</a><aclass="headerlink"href="#external-inventory-scripts"title="Permalink to this headline">¶</a></h2>
<p>Often a user of a configuration management system will want to keep inventory
<p>Often a user of a configuration management system will want to keep inventory
in a different system. Frequent examples include LDAP, <aclass="reference external"href="http://cobbler.github.com">Cobbler</a>,
in a different system. Frequent examples include LDAP, <aclass="reference external"href="http://cobbler.github.com">Cobbler</a>,
or a piece of expensive enterprisey CMDB software. Ansible easily supports all
or a piece of expensive enterprisey CMDB software. Ansible easily supports all
of these options via an external inventory system. The <aclass="reference external"href="http://github.com/ansible/ansible-plugins">ansible-plugins</a> repo contains some of these already.</p>
of these options via an external inventory system. The ansible-plugins repo contains some of these already – including options for EC2/Eucalyptus and OpenStack, which will be detailed below.</p>
<p>It’s possible to write an external inventory script in any language. If you are familiar with Puppet terminology, this concept is basically the same as ‘external nodes’, with the slight difference that it also defines which hosts are managed.</p>
<p>It’s possible to write an external inventory script in any language. If you are familiar with Puppet terminology, this concept is basically the same as ‘external nodes’, with the slight difference that it also defines which hosts are managed.</p>
<divclass="section"id="script-conventions">
<divclass="section"id="script-conventions">
<h3>Script Conventions<aclass="headerlink"href="#script-conventions"title="Permalink to this headline">¶</a></h3>
<h3>Script Conventions<aclass="headerlink"href="#script-conventions"title="Permalink to this headline">¶</a></h3>
<h3>Example: OpenStack<aclass="headerlink"href="#example-openstack"title="Permalink to this headline">¶</a></h3>
<p>Though not detailed here in as much depth as the EC2 module, there’s also a OpenStack Nova external inventory source in the ansible-plugins repository. See the inline comments in the module source.</p>
</div>
</div>
<divclass="section"id="callback-plugins">
<h2><aclass="toc-backref"href="#table-of-contents">Callback Plugins</a><aclass="headerlink"href="#callback-plugins"title="Permalink to this headline">¶</a></h2>
<p>Ansible can be configured via code to respond to external events. This can include enhancing logging, signalling an external software
system, or even (yes, really) making sound effects. Some examples are contained in the ansible-plugins repository.</p>
</div>
<divclass="section"id="connection-type-plugins">
<h2><aclass="toc-backref"href="#table-of-contents">Connection Type Plugins</a><aclass="headerlink"href="#connection-type-plugins"title="Permalink to this headline">¶</a></h2>
<p>By default, ansible ships with a ‘paramiko’ SSH, native ssh (just called ‘ssh’), and ‘local’ connection type, which can be used
in playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines. The basics of these connection types
are covered in the ‘getting started’ section. Should you want to extend Ansible to support other transports (SNMP? Message bus?
Carrier Pigeon?) it’s as simple as copying the format of one of the existing modules and dropping it into the connection plugins
There are two major ways to use Ansible from an API perspective. The primary way
There are several interesting ways to use Ansible from an API perspective. You can use
is to use the Ansible python API to control nodes. Ansible is written in its own
the Ansible python API to control nodes, you can extend Ansible to respond to various python events,
API so you have a considerable amount of power there.
and you can plug in inventory data from external data sources. Ansible is written in its own
API so you have a considerable amount of power across the board.
Also covered here, Ansible's
list of hosts, groups, and variables assigned to each host can be driven from
external sources. We'll start with the Python API.
.. contents:: `Table of contents`
.. contents:: `Table of contents`
:depth: 2
:depth: 2
...
@@ -85,13 +82,18 @@ Advanced programmers may also wish to read the source to ansible itself, for
...
@@ -85,13 +82,18 @@ Advanced programmers may also wish to read the source to ansible itself, for
it uses the Runner() API (with all available options) to implement the
it uses the Runner() API (with all available options) to implement the
command line tools ``ansible`` and ``ansible-playbook``.
command line tools ``ansible`` and ``ansible-playbook``.
External Inventory
Plugins Repository
------------------
------------------
The remainder of features in the API docs have components available in the `ansible-plugins <http://github.com/ansible/ansible-plugins>`_ repository. Please consult this repository for more information. Send us a github pull request if you develop any interesting features.
External Inventory Scripts
--------------------------
Often a user of a configuration management system will want to keep inventory
Often a user of a configuration management system will want to keep inventory
in a different system. Frequent examples include LDAP, `Cobbler <http://cobbler.github.com>`_,
in a different system. Frequent examples include LDAP, `Cobbler <http://cobbler.github.com>`_,
or a piece of expensive enterprisey CMDB software. Ansible easily supports all
or a piece of expensive enterprisey CMDB software. Ansible easily supports all
of these options via an external inventory system. The `ansible-plugins <http://github.com/ansible/ansible-plugins>`_ repo contains some of these already.
of these options via an external inventory system. The ansible-plugins repo contains some of these already -- including options for EC2/Eucalyptus and OpenStack, which will be detailed below.
It's possible to write an external inventory script in any language. If you are familiar with Puppet terminology, this concept is basically the same as 'external nodes', with the slight difference that it also defines which hosts are managed.
It's possible to write an external inventory script in any language. If you are familiar with Puppet terminology, this concept is basically the same as 'external nodes', with the slight difference that it also defines which hosts are managed.
...
@@ -277,6 +279,25 @@ To see the complete list of variables available for an instance, run the script
...
@@ -277,6 +279,25 @@ To see the complete list of variables available for an instance, run the script
Though not detailed here in as much depth as the EC2 module, there's also a OpenStack Nova external inventory source in the ansible-plugins repository. See the inline comments in the module source.
Callback Plugins
----------------
Ansible can be configured via code to respond to external events. This can include enhancing logging, signalling an external software
system, or even (yes, really) making sound effects. Some examples are contained in the ansible-plugins repository.
Connection Type Plugins
-----------------------
By default, ansible ships with a 'paramiko' SSH, native ssh (just called 'ssh'), and 'local' connection type, which can be used
in playbooks and with /usr/bin/ansible to decide how you want to talk to remote machines. The basics of these connection types
are covered in the 'getting started' section. Should you want to extend Ansible to support other transports (SNMP? Message bus?
Carrier Pigeon?) it's as simple as copying the format of one of the existing modules and dropping it into the connection plugins