commit
ace0d5ade4
5 changed files with 13 additions and 14 deletions
|
@ -2,7 +2,7 @@ API & Integrations
|
|||
==================
|
||||
|
||||
There are two major ways to use Ansible from an API perspective. The primary way
|
||||
is to use the Ansible python API to control nodes. Ansible is written in it's own
|
||||
is to use the Ansible python API to control nodes. Ansible is written in its own
|
||||
API so you have a considerable amount of power there.
|
||||
|
||||
Also covered here, Ansible's
|
||||
|
@ -89,8 +89,7 @@ in a different system. Frequent examples include LDAP, `Cobbler <http://cobbler
|
|||
or a piece of expensive enterprisey CMDB software. Ansible easily supports all
|
||||
of these options via an external interventory system.
|
||||
|
||||
If you have a data store system where an Ansible external inventory script doesn't already exist, this may require a little coding,J
|
||||
but we have a `Cobbler example <https://github.com/ansible/ansible/blob/master/examples/scripts/cobbler_external_inventory.py>`_ in the main source tree -- but it's pretty simple, as we'll explain below -- that would provide a good starting point. Like with modules, it's possible to build an external inventory script in any language, as long as it returns JSON.
|
||||
If you have a data store system where an Ansible external inventory script doesn't already exist, this may require a little coding, but we have a `Cobbler example <https://github.com/ansible/ansible/blob/master/examples/scripts/cobbler_external_inventory.py>`_ in the main source tree -- but it's pretty simple, as we'll explain below -- that would provide a good starting point. Like with modules, it's possible to build an external inventory script in any language, as long as it returns JSON.
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
@ -83,7 +83,7 @@ as it can. A system shouldn't be half correct, especially if we're planning on
|
|||
other systems that depend on that system.
|
||||
|
||||
Ansible also has a VERY short learning curve -- but it also has less language constructs and
|
||||
does not create it's own programming language. What constructs Ansible does have should be enough to cover 80% or so of the cases of most Puppet users, and it should scale equally well (not having a server is
|
||||
does not create its own programming language. What constructs Ansible does have should be enough to cover 80% or so of the cases of most Puppet users, and it should scale equally well (not having a server is
|
||||
almost like cheating).
|
||||
|
||||
I also suspect some Ansible users will actually use Ansible to trigger Puppet -- using the git
|
||||
|
@ -146,7 +146,7 @@ Python's multiprocessing module.
|
|||
|
||||
If you need to address 500 machines you can decide if you want to try
|
||||
to contact 5 at a time, or 50 at a time.
|
||||
It's up to you and how much power you can throw at it, but it's heritage
|
||||
It's up to you and how much power you can throw at it, but its heritage
|
||||
is about handling those kinds of use cases.
|
||||
|
||||
There are no daemons so it's entirely up to you. When you are aren't using
|
||||
|
|
|
@ -60,7 +60,7 @@ Reading Input
|
|||
Let's modify the module to allow setting the current time. We'll do this by seeing
|
||||
if a key value pair in the form `time=<string>` is passed in to the module.
|
||||
|
||||
Ansible internally saves arguments to a arguments file. So we must read the file
|
||||
Ansible internally saves arguments to an arguments file. So we must read the file
|
||||
and parse it. The arguments file is just a string, so any form of arguments are legal.
|
||||
Here we'll do some basic parsing to treat the input as key=value.
|
||||
|
||||
|
|
|
@ -306,9 +306,9 @@ Example action from Ansible :doc:`playbooks`::
|
|||
ntpserver: 'ntp.example.com'
|
||||
xyz: 1234
|
||||
|
||||
Example action from `/usr/bin/Ansible`::
|
||||
Example action from `/usr/bin/ansible`::
|
||||
|
||||
Ansible -m all setup -a "ntpserver=ntp.example.com xyz=1234"
|
||||
ansible all -m setup -a "ntpserver=ntp.example.com xyz=1234"
|
||||
|
||||
|
||||
.. _shell:
|
||||
|
@ -499,14 +499,14 @@ See :doc:`moduledev`.
|
|||
.. seealso::
|
||||
|
||||
:doc:`examples`
|
||||
Examples of using modules in /usr/bin/Ansible
|
||||
Examples of using modules in /usr/bin/ansible
|
||||
:doc:`playbooks`
|
||||
Examples of using modules with /usr/bin/Ansible-playbook
|
||||
Examples of using modules with /usr/bin/ansible-playbook
|
||||
:doc:`moduledev`
|
||||
How to write your own modules
|
||||
:doc:`api`
|
||||
Examples of using modules with the Python API
|
||||
`Mailing List <http://groups.google.com/group/Ansible-project>`_
|
||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
`irc.freenode.net <http://irc.freenode.net>`_
|
||||
#ansible IRC chat channel
|
||||
|
|
|
@ -32,7 +32,7 @@ orchestrate multi-machine deployments, running certain steps on all
|
|||
machines in the webservers group, then certain steps on the database
|
||||
server group, then more commands back on the webservers group, etc.
|
||||
|
||||
For starters, here's a playbook that contains just one play.::
|
||||
For starters, here's a playbook that contains just one play::
|
||||
|
||||
---
|
||||
- hosts: webservers
|
||||
|
@ -290,7 +290,7 @@ or it could be something like performing some cleanup steps if a filesystem is g
|
|||
This is easy to do in Ansible, with the `only_if` clause. This clause can be applied to any task,
|
||||
and allows usage of variables from anywhere in ansible, either denoted with `$dollar_sign_syntax` or
|
||||
`{{ braces_syntax }}` and then evaluates them with a Python expression. Don't panic -- it's actually
|
||||
pretty simple.::
|
||||
pretty simple::
|
||||
|
||||
vars:
|
||||
favcolor: blue
|
||||
|
@ -474,7 +474,7 @@ to kick them off all at once and then poll until they are done.
|
|||
You will also want to use asynchronous mode on very long running
|
||||
operations that might be subject to timeout.
|
||||
|
||||
To launch a task asynchronously, specify it's maximum runtime
|
||||
To launch a task asynchronously, specify its maximum runtime
|
||||
and how frequently you would like to poll for status. The default
|
||||
poll value is 10 seconds if you do not specify a value for `poll`::
|
||||
|
||||
|
|
Loading…
Reference in a new issue