Various docs reorg and additions
This commit is contained in:
parent
bdba38c790
commit
4994566124
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
|
13
api.html
13
api.html
|
@ -27,8 +27,8 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="Module Development Guide" href="moduledev.html" />
|
||||
<link rel="prev" title="Playbooks" href="playbooks.html" />
|
||||
<link rel="next" title="Module Development" href="moduledev.html" />
|
||||
<link rel="prev" title="Advanced Playbooks" href="playbooks2.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
<title>Command Line Examples — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<title>Command Line — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/bootstrap.css" type="text/css" />
|
||||
|
@ -28,7 +28,7 @@
|
|||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="Ansible Modules" href="modules.html" />
|
||||
<link rel="prev" title="The Inventory File, Patterns, and Groups" href="patterns.html" />
|
||||
<link rel="prev" title="Inventory & Patterns" href="patterns.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -145,7 +146,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Page</a>
|
||||
<span class="localtoc"><ul>
|
||||
<li><a class="reference internal" href="#">Command Line Examples</a><ul>
|
||||
<li><a class="reference internal" href="#">Command Line</a><ul>
|
||||
<li><a class="reference internal" href="#parallelism-and-shell-commands">Parallelism and Shell Commands</a></li>
|
||||
<li><a class="reference internal" href="#file-transfer-templating">File Transfer & Templating</a></li>
|
||||
<li><a class="reference internal" href="#managing-packages">Managing Packages</a></li>
|
||||
|
@ -180,8 +181,8 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="http://ansible.github.com"><img src="http://ansible.github.com/ansible-logo.png" alt="Ansible"/></a><br/>
|
||||
<br/>
|
||||
|
||||
<div class="section" id="command-line-examples">
|
||||
<h1>Command Line Examples<a class="headerlink" href="#command-line-examples" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="command-line">
|
||||
<h1>Command Line<a class="headerlink" href="#command-line" title="Permalink to this headline">¶</a></h1>
|
||||
<p>The following examples show how to use <cite>/usr/bin/ansible</cite> for running ad-hoc tasks.
|
||||
Start here.</p>
|
||||
<p>For configuration management and deployments, you’ll want to pick up on
|
||||
|
@ -211,7 +212,7 @@ not required.</p>
|
|||
<p>It is also possible to sudo to a user other than root using –sudo-user (-U):</p>
|
||||
<div class="highlight-python"><pre>ansible atlanta -a "/usr/bin/foo" -u yourname -U otheruser [--ask-sudo-pass]</pre>
|
||||
</div>
|
||||
<p>Ok, so those are basics. If you didn’t read about patterns and groups yet, go back and read <a class="reference internal" href="patterns.html"><em>The Inventory File, Patterns, and Groups</em></a>.</p>
|
||||
<p>Ok, so those are basics. If you didn’t read about patterns and groups yet, go back and read <a class="reference internal" href="patterns.html"><em>Inventory & Patterns</em></a>.</p>
|
||||
<p>The -f 10 in the above specifies the usage of 10 simultaneous processes. Normally commands also take
|
||||
a <cite>-m</cite> for module name, but the default module name is ‘command’, so we didn’t need to specify that
|
||||
all of the time. We’ll use <cite>-m</cite> in later examples to run some other <a class="reference internal" href="modules.html"><em>Ansible Modules</em></a>.</p>
|
||||
|
|
13
faq.html
13
faq.html
|
@ -27,7 +27,7 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="prev" title="Module Development Guide" href="moduledev.html" />
|
||||
<link rel="prev" title="Module Development" href="moduledev.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -128,14 +128,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -350,7 +351,7 @@ tasks – whether for a QA sytem, build system, or anything you can think of
|
|||
<div class="admonition-see-also admonition seealso">
|
||||
<p class="first admonition-title">See also</p>
|
||||
<dl class="last docutils">
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line Examples</em></a></dt>
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line</em></a></dt>
|
||||
<dd>Examples of basic commands</dd>
|
||||
<dt><a class="reference internal" href="playbooks.html"><em>Playbooks</em></a></dt>
|
||||
<dd>Learning ansible’s configuration management language</dd>
|
||||
|
|
|
@ -127,14 +127,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
<title>Downloads & Getting Started — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<title>Getting Started — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/bootstrap.css" type="text/css" />
|
||||
|
@ -27,7 +27,7 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="The Inventory File, Patterns, and Groups" href="patterns.html" />
|
||||
<link rel="next" title="Inventory & Patterns" href="patterns.html" />
|
||||
<link rel="prev" title="The Future Is Now" href="index.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -145,7 +146,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Page</a>
|
||||
<span class="localtoc"><ul>
|
||||
<li><a class="reference internal" href="#">Downloads & Getting Started</a><ul>
|
||||
<li><a class="reference internal" href="#">Getting Started</a><ul>
|
||||
<li><a class="reference internal" href="#requirements">Requirements</a></li>
|
||||
<li><a class="reference internal" href="#python-2-6-epel-instructions-for-rhel-and-centos-5">Python 2.6 EPEL instructions for RHEL and CentOS 5</a></li>
|
||||
<li><a class="reference internal" href="#getting-ansible">Getting Ansible</a><ul>
|
||||
|
@ -184,8 +185,8 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="http://ansible.github.com"><img src="http://ansible.github.com/ansible-logo.png" alt="Ansible"/></a><br/>
|
||||
<br/>
|
||||
|
||||
<div class="section" id="downloads-getting-started">
|
||||
<h1>Downloads & Getting Started<a class="headerlink" href="#downloads-getting-started" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="getting-started">
|
||||
<h1>Getting Started<a class="headerlink" href="#getting-started" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="requirements">
|
||||
<h2>Requirements<a class="headerlink" href="#requirements" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Requirements for Ansible are extremely minimal.</p>
|
||||
|
@ -313,7 +314,7 @@ ssh-add ~/.ssh/id_rsa</pre>
|
|||
<div class="highlight-python"><pre>ansible all -a "/bin/echo hello"</pre>
|
||||
</div>
|
||||
<p>Congratulations. You’ve just contacted your nodes with Ansible. It’s
|
||||
now time to read some of the more real-world <a class="reference internal" href="examples.html"><em>Command Line Examples</em></a>, and explore
|
||||
now time to read some of the more real-world <a class="reference internal" href="examples.html"><em>Command Line</em></a>, and explore
|
||||
what you can do with different modules, as well as the Ansible
|
||||
<a class="reference internal" href="playbooks.html"><em>Playbooks</em></a> language. Ansible is not just about running commands, it
|
||||
also has powerful configuration management and deployment features. There’s more to
|
||||
|
@ -321,7 +322,7 @@ explore, but you already have a fully working infrastructure!</p>
|
|||
<div class="admonition-see-also admonition seealso">
|
||||
<p class="first admonition-title">See also</p>
|
||||
<dl class="last docutils">
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line Examples</em></a></dt>
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line</em></a></dt>
|
||||
<dd>Examples of basic commands</dd>
|
||||
<dt><a class="reference internal" href="playbooks.html"><em>Playbooks</em></a></dt>
|
||||
<dd>Learning ansible’s configuration management language</dd>
|
||||
|
|
41
index.html
41
index.html
|
@ -27,7 +27,7 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="#" />
|
||||
<link rel="next" title="Downloads & Getting Started" href="gettingstarted.html" />
|
||||
<link rel="next" title="Getting Started" href="gettingstarted.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -128,14 +128,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -190,7 +191,7 @@ much learning curve. Ansible is dead simple and painless to extend.
|
|||
For comparison, Puppet and Chef have about 60k lines of code.
|
||||
Ansible’s core is a little over 1000 lines.</p>
|
||||
<p>Ansible isn’t just for idempotent configuration – it’s also great for ad-hoc
|
||||
tasks, quickly firing off commands against nodes. See <a class="reference internal" href="examples.html"><em>Command Line Examples</em></a>.</p>
|
||||
tasks, quickly firing off commands against nodes. See <a class="reference internal" href="examples.html"><em>Command Line</em></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="innovative-multi-node-control">
|
||||
<h1>Innovative Multi-node Control<a class="headerlink" href="#innovative-multi-node-control" title="Permalink to this headline">¶</a></h1>
|
||||
|
@ -277,7 +278,7 @@ Email: <input type=text name=email> <input type=submit name="sub" val
|
|||
<h1>Contents<a class="headerlink" href="#contents" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="toctree-wrapper compound">
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#requirements">Requirements</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#python-2-6-epel-instructions-for-rhel-and-centos-5">Python 2.6 EPEL instructions for RHEL and CentOS 5</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#getting-ansible">Getting Ansible</a><ul>
|
||||
|
@ -291,7 +292,7 @@ Email: <input type=text name=email> <input type=submit name="sub" val
|
|||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#your-first-commands">Your first commands</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#hosts-and-groups">Hosts and Groups</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#selecting-targets">Selecting Targets</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#host-variables">Host Variables</a></li>
|
||||
|
@ -300,7 +301,7 @@ Email: <input type=text name=email> <input type=submit name="sub" val
|
|||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#yaml-inventory-format">YAML Inventory Format</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#parallelism-and-shell-commands">Parallelism and Shell Commands</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#file-transfer-templating">File Transfer & Templating</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#managing-packages">Managing Packages</a></li>
|
||||
|
@ -346,20 +347,24 @@ Email: <input type=text name=email> <input type=submit name="sub" val
|
|||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#running-operations-on-change">Running Operations On Change</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#power-tricks">Power Tricks</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#local-playbooks">Local Playbooks</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#variables-from-other-hosts">Variables From Other Hosts</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#external-variables-and-prompted-or-sensitive-data">External Variables and Prompted or Sensitive Data</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#conditional-execution">Conditional Execution</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#conditional-imports">Conditional Imports</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#include-files-and-reuse">Include Files And Reuse</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#using-includes-to-assign-classes-of-systems">Using Includes To Assign Classes of Systems</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#loop-shorthand">Loop Shorthand</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#executing-a-playbook">Executing A Playbook</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#local-playbooks">Local Playbooks</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#pull-mode-playbooks">Pull-Mode Playbooks</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#variables-from-other-hosts">Variables From Other Hosts</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#external-variables-and-prompted-or-sensitive-data">External Variables and Prompted or Sensitive Data</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#conditional-execution">Conditional Execution</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#conditional-imports">Conditional Imports</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#using-includes-to-assign-classes-of-systems">Using Includes To Assign Classes of Systems</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#loop-shorthand">Loop Shorthand</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="api.html#python-api">Python API</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="api.html#detailed-api-example">Detailed API Example</a></li>
|
||||
|
@ -372,7 +377,7 @@ Email: <input type=text name=email> <input type=submit name="sub" val
|
|||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#tutorial">Tutorial</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#testing-modules">Testing Modules</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#reading-input">Reading Input</a></li>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
<title>Module Development Guide — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<title>Module Development — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/bootstrap.css" type="text/css" />
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Module Development Guide</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -145,7 +146,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Page</a>
|
||||
<span class="localtoc"><ul>
|
||||
<li><a class="reference internal" href="#">Module Development Guide</a><ul>
|
||||
<li><a class="reference internal" href="#">Module Development</a><ul>
|
||||
<li><a class="reference internal" href="#tutorial">Tutorial</a></li>
|
||||
<li><a class="reference internal" href="#testing-modules">Testing Modules</a></li>
|
||||
<li><a class="reference internal" href="#reading-input">Reading Input</a></li>
|
||||
|
@ -182,8 +183,8 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="http://ansible.github.com"><img src="http://ansible.github.com/ansible-logo.png" alt="Ansible"/></a><br/>
|
||||
<br/>
|
||||
|
||||
<div class="section" id="module-development-guide">
|
||||
<h1>Module Development Guide<a class="headerlink" href="#module-development-guide" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="module-development">
|
||||
<h1>Module Development<a class="headerlink" href="#module-development" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Ansible modules are reusable units of magic that can be used by the Ansible API,
|
||||
or by the <cite>ansible</cite> or <cite>ansible-playbook</cite> programs.</p>
|
||||
<p>Modules can be written in any language and are found in the path specified
|
||||
|
|
19
modules.html
19
modules.html
|
@ -28,7 +28,7 @@
|
|||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="YAML Syntax" href="YAMLSyntax.html" />
|
||||
<link rel="prev" title="Command Line Examples" href="examples.html" />
|
||||
<link rel="prev" title="Command Line" href="examples.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -254,8 +255,6 @@ apt pkg=foo state=installed
|
|||
apt pkg=foo=1.00 state=installed
|
||||
apt pkg=nginx state=latest default-release=squeeze-backports update-cache=yes</pre>
|
||||
</div>
|
||||
<p>NOTE: the apt module cannot currently request installation of a specific software version, as the yum
|
||||
module can. This should be available in a future release.</p>
|
||||
</div>
|
||||
<div class="section" id="command">
|
||||
<span id="id2"></span><h2>command<a class="headerlink" href="#command" title="Permalink to this headline">¶</a></h2>
|
||||
|
@ -751,15 +750,15 @@ yum pkg=httpd state=installed</pre>
|
|||
</div>
|
||||
<div class="section" id="writing-your-own-modules">
|
||||
<h2>Writing your own modules<a class="headerlink" href="#writing-your-own-modules" title="Permalink to this headline">¶</a></h2>
|
||||
<p>See <a class="reference internal" href="moduledev.html"><em>Module Development Guide</em></a>.</p>
|
||||
<p>See <a class="reference internal" href="moduledev.html"><em>Module Development</em></a>.</p>
|
||||
<div class="admonition-see-also admonition seealso">
|
||||
<p class="first admonition-title">See also</p>
|
||||
<dl class="last docutils">
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line Examples</em></a></dt>
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line</em></a></dt>
|
||||
<dd>Examples of using modules in /usr/bin/ansible</dd>
|
||||
<dt><a class="reference internal" href="playbooks.html"><em>Playbooks</em></a></dt>
|
||||
<dd>Examples of using modules with /usr/bin/ansible-playbook</dd>
|
||||
<dt><a class="reference internal" href="moduledev.html"><em>Module Development Guide</em></a></dt>
|
||||
<dt><a class="reference internal" href="moduledev.html"><em>Module Development</em></a></dt>
|
||||
<dd>How to write your own modules</dd>
|
||||
<dt><a class="reference internal" href="api.html"><em>API & Integrations</em></a></dt>
|
||||
<dd>Examples of using modules with the Python API</dd>
|
||||
|
|
|
@ -6,7 +6,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
<title>The Inventory File, Patterns, and Groups — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<title>Inventory & Patterns — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/bootstrap.css" type="text/css" />
|
||||
|
@ -27,8 +27,8 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="Command Line Examples" href="examples.html" />
|
||||
<link rel="prev" title="Downloads & Getting Started" href="gettingstarted.html" />
|
||||
<link rel="next" title="Command Line" href="examples.html" />
|
||||
<link rel="prev" title="Getting Started" href="gettingstarted.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -145,7 +146,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Page</a>
|
||||
<span class="localtoc"><ul>
|
||||
<li><a class="reference internal" href="#">The Inventory File, Patterns, and Groups</a><ul>
|
||||
<li><a class="reference internal" href="#">Inventory & Patterns</a><ul>
|
||||
<li><a class="reference internal" href="#hosts-and-groups">Hosts and Groups</a></li>
|
||||
<li><a class="reference internal" href="#selecting-targets">Selecting Targets</a></li>
|
||||
<li><a class="reference internal" href="#host-variables">Host Variables</a></li>
|
||||
|
@ -179,8 +180,8 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="http://ansible.github.com"><img src="http://ansible.github.com/ansible-logo.png" alt="Ansible"/></a><br/>
|
||||
<br/>
|
||||
|
||||
<div class="section" id="the-inventory-file-patterns-and-groups">
|
||||
<span id="patterns"></span><h1>The Inventory File, Patterns, and Groups<a class="headerlink" href="#the-inventory-file-patterns-and-groups" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="inventory-patterns">
|
||||
<span id="patterns"></span><h1>Inventory & Patterns<a class="headerlink" href="#inventory-patterns" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Ansible works against multiple systems in your infrastructure at the
|
||||
same time. It does this by selecting portions of systems listed in
|
||||
Ansible’s inventory file, which defaults to /etc/ansible/hosts.</p>
|
||||
|
@ -208,7 +209,7 @@ after the hostname with a colon.</p>
|
|||
</div>
|
||||
<div class="section" id="selecting-targets">
|
||||
<h2>Selecting Targets<a class="headerlink" href="#selecting-targets" title="Permalink to this headline">¶</a></h2>
|
||||
<p>We’ll go over how to use the command line in <a class="reference internal" href="examples.html"><em>Command Line Examples</em></a> section, however, basically it looks like this:</p>
|
||||
<p>We’ll go over how to use the command line in <a class="reference internal" href="examples.html"><em>Command Line</em></a> section, however, basically it looks like this:</p>
|
||||
<div class="highlight-python"><pre>ansible <pattern_goes_here> -m <module_name> -a <arguments></pre>
|
||||
</div>
|
||||
<p>Such as:</p>
|
||||
|
@ -240,7 +241,7 @@ wildcards:</p>
|
|||
<p>It’s also ok to mix wildcard patterns and groups at the same time:</p>
|
||||
<div class="highlight-python"><pre>one*.com:dbservers</pre>
|
||||
</div>
|
||||
<p>Easy enough. See <a class="reference internal" href="examples.html"><em>Command Line Examples</em></a> and then <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a> for how to do things to selected hosts.</p>
|
||||
<p>Easy enough. See <a class="reference internal" href="examples.html"><em>Command Line</em></a> and then <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a> for how to do things to selected hosts.</p>
|
||||
</div>
|
||||
<div class="section" id="host-variables">
|
||||
<h2>Host Variables<a class="headerlink" href="#host-variables" title="Permalink to this headline">¶</a></h2>
|
||||
|
@ -333,7 +334,7 @@ YAML:</p>
|
|||
<div class="admonition-see-also admonition seealso">
|
||||
<p class="first admonition-title">See also</p>
|
||||
<dl class="last docutils">
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line Examples</em></a></dt>
|
||||
<dt><a class="reference internal" href="examples.html"><em>Command Line</em></a></dt>
|
||||
<dd>Examples of basic commands</dd>
|
||||
<dt><a class="reference internal" href="playbooks.html"><em>Playbooks</em></a></dt>
|
||||
<dd>Learning ansible’s configuration management language</dd>
|
||||
|
|
285
playbooks.html
285
playbooks.html
|
@ -27,7 +27,7 @@
|
|||
<script type="text/javascript" src="_static/bootstrap-scrollspy.js"></script>
|
||||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="API & Integrations" href="api.html" />
|
||||
<link rel="next" title="Advanced Playbooks" href="playbooks2.html" />
|
||||
<link rel="prev" title="YAML Syntax" href="YAMLSyntax.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
|
@ -129,14 +129,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul class="current">
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1 current"><a class="current reference internal" href="">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
@ -155,15 +156,7 @@ s.parentNode.insertBefore(ga, s);
|
|||
</li>
|
||||
<li><a class="reference internal" href="#running-operations-on-change">Running Operations On Change</a></li>
|
||||
<li><a class="reference internal" href="#power-tricks">Power Tricks</a><ul>
|
||||
<li><a class="reference internal" href="#local-playbooks">Local Playbooks</a></li>
|
||||
<li><a class="reference internal" href="#variables-from-other-hosts">Variables From Other Hosts</a></li>
|
||||
<li><a class="reference internal" href="#external-variables-and-prompted-or-sensitive-data">External Variables and Prompted or Sensitive Data</a></li>
|
||||
<li><a class="reference internal" href="#conditional-execution">Conditional Execution</a></li>
|
||||
<li><a class="reference internal" href="#conditional-imports">Conditional Imports</a></li>
|
||||
<li><a class="reference internal" href="#include-files-and-reuse">Include Files And Reuse</a></li>
|
||||
<li><a class="reference internal" href="#using-includes-to-assign-classes-of-systems">Using Includes To Assign Classes of Systems</a></li>
|
||||
<li><a class="reference internal" href="#loop-shorthand">Loop Shorthand</a></li>
|
||||
<li><a class="reference internal" href="#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#executing-a-playbook">Executing A Playbook</a></li>
|
||||
|
@ -249,7 +242,7 @@ server group, then more commands back on the webservers group, etc.</p>
|
|||
<p>For each play in a playbook, you get to choose which machines in your infrastructure
|
||||
to target and what remote user to complete the steps (called tasks) as.</p>
|
||||
<p>The <cite>hosts</cite> line is a list of one or more groups or host patterns,
|
||||
separated by colons, as described in the <a class="reference internal" href="patterns.html#patterns"><em>The Inventory File, Patterns, and Groups</em></a>
|
||||
separated by colons, as described in the <a class="reference internal" href="patterns.html#patterns"><em>Inventory & Patterns</em></a>
|
||||
documentation. The <cite>user</cite> is just the name of the user account:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: webservers
|
||||
|
@ -276,14 +269,16 @@ Just <cite>Control-C</cite> to kill it and run it again with <cite>-K</cite>.</p
|
|||
van_halen_port: 5150
|
||||
other: 'magic'</pre>
|
||||
</div>
|
||||
<p>These variables can be used later in the playbook, or on the managed system (in templates), just like this:</p>
|
||||
<div class="highlight-python"><pre>{{ varname }}</pre>
|
||||
</div>
|
||||
<p>Within playbooks themselves, but not within templates on the remote machines, it’s also legal
|
||||
to use nicer shorthand like this:</p>
|
||||
<p>These variables can be used later in the playbook like this:</p>
|
||||
<div class="highlight-python"><pre>$varname</pre>
|
||||
</div>
|
||||
<p>Further, if there are discovered variables about the system (ansible provides some of these,
|
||||
<p>In templates, the full power of the Jinja2 templating language is also available, which looks like this:</p>
|
||||
<blockquote>
|
||||
<div>{{ varname }}</div></blockquote>
|
||||
<p>The Jinja2 documentation provides information about how to construct loops and conditionals for those
|
||||
who which to use more advanced templating. This is optional and the $varname format still works in template
|
||||
files.</p>
|
||||
<p>If there are discovered variables about the system (ansible provides some of these,
|
||||
plus we include ones taken from facter or ohai if installed) these variables bubble up back into the
|
||||
playbook, and can be used on each system just like explicitly set
|
||||
variables.</p>
|
||||
|
@ -382,143 +377,6 @@ won’t need them for much else.</p>
|
|||
<h2>Power Tricks<a class="headerlink" href="#power-tricks" title="Permalink to this headline">¶</a></h2>
|
||||
<p>Now that you have the basics down, let’s learn some more advanced
|
||||
things you can do with playbooks.</p>
|
||||
<div class="section" id="local-playbooks">
|
||||
<h3>Local Playbooks<a class="headerlink" href="#local-playbooks" title="Permalink to this headline">¶</a></h3>
|
||||
<p>It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful
|
||||
for assuring the configuration of a system by putting a playbook on a crontab. This may also be used
|
||||
to run a playbook inside a OS installer, such as an Anaconda kickstart.</p>
|
||||
<p>To run an entire playbook locally, just set the “hosts:” line to “hosts:127.0.0.1” and then run the playbook like so:</p>
|
||||
<div class="highlight-python"><pre>ansible-playbook playbook.yml --connection=local</pre>
|
||||
</div>
|
||||
<p>Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook
|
||||
use the default remote connection type:</p>
|
||||
<div class="highlight-python"><pre>hosts: 127.0.0.1
|
||||
connection: local</pre>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="variables-from-other-hosts">
|
||||
<h3>Variables From Other Hosts<a class="headerlink" href="#variables-from-other-hosts" title="Permalink to this headline">¶</a></h3>
|
||||
<p>If your database server wants to check the value of a ‘fact’ from another node, it’s easy to do so
|
||||
within a template or even an action line:</p>
|
||||
<div class="highlight-python"><pre>{{ hostvars.get('name_of_host').get('name_of_fact') }}</pre>
|
||||
</div>
|
||||
<p>NOTE: No database or other complex system is required to exchange data between hosts. The hosts that you
|
||||
want to reference data from must be included in either the current play or any previous play.</p>
|
||||
</div>
|
||||
<div class="section" id="external-variables-and-prompted-or-sensitive-data">
|
||||
<h3>External Variables and Prompted or Sensitive Data<a class="headerlink" href="#external-variables-and-prompted-or-sensitive-data" title="Permalink to this headline">¶</a></h3>
|
||||
<p>It’s a great idea to keep your playbooks under source control, but
|
||||
you may wish to make the playbook source public while keeping certain
|
||||
important variables private. Similarly, sometimes you may just
|
||||
want to keep certain information in different files, away from
|
||||
the main playbook.</p>
|
||||
<p>You can do this by using an external variables file, or files, just like this:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
favcolor: blue
|
||||
vars_files:
|
||||
- /vars/external_vars.yml
|
||||
tasks:
|
||||
- name: this is just a placeholder
|
||||
action: command /bin/echo foo</pre>
|
||||
</div>
|
||||
<p>This removes the risk of sharing sensitive data with others when
|
||||
sharing your playbook source with them.</p>
|
||||
<p>The contents of each variables file is a simple YAML dictionary, like this:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
# in the above example, this would be vars/external_vars.yml
|
||||
somevar: somevalue
|
||||
password: magic</pre>
|
||||
</div>
|
||||
<p>Alternatively, you may wish to prompt the user for certain input, and can
|
||||
do so with the similarly named ‘vars_prompt’ section. This has uses
|
||||
beyond security, for instance, you may use the same playbook for all
|
||||
software releases and would prompt for a particular release version
|
||||
in a push-script:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
from: "camelot"
|
||||
vars_prompt:
|
||||
name: "what is your name?"
|
||||
quest: "what is your quest?"
|
||||
favcolor: "what is your favorite color?"</pre>
|
||||
</div>
|
||||
<p>There are full examples of both of these items in the github examples/playbooks directory.</p>
|
||||
</div>
|
||||
<div class="section" id="conditional-execution">
|
||||
<h3>Conditional Execution<a class="headerlink" href="#conditional-execution" title="Permalink to this headline">¶</a></h3>
|
||||
<p>Sometimes you will want to skip a particular step on a particular host. This could be something
|
||||
as simple as not installing a certain package if the operating system is a particular version,
|
||||
or it could be something like performing some cleanup steps if a filesystem is getting full.</p>
|
||||
<p>This is easy to do in Ansible, with the <cite>only_if</cite> clause. This clause can be applied to any task,
|
||||
and allows usage of variables from anywhere in ansible, either denoted with <cite>$dollar_sign_syntax</cite> or
|
||||
<cite>{{ braces_syntax }}</cite> and then evaluates them with a Python expression. Don’t panic – it’s actually
|
||||
pretty simple:</p>
|
||||
<div class="highlight-python"><pre>vars:
|
||||
favcolor: blue
|
||||
is_favcolor_blue: "'$favcolor' == 'blue'"
|
||||
is_centos: "'$facter_operatingsystem' == 'CentOS'"
|
||||
tasks:
|
||||
- name: "shutdown if my favorite color is blue"
|
||||
action: command /sbin/shutdown -t now
|
||||
only_if: '$is_favcolor_blue'</pre>
|
||||
</div>
|
||||
<p>Variables from tools like <cite>facter</cite> and <cite>ohai</cite> can be used here, if installed, or you can
|
||||
use variables that bubble up from ansible (0.3 and later). As a reminder,
|
||||
these variables are prefixed, so it’s <cite>$facter_operatingsystem</cite>, not <cite>$operatingsystem</cite>. Ansible’s
|
||||
built in variables are prefixed with <cite>ansible_</cite>. The only_if
|
||||
expression is actually a tiny small bit of Python, so be sure to quote variables and make something
|
||||
that evaluates to <cite>True</cite> or <cite>False</cite>. It is a good idea to use ‘vars_files’ instead of ‘vars’ to define
|
||||
all of your conditional expressions in a way that makes them very easy to reuse between plays
|
||||
and playbooks.</p>
|
||||
</div>
|
||||
<div class="section" id="conditional-imports">
|
||||
<h3>Conditional Imports<a class="headerlink" href="#conditional-imports" title="Permalink to this headline">¶</a></h3>
|
||||
<p>Sometimes you will want to do certain things differently in a playbook based on certain criteria.
|
||||
Having one playbook that works on multiple platforms and OS versions is a good example.</p>
|
||||
<p>As an example, the name of the Apache package may be different between CentOS and Debian,
|
||||
but it is easily handled with a minimum of syntax in an Ansible Playbook:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars_files:
|
||||
- "vars/common.yml"
|
||||
- [ "vars/$facter_operatingsystem.yml", "vars/os_defaults.yml" ]
|
||||
tasks:
|
||||
- name: make sure apache is running
|
||||
action: service name=$apache state=running</pre>
|
||||
</div>
|
||||
<p>Note that a variable (<cite>$facter_operatingsystem</cite>) is being interpolated into the list of
|
||||
filenames being defined for vars_files.</p>
|
||||
<p>As a reminder, the various YAML files contain just keys and values:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
# for vars/CentOS.yml
|
||||
apache: httpd
|
||||
somethingelse: 42</pre>
|
||||
</div>
|
||||
<p>How does this work? If the operating system was ‘CentOS’, the first file Ansible would try to import
|
||||
would be ‘vars/CentOS.yml’, followed up by ‘/vars/os_defaults.yml’ if that file
|
||||
did not exist. If no files in the list were found, an error would be raised.
|
||||
On Debian, it would instead first look towards ‘vars/Debian.yml’ instead of ‘vars/CentOS.yml’, before
|
||||
falling back on ‘vars/os_defaults.yml’. Pretty simple.</p>
|
||||
<p>To use this conditional import feature, you’ll need facter or ohai installed prior to running the playbook, but
|
||||
you can of course push this out with Ansible if you like:</p>
|
||||
<div class="highlight-python"><pre># for facter
|
||||
ansible -m yum -a "pkg=facter ensure=installed"
|
||||
ansible -m yum -a "pkg=ruby-json ensure=installed"
|
||||
|
||||
# for ohai
|
||||
ansible -m yum -a "pkg=ohai ensure=installed"</pre>
|
||||
</div>
|
||||
<p>Ansible’s approach to configuration – seperating variables from tasks, keeps your playbooks
|
||||
from turning into arbitrary code with ugly nested ifs, conditionals, and so on - and results
|
||||
in more streamlined & auditable configuration rules – especially because there are a
|
||||
minimum of decision points to track.</p>
|
||||
</div>
|
||||
<div class="section" id="include-files-and-reuse">
|
||||
<h3>Include Files And Reuse<a class="headerlink" href="#include-files-and-reuse" title="Permalink to this headline">¶</a></h3>
|
||||
<p>Suppose you want to reuse lists of tasks between plays or playbooks. You can use
|
||||
|
@ -543,11 +401,7 @@ contain all of my wordpress tasks in a single wordpress.yml file, and use it lik
|
|||
- include: wordpress.yml user=alice
|
||||
- include: wordpress.yml user=bob</pre>
|
||||
</div>
|
||||
<p>Variables passed in can be used in the included files. Using
|
||||
<cite>jinja2</cite> syntax, in the included file, you can reference them like this:</p>
|
||||
<div class="highlight-python"><pre>{{ user }}</pre>
|
||||
</div>
|
||||
<p>or, more simply, using Ansible’s simplified variable syntax:</p>
|
||||
<p>Variables passed in can be used in the included files. You can reference them like this:</p>
|
||||
<div class="highlight-python"><pre>$user</pre>
|
||||
</div>
|
||||
<p>In addition to the explicitly passed in parameters, all variables from
|
||||
|
@ -576,107 +430,6 @@ of a play:</p>
|
|||
with ‘vars_files’. If you find yourself needing to do this, consider how you can
|
||||
restructure your playbook to be more class/role oriented.</p>
|
||||
</div>
|
||||
<div class="section" id="using-includes-to-assign-classes-of-systems">
|
||||
<h3>Using Includes To Assign Classes of Systems<a class="headerlink" href="#using-includes-to-assign-classes-of-systems" title="Permalink to this headline">¶</a></h3>
|
||||
<p>Include files are really powerful when used to reuse logic between playbooks. You
|
||||
could imagine a playbook describing your entire infrastructure like
|
||||
this, in a list of just a few plays:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: atlanta-webservers
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/webservers.yml database=db.atlanta.com
|
||||
handlers:
|
||||
- include: handlers/common.yml
|
||||
- hosts: atlanta-dbservers
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/dbservers.yml
|
||||
handlers:
|
||||
- include: handlers/common.yml</pre>
|
||||
</div>
|
||||
<p>There is one (or more) play defined for each group of systems, and
|
||||
each play maps each group to several includes. These includes represent
|
||||
‘class definitions’, telling the systems what they are supposed to do or be.
|
||||
In the above example, all hosts get the base configuration first and further
|
||||
customize it depending on what class or nature of machines they are.</p>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Playbooks do not always have to be declarative; you can do something
|
||||
similar to model a push process for a multi-tier web application. This is
|
||||
actually one of the things playbooks were invented to do.</p>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="loop-shorthand">
|
||||
<h3>Loop Shorthand<a class="headerlink" href="#loop-shorthand" title="Permalink to this headline">¶</a></h3>
|
||||
<p>To save some typing, repeated tasks can be written in short-hand like so:</p>
|
||||
<div class="highlight-python"><pre>- name: add user $item
|
||||
action: user name=$item state=present groups=wheel
|
||||
with_items:
|
||||
- testuser1
|
||||
- testuser2</pre>
|
||||
</div>
|
||||
<p>The above would be the equivalent of:</p>
|
||||
<div class="highlight-python"><pre>- name: add user testuser1
|
||||
action: user name=testuser1 state=present groups=wheel
|
||||
- name: add user testuser2
|
||||
action: user name=testuser2 state=present groups=wheel</pre>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="asynchronous-actions-and-polling">
|
||||
<h3>Asynchronous Actions and Polling<a class="headerlink" href="#asynchronous-actions-and-polling" title="Permalink to this headline">¶</a></h3>
|
||||
<p>By default tasks in playbooks block, meaning the connections stay open
|
||||
until the task is done on each node. If executing playbooks with
|
||||
a small parallelism value (aka <tt class="docutils literal"><span class="pre">--forks</span></tt>), you may wish that long
|
||||
running operations can go faster. The easiest way to do this is
|
||||
to kick them off all at once and then poll until they are done.</p>
|
||||
<p>You will also want to use asynchronous mode on very long running
|
||||
operations that might be subject to timeout.</p>
|
||||
<p>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 <cite>poll</cite>:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 5</pre>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">There is no default for the async time limit. If you leave off the
|
||||
‘async’ keyword, the task runs synchronously, which is Ansible’s
|
||||
default.</p>
|
||||
</div>
|
||||
<p>Alternatively, if you do not need to wait on the task to complete, you may
|
||||
“fire and forget” by specifying a poll value of 0:</p>
|
||||
<div class="highlight-python"><pre>---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op, allow to run for 45, fire and forget
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 0</pre>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">You shouldn’t “fire and forget” with operations that require
|
||||
exclusive locks, such as yum transactions, if you expect to run other
|
||||
commands later in the playbook against those same resources.</p>
|
||||
</div>
|
||||
<div class="admonition note">
|
||||
<p class="first admonition-title">Note</p>
|
||||
<p class="last">Using a higher value for <tt class="docutils literal"><span class="pre">--forks</span></tt> will result in kicking off asynchronous
|
||||
tasks even faster. This also increases the efficiency of polling.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="executing-a-playbook">
|
||||
<h2>Executing A Playbook<a class="headerlink" href="#executing-a-playbook" title="Permalink to this headline">¶</a></h2>
|
||||
|
@ -689,11 +442,13 @@ Let’s run a playbook using a parallelism level of 10:</p>
|
|||
<dl class="last docutils">
|
||||
<dt><a class="reference internal" href="YAMLSyntax.html"><em>YAML Syntax</em></a></dt>
|
||||
<dd>Learn about YAML syntax</dd>
|
||||
<dt><a class="reference internal" href="playbooks2.html"><em>Advanced Playbooks</em></a></dt>
|
||||
<dd>Learn about Advanced Playbook Features</dd>
|
||||
<dt><a class="reference internal" href="modules.html"><em>Ansible Modules</em></a></dt>
|
||||
<dd>Learn about available modules</dd>
|
||||
<dt><a class="reference internal" href="moduledev.html"><em>Module Development Guide</em></a></dt>
|
||||
<dt><a class="reference internal" href="moduledev.html"><em>Module Development</em></a></dt>
|
||||
<dd>Learn how to extend Ansible by writing your own modules</dd>
|
||||
<dt><a class="reference internal" href="patterns.html"><em>The Inventory File, Patterns, and Groups</em></a></dt>
|
||||
<dt><a class="reference internal" href="patterns.html"><em>Inventory & Patterns</em></a></dt>
|
||||
<dd>Learn about how to select hosts</dd>
|
||||
<dt><a class="reference external" href="https://github.com/ansible/ansible/tree/master/examples/playbooks">Github examples directory</a></dt>
|
||||
<dd>Complete playbook files from the github project source</dd>
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Command Line Examples
|
||||
=====================
|
||||
Command Line
|
||||
============
|
||||
|
||||
The following examples show how to use `/usr/bin/ansible` for running ad-hoc tasks.
|
||||
Start here.
|
||||
|
|
35
rst/faq.rst
35
rst/faq.rst
|
@ -1,5 +1,5 @@
|
|||
Frequently Asked Questions
|
||||
==========================
|
||||
FAQ
|
||||
===
|
||||
|
||||
What inspired Ansible?
|
||||
----------------------
|
||||
|
@ -155,30 +155,37 @@ How does Ansible scale?
|
|||
+++++++++++++++++++++++
|
||||
|
||||
Whether in single-execution mode or using ansible playbooks, ansible can
|
||||
run multiple commands in seperate forks, thanks to the magic behind
|
||||
run multiple commands in seperate parallel forks, thanks to the magic behind
|
||||
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 its heritage
|
||||
is about handling those kinds of use cases.
|
||||
You can decide if you want to try to manage 5 hosts at a time, or 50 at a time.
|
||||
It's up to you and how much power you can throw at it and how fast you want
|
||||
to go.
|
||||
|
||||
There are no daemons so it's entirely up to you. When you are aren't using
|
||||
Ansible, it is not consuming any resources.
|
||||
Ansible, it is not consuming any resources, and you don't have to contend
|
||||
with a herd of machines all knocking at the door of your management server
|
||||
all at once.
|
||||
|
||||
If you have 10,000 systems, running a single ansible playbook against all of
|
||||
them probably isn't always appropriate, but most users shouldn't have any problems.
|
||||
If you want to kick off an async task/module, it's probably fine. We also
|
||||
support a local connection mode (--connection=local) that will enable pull
|
||||
based usage for those that want that. Look for future features in this area.
|
||||
them probably isn't appropriate, which is why ansible-pull exists.
|
||||
|
||||
If you'd like to discuss scaling, please hop on the mailing list.
|
||||
This tool is designed for running out of git and cron, and can scale to any
|
||||
number of hosts. Ansible-pull uses local connections versus SSH, but can be
|
||||
easily bootstrapped or reconfigured just using SSH. There is more information
|
||||
available about this in the ref:`playbooks2` section. The self-bootstrapping
|
||||
and ease of use are ansible are still retained, even when switching to the pull
|
||||
model.
|
||||
|
||||
If you'd like to discuss scaling strategies further, please hop on the mailing list.
|
||||
|
||||
Are transports other than SSH supported?
|
||||
++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Currently SSH is the only remote transport, though the interface is pluggable so a
|
||||
Currently SSH and local connections are supported. In 0.5, we'll also be including
|
||||
a faster SSH transport. The interface is actually pluggable so a
|
||||
small patch could bring transport over message bus or XMPP as an option.
|
||||
|
||||
Stop by the mailing list if you have ideas. The connection-specific parts of Ansible
|
||||
are all abstracted away from the core implementation so it is very easy to extend.
|
||||
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Downloads & Getting Started
|
||||
===========================
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
Requirements
|
||||
````````````
|
||||
|
|
|
@ -126,6 +126,7 @@ Contents
|
|||
modules
|
||||
YAMLSyntax
|
||||
playbooks
|
||||
playbooks2
|
||||
api
|
||||
moduledev
|
||||
faq
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
Module Development Guide
|
||||
========================
|
||||
Module Development
|
||||
==================
|
||||
|
||||
Ansible modules are reusable units of magic that can be used by the Ansible API,
|
||||
or by the `ansible` or `ansible-playbook` programs.
|
||||
|
|
|
@ -1,7 +1,7 @@
|
|||
.. _patterns:
|
||||
|
||||
The Inventory File, Patterns, and Groups
|
||||
========================================
|
||||
Inventory & Patterns
|
||||
====================
|
||||
|
||||
Ansible works against multiple systems in your infrastructure at the
|
||||
same time. It does this by selecting portions of systems listed in
|
||||
|
|
|
@ -97,16 +97,19 @@ The `vars` section contains a list of variables and values that can be used in t
|
|||
van_halen_port: 5150
|
||||
other: 'magic'
|
||||
|
||||
These variables can be used later in the playbook, or on the managed system (in templates), just like this::
|
||||
|
||||
{{ varname }}
|
||||
|
||||
Within playbooks themselves, but not within templates on the remote machines, it's also legal
|
||||
to use nicer shorthand like this::
|
||||
These variables can be used later in the playbook like this::
|
||||
|
||||
$varname
|
||||
|
||||
Further, if there are discovered variables about the system (ansible provides some of these,
|
||||
In templates, the full power of the Jinja2 templating language is also available, which looks like this:
|
||||
|
||||
{{ varname }}
|
||||
|
||||
The Jinja2 documentation provides information about how to construct loops and conditionals for those
|
||||
who which to use more advanced templating. This is optional and the $varname format still works in template
|
||||
files.
|
||||
|
||||
If there are discovered variables about the system (ansible provides some of these,
|
||||
plus we include ones taken from facter or ohai if installed) these variables bubble up back into the
|
||||
playbook, and can be used on each system just like explicitly set
|
||||
variables.
|
||||
|
@ -227,166 +230,6 @@ Power Tricks
|
|||
Now that you have the basics down, let's learn some more advanced
|
||||
things you can do with playbooks.
|
||||
|
||||
Local Playbooks
|
||||
+++++++++++++++
|
||||
|
||||
It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful
|
||||
for assuring the configuration of a system by putting a playbook on a crontab. This may also be used
|
||||
to run a playbook inside a OS installer, such as an Anaconda kickstart.
|
||||
|
||||
To run an entire playbook locally, just set the "hosts:" line to "hosts:127.0.0.1" and then run the playbook like so::
|
||||
|
||||
ansible-playbook playbook.yml --connection=local
|
||||
|
||||
Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook
|
||||
use the default remote connection type::
|
||||
|
||||
hosts: 127.0.0.1
|
||||
connection: local
|
||||
|
||||
Variables From Other Hosts
|
||||
++++++++++++++++++++++++++
|
||||
|
||||
If your database server wants to check the value of a 'fact' from another node, it's easy to do so
|
||||
within a template or even an action line::
|
||||
|
||||
{{ hostvars.get('name_of_host').get('name_of_fact') }}
|
||||
|
||||
NOTE: No database or other complex system is required to exchange data between hosts. The hosts that you
|
||||
want to reference data from must be included in either the current play or any previous play.
|
||||
|
||||
External Variables and Prompted or Sensitive Data
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
It's a great idea to keep your playbooks under source control, but
|
||||
you may wish to make the playbook source public while keeping certain
|
||||
important variables private. Similarly, sometimes you may just
|
||||
want to keep certain information in different files, away from
|
||||
the main playbook.
|
||||
|
||||
You can do this by using an external variables file, or files, just like this::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
favcolor: blue
|
||||
vars_files:
|
||||
- /vars/external_vars.yml
|
||||
tasks:
|
||||
- name: this is just a placeholder
|
||||
action: command /bin/echo foo
|
||||
|
||||
This removes the risk of sharing sensitive data with others when
|
||||
sharing your playbook source with them.
|
||||
|
||||
The contents of each variables file is a simple YAML dictionary, like this::
|
||||
|
||||
---
|
||||
# in the above example, this would be vars/external_vars.yml
|
||||
somevar: somevalue
|
||||
password: magic
|
||||
|
||||
Alternatively, you may wish to prompt the user for certain input, and can
|
||||
do so with the similarly named 'vars_prompt' section. This has uses
|
||||
beyond security, for instance, you may use the same playbook for all
|
||||
software releases and would prompt for a particular release version
|
||||
in a push-script::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
from: "camelot"
|
||||
vars_prompt:
|
||||
name: "what is your name?"
|
||||
quest: "what is your quest?"
|
||||
favcolor: "what is your favorite color?"
|
||||
|
||||
There are full examples of both of these items in the github examples/playbooks directory.
|
||||
|
||||
Conditional Execution
|
||||
+++++++++++++++++++++
|
||||
|
||||
Sometimes you will want to skip a particular step on a particular host. This could be something
|
||||
as simple as not installing a certain package if the operating system is a particular version,
|
||||
or it could be something like performing some cleanup steps if a filesystem is getting full.
|
||||
|
||||
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::
|
||||
|
||||
vars:
|
||||
favcolor: blue
|
||||
is_favcolor_blue: "'$favcolor' == 'blue'"
|
||||
is_centos: "'$facter_operatingsystem' == 'CentOS'"
|
||||
tasks:
|
||||
- name: "shutdown if my favorite color is blue"
|
||||
action: command /sbin/shutdown -t now
|
||||
only_if: '$is_favcolor_blue'
|
||||
|
||||
Variables from tools like `facter` and `ohai` can be used here, if installed, or you can
|
||||
use variables that bubble up from ansible (0.3 and later). As a reminder,
|
||||
these variables are prefixed, so it's `$facter_operatingsystem`, not `$operatingsystem`. Ansible's
|
||||
built in variables are prefixed with `ansible_`. The only_if
|
||||
expression is actually a tiny small bit of Python, so be sure to quote variables and make something
|
||||
that evaluates to `True` or `False`. It is a good idea to use 'vars_files' instead of 'vars' to define
|
||||
all of your conditional expressions in a way that makes them very easy to reuse between plays
|
||||
and playbooks.
|
||||
|
||||
|
||||
Conditional Imports
|
||||
+++++++++++++++++++
|
||||
|
||||
Sometimes you will want to do certain things differently in a playbook based on certain criteria.
|
||||
Having one playbook that works on multiple platforms and OS versions is a good example.
|
||||
|
||||
As an example, the name of the Apache package may be different between CentOS and Debian,
|
||||
but it is easily handled with a minimum of syntax in an Ansible Playbook::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars_files:
|
||||
- "vars/common.yml"
|
||||
- [ "vars/$facter_operatingsystem.yml", "vars/os_defaults.yml" ]
|
||||
tasks:
|
||||
- name: make sure apache is running
|
||||
action: service name=$apache state=running
|
||||
|
||||
Note that a variable (`$facter_operatingsystem`) is being interpolated into the list of
|
||||
filenames being defined for vars_files.
|
||||
|
||||
As a reminder, the various YAML files contain just keys and values::
|
||||
|
||||
---
|
||||
# for vars/CentOS.yml
|
||||
apache: httpd
|
||||
somethingelse: 42
|
||||
|
||||
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
|
||||
would be 'vars/CentOS.yml', followed up by '/vars/os_defaults.yml' if that file
|
||||
did not exist. If no files in the list were found, an error would be raised.
|
||||
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
|
||||
falling back on 'vars/os_defaults.yml'. Pretty simple.
|
||||
|
||||
To use this conditional import feature, you'll need facter or ohai installed prior to running the playbook, but
|
||||
you can of course push this out with Ansible if you like::
|
||||
|
||||
# for facter
|
||||
ansible -m yum -a "pkg=facter ensure=installed"
|
||||
ansible -m yum -a "pkg=ruby-json ensure=installed"
|
||||
|
||||
# for ohai
|
||||
ansible -m yum -a "pkg=ohai ensure=installed"
|
||||
|
||||
Ansible's approach to configuration -- seperating variables from tasks, keeps your playbooks
|
||||
from turning into arbitrary code with ugly nested ifs, conditionals, and so on - and results
|
||||
in more streamlined & auditable configuration rules -- especially because there are a
|
||||
minimum of decision points to track.
|
||||
|
||||
|
||||
Include Files And Reuse
|
||||
+++++++++++++++++++++++
|
||||
|
||||
|
@ -417,13 +260,8 @@ contain all of my wordpress tasks in a single wordpress.yml file, and use it lik
|
|||
- include: wordpress.yml user=alice
|
||||
- include: wordpress.yml user=bob
|
||||
|
||||
Variables passed in can be used in the included files. Using
|
||||
`jinja2` syntax, in the included file, you can reference them like this::
|
||||
Variables passed in can be used in the included files. You can reference them like this::
|
||||
|
||||
{{ user }}
|
||||
|
||||
or, more simply, using Ansible's simplified variable syntax::
|
||||
|
||||
$user
|
||||
|
||||
In addition to the explicitly passed in parameters, all variables from
|
||||
|
@ -456,111 +294,6 @@ with 'vars_files'. If you find yourself needing to do this, consider how you ca
|
|||
restructure your playbook to be more class/role oriented.
|
||||
|
||||
|
||||
Using Includes To Assign Classes of Systems
|
||||
+++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Include files are really powerful when used to reuse logic between playbooks. You
|
||||
could imagine a playbook describing your entire infrastructure like
|
||||
this, in a list of just a few plays::
|
||||
|
||||
---
|
||||
- hosts: atlanta-webservers
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/webservers.yml database=db.atlanta.com
|
||||
handlers:
|
||||
- include: handlers/common.yml
|
||||
- hosts: atlanta-dbservers
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/dbservers.yml
|
||||
handlers:
|
||||
- include: handlers/common.yml
|
||||
|
||||
There is one (or more) play defined for each group of systems, and
|
||||
each play maps each group to several includes. These includes represent
|
||||
'class definitions', telling the systems what they are supposed to do or be.
|
||||
In the above example, all hosts get the base configuration first and further
|
||||
customize it depending on what class or nature of machines they are.
|
||||
|
||||
.. note::
|
||||
Playbooks do not always have to be declarative; you can do something
|
||||
similar to model a push process for a multi-tier web application. This is
|
||||
actually one of the things playbooks were invented to do.
|
||||
|
||||
Loop Shorthand
|
||||
++++++++++++++
|
||||
|
||||
To save some typing, repeated tasks can be written in short-hand like so::
|
||||
|
||||
- name: add user $item
|
||||
action: user name=$item state=present groups=wheel
|
||||
with_items:
|
||||
- testuser1
|
||||
- testuser2
|
||||
|
||||
The above would be the equivalent of::
|
||||
|
||||
- name: add user testuser1
|
||||
action: user name=testuser1 state=present groups=wheel
|
||||
- name: add user testuser2
|
||||
action: user name=testuser2 state=present groups=wheel
|
||||
|
||||
Asynchronous Actions and Polling
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
By default tasks in playbooks block, meaning the connections stay open
|
||||
until the task is done on each node. If executing playbooks with
|
||||
a small parallelism value (aka ``--forks``), you may wish that long
|
||||
running operations can go faster. The easiest way to do this is
|
||||
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 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`::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 5
|
||||
|
||||
.. note::
|
||||
There is no default for the async time limit. If you leave off the
|
||||
'async' keyword, the task runs synchronously, which is Ansible's
|
||||
default.
|
||||
|
||||
Alternatively, if you do not need to wait on the task to complete, you may
|
||||
"fire and forget" by specifying a poll value of 0::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op, allow to run for 45, fire and forget
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 0
|
||||
|
||||
.. note::
|
||||
You shouldn't "fire and forget" with operations that require
|
||||
exclusive locks, such as yum transactions, if you expect to run other
|
||||
commands later in the playbook against those same resources.
|
||||
|
||||
.. note::
|
||||
Using a higher value for ``--forks`` will result in kicking off asynchronous
|
||||
tasks even faster. This also increases the efficiency of polling.
|
||||
|
||||
Executing A Playbook
|
||||
````````````````````
|
||||
|
||||
|
@ -573,6 +306,8 @@ Let's run a playbook using a parallelism level of 10::
|
|||
|
||||
:doc:`YAMLSyntax`
|
||||
Learn about YAML syntax
|
||||
:doc:`playbooks2`
|
||||
Learn about Advanced Playbook Features
|
||||
:doc:`modules`
|
||||
Learn about available modules
|
||||
:doc:`moduledev`
|
||||
|
|
352
rst/playbooks2.rst
Normal file
352
rst/playbooks2.rst
Normal file
|
@ -0,0 +1,352 @@
|
|||
Advanced Playbooks
|
||||
==================
|
||||
|
||||
Here are some advanced features of the playbooks language. Using all of these features
|
||||
are not neccessary, but many of them will prove useful.
|
||||
|
||||
Local Playbooks
|
||||
+++++++++++++++
|
||||
|
||||
It may be useful to use a playbook locally, rather than by connecting over SSH. This can be useful
|
||||
for assuring the configuration of a system by putting a playbook on a crontab. This may also be used
|
||||
to run a playbook inside a OS installer, such as an Anaconda kickstart.
|
||||
|
||||
To run an entire playbook locally, just set the "hosts:" line to "hosts:127.0.0.1" and then run the playbook like so::
|
||||
|
||||
ansible-playbook playbook.yml --connection=local
|
||||
|
||||
Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook
|
||||
use the default remote connection type::
|
||||
|
||||
hosts: 127.0.0.1
|
||||
connection: local
|
||||
|
||||
Pull-Mode Playbooks
|
||||
+++++++++++++++++++
|
||||
|
||||
The use of playbooks in local mode (above) is made extremely powerful with the addition of `ansible-pull` in the
|
||||
0.4 release. A script for setting up ansible-pull is provided in the examples/playbooks directory of the source
|
||||
checkout.
|
||||
|
||||
The basic idea is to use Ansible to set up a remote copy of ansible on each managed node, each set to run via
|
||||
cron and update playbook source via git. This interverts the default push architecture of ansible into a pull
|
||||
architecture, which has near-limitless scaling potential. The setup playbook can be tuned to change
|
||||
the cron frequency, logging locations, and parameters to ansible-pull.
|
||||
|
||||
Accessing Hash and Array Variable Data
|
||||
++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Some provided facts, like networking information, are made available as nested datastructures. To access
|
||||
them a simple '$foo' is not sufficient, but it is still easy to do. Here's how we get an IP address using
|
||||
Ansible 0.4 and later::
|
||||
|
||||
${ansible_eth0.ipv4.address}
|
||||
|
||||
It is also possible to access variables whose elements are arrays::
|
||||
|
||||
${somelist[1]}
|
||||
|
||||
And the array and hash reference syntaxes can be mixed.
|
||||
|
||||
Accessing Variables From Other Hosts
|
||||
++++++++++++++++++++++++++++++++++++
|
||||
|
||||
If your database server wants to check the value of a 'fact' from another node, or an inventory variable
|
||||
assigned to another node, it's easy to do so within a template or even an action line (note: this uses syntax available in 0.4 and later)::
|
||||
|
||||
${hostvars.hostname.factname}
|
||||
|
||||
NOTE: No database or other complex system is required to exchange data between hosts. The hosts that you
|
||||
want to reference data from must be included in either the current play or any previous play.
|
||||
|
||||
External Variables and Prompted or Sensitive Data
|
||||
+++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
It's a great idea to keep your playbooks under source control, but
|
||||
you may wish to make the playbook source public while keeping certain
|
||||
important variables private. Similarly, sometimes you may just
|
||||
want to keep certain information in different files, away from
|
||||
the main playbook.
|
||||
|
||||
You can do this by using an external variables file, or files, just like this::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
favcolor: blue
|
||||
vars_files:
|
||||
- /vars/external_vars.yml
|
||||
tasks:
|
||||
- name: this is just a placeholder
|
||||
action: command /bin/echo foo
|
||||
|
||||
This removes the risk of sharing sensitive data with others when
|
||||
sharing your playbook source with them.
|
||||
|
||||
The contents of each variables file is a simple YAML dictionary, like this::
|
||||
|
||||
---
|
||||
# in the above example, this would be vars/external_vars.yml
|
||||
somevar: somevalue
|
||||
password: magic
|
||||
|
||||
Prompting For Sensitive Data
|
||||
++++++++++++++++++++++++++++
|
||||
|
||||
You may wish to prompt the user for certain input, and can
|
||||
do so with the similarly named 'vars_prompt' section. This has uses
|
||||
beyond security, for instance, you may use the same playbook for all
|
||||
software releases and would prompt for a particular release version
|
||||
in a push-script::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars:
|
||||
from: "camelot"
|
||||
vars_prompt:
|
||||
name: "what is your name?"
|
||||
quest: "what is your quest?"
|
||||
favcolor: "what is your favorite color?"
|
||||
|
||||
There are full examples of both of these items in the github examples/playbooks directory.
|
||||
|
||||
Passing Variables On The Command Line
|
||||
+++++++++++++++++++++++++++++++++++++
|
||||
|
||||
In addition to `vars_prompt` and `vars_files`, it is possible to send variables over
|
||||
the ansible command line. This is particularly useful when writing a generic release playbook
|
||||
where you may want to pass in the version of the application to deploy::
|
||||
|
||||
ansible-playbook release.yml --extra-vars "version=1.23.45 other_variable=foo"
|
||||
|
||||
Conditional Execution
|
||||
+++++++++++++++++++++
|
||||
|
||||
Sometimes you will want to skip a particular step on a particular host. This could be something
|
||||
as simple as not installing a certain package if the operating system is a particular version,
|
||||
or it could be something like performing some cleanup steps if a filesystem is getting full.
|
||||
|
||||
This is easy to do in Ansible, with the `only_if` clause, which actually is a Python expression.
|
||||
Don't panic -- it's actually pretty simple::
|
||||
|
||||
vars:
|
||||
favcolor: blue
|
||||
is_favcolor_blue: "'$favcolor' == 'blue'"
|
||||
is_centos: "'$facter_operatingsystem' == 'CentOS'"
|
||||
tasks:
|
||||
- name: "shutdown if my favorite color is blue"
|
||||
action: command /sbin/shutdown -t now
|
||||
only_if: '$is_favcolor_blue'
|
||||
|
||||
Variables from tools like `facter` and `ohai` can be used here, if installed, or you can
|
||||
use variables that bubble up from ansible (0.3 and later). As a reminder,
|
||||
these variables are prefixed, so it's `$facter_operatingsystem`, not `$operatingsystem`. Ansible's
|
||||
built in variables are prefixed with `ansible_`. The only_if
|
||||
expression is actually a tiny small bit of Python, so be sure to quote variables and make something
|
||||
that evaluates to `True` or `False`. It is a good idea to use 'vars_files' instead of 'vars' to define
|
||||
all of your conditional expressions in a way that makes them very easy to reuse between plays
|
||||
and playbooks.
|
||||
|
||||
|
||||
Conditional Imports
|
||||
+++++++++++++++++++
|
||||
|
||||
Sometimes you will want to do certain things differently in a playbook based on certain criteria.
|
||||
Having one playbook that works on multiple platforms and OS versions is a good example.
|
||||
|
||||
As an example, the name of the Apache package may be different between CentOS and Debian,
|
||||
but it is easily handled with a minimum of syntax in an Ansible Playbook::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
vars_files:
|
||||
- "vars/common.yml"
|
||||
- [ "vars/$facter_operatingsystem.yml", "vars/os_defaults.yml" ]
|
||||
tasks:
|
||||
- name: make sure apache is running
|
||||
action: service name=$apache state=running
|
||||
|
||||
Note that a variable (`$facter_operatingsystem`) is being interpolated into the list of
|
||||
filenames being defined for vars_files.
|
||||
|
||||
As a reminder, the various YAML files contain just keys and values::
|
||||
|
||||
---
|
||||
# for vars/CentOS.yml
|
||||
apache: httpd
|
||||
somethingelse: 42
|
||||
|
||||
How does this work? If the operating system was 'CentOS', the first file Ansible would try to import
|
||||
would be 'vars/CentOS.yml', followed up by '/vars/os_defaults.yml' if that file
|
||||
did not exist. If no files in the list were found, an error would be raised.
|
||||
On Debian, it would instead first look towards 'vars/Debian.yml' instead of 'vars/CentOS.yml', before
|
||||
falling back on 'vars/os_defaults.yml'. Pretty simple.
|
||||
|
||||
To use this conditional import feature, you'll need facter or ohai installed prior to running the playbook, but
|
||||
you can of course push this out with Ansible if you like::
|
||||
|
||||
# for facter
|
||||
ansible -m yum -a "pkg=facter ensure=installed"
|
||||
ansible -m yum -a "pkg=ruby-json ensure=installed"
|
||||
|
||||
# for ohai
|
||||
ansible -m yum -a "pkg=ohai ensure=installed"
|
||||
|
||||
Ansible's approach to configuration -- seperating variables from tasks, keeps your playbooks
|
||||
from turning into arbitrary code with ugly nested ifs, conditionals, and so on - and results
|
||||
in more streamlined & auditable configuration rules -- especially because there are a
|
||||
minimum of decision points to track.
|
||||
|
||||
|
||||
Using Includes To Assign Classes of Systems
|
||||
+++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Include files are really powerful when used to reuse logic between playbooks. You
|
||||
could imagine a playbook describing your entire infrastructure like
|
||||
this, in a list of just a few plays::
|
||||
|
||||
---
|
||||
|
||||
- hosts: atlanta-webservers
|
||||
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
database: db.atlanta.com
|
||||
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/webservers.yml
|
||||
|
||||
handlers:
|
||||
- include: handlers/common.yml
|
||||
|
||||
- hosts: atlanta-dbservers
|
||||
|
||||
vars:
|
||||
datacenter: atlanta
|
||||
|
||||
tasks:
|
||||
- include: tasks/base.yml
|
||||
- include: tasks/dbservers.yml
|
||||
|
||||
handlers:
|
||||
- include: handlers/common.yml
|
||||
|
||||
There is one (or more) play defined for each group of systems, and
|
||||
each play maps each group to several includes. These includes represent
|
||||
'class definitions', telling the systems what they are supposed to do or be.
|
||||
In the above example, all hosts get the base configuration first and further
|
||||
customize it depending on what class or nature of machines they are.
|
||||
|
||||
|
||||
Loop Shorthand
|
||||
++++++++++++++
|
||||
|
||||
To save some typing, repeated tasks can be written in short-hand like so::
|
||||
|
||||
- name: add user $item
|
||||
action: user name=$item state=present groups=wheel
|
||||
with_items:
|
||||
- testuser1
|
||||
- testuser2
|
||||
|
||||
The above would be the equivalent of::
|
||||
|
||||
- name: add user testuser1
|
||||
action: user name=testuser1 state=present groups=wheel
|
||||
- name: add user testuser2
|
||||
action: user name=testuser2 state=present groups=wheel
|
||||
|
||||
In a future release, the yum and apt modules will use with_items to execute fewer package
|
||||
manager transactions.
|
||||
|
||||
|
||||
Selecting Files And Templates Based On Variables
|
||||
++++++++++++++++++++++++++++++++++++++++++++++++
|
||||
|
||||
Sometimes a configuration file you want to copy, or a template you will use may depend on a variable.
|
||||
The following construct (new in 0.4) selects the first available file appropriate for the variables of a given host,
|
||||
which is often much cleaner than putting a lot of if conditionals in a template.
|
||||
|
||||
The following example shows how to template out a configuration file that was very different between, say,
|
||||
CentOS and Debian.
|
||||
|
||||
- name: template a file
|
||||
action: template src=$item dest=/etc/myapp/foo.conf
|
||||
first_available_file:
|
||||
- /srv/templates/myapp/${ansible_distribution}.conf
|
||||
- /srv/templates/myapp/default.conf
|
||||
|
||||
|
||||
Asynchronous Actions and Polling
|
||||
++++++++++++++++++++++++++++++++
|
||||
|
||||
By default tasks in playbooks block, meaning the connections stay open
|
||||
until the task is done on each node. If executing playbooks with
|
||||
a small parallelism value (aka ``--forks``), you may wish that long
|
||||
running operations can go faster. The easiest way to do this is
|
||||
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 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`::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op (15 sec), wait for up to 45, poll every 5
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 5
|
||||
|
||||
.. note::
|
||||
There is no default for the async time limit. If you leave off the
|
||||
'async' keyword, the task runs synchronously, which is Ansible's
|
||||
default.
|
||||
|
||||
Alternatively, if you do not need to wait on the task to complete, you may
|
||||
"fire and forget" by specifying a poll value of 0::
|
||||
|
||||
---
|
||||
- hosts: all
|
||||
user: root
|
||||
tasks:
|
||||
- name: simulate long running op, allow to run for 45, fire and forget
|
||||
action: command /bin/sleep 15
|
||||
async: 45
|
||||
poll: 0
|
||||
|
||||
.. note::
|
||||
You shouldn't "fire and forget" with operations that require
|
||||
exclusive locks, such as yum transactions, if you expect to run other
|
||||
commands later in the playbook against those same resources.
|
||||
|
||||
.. note::
|
||||
Using a higher value for ``--forks`` will result in kicking off asynchronous
|
||||
tasks even faster. This also increases the efficiency of polling.
|
||||
|
||||
.. seealso::
|
||||
|
||||
:doc:`YAMLSyntax`
|
||||
Learn about YAML syntax
|
||||
:doc:`playbooks`
|
||||
Review the basic playbook features
|
||||
:doc:`modules`
|
||||
Learn about available modules
|
||||
:doc:`moduledev`
|
||||
Learn how to extend Ansible by writing your own modules
|
||||
:doc:`patterns`
|
||||
Learn about how to select hosts
|
||||
`Github examples directory <https://github.com/ansible/ansible/tree/master/examples/playbooks>`_
|
||||
Complete playbook files from the github project source
|
||||
`Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
Questions? Help? Ideas? Stop by the list on Google Groups
|
||||
|
||||
|
|
@ -133,14 +133,15 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="index.html"
|
||||
class="dropdown-toggle">Chapter</a>
|
||||
<span class="globaltoc"><ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Downloads & Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">The Inventory File, Patterns, and Groups</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line Examples</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development Guide</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">Frequently Asked Questions</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
|
|
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue