mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
rebuild
This commit is contained in:
parent
ea3bf960aa
commit
331cfa6b36
6 changed files with 55 additions and 28 deletions
|
@ -253,8 +253,12 @@ You may wish to construct simple shell scripts to wrap calls to ansible-playbook
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="bundling-ansible-modules-with-playbooks">
|
<div class="section" id="bundling-ansible-modules-with-playbooks">
|
||||||
<h2>Bundling Ansible Modules With Playbooks<a class="headerlink" href="#bundling-ansible-modules-with-playbooks" title="Permalink to this headline">¶</a></h2>
|
<h2>Bundling Ansible Modules With Playbooks<a class="headerlink" href="#bundling-ansible-modules-with-playbooks" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>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
|
<p class="versionadded">
|
||||||
go with a playbook together.</p>
|
<span class="versionmodified">New in version 0.5.</span></p>
|
||||||
|
<p>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.</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="miscellaneous-tips">
|
<div class="section" id="miscellaneous-tips">
|
||||||
<h2>Miscellaneous Tips<a class="headerlink" href="#miscellaneous-tips" title="Permalink to this headline">¶</a></h2>
|
<h2>Miscellaneous Tips<a class="headerlink" href="#miscellaneous-tips" title="Permalink to this headline">¶</a></h2>
|
||||||
|
|
|
@ -298,10 +298,12 @@ project page:</p>
|
||||||
<p>By default, ansible uses paramiko to talk to managed nodes over SSH. Paramiko is fast, works
|
<p>By default, ansible uses paramiko to talk to managed nodes over SSH. Paramiko is fast, works
|
||||||
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.</p>
|
However, it does not support some advanced SSH features that folks will want to use.</p>
|
||||||
<p>Starting in version 0.5, if you want to leverage more advanced SSH features (such as Kerberized SSH or jump hosts),
|
<p class="versionadded">
|
||||||
pass the flag “–connection=ssh” to any ansible command, or set the
|
<span class="versionmodified">New in version 0.5.</span></p>
|
||||||
ANSIBLE_TRANSPORT environment variable to ‘ssh’. This will cause Ansible to use openssh
|
<p>If you want to leverage more advanced SSH features (such as Kerberized
|
||||||
tools instead.</p>
|
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.</p>
|
||||||
<p>If ANSIBLE_SSH_ARGS are not set, ansible will try to use some sensible ControlMaster options
|
<p>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
|
||||||
options to ensure performance of this transport. With ControlMaster in use, both transports
|
options to ensure performance of this transport. With ControlMaster in use, both transports
|
||||||
|
|
18
modules.html
18
modules.html
|
@ -340,11 +340,15 @@ apt_repository repo='deb http://archive.canonical.com/ubuntu hardy partner'</pre
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="assemble">
|
<div class="section" id="assemble">
|
||||||
<span id="id3"></span><h2>assemble<a class="headerlink" href="#assemble" title="Permalink to this headline">¶</a></h2>
|
<span id="id3"></span><h2>assemble<a class="headerlink" href="#assemble" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>(new in 0.5) Assembles a configuration file from fragments. Often a particular program will take a single configuration file
|
<p class="versionadded">
|
||||||
and does not support a conf.d style structure where it is easy to build up the configuration from multiple sources.
|
<span class="versionmodified">New in version 0.5.</span></p>
|
||||||
Assmeble will take a directory of files that have already been transferred to the system, and concatenate them
|
<p>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”.</p>
|
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”.</p>
|
||||||
<table border="1" class="docutils">
|
<table border="1" class="docutils">
|
||||||
<colgroup>
|
<colgroup>
|
||||||
<col width="17%" />
|
<col width="17%" />
|
||||||
|
@ -383,7 +387,9 @@ together to produce a destination file. Files are assembled in string sorting o
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="authorized-key">
|
<div class="section" id="authorized-key">
|
||||||
<span id="id4"></span><h2>authorized_key<a class="headerlink" href="#authorized-key" title="Permalink to this headline">¶</a></h2>
|
<span id="id4"></span><h2>authorized_key<a class="headerlink" href="#authorized-key" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>(new in 0.5). Adds or removes an authorized key for a user from a remote host.</p>
|
<p class="versionadded">
|
||||||
|
<span class="versionmodified">New in version 0.5.</span></p>
|
||||||
|
<p>Adds or removes an authorized key for a user from a remote host.</p>
|
||||||
<table border="1" class="docutils">
|
<table border="1" class="docutils">
|
||||||
<colgroup>
|
<colgroup>
|
||||||
<col width="17%" />
|
<col width="17%" />
|
||||||
|
|
|
@ -304,9 +304,11 @@ seperate from the inventory file, see the next section.</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="splitting-out-host-and-group-specific-data">
|
<div class="section" id="splitting-out-host-and-group-specific-data">
|
||||||
<h2>Splitting Out Host and Group Specific Data<a class="headerlink" href="#splitting-out-host-and-group-specific-data" title="Permalink to this headline">¶</a></h2>
|
<h2>Splitting Out Host and Group Specific Data<a class="headerlink" href="#splitting-out-host-and-group-specific-data" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>In Ansible 0.6 and later, in addition to the storing variables directly in the INI file, host and
|
<p class="versionadded">
|
||||||
group variables can be stored in individual files relative to the inventory file. These
|
<span class="versionmodified">New in version 0.6.</span></p>
|
||||||
variable files are in YAML format.</p>
|
<p>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.</p>
|
||||||
<p>Assuming the inventory file path is:</p>
|
<p>Assuming the inventory file path is:</p>
|
||||||
<div class="highlight-python"><pre>/etc/ansible/hosts</pre>
|
<div class="highlight-python"><pre>/etc/ansible/hosts</pre>
|
||||||
</div>
|
</div>
|
||||||
|
@ -326,13 +328,17 @@ database_server: storage.example.org</pre>
|
||||||
<p>It is ok if these files do not exist, this is an optional feature.</p>
|
<p>It is ok if these files do not exist, this is an optional feature.</p>
|
||||||
<p>Tip: Keeping your inventory file and variables in a git repo (or other version control)
|
<p>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.</p>
|
is an excellent way to track changes to your inventory and host variables.</p>
|
||||||
<p>Tip: If you ever have two python interpreters on a system, set a variable called ‘ansible_python_interpreter’ to
|
<p class="versionadded">
|
||||||
the Python interpreter path you would like to use.</p>
|
<span class="versionmodified">New in version 0.5: </span>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.</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="yaml-inventory">
|
<div class="section" id="yaml-inventory">
|
||||||
<h2>YAML Inventory<a class="headerlink" href="#yaml-inventory" title="Permalink to this headline">¶</a></h2>
|
<h2>YAML Inventory<a class="headerlink" href="#yaml-inventory" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>Ansible’s YAML inventory format is deprecated and will be removed in Ansible 0.7. Ansible 0.6 includes
|
<p class="deprecated">
|
||||||
a <a class="reference external" href="https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py">conversion script</a>.</p>
|
<span class="versionmodified">Deprecated since version 0.7.</span></p>
|
||||||
|
<p>Ansible’s YAML inventory format is deprecated and will be removed in
|
||||||
|
Ansible 0.7. Ansible 0.6 includes a <a class="reference external" href="https://github.com/ansible/ansible/blob/devel/examples/scripts/yaml_to_ini.py">conversion script</a>.</p>
|
||||||
<p>Usage:</p>
|
<p>Usage:</p>
|
||||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">yaml_to_ini</span><span class="o">.</span><span class="n">py</span> <span class="o">/</span><span class="n">etc</span><span class="o">/</span><span class="n">ansible</span><span class="o">/</span><span class="n">hosts</span>
|
<div class="highlight-python"><div class="highlight"><pre><span class="n">yaml_to_ini</span><span class="o">.</span><span class="n">py</span> <span class="o">/</span><span class="n">etc</span><span class="o">/</span><span class="n">ansible</span><span class="o">/</span><span class="n">hosts</span>
|
||||||
</pre></div>
|
</pre></div>
|
||||||
|
|
|
@ -202,8 +202,11 @@ relevant, feel free to skip it. For many people, the features documented in <ci
|
||||||
be 90% or more of what they use in Ansible.</p>
|
be 90% or more of what they use in Ansible.</p>
|
||||||
<div class="section" id="tags">
|
<div class="section" id="tags">
|
||||||
<h2>Tags<a class="headerlink" href="#tags" title="Permalink to this headline">¶</a></h2>
|
<h2>Tags<a class="headerlink" href="#tags" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>(New in 0.6) If you have a large playbook it may become useful to be able to run a specific
|
<p class="versionadded">
|
||||||
part of the configuration. Both plays and tasks support a “tags:” attribute for this reason.</p>
|
<span class="versionmodified">New in version 0.6.</span></p>
|
||||||
|
<p>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.</p>
|
||||||
<p>Example:</p>
|
<p>Example:</p>
|
||||||
<div class="highlight-python"><pre>tasks:
|
<div class="highlight-python"><pre>tasks:
|
||||||
|
|
||||||
|
@ -224,10 +227,13 @@ part of the configuration. Both plays and tasks support a “tags:” a
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="playbooks-including-playbooks">
|
<div class="section" id="playbooks-including-playbooks">
|
||||||
<h2>Playbooks Including Playbooks<a class="headerlink" href="#playbooks-including-playbooks" title="Permalink to this headline">¶</a></h2>
|
<h2>Playbooks Including Playbooks<a class="headerlink" href="#playbooks-including-playbooks" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>(New in 0.6) To further advance the concept of include files, playbook files can include other playbook
|
<p class="versionadded">
|
||||||
files. Suppose you define the behavior of all your webservers in “webservers.yml” and
|
<span class="versionmodified">New in version 0.6.</span></p>
|
||||||
all your database servers in “dbservers.yml”. You can create a “site.yml” that would
|
<p>To further advance the concept of include files, playbook files can
|
||||||
reconfigure all of your systems like this:</p>
|
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:</p>
|
||||||
<div class="highlight-python"><pre>----
|
<div class="highlight-python"><pre>----
|
||||||
- include: playbooks/webservers.yml
|
- include: playbooks/webservers.yml
|
||||||
- include: playbooks/dbservers.yml</pre>
|
- include: playbooks/dbservers.yml</pre>
|
||||||
|
@ -237,8 +243,11 @@ what parts of those plays.</p>
|
||||||
</div>
|
</div>
|
||||||
<div class="section" id="ignoring-failed-commands">
|
<div class="section" id="ignoring-failed-commands">
|
||||||
<h2>Ignoring Failed Commands<a class="headerlink" href="#ignoring-failed-commands" title="Permalink to this headline">¶</a></h2>
|
<h2>Ignoring Failed Commands<a class="headerlink" href="#ignoring-failed-commands" title="Permalink to this headline">¶</a></h2>
|
||||||
<p>(New in 0.6) Generally playbooks will stop executing any more steps on a host that has a failure.
|
<p class="deprecated">
|
||||||
Sometimes, though, you want to continue on. To do so, write a task that looks like this:</p>
|
<span class="versionmodified">Deprecated since version 0.6.</span></p>
|
||||||
|
<p>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:</p>
|
||||||
<div class="highlight-python"><pre>- name: this will not be counted as a failure
|
<div class="highlight-python"><pre>- name: this will not be counted as a failure
|
||||||
action: command /bin/false
|
action: command /bin/false
|
||||||
ignore_errors: True</pre>
|
ignore_errors: True</pre>
|
||||||
|
|
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue