@ -11,21 +11,28 @@ Playbooks: Ansible for Deployment, Configuration Management, and Orchestration
Learn about how to select hosts
Playbooks are a completely different way to use ansible and are particularly awesome.
Playbooks are a completely different way to use ansible and are
particularly awesome.
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.
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.
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.
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.
Playbook Example
````````````````
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::
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::
---
- hosts: webservers
@ -47,21 +54,25 @@ back on the webservers group, etc::
Hosts line
``````````
The hosts line is a list of one or more groups or host patterns, seperated by colons, asdescribed in the 'patterns' documentation. This is just like the first parameter to /usr/bin/ansible.
The hosts line is a list of one or more groups or host patterns,
seperated by colons, asdescribed in the :ref:`patterns` documentation.
This is just like the first parameter to ``/usr/bin/ansible``.
Vars section
````````````
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 ```jinja2``` syntax like this::
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
```jinja2``` syntax like this::
{{ varname }}
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 'facter_'
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
hostname into the /etc/motd file, I could say::
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 ``facter_`` and Ohai
variables are prefixed with ``ohai_``. So for instance, if I wanted
to write the hostname into the /etc/motd file, I could say::
<liclass="toctree-l1"><aclass="reference internal"href="playbooks.html">Playbooks: Ansible for Deployment, Configuration Management, and Orchestration</a><ul>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-modules</title><linkrel="stylesheet" href="./docbook-xsl.css" type="text/css" /><metaname="generator"content="DocBook XSL Stylesheets V1.75.2" /></head><body><divxml:lang="en"class="refentry"title="ansible-modules"lang="en"><aid="id373277"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-modules — stock modules shipped with ansible</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p>Ansible ships with a number of modules that can be executed directly on remote hosts or through
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-modules</title><linkrel="stylesheet"type="text/css"href="./docbook-xsl.css" /><metaname="generator"content="DocBook XSL Stylesheets V1.76.1" /></head><body><divxml:lang="en"class="refentry"title="ansible-modules"lang="en"><aid="id434580"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-modules — stock modules shipped with ansible</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p>Ansible ships with a number of modules that can be executed directly on remote hosts or through
ansible playbooks.</p></div><divclass="refsect1"title="IDEMPOTENCE"><aid="_idempotence"></a><h2>IDEMPOTENCE</h2><p>Most modules other than command are idempotent, meaning they will seek to avoid changes
unless a change needs to be made. When using ansible playbooks, these modules can
trigger change events, as described in <spanclass="strong"><strong>ansible-playbooks</strong></span>(5).</p><p>Unless otherwise noted, all modules support change hooks.</p></div><divclass="refsect1"title="command"><aid="_command"></a><h2>command</h2><p>The command module takes the command name followed by a list of arguments, space delimited.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-modules</title><linkrel="stylesheet" href="./docbook-xsl.css" type="text/css" /><metaname="generator"content="DocBook XSL Stylesheets V1.75.2" /></head><body><divxml:lang="en"class="refentry"title="ansible-modules"lang="en"><aid="id303952"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-playbook — format and function of an ansible playbook file</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p>Ansible ships with <spanclass="emphasis"><em>ansible-playbook</em></span>, a tool for running playbooks.
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible-modules</title><linkrel="stylesheet"type="text/css"href="./docbook-xsl.css" /><metaname="generator"content="DocBook XSL Stylesheets V1.76.1" /></head><body><divxml:lang="en"class="refentry"title="ansible-modules"lang="en"><aid="id401198"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible-playbook — format and function of an ansible playbook file</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p>Ansible ships with <spanclass="emphasis"><em>ansible-playbook</em></span>, a tool for running playbooks.
Playbooks can represent frequent tasks, desired system configurations,
or deployment processes.</p></div><divclass="refsect1"title="FORMAT"><aid="_format"></a><h2>FORMAT</h2><p>Playbooks are written in YAML.</p></div><divclass="refsect1"title="EXAMPLE"><aid="_example"></a><h2>EXAMPLE</h2><p>See:</p><divclass="itemizedlist"><ulclass="itemizedlist"type="disc"><liclass="listitem">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible</title><linkrel="stylesheet" href="./docbook-xsl.css" type="text/css" /><metaname="generator"content="DocBook XSL Stylesheets V1.75.2" /></head><body><divxml:lang="en"class="refentry"title="ansible"lang="en"><aid="id547970"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
<htmlxmlns="http://www.w3.org/1999/xhtml"><head><metahttp-equiv="Content-Type"content="text/html; charset=UTF-8"/><title>ansible</title><linkrel="stylesheet"type="text/css"href="./docbook-xsl.css" /><metaname="generator"content="DocBook XSL Stylesheets V1.76.1" /></head><body><divxml:lang="en"class="refentry"title="ansible"lang="en"><aid="id324637"></a><divclass="titlepage"></div><divclass="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><divclass="refsynopsisdiv"title="Synopsis"><aid="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><divclass="refsect1"title="DESCRIPTION"><aid="_description"></a><h2>DESCRIPTION</h2><p><spanclass="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
<h1>The Inventory File, Patterns, and Groups<aclass="headerlink"href="#the-inventory-file-patterns-and-groups"title="Permalink to this headline">¶</a></h1>
<spanid="patterns"></span><h1>The Inventory File, Patterns, and Groups<aclass="headerlink"href="#the-inventory-file-patterns-and-groups"title="Permalink to this headline">¶</a></h1>
<h1>Playbooks: Ansible for Deployment, Configuration Management, and Orchestration<aclass="headerlink"href="#playbooks-ansible-for-deployment-configuration-management-and-orchestration"title="Permalink to this headline">¶</a></h1>
<divclass="section"id="playbooks">
<h1>Playbooks<aclass="headerlink"href="#playbooks"title="Permalink to this headline">¶</a></h1>
<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>
<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 <ttclass="docutils literal"><spanclass="pre">/usr/bin/ansible</span></tt> 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>
<divclass="section"id="playbook-example">
<h2>Playbook Example<aclass="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>
<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>
<divclass="highlight-python"><pre>---
- hosts: webservers
vars:
@ -91,19 +207,24 @@ back on the webservers group, etc:</p>
</div>
<divclass="section"id="hosts-line">
<h2>Hosts line<aclass="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, asdescribed in the ‘patterns’ documentation. This is just like the first parameter to /usr/bin/ansible.</p>
<p>The hosts line is a list of one or more groups or host patterns,
seperated by colons, asdescribed in the <aclass="reference internal"href="patterns.html#patterns"><em>The Inventory File, Patterns, and Groups</em></a> documentation.
This is just like the first parameter to <ttclass="docutils literal"><spanclass="pre">/usr/bin/ansible</span></tt>.</p>
</div>
<divclass="section"id="vars-section">
<h2>Vars section<aclass="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 <ttclass="docutils literal"><spanclass="pre">`jinja2`</span></tt> syntax like this:</p>
<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 ‘<ahref="#id1"><spanclass="problematic"id="id2">facter_</span></a>‘
and Ohai variables are prefixed with ‘<ahref="#id3"><spanclass="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>
<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 <ttclass="docutils literal"><spanclass="pre">facter_</span></tt> and Ohai
variables are prefixed with <ttclass="docutils literal"><spanclass="pre">ohai_</span></tt>. So for instance, if I wanted
to write the hostname into the /etc/motd file, I could say:</p>
<divclass="highlight-python"><pre>- name: write the motd
<h2>Using Includes To Assign Classes of Systems<aclass="headerlink"href="#using-includes-to-assign-classes-of-systems"title="Permalink to this headline">¶</a></h2>
<p>Include files are best used to reuse logic between playbooks. You could imagine
a playbook describing your entire infrastructure like this:</p>
<p>Include files are best used to reuse logic between playbooks. You
could imagine a playbook describing your entire infrastructure like
this:</p>
<divclass="highlight-python"><pre>---
- hosts: atlanta-webservers
vars:
@ -205,13 +339,14 @@ a playbook describing your entire infrastructure like this:</p>
handlers:
- include: generic-handlers.yml</pre>
</div>
<p>There is one (or more) play defined for each group of systems, and each play maps
each group includes one or more ‘class definitions’ telling the systems what they
are supposed to do or be.</p>
<p>Using a common handlers file could allow one task in ‘webservers’ to define ‘restart apache’,
and it could be reused between multiple plays.</p>
<p>Variables like ‘database’ above can be used in templates referenced from the
configuration file to generate machine specific variables.</p>
<p>There is one (or more) play defined for each group of systems, and
each play maps each group includes one or more ‘class definitions’
telling the systems what they are supposed to do or be.</p>
<p>Using a common handlers file could allow one task in ‘webservers’ to
define ‘restart apache’, and it could be reused between multiple
plays.</p>
<p>Variables like ‘database’ above can be used in templates referenced
from the configuration file to generate machine specific variables.</p>
@ -11,21 +11,28 @@ Playbooks: Ansible for Deployment, Configuration Management, and Orchestration
Learn about how to select hosts
Playbooks are a completely different way to use ansible and are particularly awesome.
Playbooks are a completely different way to use ansible and are
particularly awesome.
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.
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.
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.
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.
Playbook Example
````````````````
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::
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::
---
- hosts: webservers
@ -47,21 +54,26 @@ back on the webservers group, etc::
Hosts line
``````````
The hosts line is a list of one or more groups or host patterns, seperated by colons, asdescribed in the 'patterns' documentation. This is just like the first parameter to /usr/bin/ansible.
The hosts line is a list of one or more groups or host patterns,
seperated by colons, as described in the :ref:`patterns`
documentation. This is just like the first parameter to
`/usr/bin/ansible`.
Vars section
````````````
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 ```jinja2``` syntax like this::
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
`jinja2` syntax like this::
{{ varname }}
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 'facter_'
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
hostname into the /etc/motd file, I could say::
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 ``facter_`` and Ohai
variables are prefixed with ``ohai_``. So for instance, if I wanted
to write the hostname into the /etc/motd file, I could say::
Tim Bielawa
13 years ago