mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
271 lines
No EOL
13 KiB
HTML
271 lines
No EOL
13 KiB
HTML
|
|
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
|
|
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
|
|
|
<title>Playbooks: Ansible for Deployment, Configuration Management, and Orchestration — Ansible v0.0.1 documentation</title>
|
|
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
|
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
|
<script type="text/javascript">
|
|
var DOCUMENTATION_OPTIONS = {
|
|
URL_ROOT: '',
|
|
VERSION: '0.0.1',
|
|
COLLAPSE_INDEX: false,
|
|
FILE_SUFFIX: '.html',
|
|
HAS_SOURCE: true
|
|
};
|
|
</script>
|
|
<script type="text/javascript" src="_static/jquery.js"></script>
|
|
<script type="text/javascript" src="_static/underscore.js"></script>
|
|
<script type="text/javascript" src="_static/doctools.js"></script>
|
|
<link rel="top" title="Ansible v0.0.1 documentation" href="index.html" />
|
|
<link rel="next" title="API" href="api.html" />
|
|
<link rel="prev" title="YAML Format" href="YAMLScripts.html" />
|
|
</head>
|
|
<body>
|
|
<div class="related">
|
|
<h3>Navigation</h3>
|
|
<ul>
|
|
<li class="right" style="margin-right: 10px">
|
|
<a href="genindex.html" title="General Index"
|
|
accesskey="I">index</a></li>
|
|
<li class="right" >
|
|
<a href="api.html" title="API"
|
|
accesskey="N">next</a> |</li>
|
|
<li class="right" >
|
|
<a href="YAMLScripts.html" title="YAML Format"
|
|
accesskey="P">previous</a> |</li>
|
|
<li><a href="index.html">Ansible v0.0.1 documentation</a> »</li>
|
|
</ul>
|
|
</div>
|
|
|
|
<div class="document">
|
|
<div class="documentwrapper">
|
|
<div class="bodywrapper">
|
|
<div class="body">
|
|
|
|
<div class="section" id="playbooks-ansible-for-deployment-configuration-management-and-orchestration">
|
|
<h1>Playbooks: Ansible for Deployment, Configuration Management, and Orchestration<a class="headerlink" href="#playbooks-ansible-for-deployment-configuration-management-and-orchestration" title="Permalink to this headline">¶</a></h1>
|
|
<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="YAMLScripts.html"><em>YAML Format</em></a></dt>
|
|
<dd>Learn about YAML syntax</dd>
|
|
<dt><a class="reference internal" href="modules.html"><em>Ansible Modules</em></a></dt>
|
|
<dd>Learn about available modules and writing your own</dd>
|
|
<dt><a class="reference internal" href="patterns.html"><em>The Inventory File, Patterns, and Groups</em></a></dt>
|
|
<dd>Learn about how to select hosts</dd>
|
|
</dl>
|
|
</div>
|
|
<p>Playbooks are a completely different way to use ansible and are particularly awesome.</p>
|
|
<p>They are the basis for a really simple configuration management and multi-machine deployment system, unlike any that already exist, and one that is very well suited to deploying complex applications.</p>
|
|
<p>While you might run the main /usr/bin/ansible program for ad-hoc tasks, playbooks are more likely to be kept in source control and used to push out your configuration or assure the configurations of your remote systems are in spec.</p>
|
|
<div class="section" id="playbook-example">
|
|
<h2>Playbook Example<a class="headerlink" href="#playbook-example" title="Permalink to this headline">¶</a></h2>
|
|
<p>Playbooks are expressed in YAML format and have a minimum of syntax. Each playbook is composed
|
|
of one or more ‘plays’ in a list. By composing a playbook of multiple ‘plays’, it is possible
|
|
to orchestrate multi-machine deployments, running certain steps on all machines in
|
|
the webservers group, then certain steps on the database server group, then more commands
|
|
back on the webservers group, etc:</p>
|
|
<div class="highlight-python"><pre>---
|
|
- hosts: webservers
|
|
vars:
|
|
http_port: 80
|
|
max_clients: 200
|
|
user: root
|
|
tasks:
|
|
- include: base.yml somevar=3 othervar=4
|
|
- name: write the apache config file
|
|
action: template src=/srv/httpd.j2 dest=/etc/httpd.conf
|
|
notify:
|
|
- restart apache
|
|
- name: ensure apache is running
|
|
action: service name=httpd state=started
|
|
handlers:
|
|
- include: handlers.yml</pre>
|
|
</div>
|
|
</div>
|
|
<div class="section" id="hosts-line">
|
|
<h2>Hosts line<a class="headerlink" href="#hosts-line" title="Permalink to this headline">¶</a></h2>
|
|
<p>The hosts line is a list of one or more groups or host patterns, seperated by colons, as
|
|
described in the ‘patterns’ documentation. This is just like the first parameter to /usr/bin/ansible.</p>
|
|
</div>
|
|
<div class="section" id="vars-section">
|
|
<h2>Vars section<a class="headerlink" href="#vars-section" title="Permalink to this headline">¶</a></h2>
|
|
<p>A list of variables and values that can be used in the plays. These can be used in templates
|
|
or ‘action’ lines and are dereferenced using <tt class="docutils literal"><span class="pre">`jinja2`</span></tt> syntax like this:</p>
|
|
<blockquote>
|
|
<div>{{ varname }}</div></blockquote>
|
|
<p>Further, if there are discovered variables about the system (say, if facter or ohai were
|
|
installed) these variables bubble up back into the playbook, and can be used on each
|
|
system just like explicitly set variables. Facter variables are prefixed with ‘<a href="#id1"><span class="problematic" id="id2">facter_</span></a>‘
|
|
and Ohai variables are prefixed with ‘<a href="#id3"><span class="problematic" id="id4">ohai_</span></a>‘. So for instance, if I wanted to write the
|
|
hostname into the /etc/motd file, I could say:</p>
|
|
<blockquote>
|
|
<div><ul class="simple">
|
|
<li>name: write the motd</li>
|
|
<li>action: template src=/srv/templates/motd.j2 dest=/etc/motd</li>
|
|
</ul>
|
|
</div></blockquote>
|
|
<p>And in /srv/templates/motd.j2::</p>
|
|
<div class="highlight-python"><pre>You are logged into {{ facter_hostname }}</pre>
|
|
</div>
|
|
<p>But we’re getting ahead of ourselves. Let’s talk about tasks.</p>
|
|
</div>
|
|
<div class="section" id="tasks-list">
|
|
<h2>Tasks list<a class="headerlink" href="#tasks-list" title="Permalink to this headline">¶</a></h2>
|
|
<p>Each play contains a list of tasks. Tasks are executed in order, one at a time, against
|
|
all machines matched by the play’s host pattern, before moving on to the next task.</p>
|
|
<p>Hosts with failed tasks are taken out of the rotation for the entire playbook. If things fail,
|
|
simply correct the playbook file and rerun.</p>
|
|
<p>Modules other than command are idempotent, meaning if you run them again, they will make the
|
|
changes they are told to make to bring the system to the desired state.</p>
|
|
</div>
|
|
<div class="section" id="task-name-and-action">
|
|
<h2>Task name and action<a class="headerlink" href="#task-name-and-action" title="Permalink to this headline">¶</a></h2>
|
|
<p>Every task must have a name, which is included in the output from running the playbook.</p>
|
|
<p>The action line is the name of an ansible module followed by parameters. Usually these
|
|
are expressed in key=value form, except for the command module, which looks just like a Linux/Unix
|
|
command line. See the module documentation for more info.</p>
|
|
<p>Variables, as mentioned above, can be used in action lines. So if, hypothetically, you wanted
|
|
to make a directory on each system named after the hostname ... yeah, that’s I know silly ... you could
|
|
do it like so:</p>
|
|
<blockquote>
|
|
<div><ul class="simple">
|
|
<li>name: make a directory</li>
|
|
<li>action: mkdir /tmp/{{ facter_hostname }}</li>
|
|
</ul>
|
|
</div></blockquote>
|
|
</div>
|
|
<div class="section" id="notify-statements">
|
|
<h2>Notify statements<a class="headerlink" href="#notify-statements" title="Permalink to this headline">¶</a></h2>
|
|
<p>Nearly all modules are written to be ‘idempotent’ and can signal when they have affected a change
|
|
on the remote system. If a notify statement is used, the named handler will be run against
|
|
each system where a change was effected, but NOT on systems where no change occurred. This happens
|
|
after all of the tasks are run. For example, if notifying Apache and potentially replacing lots of
|
|
configuration files, you could have Apache restart just once, at the end of a run. If you need
|
|
Apache restarted in the middle of a run, you could just make a task for it, no harm done. Notifiers
|
|
are optional.</p>
|
|
</div>
|
|
<div class="section" id="handlers">
|
|
<h2>Handlers<a class="headerlink" href="#handlers" title="Permalink to this headline">¶</a></h2>
|
|
<p>Handlers are lists of tasks, not really any different from regular tasks, that are referenced
|
|
by name. Handlers are what notifiers notify. If nothing notifies a handler, it will not run.
|
|
Regardless of how many things notify a handler, it will run only once, after all of the tasks
|
|
complete in a particular play.</p>
|
|
</div>
|
|
<div class="section" id="includes">
|
|
<h2>Includes<a class="headerlink" href="#includes" title="Permalink to this headline">¶</a></h2>
|
|
<p>Not all tasks have to be listed directly in the main file. An include file can contain
|
|
a list of tasks (in YAML) as well, optionally passing extra variables into the file.
|
|
Variables passed in can be deferenced like this (assume a variable named ‘user’)</p>
|
|
<blockquote>
|
|
<div>{{ user }}</div></blockquote>
|
|
<p>For instance, if deploying multiple wordpress instances, I could contain all of my tasks
|
|
in a wordpress.yml file, and use it like so:</p>
|
|
<blockquote>
|
|
<div><ul>
|
|
<li><dl class="first docutils">
|
|
<dt>tasks:</dt>
|
|
<dd><ul class="first last simple">
|
|
<li>include: wordpress.yml user=timmy</li>
|
|
<li>include: wordpress.yml user=alice</li>
|
|
<li>include: wordpress.yml user=bob</li>
|
|
</ul>
|
|
</dd>
|
|
</dl>
|
|
</li>
|
|
</ul>
|
|
</div></blockquote>
|
|
<p>In addition to the explicitly passed in parameters, all variables from the vars section
|
|
are also available.</p>
|
|
</div>
|
|
<div class="section" id="asynchronous-actions-and-polling">
|
|
<h2>Asynchronous Actions and Polling<a class="headerlink" href="#asynchronous-actions-and-polling" title="Permalink to this headline">¶</a></h2>
|
|
<p>(Information on this feature is pending)</p>
|
|
</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>
|
|
<p>To run a playbook:</p>
|
|
<div class="highlight-python"><pre>ansible-playbook playbook.yml</pre>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="sphinxsidebar">
|
|
<div class="sphinxsidebarwrapper">
|
|
<h3><a href="index.html">Table Of Contents</a></h3>
|
|
<ul>
|
|
<li><a class="reference internal" href="#">Playbooks: Ansible for Deployment, Configuration Management, and Orchestration</a><ul>
|
|
<li><a class="reference internal" href="#playbook-example">Playbook Example</a></li>
|
|
<li><a class="reference internal" href="#hosts-line">Hosts line</a></li>
|
|
<li><a class="reference internal" href="#vars-section">Vars section</a></li>
|
|
<li><a class="reference internal" href="#tasks-list">Tasks list</a></li>
|
|
<li><a class="reference internal" href="#task-name-and-action">Task name and action</a></li>
|
|
<li><a class="reference internal" href="#notify-statements">Notify statements</a></li>
|
|
<li><a class="reference internal" href="#handlers">Handlers</a></li>
|
|
<li><a class="reference internal" href="#includes">Includes</a></li>
|
|
<li><a class="reference internal" href="#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
|
|
<li><a class="reference internal" href="#executing-a-playbook">Executing A Playbook</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<h4>Previous topic</h4>
|
|
<p class="topless"><a href="YAMLScripts.html"
|
|
title="previous chapter">YAML Format</a></p>
|
|
<h4>Next topic</h4>
|
|
<p class="topless"><a href="api.html"
|
|
title="next chapter">API</a></p>
|
|
<h3>This Page</h3>
|
|
<ul class="this-page-menu">
|
|
<li><a href="_sources/playbooks.txt"
|
|
rel="nofollow">Show Source</a></li>
|
|
</ul>
|
|
<div id="searchbox" style="display: none">
|
|
<h3>Quick search</h3>
|
|
<form class="search" action="search.html" method="get">
|
|
<input type="text" name="q" />
|
|
<input type="submit" value="Go" />
|
|
<input type="hidden" name="check_keywords" value="yes" />
|
|
<input type="hidden" name="area" value="default" />
|
|
</form>
|
|
<p class="searchtip" style="font-size: 90%">
|
|
Enter search terms or a module, class or function name.
|
|
</p>
|
|
</div>
|
|
<script type="text/javascript">$('#searchbox').show(0);</script>
|
|
</div>
|
|
</div>
|
|
<div class="clearer"></div>
|
|
</div>
|
|
<div class="related">
|
|
<h3>Navigation</h3>
|
|
<ul>
|
|
<li class="right" style="margin-right: 10px">
|
|
<a href="genindex.html" title="General Index"
|
|
>index</a></li>
|
|
<li class="right" >
|
|
<a href="api.html" title="API"
|
|
>next</a> |</li>
|
|
<li class="right" >
|
|
<a href="YAMLScripts.html" title="YAML Format"
|
|
>previous</a> |</li>
|
|
<li><a href="index.html">Ansible v0.0.1 documentation</a> »</li>
|
|
</ul>
|
|
</div>
|
|
<div class="footer">
|
|
© Copyright 2012 Michael DeHaan.
|
|
Last updated on Mar 08, 2012.
|
|
Created using <a href="http://sphinx.pocoo.org/">Sphinx</a> 1.0.8.
|
|
</div>
|
|
</body>
|
|
</html> |