Add consistent versionadded/deprecated tags.
This commit is contained in:
parent
391acfb20c
commit
688086c54a
5 changed files with 55 additions and 27 deletions
|
@ -82,8 +82,12 @@ You may wish to construct simple shell scripts to wrap calls to ansible-playbook
|
||||||
Bundling Ansible Modules With Playbooks
|
Bundling Ansible Modules With Playbooks
|
||||||
+++++++++++++++++++++++++++++++++++++++
|
+++++++++++++++++++++++++++++++++++++++
|
||||||
|
|
||||||
In version 0.5 and later, if a playbook has a "./library" directory relative to it's YAML file, this directory can be used to add ansible modules that will automatically be in the ansible module path. This is a great way to keep modules that
|
.. versionadded:: 0.5
|
||||||
go with a playbook together.
|
|
||||||
|
If a playbook has a "./library" directory relative to it's YAML file,
|
||||||
|
this directory can be used to add ansible modules that will
|
||||||
|
automatically be in the ansible module path. This is a great way to
|
||||||
|
keep modules that go with a playbook together.
|
||||||
|
|
||||||
Miscellaneous Tips
|
Miscellaneous Tips
|
||||||
++++++++++++++++++
|
++++++++++++++++++
|
||||||
|
|
|
@ -132,10 +132,12 @@ By default, ansible uses paramiko to talk to managed nodes over SSH. Paramiko i
|
||||||
very transparently, requires no configuration, and is a good choice for most users.
|
very transparently, requires no configuration, and is a good choice for most users.
|
||||||
However, it does not support some advanced SSH features that folks will want to use.
|
However, it does not support some advanced SSH features that folks will want to use.
|
||||||
|
|
||||||
Starting in version 0.5, if you want to leverage more advanced SSH features (such as Kerberized SSH or jump hosts),
|
.. versionadded:: 0.5
|
||||||
pass the flag "--connection=ssh" to any ansible command, or set the
|
|
||||||
ANSIBLE_TRANSPORT environment variable to 'ssh'. This will cause Ansible to use openssh
|
If you want to leverage more advanced SSH features (such as Kerberized
|
||||||
tools instead.
|
SSH or jump hosts), pass the flag "--connection=ssh" to any ansible
|
||||||
|
command, or set the ANSIBLE_TRANSPORT environment variable to
|
||||||
|
'ssh'. This will cause Ansible to use openssh tools instead.
|
||||||
|
|
||||||
If ANSIBLE_SSH_ARGS are not set, ansible will try to use some sensible ControlMaster options
|
If ANSIBLE_SSH_ARGS are not set, ansible will try to use some sensible ControlMaster options
|
||||||
by default. You are free to override this environment variable, but should still pass ControlMaster
|
by default. You are free to override this environment variable, but should still pass ControlMaster
|
||||||
|
|
|
@ -96,11 +96,15 @@ Example action from Ansible :doc:`playbooks`::
|
||||||
assemble
|
assemble
|
||||||
````````
|
````````
|
||||||
|
|
||||||
(new in 0.5) Assembles a configuration file from fragments. Often a particular program will take a single configuration file
|
.. versionadded:: 0.5
|
||||||
and does not support a conf.d style structure where it is easy to build up the configuration from multiple sources.
|
|
||||||
Assmeble will take a directory of files that have already been transferred to the system, and concatenate them
|
Assembles a configuration file from fragments. Often a particular
|
||||||
together to produce a destination file. Files are assembled in string sorting order. Puppet calls this idea
|
program will take a single configuration file and does not support a
|
||||||
"fragments".
|
conf.d style structure where it is easy to build up the configuration
|
||||||
|
from multiple sources. Assmeble will take a directory of files that
|
||||||
|
have already been transferred to the system, and concatenate them
|
||||||
|
together to produce a destination file. Files are assembled in string
|
||||||
|
sorting order. Puppet calls this idea "fragments".
|
||||||
|
|
||||||
+--------------------+----------+---------+----------------------------------------------------------------------------+
|
+--------------------+----------+---------+----------------------------------------------------------------------------+
|
||||||
| parameter | required | default | comments |
|
| parameter | required | default | comments |
|
||||||
|
@ -122,7 +126,9 @@ Example action from Ansible :doc:`playbooks`::
|
||||||
authorized_key
|
authorized_key
|
||||||
``````````````
|
``````````````
|
||||||
|
|
||||||
(new in 0.5). Adds or removes an authorized key for a user from a remote host.
|
.. versionadded:: 0.5
|
||||||
|
|
||||||
|
Adds or removes an authorized key for a user from a remote host.
|
||||||
|
|
||||||
+--------------------+----------+---------+----------------------------------------------------------------------------+
|
+--------------------+----------+---------+----------------------------------------------------------------------------+
|
||||||
| parameter | required | default | comments |
|
| parameter | required | default | comments |
|
||||||
|
|
|
@ -144,9 +144,11 @@ seperate from the inventory file, see the next section.
|
||||||
Splitting Out Host and Group Specific Data
|
Splitting Out Host and Group Specific Data
|
||||||
++++++++++++++++++++++++++++++++++++++++++
|
++++++++++++++++++++++++++++++++++++++++++
|
||||||
|
|
||||||
In Ansible 0.6 and later, in addition to the storing variables directly in the INI file, host and
|
.. versionadded:: 0.6
|
||||||
group variables can be stored in individual files relative to the inventory file. These
|
|
||||||
variable files are in YAML format.
|
In addition to the storing variables directly in the INI file, host
|
||||||
|
and group variables can be stored in individual files relative to the
|
||||||
|
inventory file. These variable files are in YAML format.
|
||||||
|
|
||||||
Assuming the inventory file path is::
|
Assuming the inventory file path is::
|
||||||
|
|
||||||
|
@ -172,14 +174,19 @@ It is ok if these files do not exist, this is an optional feature.
|
||||||
Tip: Keeping your inventory file and variables in a git repo (or other version control)
|
Tip: Keeping your inventory file and variables in a git repo (or other version control)
|
||||||
is an excellent way to track changes to your inventory and host variables.
|
is an excellent way to track changes to your inventory and host variables.
|
||||||
|
|
||||||
Tip: If you ever have two python interpreters on a system, set a variable called 'ansible_python_interpreter' to
|
.. versionadded:: 0.5
|
||||||
the Python interpreter path you would like to use.
|
If you ever have two python interpreters on a system, set a
|
||||||
|
variable called 'ansible_python_interpreter' to the Python
|
||||||
|
interpreter path you would like to use.
|
||||||
|
|
||||||
YAML Inventory
|
YAML Inventory
|
||||||
++++++++++++++
|
++++++++++++++
|
||||||
|
|
||||||
Ansible's YAML inventory format is deprecated and will be removed in Ansible 0.7. Ansible 0.6 includes
|
.. deprecated:: 0.7
|
||||||
a `conversion script <https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py>`_.
|
|
||||||
|
Ansible's YAML inventory format is deprecated and will be removed in
|
||||||
|
Ansible 0.7. Ansible 0.6 includes a `conversion script
|
||||||
|
<https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py>`_.
|
||||||
|
|
||||||
Usage::
|
Usage::
|
||||||
|
|
||||||
|
|
|
@ -9,8 +9,11 @@ be 90% or more of what they use in Ansible.
|
||||||
Tags
|
Tags
|
||||||
````
|
````
|
||||||
|
|
||||||
(New in 0.6) If you have a large playbook it may become useful to be able to run a specific
|
.. versionadded:: 0.6
|
||||||
part of the configuration. Both plays and tasks support a "tags:" attribute for this reason.
|
|
||||||
|
If you have a large playbook it may become useful to be able to run a
|
||||||
|
specific part of the configuration. Both plays and tasks support a
|
||||||
|
"tags:" attribute for this reason.
|
||||||
|
|
||||||
Example::
|
Example::
|
||||||
|
|
||||||
|
@ -34,10 +37,13 @@ If you wanted to just run the "configuration" and "packages" part of a very long
|
||||||
Playbooks Including Playbooks
|
Playbooks Including Playbooks
|
||||||
`````````````````````````````
|
`````````````````````````````
|
||||||
|
|
||||||
(New in 0.6) To further advance the concept of include files, playbook files can include other playbook
|
.. versionadded:: 0.6
|
||||||
files. Suppose you define the behavior of all your webservers in "webservers.yml" and
|
|
||||||
all your database servers in "dbservers.yml". You can create a "site.yml" that would
|
To further advance the concept of include files, playbook files can
|
||||||
reconfigure all of your systems like this::
|
include other playbook files. Suppose you define the behavior of all
|
||||||
|
your webservers in "webservers.yml" and all your database servers in
|
||||||
|
"dbservers.yml". You can create a "site.yml" that would reconfigure
|
||||||
|
all of your systems like this::
|
||||||
|
|
||||||
----
|
----
|
||||||
- include: playbooks/webservers.yml
|
- include: playbooks/webservers.yml
|
||||||
|
@ -49,8 +55,11 @@ what parts of those plays.
|
||||||
Ignoring Failed Commands
|
Ignoring Failed Commands
|
||||||
````````````````````````
|
````````````````````````
|
||||||
|
|
||||||
(New in 0.6) Generally playbooks will stop executing any more steps on a host that has a failure.
|
.. deprecated:: 0.6
|
||||||
Sometimes, though, you want to continue on. To do so, write a task that looks like this::
|
|
||||||
|
Generally playbooks will stop executing any more steps on a host that
|
||||||
|
has a failure. Sometimes, though, you want to continue on. To do so,
|
||||||
|
write a task that looks like this::
|
||||||
|
|
||||||
- name: this will not be counted as a failure
|
- name: this will not be counted as a failure
|
||||||
action: command /bin/false
|
action: command /bin/false
|
||||||
|
|
Loading…
Reference in a new issue