@ -11,21 +11,28 @@ Playbooks: Ansible for Deployment, Configuration Management, and Orchestration
Learn about how to select hosts
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
Playbook Example
````````````````
````````````````
Playbooks are expressed in YAML format and have a minimum of syntax. Each playbook is composed
Playbooks are expressed in YAML format and have a minimum of syntax.
of one or more 'plays' in a list. By composing a playbook of multiple 'plays', it is possible
Each playbook is composed of one or more 'plays' in a list. By
to orchestrate multi-machine deployments, running certain steps on all machines in
composing a playbook of multiple 'plays', it is possible to
the webservers group, then certain steps on the database server group, then more commands
orchestrate multi-machine deployments, running certain steps on all
back on the webservers group, etc::
machines in the webservers group, then certain steps on the database
server group, then more commands back on the webservers group, etc::
---
---
- hosts: webservers
- hosts: webservers
@ -47,21 +54,25 @@ back on the webservers group, etc::
Hosts line
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
Vars section
````````````
````````````
A list of variables and values that can be used in the plays. These can be used in templates
A list of variables and values that can be used in the plays. These
or 'action' lines and are dereferenced using ```jinja2``` syntax like this::
can be used in templates or 'action' lines and are dereferenced using
```jinja2``` syntax like this::
{{ varname }}
{{ varname }}
Further, if there are discovered variables about the system (say, if facter or ohai were
Further, if there are discovered variables about the system (say, if
installed) these variables bubble up back into the playbook, and can be used on each
facter or ohai were installed) these variables bubble up back into the
system just like explicitly set variables. Facter variables are prefixed with 'facter_'
playbook, and can be used on each system just like explicitly set
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
variables. Facter variables are prefixed with ``facter_`` and Ohai
hostname into the /etc/motd file, I could say::
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">
<!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
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
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.
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">
<!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,
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">
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">
<!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>
<p>Playbooks are a completely different way to use ansible and are particularly awesome.</p>
<p>Playbooks are a completely different way to use ansible and are
<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>
particularly awesome.</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>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">
<divclass="section"id="playbook-example">
<h2>Playbook Example<aclass="headerlink"href="#playbook-example"title="Permalink to this headline">¶</a></h2>
<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
<p>Playbooks are expressed in YAML format and have a minimum of syntax.
of one or more ‘plays’ in a list. By composing a playbook of multiple ‘plays’, it is possible
Each playbook is composed of one or more ‘plays’ in a list. By
to orchestrate multi-machine deployments, running certain steps on all machines in
composing a playbook of multiple ‘plays’, it is possible to
the webservers group, then certain steps on the database server group, then more commands
orchestrate multi-machine deployments, running certain steps on all
back on the webservers group, etc:</p>
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>---
<divclass="highlight-python"><pre>---
- hosts: webservers
- hosts: webservers
vars:
vars:
@ -91,19 +207,24 @@ back on the webservers group, etc:</p>
</div>
</div>
<divclass="section"id="hosts-line">
<divclass="section"id="hosts-line">
<h2>Hosts line<aclass="headerlink"href="#hosts-line"title="Permalink to this headline">¶</a></h2>
<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>
</div>
<divclass="section"id="vars-section">
<divclass="section"id="vars-section">
<h2>Vars section<aclass="headerlink"href="#vars-section"title="Permalink to this headline">¶</a></h2>
<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
<p>A list of variables and values that can be used in the plays. These
or ‘action’ lines and are dereferenced using <ttclass="docutils literal"><spanclass="pre">`jinja2`</span></tt> syntax like this:</p>
can be used in templates or ‘action’ lines and are dereferenced using
<p>Further, if there are discovered variables about the system (say, if facter or ohai were
<p>Further, if there are discovered variables about the system (say, if
installed) these variables bubble up back into the playbook, and can be used on each
facter or ohai were installed) these variables bubble up back into the
system just like explicitly set variables. Facter variables are prefixed with ‘<ahref="#id1"><spanclass="problematic"id="id2">facter_</span></a>‘
playbook, and can be used on each system just like explicitly set
and Ohai variables are prefixed with ‘<ahref="#id3"><spanclass="problematic"id="id4">ohai_</span></a>‘. So for instance, if I wanted to write the
variables. Facter variables are prefixed with <ttclass="docutils literal"><spanclass="pre">facter_</span></tt> and Ohai
hostname into the /etc/motd file, I could say:</p>
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
<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>
<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
<p>Include files are best used to reuse logic between playbooks. You
a playbook describing your entire infrastructure like this:</p>
could imagine a playbook describing your entire infrastructure like
this:</p>
<divclass="highlight-python"><pre>---
<divclass="highlight-python"><pre>---
- hosts: atlanta-webservers
- hosts: atlanta-webservers
vars:
vars:
@ -205,13 +339,14 @@ a playbook describing your entire infrastructure like this:</p>
handlers:
handlers:
- include: generic-handlers.yml</pre>
- include: generic-handlers.yml</pre>
</div>
</div>
<p>There is one (or more) play defined for each group of systems, and each play maps
<p>There is one (or more) play defined for each group of systems, and
each group includes one or more ‘class definitions’ telling the systems what they
each play maps each group includes one or more ‘class definitions’
are supposed to do or be.</p>
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’,
<p>Using a common handlers file could allow one task in ‘webservers’ to
and it could be reused between multiple plays.</p>
define ‘restart apache’, and it could be reused between multiple
<p>Variables like ‘database’ above can be used in templates referenced from the
plays.</p>
configuration file to generate machine specific variables.</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
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
Playbook Example
````````````````
````````````````
Playbooks are expressed in YAML format and have a minimum of syntax. Each playbook is composed
Playbooks are expressed in YAML format and have a minimum of syntax.
of one or more 'plays' in a list. By composing a playbook of multiple 'plays', it is possible
Each playbook is composed of one or more 'plays' in a list. By
to orchestrate multi-machine deployments, running certain steps on all machines in
composing a playbook of multiple 'plays', it is possible to
the webservers group, then certain steps on the database server group, then more commands
orchestrate multi-machine deployments, running certain steps on all
back on the webservers group, etc::
machines in the webservers group, then certain steps on the database
server group, then more commands back on the webservers group, etc::
---
---
- hosts: webservers
- hosts: webservers
@ -47,21 +54,26 @@ back on the webservers group, etc::
Hosts line
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
Vars section
````````````
````````````
A list of variables and values that can be used in the plays. These can be used in templates
A list of variables and values that can be used in the plays. These
or 'action' lines and are dereferenced using ```jinja2``` syntax like this::
can be used in templates or 'action' lines and are dereferenced using
`jinja2` syntax like this::
{{ varname }}
{{ varname }}
Further, if there are discovered variables about the system (say, if facter or ohai were
Further, if there are discovered variables about the system (say, if
installed) these variables bubble up back into the playbook, and can be used on each
facter or ohai were installed) these variables bubble up back into the
system just like explicitly set variables. Facter variables are prefixed with 'facter_'
playbook, and can be used on each system just like explicitly set
and Ohai variables are prefixed with 'ohai_'. So for instance, if I wanted to write the
variables. Facter variables are prefixed with ``facter_`` and Ohai
hostname into the /etc/motd file, I could say::
variables are prefixed with ``ohai_``. So for instance, if I wanted
to write the hostname into the /etc/motd file, I could say::