mirror of https://github.com/ansible/ansible.git
Fixup RPM building: Makefile, Spec File, .gitignore
Fixup distutils: setup.py Clean old cruft: section 5 man pagespull/16/head
Tim Bielawa
13 years ago
parent
8808c814ea
commit
3f245498c4
@ -1,235 +0,0 @@
|
||||
ansible-modules(5)
|
||||
=================
|
||||
:doctype:manpage
|
||||
:man source: Ansible-modules
|
||||
:man version: 0.0.1
|
||||
:man manual: Ansible
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
ansible-modules - stock modules shipped with ansible
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Ansible ships with a number of modules that can be executed directly on remote hosts or through
|
||||
ansible playbooks.
|
||||
|
||||
|
||||
IDEMPOTENCE
|
||||
-----------
|
||||
|
||||
Most modules other than command are idempotent, meaning they will seek to avoid changes
|
||||
unless a change needs to be made. When using ansible playbooks, these modules can
|
||||
trigger change events, as described in *ansible-playbooks*(5).
|
||||
|
||||
Unless otherwise noted, all modules support change hooks.
|
||||
|
||||
|
||||
command
|
||||
-------
|
||||
|
||||
The command module takes the command name followed by a list of arguments, space delimited.
|
||||
This is the only module that does not use key=value style parameters.
|
||||
|
||||
Example usage::
|
||||
|
||||
/sbin/shutdown -t now
|
||||
|
||||
This module does not support change hooks.
|
||||
|
||||
Returns the return code from the program as well as timing information.
|
||||
|
||||
(Async command running and command execution time limits are in plan.)
|
||||
|
||||
copy
|
||||
----
|
||||
|
||||
The copy module moves a file on the local box to remote locations.
|
||||
|
||||
*src=*::
|
||||
|
||||
Local absolute path to a file to copy to the remote server
|
||||
|
||||
|
||||
*dest=*::
|
||||
|
||||
Remote absolute path where the file should end up
|
||||
|
||||
|
||||
This module also returns md5sum information about the resultant file.
|
||||
|
||||
|
||||
facter
|
||||
------
|
||||
|
||||
Runs the discovery program 'facter' on the remote system, returning
|
||||
JSON data that can be useful for inventory purposes.
|
||||
|
||||
Requires that 'facter' and 'ruby-json' be installed on the remote end.
|
||||
|
||||
This module is informative only - it takes no parameters & does not support change hooks,
|
||||
nor does it make any changes on the system.
|
||||
|
||||
|
||||
file
|
||||
----
|
||||
|
||||
Ensures the ownership and permissions of files are as desired.
|
||||
|
||||
Use copy or template first if you need to make sure a file is on the box.
|
||||
|
||||
In plan.
|
||||
|
||||
|
||||
git
|
||||
---
|
||||
|
||||
Deploys software from git checkouts.
|
||||
|
||||
*repo=*::
|
||||
|
||||
git or http protocol address of the repo to checkout
|
||||
|
||||
*dest=*::
|
||||
|
||||
where to check it out, an absolute directory path
|
||||
|
||||
*version=*::
|
||||
|
||||
what version to check out -- either the git SHA, the literal string 'HEAD', or a tag name
|
||||
|
||||
|
||||
ohai
|
||||
----
|
||||
|
||||
Similar to the facter module, this returns JSON inventory data. Ohai
|
||||
data is a bit more verbose and nested than facter.
|
||||
|
||||
Requires that 'ohai' be installed on the remote end.
|
||||
|
||||
This module is information only - it takes no parameters & does not
|
||||
support change hooks, nor does it make any changes on the system.
|
||||
|
||||
|
||||
ping
|
||||
----
|
||||
|
||||
A trivial test module, this module always returns the integer '1' on
|
||||
successful contact.
|
||||
|
||||
This module does not support change hooks.
|
||||
|
||||
This module is informative only - it takes no parameters & does not
|
||||
support change hooks, nor does it make any changes on the system.
|
||||
|
||||
|
||||
service
|
||||
-------
|
||||
|
||||
Controls services on remote machines.
|
||||
|
||||
*state=*::
|
||||
|
||||
Values are 'started', 'stopped', or 'restarted'. Started/stopped
|
||||
are idempotent actions that will not run commands unless neccessary.
|
||||
'restarted' will always bounce the service
|
||||
|
||||
|
||||
*name=*::
|
||||
|
||||
The name of the service
|
||||
|
||||
|
||||
setup
|
||||
-----
|
||||
|
||||
Writes a JSON file containing key/value data, for use in templating.
|
||||
Call this once before using the template modules, usually as the very
|
||||
first step in your playbook.
|
||||
|
||||
If facter or ohai are installed, variables from these programs will also
|
||||
be snapshotted into the JSON file for usage in templating. These variables
|
||||
are prefixed with 'facter_' and 'ohai_" so it's easy to tell their source.
|
||||
|
||||
*metadata=*::
|
||||
|
||||
Optionally overrides the default JSON file location of /etc/ansible/setup.
|
||||
If used, also supply the metadata parameter to 'template'. Change if
|
||||
running as a non-root remote user who does not have permissions on /etc/ansible.
|
||||
|
||||
*anything=*::
|
||||
|
||||
any other parameters can be named basically anything, and set a key=value
|
||||
pair in the JSON file for use in templating.
|
||||
|
||||
|
||||
template
|
||||
--------
|
||||
|
||||
Templates a file out to a remote server. Call the setup module prior to usage.
|
||||
|
||||
*src=*::
|
||||
|
||||
path of a Jinja2 formatted template on the local server
|
||||
|
||||
|
||||
*dest*::
|
||||
|
||||
location to render the template on the remote server
|
||||
|
||||
|
||||
*metadata*::
|
||||
|
||||
location of a JSON file to use to supply template data. Default is /etc/ansible/setup
|
||||
which is the same as the default for the setup module. Change if running as a non-root
|
||||
remote user who does not have permissions on /etc/ansible.
|
||||
|
||||
|
||||
This module also returns md5sum information about the resultant file.
|
||||
|
||||
|
||||
user
|
||||
----
|
||||
|
||||
This module is in plan.
|
||||
|
||||
|
||||
yum
|
||||
---
|
||||
|
||||
This module is in plan.
|
||||
|
||||
|
||||
WRITING YOUR OWN MODULES
|
||||
------------------------
|
||||
|
||||
To write your own modules, simply follow the convention of those already available in
|
||||
/usr/share/ansible. Modules must return JSON but can be written in any language.
|
||||
To support change hooks, modules should return hashes, with a changed: True/False
|
||||
element at the top level. Modules can also choose to indicate a failure scenario
|
||||
by returning a top level 'failure' element with a True value.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
ANSIBLE_LIBRARY -- Override the default ansible module library path
|
||||
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Ansible was originally written by Michael DeHaan. See the AUTHORS file
|
||||
for a complete list of contributors.
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
*ansible*(1)
|
||||
|
||||
*ansible-playbook*(5)
|
||||
|
||||
Ansible home page: <https://github.com/mpdehaan/ansible/>
|
||||
@ -1,123 +0,0 @@
|
||||
ansible-modules(5)
|
||||
=================
|
||||
:doctype:manpage
|
||||
:man source: Ansible-playbook
|
||||
:man version: 0.0.1
|
||||
:man manual: Ansible
|
||||
|
||||
|
||||
NAME
|
||||
----
|
||||
ansible-playbook - format and function of an ansible playbook file
|
||||
|
||||
|
||||
DESCRIPTION
|
||||
-----------
|
||||
|
||||
Ansible ships with 'ansible-playbook', a tool for running playbooks.
|
||||
Playbooks can represent frequent tasks, desired system configurations,
|
||||
or deployment processes.
|
||||
|
||||
|
||||
FORMAT
|
||||
------
|
||||
|
||||
Playbooks are written in YAML.
|
||||
|
||||
|
||||
EXAMPLE
|
||||
-------
|
||||
|
||||
See:
|
||||
|
||||
- https://github.com/mpdehaan/ansible/blob/master/examples/playbook.yml
|
||||
|
||||
- https://github.com/mpdehaan/ansible/blob/master/examples/base.yml
|
||||
|
||||
- https://github.com/mpdehaan/ansible/blob/master/examples/handlers.yml
|
||||
|
||||
WHAT THE EXAMPLE MEANS
|
||||
-----------------------
|
||||
|
||||
Here's what playbook.yml (above) will do.
|
||||
|
||||
The first pattern will select all hosts. The patterns are the same
|
||||
as supported by /usr/bin/ansible.
|
||||
|
||||
First, it will run all the modules specified in base.yml. Includes can
|
||||
be used to implement classes of things, and if you wanted, a playbook
|
||||
could consist of nothing but include files. This is an example of an
|
||||
include.
|
||||
|
||||
After processing base.yml, on each host we'll write for
|
||||
a JSON file into /etc/ansible/setup on each remote system with the
|
||||
values max_clients and http_port.
|
||||
|
||||
Next, we'll use a Jinja2 template locally residing at
|
||||
/srv/templates/httpd.j2 to write the Apache config file on each host,
|
||||
using the previous values in that setup file.
|
||||
|
||||
Next, We'll ensure that apache is running if stopped.
|
||||
|
||||
The template task set up a notifier, which means if the configuration
|
||||
file actually changed, we have a named handler, in this case, 'restart apache'
|
||||
to run. In this case, all the notifiers come from handlers.yml, though it's
|
||||
also ok to express handlers directly in the main yaml file too. Using
|
||||
the include promotes reuse.
|
||||
|
||||
What does the handler say? If and only if the config file changed, note that we need to restart
|
||||
apache at the end of the run, otherwise, don't bother because we
|
||||
already know it is running.
|
||||
|
||||
|
||||
HIGH LEVEL EXPLANATION
|
||||
----------------------
|
||||
|
||||
Playbooks are executed top down and can contain multiple references to
|
||||
patterns. For instance, a playbook could do something to all
|
||||
webservers, then do something to all database servers, then do
|
||||
something different to all webservers again.
|
||||
|
||||
For each pattern, the tasks in the 'tasks' list are executed in order
|
||||
for all hosts in the host file matching the pattern.
|
||||
|
||||
For each task, a name/action pair describes what the task is and what
|
||||
ansible module to use to accomplish the task, along with any
|
||||
arguments. Additional fields like 'comment:' can be added and will
|
||||
be ignored, so feel free to take notes in the file.
|
||||
|
||||
Most modules accept key=value format arguments.
|
||||
|
||||
Handlers are like tasks, but are conditionally executed. If a module
|
||||
reports a 'change', it can notify one or more handler by name. If
|
||||
notified, it will run only for hosts that changed.
|
||||
|
||||
|
||||
ERROR HANDLING
|
||||
--------------
|
||||
|
||||
If a host has a failure, the host will be ignored for the remainder
|
||||
of the playbook execution.
|
||||
|
||||
|
||||
ENVIRONMENT
|
||||
-----------
|
||||
|
||||
ANSIBLE_LIBRARY -- Override the default ansible module library path
|
||||
|
||||
|
||||
AUTHOR
|
||||
------
|
||||
|
||||
Ansible was originally written by Michael DeHaan. See the AUTHORS file
|
||||
for a complete list of contributors.
|
||||
|
||||
|
||||
SEE ALSO
|
||||
--------
|
||||
|
||||
*ansible*(1)
|
||||
|
||||
*ansible-modules*(5)
|
||||
|
||||
Ansible home page: <https://github.com/mpdehaan/ansible/>
|
||||
Loading…
Reference in New Issue