Added some foreshadowing of CLI syntax to the patterns page.
This commit is contained in:
Michael DeHaan
parent
7a8397d60f
commit
1a926c69a1
7 changed files with 87 additions and 37 deletions
|
|
@ -1,6 +1,6 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!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>ansible-playbook</title><link rel="stylesheet" href="./docbook-xsl.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div xml:lang="en" class="refentry" title="ansible-playbook" lang="en"><a id="id412767"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ansible-playbook — run an ansible playbook</p></div><div class="refsynopsisdiv" title="Synopsis"><a id="_synopsis"></a><h2>Synopsis</h2><p>ansible-playbook <filename.yml> … [options]</p></div><div class="refsect1" title="DESCRIPTION"><a id="_description"></a><h2>DESCRIPTION</h2><p><span class="strong"><strong>Ansible playbooks</strong></span> are a configuration and multinode deployment system. Ansible-playbook is the tool
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>ansible-playbook</title><link rel="stylesheet" href="./docbook-xsl.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div xml:lang="en" class="refentry" title="ansible-playbook" lang="en"><a id="id392696"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ansible-playbook — run an ansible playbook</p></div><div class="refsynopsisdiv" title="Synopsis"><a id="_synopsis"></a><h2>Synopsis</h2><p>ansible-playbook <filename.yml> … [options]</p></div><div class="refsect1" title="DESCRIPTION"><a id="_description"></a><h2>DESCRIPTION</h2><p><span class="strong"><strong>Ansible playbooks</strong></span> are a configuration and multinode deployment system. Ansible-playbook is the tool
|
||||
used to run them. See the project home page (link below) for more information.</p></div><div class="refsect1" title="ARGUMENTS"><a id="_arguments"></a><h2>ARGUMENTS</h2><div class="variablelist"><dl><dt><span class="term">
|
||||
<span class="strong"><strong>filename.yml</strong></span>
|
||||
</span></dt><dd>
|
||||
|
|
|
|||
|
|
@ -1,6 +1,6 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!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>ansible</title><link rel="stylesheet" href="./docbook-xsl.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div xml:lang="en" class="refentry" title="ansible" lang="en"><a id="id342828"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><div class="refsynopsisdiv" title="Synopsis"><a id="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><div class="refsect1" title="DESCRIPTION"><a id="_description"></a><h2>DESCRIPTION</h2><p><span class="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
|
||||
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>ansible</title><link rel="stylesheet" href="./docbook-xsl.css" type="text/css" /><meta name="generator" content="DocBook XSL Stylesheets V1.75.2" /></head><body><div xml:lang="en" class="refentry" title="ansible" lang="en"><a id="id325044"></a><div class="titlepage"></div><div class="refnamediv"><h2>Name</h2><p>ansible — run a command somewhere else</p></div><div class="refsynopsisdiv" title="Synopsis"><a id="_synopsis"></a><h2>Synopsis</h2><p>ansible <host-pattern> [-f forks] [-m module_name] [-a args]</p></div><div class="refsect1" title="DESCRIPTION"><a id="_description"></a><h2>DESCRIPTION</h2><p><span class="strong"><strong>Ansible</strong></span> is an extra-simple tool/framework/API for doing 'remote things' over
|
||||
SSH.</p></div><div class="refsect1" title="ARGUMENTS"><a id="_arguments"></a><h2>ARGUMENTS</h2><div class="variablelist"><dl><dt><span class="term">
|
||||
<span class="strong"><strong>host-pattern</strong></span>
|
||||
</span></dt><dd>
|
||||
|
|
|
|||
36
modules.html
36
modules.html
|
|
@ -168,19 +168,33 @@ s.parentNode.insertBefore(ga, s);
|
|||
|
||||
<div class="section" id="ansible-modules">
|
||||
<h1>Ansible Modules<a class="headerlink" href="#ansible-modules" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Ansible ships with a number of modules that can be executed directly
|
||||
on remote hosts or through ansible playbooks.</p>
|
||||
<p>Nearly all modules take <tt class="docutils literal"><span class="pre">key=value</span></tt> parameters, space delimited. Some modules take
|
||||
no parameters, and the command/shell modules simply take the string
|
||||
<p>Ansible ships with a number of modules (called the ‘module library’)
|
||||
that can be executed directly on remote hosts or through <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a>.
|
||||
Users can also write their own modules. These modules can control system
|
||||
resources, like services, packages, or files (anything really), or
|
||||
handle executing system commands.</p>
|
||||
<p>Let’s review how we execute three different modules from the command line:</p>
|
||||
<div class="highlight-python"><pre>ansible webservers -m service -a "name=httpd state=running"
|
||||
ansible webservers -m ping
|
||||
ansible webservers -m command -a "/sbin/reboot -t now"</pre>
|
||||
</div>
|
||||
<p>Each module supports taking arguments. Nearly all modules take <tt class="docutils literal"><span class="pre">key=value</span></tt>
|
||||
arguments, space delimited. Some modules take
|
||||
no arguments, and the command/shell modules simply take the string
|
||||
of the command you want to run.</p>
|
||||
<p>All modules return JSON format data, though if you are using the
|
||||
<p>From playbooks, Ansible modules are executed in a very similar way:</p>
|
||||
<div class="highlight-python"><pre>- name: reboot the servers
|
||||
action: command /sbin/reboot -t now</pre>
|
||||
</div>
|
||||
<p>All modules technically return JSON format data, though if you are using the
|
||||
command line or playbooks, you don’t really need to know much about
|
||||
that.</p>
|
||||
<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. Unless otherwise
|
||||
noted, all modules support change hooks.</p>
|
||||
<p>Stock modules:</p>
|
||||
that. If you’re writing your own module, you care, and this means you do
|
||||
not have to write modules in any particular language – you get tho choose.</p>
|
||||
<p>Most modules other than command are <cite>idempotent</cite>, meaning they will seek
|
||||
to avoid changes to the system unless a change needs to be made. When using ansible
|
||||
playbooks, these modules can trigger ‘change events’. Unless otherwise
|
||||
noted, any given module does support change hooks.</p>
|
||||
<p>Let’s see what’s available in the Ansible module library, out of the box:</p>
|
||||
<div class="section" id="command">
|
||||
<span id="id1"></span><h2>command<a class="headerlink" href="#command" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The command module takes the command name followed by a list of
|
||||
|
|
|
|||
|
|
@ -157,13 +157,12 @@ s.parentNode.insertBefore(ga, s);
|
|||
|
||||
<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>
|
||||
<p>How to define and select hosts you wish to manage</p>
|
||||
<div class="section" id="inventory-file-format">
|
||||
<span id="inventoryformat"></span><h2>Inventory File Format<a class="headerlink" href="#inventory-file-format" title="Permalink to this headline">¶</a></h2>
|
||||
<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, and
|
||||
looks like this:</p>
|
||||
Ansible’s inventory file, which defaults to /etc/ansible/hosts.</p>
|
||||
<div class="section" id="inventory-file-format">
|
||||
<span id="inventoryformat"></span><h2>Inventory File Format<a class="headerlink" href="#inventory-file-format" title="Permalink to this headline">¶</a></h2>
|
||||
<p>The format for /etc/ansible/hosts looks like this:</p>
|
||||
<div class="highlight-python"><div class="highlight"><pre><span class="n">mail</span><span class="o">.</span><span class="n">example</span><span class="o">.</span><span class="n">com</span>
|
||||
|
||||
<span class="p">[</span><span class="n">webservers</span><span class="p">]</span>
|
||||
|
|
@ -181,7 +180,16 @@ but they are useful.</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>These patterns target all hosts in the inventory file:</p>
|
||||
<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>
|
||||
<div class="highlight-python"><pre>ansible <pattern_goes_here> -m <module_name> -a <arguments></pre>
|
||||
</div>
|
||||
<p>Such as:</p>
|
||||
<blockquote>
|
||||
<div>ansible <pattern_goes_here> -m service -a “name=httpd state=running”</div></blockquote>
|
||||
<p>Within <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a>, these patterns can also be used, for even greater purposes.</p>
|
||||
<p>Anyway, to use Ansible, you’ll first need to know how to tell Ansible which hosts in your inventory file to talk to.
|
||||
This is done by designating particular host names or groups of hosts.</p>
|
||||
<p>The following patterns target all hosts in the inventory file:</p>
|
||||
<div class="highlight-python"><pre>all
|
||||
*</pre>
|
||||
</div>
|
||||
|
|
|
|||
|
|
@ -1,23 +1,39 @@
|
|||
Ansible Modules
|
||||
===============
|
||||
|
||||
Ansible ships with a number of modules that can be executed directly
|
||||
on remote hosts or through ansible playbooks.
|
||||
Ansible ships with a number of modules (called the 'module library')
|
||||
that can be executed directly on remote hosts or through :doc:`playbooks`.
|
||||
Users can also write their own modules. These modules can control system
|
||||
resources, like services, packages, or files (anything really), or
|
||||
handle executing system commands.
|
||||
|
||||
Nearly all modules take ``key=value`` parameters, space delimited. Some modules take
|
||||
no parameters, and the command/shell modules simply take the string
|
||||
Let's review how we execute three different modules from the command line::
|
||||
|
||||
ansible webservers -m service -a "name=httpd state=running"
|
||||
ansible webservers -m ping
|
||||
ansible webservers -m command -a "/sbin/reboot -t now"
|
||||
|
||||
Each module supports taking arguments. Nearly all modules take ``key=value``
|
||||
arguments, space delimited. Some modules take
|
||||
no arguments, and the command/shell modules simply take the string
|
||||
of the command you want to run.
|
||||
|
||||
All modules return JSON format data, though if you are using the
|
||||
From playbooks, Ansible modules are executed in a very similar way::
|
||||
|
||||
- name: reboot the servers
|
||||
action: command /sbin/reboot -t now
|
||||
|
||||
All modules technically return JSON format data, though if you are using the
|
||||
command line or playbooks, you don't really need to know much about
|
||||
that.
|
||||
that. If you're writing your own module, you care, and this means you do
|
||||
not have to write modules in any particular language -- you get tho choose.
|
||||
|
||||
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. Unless otherwise
|
||||
noted, all modules support change hooks.
|
||||
Most modules other than command are `idempotent`, meaning they will seek
|
||||
to avoid changes to the system unless a change needs to be made. When using ansible
|
||||
playbooks, these modules can trigger 'change events'. Unless otherwise
|
||||
noted, any given module does support change hooks.
|
||||
|
||||
Stock modules:
|
||||
Let's see what's available in the Ansible module library, out of the box:
|
||||
|
||||
.. _command:
|
||||
|
||||
|
|
|
|||
|
|
@ -3,17 +3,16 @@
|
|||
The Inventory File, Patterns, and Groups
|
||||
========================================
|
||||
|
||||
How to define and select hosts you wish to manage
|
||||
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.
|
||||
|
||||
.. _inventoryformat:
|
||||
|
||||
Inventory File Format
|
||||
+++++++++++++++++++++
|
||||
|
||||
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, and
|
||||
looks like this::
|
||||
The format for /etc/ansible/hosts looks like this::
|
||||
|
||||
mail.example.com
|
||||
|
||||
|
|
@ -32,7 +31,20 @@ but they are useful.
|
|||
Selecting Targets
|
||||
+++++++++++++++++
|
||||
|
||||
These patterns target all hosts in the inventory file::
|
||||
We'll go over how to use the command line in :doc:`examples` section, however, basically it looks like this::
|
||||
|
||||
ansible <pattern_goes_here> -m <module_name> -a <arguments>
|
||||
|
||||
Such as::
|
||||
|
||||
ansible webservers -m service -a "name=httpd state=restarted"
|
||||
|
||||
Within :doc:`playbooks`, these patterns can also be used, for even greater purposes.
|
||||
|
||||
Anyway, to use Ansible, you'll first need to know how to tell Ansible which hosts in your inventory file to talk to.
|
||||
This is done by designating particular host names or groups of hosts.
|
||||
|
||||
The following patterns target all hosts in the inventory file::
|
||||
|
||||
all
|
||||
*
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue