The following examples show how to use `/usr/bin/ansible` for running ad-hoc tasks.
Start here. For configuration management and deployments, you'll want to pick up on
using `/usr/bin/ansible-playbook` -- the concepts port over directly.
.. seealso::
...
...
@@ -24,19 +28,6 @@ The -f 10 specifies the usage of 10 simultaneous processes.
Note that other than the command module, ansible modules do not work like simple scripts. They make the remote system look like you state, and run the commands neccessary to get it there. This is commonly refered to
as 'idempotency'.
Time Limited Background Operations
``````````````````````````````````
Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won't lose track. Polling support is pending in the command line.::
ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789
Any module other than 'copy' or 'template' can be backgrounded. Typically you'll be backgrounding shell
commands or software upgrades only.
After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.
File Transfer & Templating
``````````````````````````
...
...
@@ -74,4 +65,17 @@ Alternatively, restart a service on all webservers::
ansible webservers -m service name=httpd state=restarted
Time Limited Background Operations
``````````````````````````````````
Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won't lose track. Polling support is pending in the command line.::
ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789
Any module other than 'copy' or 'template' can be backgrounded. Typically you'll be backgrounding shell
commands or software upgrades only.
After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.
@@ -47,8 +47,7 @@ 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, as
described 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 'patterns' documentation. This is just like the first parameter to /usr/bin/ansible.
Vars section
````````````
...
...
@@ -140,6 +139,58 @@ in a wordpress.yml file, and use it like so::
In addition to the explicitly passed in parameters, all variables from the vars section
are also available.
The format of an included list of tasks or handlers looks just like a flat list of tasks. Here
is an example of what base.yml might look like::
---
- name: no selinux
action: command /usr/sbin/setenforce 0
- name: no iptables
action: service name=iptables state=stopped
- name: this is just to show variables work here, favcolor={{ favcolor }}
action: command /bin/true
As you can see above, variables in include files work just like they do in the main file.
Including a variable in the name of a task is a contrived example, you could also
pass them to the action command line or use them inside a template file.
Note that include statements are only usable from the top level playbook file.
At this time, includes can not include other includes.
Using Includes To Assign Classes of Systems
```````````````````````````````````````````
Include files are best used to reuse logic between playbooks. You could imagine
a playbook describing your entire infrastructure like this::
---
- hosts: atlanta-webservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: webservers.yml database=db.atlanta.com
handlers:
- include: generic-handlers.yml
- hosts: atlanta-dbservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: dbservers.yml
handlers:
- include: generic-handlers.yml
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.
Using a common handlers file could allow one task in 'webservers' to define 'restart apache',
and it could be reused between multiple plays.
Variables like 'database' above can be used in templates referenced from the
configuration file to generate machine specific variables.
<p>Advanced programmers may also wish to read the source to ansible itself, for
it uses the Runner() API (with all available options) to implement the
command line tools <ttclass="docutils literal"><spanclass="pre">ansible</span></tt> and <ttclass="docutils literal"><spanclass="pre">ansible-playbook</span></tt>.</p>
</div>
</div>
...
...
@@ -86,6 +123,14 @@ be used as a framework to rapidly build powerful applications and scripts.</p>
</div>
<divclass="sphinxsidebar">
<divclass="sphinxsidebarwrapper">
<h3><ahref="index.html">Table Of Contents</a></h3>
<ul>
<li><aclass="reference internal"href="#">Using the Python API</a><ul>
<li><aclass="reference internal"href="#detailed-api-example">Detailed API Example</a></li>
</ul>
</li>
</ul>
<h4>Previous topic</h4>
<pclass="topless"><ahref="playbooks.html"
title="previous chapter">Playbooks: Ansible for Deployment, Configuration Management, and Orchestration</a></p>
...
...
@@ -131,7 +176,7 @@ be used as a framework to rapidly build powerful applications and scripts.</p>
<h1>Communicate and Get Involved<aclass="headerlink"href="#communicate-and-get-involved"title="Permalink to this headline">¶</a></h1>
<ulclass="simple">
<li>Join the <aclass="reference external"href="http://groups.google.com/group/ansible-project">ansible-project mailing list</a> on Google Groups</li>
<li>Join <aclass="reference external"href="irc://irc.freenode.net/#ansible">#ansible</a> on the <aclass="reference external"href="http://freenode.net/">freenode IRC network</a></li>
<li>Visit the <aclass="reference external"href="https://github.com/ansible/ansible">project page</a> on Github<ul>
<li>View the <aclass="reference external"href="https://github.com/ansible/ansible/issues">issue tracker</a></li>
@@ -71,16 +74,6 @@ ansible atlanta -a "/sbin/reboot" -f 10</pre>
<p>Note that other than the command module, ansible modules do not work like simple scripts. They make the remote system look like you state, and run the commands neccessary to get it there. This is commonly refered to
<h2>Time Limited Background Operations<aclass="headerlink"href="#time-limited-background-operations"title="Permalink to this headline">¶</a></h2>
<p>Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won’t lose track. Polling support is pending in the command line.:</p>
<divclass="highlight-python"><pre>ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789</pre>
</div>
<p>Any module other than ‘copy’ or ‘template’ can be backgrounded. Typically you’ll be backgrounding shell
commands or software upgrades only.</p>
<p>After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.</p>
</div>
<divclass="section"id="file-transfer-templating">
<h2>File Transfer & Templating<aclass="headerlink"href="#file-transfer-templating"title="Permalink to this headline">¶</a></h2>
<p>Ansible can SCP lots of files to multiple machines in parallel, and optionally use them as template sources.</p>
<h2>Time Limited Background Operations<aclass="headerlink"href="#time-limited-background-operations"title="Permalink to this headline">¶</a></h2>
<p>Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won’t lose track. Polling support is pending in the command line.:</p>
<divclass="highlight-python"><pre>ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789</pre>
</div>
<p>Any module other than ‘copy’ or ‘template’ can be backgrounded. Typically you’ll be backgrounding shell
commands or software upgrades only.</p>
<p>After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.</p>
<liclass="toctree-l2"><aclass="reference internal"href="playbooks.html#using-includes-to-assign-classes-of-systems">Using Includes To Assign Classes of Systems</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="playbooks.html#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
<liclass="toctree-l2"><aclass="reference internal"href="playbooks.html#executing-a-playbook">Executing A Playbook</a></li>
<!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="id481479"></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"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="id581114"></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="id350237"></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"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="id566369"></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="id561794"></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"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="id564661"></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
@@ -91,8 +91,7 @@ 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, as
described 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 ‘patterns’ documentation. This is just like the first parameter to /usr/bin/ansible.</p>
</div>
<divclass="section"id="vars-section">
<h2>Vars section<aclass="headerlink"href="#vars-section"title="Permalink to this headline">¶</a></h2>
...
...
@@ -168,6 +167,51 @@ in a wordpress.yml file, and use it like so:</p>
</div>
<p>In addition to the explicitly passed in parameters, all variables from the vars section
are also available.</p>
<p>The format of an included list of tasks or handlers looks just like a flat list of tasks. Here
is an example of what base.yml might look like:</p>
<divclass="highlight-python"><pre>---
- name: no selinux
action: command /usr/sbin/setenforce 0
- name: no iptables
action: service name=iptables state=stopped
- name: this is just to show variables work here, favcolor={{ favcolor }}
action: command /bin/true</pre>
</div>
<p>As you can see above, variables in include files work just like they do in the main file.
Including a variable in the name of a task is a contrived example, you could also
pass them to the action command line or use them inside a template file.</p>
<p>Note that include statements are only usable from the top level playbook file.
At this time, includes can not include other includes.</p>
<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>
<divclass="highlight-python"><pre>---
- hosts: atlanta-webservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: webservers.yml database=db.atlanta.com
handlers:
- include: generic-handlers.yml
- hosts: atlanta-dbservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: dbservers.yml
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>
The following examples show how to use `/usr/bin/ansible` for running ad-hoc tasks.
Start here. For configuration management and deployments, you'll want to pick up on
using `/usr/bin/ansible-playbook` -- the concepts port over directly.
.. seealso::
...
...
@@ -24,19 +28,6 @@ The -f 10 specifies the usage of 10 simultaneous processes.
Note that other than the command module, ansible modules do not work like simple scripts. They make the remote system look like you state, and run the commands neccessary to get it there. This is commonly refered to
as 'idempotency'.
Time Limited Background Operations
``````````````````````````````````
Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won't lose track. Polling support is pending in the command line.::
ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789
Any module other than 'copy' or 'template' can be backgrounded. Typically you'll be backgrounding shell
commands or software upgrades only.
After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.
File Transfer & Templating
``````````````````````````
...
...
@@ -74,4 +65,17 @@ Alternatively, restart a service on all webservers::
ansible webservers -m service name=httpd state=restarted
Time Limited Background Operations
``````````````````````````````````
Long running operations can be backgrounded, and their status can be checked on later. The same job ID is given to the same task on all hosts, so you won't lose track. Polling support is pending in the command line.::
ansible all -B 3600 -a "/usr/bin/long_running_operation --do-stuff"
ansible all -n job_status -a jid=123456789
Any module other than 'copy' or 'template' can be backgrounded. Typically you'll be backgrounding shell
commands or software upgrades only.
After the time limit (in seconds) runs out (-B), the process on the remote nodes will be killed.
@@ -47,8 +47,7 @@ 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, as
described 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 'patterns' documentation. This is just like the first parameter to /usr/bin/ansible.
Vars section
````````````
...
...
@@ -140,6 +139,58 @@ in a wordpress.yml file, and use it like so::
In addition to the explicitly passed in parameters, all variables from the vars section
are also available.
The format of an included list of tasks or handlers looks just like a flat list of tasks. Here
is an example of what base.yml might look like::
---
- name: no selinux
action: command /usr/sbin/setenforce 0
- name: no iptables
action: service name=iptables state=stopped
- name: this is just to show variables work here, favcolor={{ favcolor }}
action: command /bin/true
As you can see above, variables in include files work just like they do in the main file.
Including a variable in the name of a task is a contrived example, you could also
pass them to the action command line or use them inside a template file.
Note that include statements are only usable from the top level playbook file.
At this time, includes can not include other includes.
Using Includes To Assign Classes of Systems
```````````````````````````````````````````
Include files are best used to reuse logic between playbooks. You could imagine
a playbook describing your entire infrastructure like this::
---
- hosts: atlanta-webservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: webservers.yml database=db.atlanta.com
handlers:
- include: generic-handlers.yml
- hosts: atlanta-dbservers
vars:
datacenter: atlanta
tasks:
- include: base.yml
- include: dbservers.yml
handlers:
- include: generic-handlers.yml
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.
Using a common handlers file could allow one task in 'webservers' to define 'restart apache',
and it could be reused between multiple plays.
Variables like 'database' above can be used in templates referenced from the
configuration file to generate machine specific variables.
