mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Document more playbook features in 0.7, docs build
This commit is contained in:
parent
7bd6fde2a3
commit
0219d88fdd
5 changed files with 51 additions and 3 deletions
|
@ -386,10 +386,12 @@ also works with <tt class="docutils literal"><span class="pre">ansible-playbook<
|
|||
</pre></div>
|
||||
</div>
|
||||
<p>Now let’s talk about range selection. Suppose you have 1000 servers in group ‘datacenter’, but only want to target one at a time. This is also easy:</p>
|
||||
<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>ansible webservers<span class="o">[</span>0-100<span class="o">]</span> -m <span class="nb">command</span> -a <span class="s2">"/bin/foo xyz"</span>
|
||||
<span class="nv">$ </span>ansible webservers<span class="o">[</span>101-200<span class="o">]</span> -m <span class="nb">command</span> -a <span class="s2">"/bin/foo xyz"</span>
|
||||
<div class="highlight-bash"><div class="highlight"><pre><span class="nv">$ </span>ansible webservers<span class="o">[</span>0-99<span class="o">]</span> -m <span class="nb">command</span> -a <span class="s2">"/bin/foo xyz"</span>
|
||||
<span class="nv">$ </span>ansible webservers<span class="o">[</span>100-199<span class="o">]</span> -m <span class="nb">command</span> -a <span class="s2">"/bin/foo xyz"</span>
|
||||
</pre></div>
|
||||
</div>
|
||||
<p>This will select the first 100, then the second 100, host entries in the webservers group. (It does not matter
|
||||
what their names or IP addresses are).</p>
|
||||
<p>Both of these methods can be used at the same time, and ranges can also be passed to the –limit parameter.</p>
|
||||
<div class="admonition-see-also admonition seealso">
|
||||
<p class="first admonition-title">See also</p>
|
||||
|
|
|
@ -853,6 +853,8 @@ the basename of the file on the remote server will be used.</td>
|
|||
</div>
|
||||
<div class="section" id="mount">
|
||||
<span id="id14"></span><h2>mount<a class="headerlink" href="#mount" title="Permalink to this headline">¶</a></h2>
|
||||
<p class="versionadded">
|
||||
<span class="versionmodified">New in version 0.6.</span></p>
|
||||
<p>The mount module controls active and configured mount points (fstab).</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
|
|
|
@ -165,6 +165,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
<li><a class="reference internal" href="#local-playbooks">Local Playbooks</a></li>
|
||||
<li><a class="reference internal" href="#turning-off-facts">Turning Off Facts</a></li>
|
||||
<li><a class="reference internal" href="#pull-mode-playbooks">Pull-Mode Playbooks</a></li>
|
||||
<li><a class="reference internal" href="#register-variables">Register Variables</a></li>
|
||||
<li><a class="reference internal" href="#style-points">Style Points</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
|
@ -578,6 +579,26 @@ the cron frequency, logging locations, and parameters to ansible-pull.</p>
|
|||
<p>This is useful both for extreme scale-out as well as periodic remediation. Usage of the ‘fetch’ module to retrieve
|
||||
logs from ansible-pull runs would be an excellent way to gather and analyze remote logs from ansible-pull.</p>
|
||||
</div>
|
||||
<div class="section" id="register-variables">
|
||||
<h2>Register Variables<a class="headerlink" href="#register-variables" title="Permalink to this headline">¶</a></h2>
|
||||
<p class="versionadded">
|
||||
<span class="versionmodified">New in version 0.7.</span></p>
|
||||
<p>Often in a playbook it may be useful to store the result of a given command in a variable and access
|
||||
it later. Use of the command module in this way can in many ways eliminate the need to write site specific facts, for
|
||||
instance, you could test for the existance of a particular program.</p>
|
||||
<p>The ‘register’ keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or only_if statements. It looks like this (in an obviously trivial example):</p>
|
||||
<div class="highlight-python"><pre>- name: test playbook
|
||||
hosts: all
|
||||
|
||||
tasks:
|
||||
|
||||
- action: shell cat /etc/motd
|
||||
register: motd_contents
|
||||
|
||||
- action: shell echo "motd contains the word hi"
|
||||
only_if: "'${motd_contents.stdout}'.find('hi') != -1"</pre>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="style-points">
|
||||
<h2>Style Points<a class="headerlink" href="#style-points" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Ansible playbooks are colorized. If you do not like this, set the ANSIBLE_NOCOLOR=1 environment variable.</p>
|
||||
|
|
|
@ -437,6 +437,29 @@ the cron frequency, logging locations, and parameters to ansible-pull.
|
|||
This is useful both for extreme scale-out as well as periodic remediation. Usage of the 'fetch' module to retrieve
|
||||
logs from ansible-pull runs would be an excellent way to gather and analyze remote logs from ansible-pull.
|
||||
|
||||
Register Variables
|
||||
``````````````````
|
||||
|
||||
.. versionadded:: 0.7
|
||||
|
||||
Often in a playbook it may be useful to store the result of a given command in a variable and access
|
||||
it later. Use of the command module in this way can in many ways eliminate the need to write site specific facts, for
|
||||
instance, you could test for the existance of a particular program.
|
||||
|
||||
The 'register' keyword decides what variable to save a result in. The resulting variables can be used in templates, action lines, or only_if statements. It looks like this (in an obviously trivial example)::
|
||||
|
||||
- name: test playbook
|
||||
hosts: all
|
||||
|
||||
tasks:
|
||||
|
||||
- action: shell cat /etc/motd
|
||||
register: motd_contents
|
||||
|
||||
- action: shell echo "motd contains the word hi"
|
||||
only_if: "'${motd_contents.stdout}'.find('hi') != -1"
|
||||
|
||||
|
||||
Style Points
|
||||
````````````
|
||||
|
||||
|
|
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue