mirror of
https://github.com/ansible-collections/community.general.git
synced 2024-09-14 20:13:21 +02:00
Attempt to make the home page less of a wall of text. Probably more to come.
This commit is contained in:
Michael DeHaan
parent
db19d83e40
commit
10fc56adf0
4 changed files with 269 additions and 346 deletions
|
|
@ -28,7 +28,7 @@
|
|||
<link rel="shortcut icon" href="_static/favicon.ico"/>
|
||||
<link rel="top" title="Ansible - SSH-Based Configuration Management & Deployment" href="index.html" />
|
||||
<link rel="next" title="Inventory & Patterns" href="patterns.html" />
|
||||
<link rel="prev" title="The Future Is Now" href="index.html" />
|
||||
<link rel="prev" title="Introducing Ansible" href="index.html" />
|
||||
<script type="text/javascript">
|
||||
(function () {
|
||||
/**
|
||||
|
|
|
|||
391
index.html
391
index.html
|
|
@ -6,7 +6,7 @@
|
|||
<head>
|
||||
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
|
||||
|
||||
<title>The Future Is Now — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<title>Introducing Ansible — Ansible - SSH-Based Configuration Management & Deployment</title>
|
||||
<link rel="stylesheet" href="_static/default.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/pygments.css" type="text/css" />
|
||||
<link rel="stylesheet" href="_static/bootstrap.css" type="text/css" />
|
||||
|
|
@ -147,18 +147,12 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="#"
|
||||
class="dropdown-toggle">Page</a>
|
||||
<span class="localtoc"><ul>
|
||||
<li><a class="reference internal" href="#">The Future Is Now</a></li>
|
||||
<li><a class="reference internal" href="#innovative-multi-node-control">Innovative Multi-node Control</a></li>
|
||||
<li><a class="reference internal" href="#deployment-and-configuration-unified">Deployment and Configuration, Unified</a></li>
|
||||
<li><a class="reference internal" href="#simple-secure-by-default">Simple & Secure By Default</a></li>
|
||||
<li><a class="reference internal" href="#">Introducing Ansible</a></li>
|
||||
<li><a class="reference internal" href="#architecture">Architecture</a></li>
|
||||
<li><a class="reference internal" href="#features">Features</a></li>
|
||||
<li><a class="reference internal" href="#what-people-are-saying">What People Are Saying</a></li>
|
||||
<li><a class="reference internal" href="#resources">Resources</a></li>
|
||||
<li><a class="reference internal" href="#contents">Contents</a><ul>
|
||||
<li><a class="reference internal" href="#documentation">Documentation</a><ul>
|
||||
</ul>
|
||||
</li>
|
||||
<li><a class="reference internal" href="#presented-by">Presented By...</a></li>
|
||||
</ul>
|
||||
</span>
|
||||
</li>
|
||||
|
|
@ -184,77 +178,104 @@ s.parentNode.insertBefore(ga, s);
|
|||
<a href="http://ansible.github.com"><img src="http://ansible.github.com/ansible-logo.png" alt="Ansible"/></a><br/>
|
||||
<br/>
|
||||
|
||||
<div class="section" id="the-future-is-now">
|
||||
<h1>The Future Is Now<a class="headerlink" href="#the-future-is-now" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="section" id="introducing-ansible">
|
||||
<h1>Introducing Ansible<a class="headerlink" href="#introducing-ansible" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Ansible is a radically simple model-driven configuration management, deployment,
|
||||
and command execution framework. Other tools in this space have been too
|
||||
complicated for too long, require too much bootstrapping, and have too
|
||||
much learning curve. Ansible is dead simple and painless to extend.
|
||||
For comparison, Puppet and Chef have about 60k lines of code.
|
||||
Ansible’s core is a little over 2000 lines..</p>
|
||||
<p>Ansible isn’t just for idempotent configuration – it’s also great for ad-hoc
|
||||
tasks, quickly firing off commands against nodes. See <a class="reference internal" href="examples.html"><em>Command Line</em></a>.</p>
|
||||
</div>
|
||||
<div class="section" id="innovative-multi-node-control">
|
||||
<h1>Innovative Multi-node Control<a class="headerlink" href="#innovative-multi-node-control" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Where Ansible excels though, is expressing complex multi-node
|
||||
deployment processes, executing ordered sequences on
|
||||
different sets of nodes through <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a>. Playbooks contain one or
|
||||
more plays, each executed against a different batch of nodes. Think about
|
||||
webservers, database servers, and backend servers in a multi-node web environment. A play can address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
|
||||
version of software if required.</p>
|
||||
<p>Multi-machine software deployment is poorly solved by most systems management tools – often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.</p>
|
||||
<p>If you actually do need pull oriented mode, though, Ansible 0.4 and later can run playbooks in pull mode as well.
|
||||
This is useful in extreme scaling scenarios or when automatic system remediation is desired. Since Ansible remains
|
||||
server and daemonless, scaling potential is unlimited, and no resources are wasted on running management daemons.</p>
|
||||
</div>
|
||||
<div class="section" id="deployment-and-configuration-unified">
|
||||
<h1>Deployment and Configuration, Unified<a class="headerlink" href="#deployment-and-configuration-unified" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Other deployment (compared to config) oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts. Ansible playbooks – having been designed with this problem in mind – are good at both deployment & idempotent configuration, meaning you don’t have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc). Performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required – while avoiding the problem of fragile scripting that assumes certain starting or ending states.</p>
|
||||
<p>Ansible is also unique in other ways. Extending ansible does not require programming in any particular language – you can write <a class="reference internal" href="modules.html"><em>Ansible Modules</em></a> as idempotent scripts or programs that return simple JSON. Ansible is also pragmatic, so when you need to, it’s also trivially easy to just execute useful shell commands.</p>
|
||||
<p>Why use Ansible versus other configuration management tools? (Puppet, Chef, etc?) Ansible will have far
|
||||
less code, it will be (by extension) more correct, and it will be the
|
||||
easiest thing to hack on and use you’ll ever see – regardless of your
|
||||
favorite language of choice. Versus other deployment tools? (Capistrano, Fabric?). Ansible playbooks are easier
|
||||
to use (not being code) and also allows intermixing of idempotent configuration management rules for a higher level
|
||||
of control. Further, it was designed for deploying multi-node applications from the beginning.</p>
|
||||
</div>
|
||||
<div class="section" id="simple-secure-by-default">
|
||||
<h1>Simple & Secure By Default<a class="headerlink" href="#simple-secure-by-default" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Compared with most configuration managememnt tools, Ansible is also much more secure. While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary). There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
|
||||
If a central server containing your playbooks are comprimised, your nodes are not – which is NOT the case
|
||||
of these other tools, which can, more or less, turn into a botnet. Our security approach is to avoid writing custom
|
||||
crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using. There is no PKI subsystem to maintain, which can be a frequent source of problems, particularly when reinstalling or migrating
|
||||
hosts.</p>
|
||||
<p>Systems management doesn’t have to be complicated. Ansible’s docs will remain short & simple, and the source will be blindingly obvious. We’ve learned well from “Infrastructure is Code”. Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project – bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.</p>
|
||||
and command execution framework. Other tools in this space have been too complicated for too long,
|
||||
require too much bootstrapping, and have too much learning curve. By comparison, Ansible is dead simple
|
||||
and painless to extend. Puppet and Chef have about 60k lines of code. Ansible’s core is a little over 2000 lines.</p>
|
||||
<p>Ansible isn’t just for configuration management – it’s also great for ad-hoc tasks, quickly firing off commands against nodes, and it excels at complex multi-node deployment tasks, being designed for that purpose from day one.</p>
|
||||
<p>Systems management doesn’t have to be complicated. We’ve learned well from the “Infrastructure is Code” movement.
|
||||
Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project – bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit. This is Ansible’s philosophy and the main reason it’s different. Read on, though, and we’ll tell you more.</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="100%" />
|
||||
</colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr><th class="head">Key Features</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr><td>Dead simple setup</td>
|
||||
</tr>
|
||||
<tr><td>Super fast & parallel by default</td>
|
||||
</tr>
|
||||
<tr><td>No server or client daemons; use existing SSHd out of the box</td>
|
||||
</tr>
|
||||
<tr><td>Supports Kerberized SSH, jump hosts, forwarding, etc</td>
|
||||
</tr>
|
||||
<tr><td>No additional software required on client boxes</td>
|
||||
</tr>
|
||||
<tr><td>Can be easily run from a checkout, no installation required</td>
|
||||
</tr>
|
||||
<tr><td>Modules are idempotent, but you can also easily use shell commands</td>
|
||||
</tr>
|
||||
<tr><td>Modules can be written in ANY language</td>
|
||||
</tr>
|
||||
<tr><td>Awesome API for creating very powerful distributed scripts</td>
|
||||
</tr>
|
||||
<tr><td>Does not have to run remote steps as root</td>
|
||||
</tr>
|
||||
<tr><td>Pluggable transports (SSH is just the default)</td>
|
||||
</tr>
|
||||
<tr><td>Source host info & variables from files or external software</td>
|
||||
</tr>
|
||||
<tr><td>The easiest config management system to use, ever.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="architecture">
|
||||
<h1>Architecture<a class="headerlink" href="#architecture" title="Permalink to this headline">¶</a></h1>
|
||||
<div align="center" class="align-center"><img alt=""Architecture Diagram"" class="align-center" src="http://ansible.github.com/ansible_arch2.jpg" style="width: 800px;" /></div>
|
||||
</div>
|
||||
<div class="section" id="features">
|
||||
<h1>Features<a class="headerlink" href="#features" title="Permalink to this headline">¶</a></h1>
|
||||
<ul class="simple">
|
||||
<li>Dead simple setup</li>
|
||||
<li>Super fast & parallel by default</li>
|
||||
<li>No server or client daemons; use existing SSHd out of the box</li>
|
||||
<li>Supports Kerberized SSH, jump hosts, forwarding, etc</li>
|
||||
<li>No additional software required on client boxes</li>
|
||||
<li>Can be easily run from a checkout, no installation required</li>
|
||||
<li>Modules are idempotent, but you can also easily use shell commands</li>
|
||||
<li>Modules can be written in ANY language</li>
|
||||
<li>Awesome API for creating very powerful distributed scripts</li>
|
||||
<li>Does not have to run remote steps as root</li>
|
||||
<li>Pluggable transports (SSH is just the default)</li>
|
||||
<li>Source host info & variables from files or external software</li>
|
||||
<li>The easiest config management system to use, ever.</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="section" id="what-people-are-saying">
|
||||
<h1>What People Are Saying<a class="headerlink" href="#what-people-are-saying" title="Permalink to this headline">¶</a></h1>
|
||||
<p>“I’ve been trying to grok Chef these last weeks, and really, I don’t get it. I discovered ansible yesterday at noon, successfully ran it at 1pm, made my first playbook by 2pm, and pushed two small [contributions to the project] before the office closed... Do that with any other config management software!”</p>
|
||||
<p>“Ansible is much more firewall-friendly. I have a number of hosts that are only accessible via reverse SSH tunnels, and let me tell you getting puppet or chef to play nice with that is a nightmare.”</p>
|
||||
<p>“This software has really changed my life as an network admin, the simplicity ansible comes with is really childs-play and I really adore its design. No more hassle with SSL keys, DNS based ‘server entries’ (e.g. puppet and what not). Just plain (secure!) SSH keys and one is good to go.”</p>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="35%" />
|
||||
<col width="65%" />
|
||||
</colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr><th class="head" colspan="2">Tell Me More</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr><td>Multi-node control & orchestration</td>
|
||||
<td>Ansible is especially strong at expressing complex multi-node
|
||||
deployment processes, executing ordered sequences on
|
||||
different sets of nodes through <a class="reference internal" href="playbooks.html"><em>Playbooks</em></a>. Performing
|
||||
steps on all your webservers, then some steps on your database
|
||||
servers, and then some steps on monitoring servers – all the
|
||||
while sharing variables between them is trivial.</td>
|
||||
</tr>
|
||||
<tr><td>Doesn’t choose sides</td>
|
||||
<td>Modules can be written in Bash, Perl, Python, Ruby, whatever.
|
||||
Playbooks are not a programming language, but a data format.</td>
|
||||
</tr>
|
||||
<tr><td>Infrastructure Is Not Code,
|
||||
Infrastructure Is Data</td>
|
||||
<td>Playbooks are not a programming language, they are designed to be
|
||||
super-easy to write, and easy to audit by non-developers. You
|
||||
will be able to skim and very quickly understand your entire
|
||||
configuration policy.</td>
|
||||
</tr>
|
||||
<tr><td>Three In One</td>
|
||||
<td>Ansible handles multiple command and control
|
||||
problems in one tool. You don’t need to use a config tool, a
|
||||
deployment tool, and yet another ad-hoc parallel task execution
|
||||
tool – Ansible will do all three.</td>
|
||||
</tr>
|
||||
<tr><td>Lower Attack Surface, No Agents</td>
|
||||
<td>Ansible is very secure. Ansible uses SSH as a transport,
|
||||
resulting in a much lower attack surface, and requires no agents
|
||||
to be running on managed machines. If a central server
|
||||
containing your playbooks are comprimised, your nodes are not –
|
||||
which is NOT the case of most other tools, which can, more or
|
||||
less, turn into a botnet. Our security approach is to avoid
|
||||
writing custom crypto code altogether, and rely on the most
|
||||
secure part of the Linux/Unix subsystem that your machines are
|
||||
already using – openssh.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="resources">
|
||||
<h1>Resources<a class="headerlink" href="#resources" title="Permalink to this headline">¶</a></h1>
|
||||
|
|
@ -266,179 +287,77 @@ you with questions about Ansible.</p>
|
|||
<li>See the presentation on <a class="reference external" href="http://speakerdeck.com/u/mpdehaan/p/ansible">Speakerdeck</a></li>
|
||||
<li>Visit the <a class="reference external" href="http://groups.google.com/group/ansible-project">Google Group</a></li>
|
||||
<li>Chat on <a class="reference external" href="http://webchat.freenode.net/?channels=ansible">FreeNode</a></li>
|
||||
<li>Join the <a class="reference external" href="http://groups.google.com/group/ansible-project">Mailing List</a></li>
|
||||
</ul>
|
||||
<img src="http://groups.google.com/intl/en/images/logos/groups_logo_sm.gif" height=30 width=140 alt="Google Groups">
|
||||
<br/>
|
||||
<b>Subscribe to Ansible Project</b>
|
||||
<br/>
|
||||
<form action="http://groups.google.com/group/ansible-project/boxsubscribe">
|
||||
<br/>
|
||||
Email: <input type=text name=email> <input type=submit name="sub" value="Subscribe">
|
||||
<br/></br>
|
||||
</form>
|
||||
<br/></div>
|
||||
<div class="section" id="contents">
|
||||
<h1>Contents<a class="headerlink" href="#contents" title="Permalink to this headline">¶</a></h1>
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="100%" />
|
||||
</colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr><th class="head">What People Are Saying</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr><td>“I’ve been trying to grok Chef these last weeks, and really, I don’t get it. I discovered ansible
|
||||
yesterday at noon, successfully ran it at 1pm, made my first playbook by 2pm, and pushed two small
|
||||
[contributions to the project] before the office closed... Do that with any other config management
|
||||
software!”</td>
|
||||
</tr>
|
||||
<tr><td>“Ansible is much more firewall-friendly. I have a number of hosts that are only accessible via reverse
|
||||
SSH tunnels, and let me tell you getting puppet or chef to play nice with that is a nightmare.”</td>
|
||||
</tr>
|
||||
<tr><td>“This software has really changed my life as an network admin, the simplicity ansible comes with is
|
||||
really childs-play and I really adore its design. No more hassle with SSL keys, DNS based ‘server
|
||||
entries’ (e.g. puppet and what not). Just plain (secure!) SSH keys and one is good to go.”</td>
|
||||
</tr>
|
||||
<tr><td>You may get a kick out of the fact that I’m using ansible to install puppetmaster(s). I’m starting to
|
||||
migrate all my stuff to the much more sensical ansible. Nice work</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
<div class="section" id="documentation">
|
||||
<h1>Documentation<a class="headerlink" href="#documentation" title="Permalink to this headline">¶</a></h1>
|
||||
<div class="toctree-wrapper compound">
|
||||
<ul>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#requirements">Requirements</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#python-2-6-epel-instructions-for-rhel-and-centos-5">Python 2.6 EPEL instructions for RHEL and CentOS 5</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#getting-ansible">Getting Ansible</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstarted.html#running-from-checkout">Running From Checkout</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstarted.html#make-install">Make Install</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstarted.html#via-rpm">Via RPM</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstarted.html#debian-gentoo-arch-others">Debian, Gentoo, Arch, Others</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="gettingstarted.html#tagged-releases">Tagged Releases</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#choosing-between-paramiko-and-native-ssh">Choosing Between Paramiko and Native SSH</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="gettingstarted.html#your-first-commands">Your first commands</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#hosts-and-groups">Hosts and Groups</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#selecting-targets">Selecting Targets</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#host-variables">Host Variables</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#group-variables">Group Variables</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#groups-of-groups-and-group-variables">Groups of Groups, and Group Variables</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#splitting-out-host-and-group-specific-data">Splitting Out Host and Group Specific Data</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="patterns.html#yaml-inventory">YAML Inventory</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#parallelism-and-shell-commands">Parallelism and Shell Commands</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#file-transfer-templating">File Transfer & Templating</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#managing-packages">Managing Packages</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#users-and-groups">Users and Groups</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#deploying-from-source-control">Deploying From Source Control</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#managing-services">Managing Services</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="examples.html#time-limited-background-operations">Time Limited Background Operations</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#apt">apt</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#assemble">assemble</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#authorized-key">authorized_key</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#command">command</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#copy">copy</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#facter">facter</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#fetch">fetch</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#file">file</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#git">git</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#group">group</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#ohai">ohai</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#ping">ping</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#raw">raw</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#id11">service</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#setup">setup</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#shell">shell</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#template">template</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#user">user</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#virt">virt</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#yum">yum</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="modules.html#writing-your-own-modules">Writing your own modules</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="YAMLSyntax.html#yaml-basics">YAML Basics</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#playbook-example">Playbook Example</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#basics">Basics</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#hosts-and-users">Hosts and Users</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#vars-section">Vars section</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="playbooks.html#tasks-list">Tasks list</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#running-operations-on-change">Running Operations On Change</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#include-files-and-reuse">Include Files And Reuse</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#executing-a-playbook">Executing A Playbook</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks.html#tips-and-tricks">Tips and Tricks</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#accessing-complex-variable-data">Accessing Complex Variable Data</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#accessing-information-about-other-hosts">Accessing Information About Other Hosts</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#magic-variables">Magic Variables</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#variable-file-seperation">Variable File Seperation</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#prompting-for-sensitive-data">Prompting For Sensitive Data</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#passing-variables-on-the-command-line">Passing Variables On The Command Line</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#conditional-execution">Conditional Execution</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#conditional-imports">Conditional Imports</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#loop-shorthand">Loop Shorthand</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#selecting-files-and-templates-based-on-variables">Selecting Files And Templates Based On Variables</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#asynchronous-actions-and-polling">Asynchronous Actions and Polling</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#local-playbooks">Local Playbooks</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="playbooks2.html#pull-mode-playbooks">Pull-Mode Playbooks</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="bestpractices.html">Best Practices</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="bestpractices.html#group-by-roles">Group By Roles</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="bestpractices.html#directory-organization">Directory Organization</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="bestpractices.html#bundling-ansible-modules-with-playbooks">Bundling Ansible Modules With Playbooks</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="bestpractices.html#miscellaneous-tips">Miscellaneous Tips</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="api.html#python-api">Python API</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="api.html#detailed-api-example">Detailed API Example</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="api.html#external-inventory">External Inventory</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="api.html#script-conventions">Script Conventions</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="api.html#example-the-cobbler-external-inventory-script">Example: The Cobbler External Inventory Script</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#tutorial">Tutorial</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#testing-modules">Testing Modules</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#reading-input">Reading Input</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#module-provided-facts">Module Provided ‘Facts’</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#common-pitfalls">Common Pitfalls</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#conventions">Conventions</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#shorthand-vs-json">Shorthand Vs JSON</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#sharing-your-module">Sharing Your Module</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="moduledev.html#getting-your-module-into-core">Getting Your Module Into Core</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">FAQ</a><ul>
|
||||
<li class="toctree-l2"><a class="reference internal" href="faq.html#what-inspired-ansible">What inspired Ansible?</a></li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="faq.html#comparisons">Comparisons</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#vs-func">vs Func?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#vs-puppet">vs Puppet?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#vs-chef">vs Chef?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#vs-capistrano-fabric">vs Capistrano/Fabric?</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l2"><a class="reference internal" href="faq.html#other-questions">Other Questions</a><ul>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#what-is-ansible-s-approach-to-security">What is Ansible’s approach to security?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#how-does-ansible-scale">How does Ansible scale?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#are-transports-other-than-ssh-supported">Are transports other than SSH supported?</a></li>
|
||||
<li class="toctree-l3"><a class="reference internal" href="faq.html#what-are-some-ideal-uses-for-ansible">What are some ideal uses for Ansible?</a></li>
|
||||
</ul>
|
||||
</li>
|
||||
</ul>
|
||||
</li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="gettingstarted.html">Getting Started</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="patterns.html">Inventory & Patterns</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="examples.html">Command Line</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="modules.html">Ansible Modules</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="YAMLSyntax.html">YAML Syntax</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks.html">Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="playbooks2.html">Advanced Playbooks</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="bestpractices.html">Best Practices</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="api.html">API & Integrations</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="moduledev.html">Module Development</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="faq.html">FAQ</a></li>
|
||||
<li class="toctree-l1"><a class="reference internal" href="who_uses_ansible.html">Who Uses Ansible</a></li>
|
||||
</ul>
|
||||
</div>
|
||||
</div>
|
||||
<div class="section" id="presented-by">
|
||||
<h1>Presented By...<a class="headerlink" href="#presented-by" title="Permalink to this headline">¶</a></h1>
|
||||
<p>Ansible was created and is run by <a class="reference external" href="http://michaeldehaan.net">Michael DeHaan</a> (<a class="reference external" href="http://twitter.com/#!/laserllama">@laserllama</a>), a Raleigh, NC
|
||||
<table border="1" class="docutils">
|
||||
<colgroup>
|
||||
<col width="100%" />
|
||||
</colgroup>
|
||||
<thead valign="bottom">
|
||||
<tr><th class="head">Presented By...</th>
|
||||
</tr>
|
||||
</thead>
|
||||
<tbody valign="top">
|
||||
<tr><td>Ansible was created and is run by <a class="reference external" href="http://michaeldehaan.net">Michael DeHaan</a>
|
||||
(<a class="reference external" href="http://twitter.com/#!/laserllama">@laserllama</a>), a Raleigh, NC
|
||||
based software developer and architect, who also created the popular
|
||||
DevOps install server <a class="reference external" href="http://cobbler.github.com/">Cobbler</a>.
|
||||
Cobbler is used to deploy mission critical systems all over the
|
||||
planet, in industries ranging from massively multiplayer gaming, core
|
||||
internet infrastructure, finance, chip design, and more. Michael also
|
||||
helped co-author <a class="reference external" href="http://fedorahosted.org/func/">Func</a>, a precursor to Ansible, which is used to
|
||||
orchestrate systems in lots of diverse places. He’s worked on systems
|
||||
helped co-author <a class="reference external" href="http://fedorahosted.org/func/">Func</a>, a precursor to Ansible, which is used
|
||||
to orchestrate systems in lots of diverse places. He’s worked on systems
|
||||
software for IBM, Motorola, Red Hat’s Emerging Technologies Group,
|
||||
Puppet Labs, and is now with <a class="reference external" href="http://rpath.com">rPath</a>. Reach Michael by email <a class="reference external" href="mailto:michael.dehaan%40gmail.com">here</a>.</p>
|
||||
Puppet Labs, and is now with <a class="reference external" href="http://rpath.com">rPath</a>. Reach Michael by email
|
||||
<a class="reference external" href="mailto:michael.dehaan%40gmail.com">here</a>.</td>
|
||||
</tr>
|
||||
</tbody>
|
||||
</table>
|
||||
</div>
|
||||
|
||||
|
||||
|
|
|
|||
220
rst/index.rst
220
rst/index.rst
|
|
@ -1,93 +1,88 @@
|
|||
|
||||
The Future Is Now
|
||||
`````````````````
|
||||
Introducing Ansible
|
||||
```````````````````
|
||||
|
||||
Ansible is a radically simple model-driven configuration management, deployment,
|
||||
and command execution framework. Other tools in this space have been too
|
||||
complicated for too long, require too much bootstrapping, and have too
|
||||
much learning curve. Ansible is dead simple and painless to extend.
|
||||
For comparison, Puppet and Chef have about 60k lines of code.
|
||||
Ansible's core is a little over 2000 lines..
|
||||
and command execution framework. Other tools in this space have been too complicated for too long,
|
||||
require too much bootstrapping, and have too much learning curve. By comparison, Ansible is dead simple
|
||||
and painless to extend. Puppet and Chef have about 60k lines of code. Ansible's core is a little over 2000 lines.
|
||||
|
||||
Ansible isn't just for idempotent configuration -- it's also great for ad-hoc
|
||||
tasks, quickly firing off commands against nodes. See :doc:`examples`.
|
||||
Ansible isn't just for configuration management -- it's also great for ad-hoc tasks, quickly firing off commands against nodes, and it excels at complex multi-node deployment tasks, being designed for that purpose from day one.
|
||||
|
||||
Innovative Multi-node Control
|
||||
`````````````````````````````
|
||||
|
||||
Where Ansible excels though, is expressing complex multi-node
|
||||
deployment processes, executing ordered sequences on
|
||||
different sets of nodes through :doc:`playbooks`. Playbooks contain one or
|
||||
more plays, each executed against a different batch of nodes. Think about
|
||||
webservers, database servers, and backend servers in a multi-node web environment. A play can address each set of machines in a cycle, ensuring the configurations of the machines were correct and also updating them to the specified
|
||||
version of software if required.
|
||||
|
||||
Multi-machine software deployment is poorly solved by most systems management tools -- often due to architectural nature of being pull oriented and having complex ordering systems, they cover configuration but fail at deployment when updating tiers of machines in well defined steps. This results in using two (or more) logically distinct tools and having complex overlap between them.
|
||||
|
||||
If you actually do need pull oriented mode, though, Ansible 0.4 and later can run playbooks in pull mode as well.
|
||||
This is useful in extreme scaling scenarios or when automatic system remediation is desired. Since Ansible remains
|
||||
server and daemonless, scaling potential is unlimited, and no resources are wasted on running management daemons.
|
||||
|
||||
Deployment and Configuration, Unified
|
||||
`````````````````````````````````````
|
||||
|
||||
Other deployment (compared to config) oriented frameworks similarly cover deployment well but lack a strongly defined resource model and devolve into glorified remote scripts. Ansible playbooks -- having been designed with this problem in mind -- are good at both deployment & idempotent configuration, meaning you don't have to spread your infrastructure management out between different tools (Puppet+Capistrano, Chef+Fabric, etc). Performing ordered steps between different classes of machines is no problem, yet our modules affect system state only when required -- while avoiding the problem of fragile scripting that assumes certain starting or ending states.
|
||||
|
||||
Ansible is also unique in other ways. Extending ansible does not require programming in any particular language -- you can write :doc:`modules` as idempotent scripts or programs that return simple JSON. Ansible is also pragmatic, so when you need to, it's also trivially easy to just execute useful shell commands.
|
||||
|
||||
Why use Ansible versus other configuration management tools? (Puppet, Chef, etc?) Ansible will have far
|
||||
less code, it will be (by extension) more correct, and it will be the
|
||||
easiest thing to hack on and use you'll ever see -- regardless of your
|
||||
favorite language of choice. Versus other deployment tools? (Capistrano, Fabric?). Ansible playbooks are easier
|
||||
to use (not being code) and also allows intermixing of idempotent configuration management rules for a higher level
|
||||
of control. Further, it was designed for deploying multi-node applications from the beginning.
|
||||
|
||||
Simple & Secure By Default
|
||||
``````````````````````````
|
||||
|
||||
Compared with most configuration managememnt tools, Ansible is also much more secure. While most configuration management tools use a daemon, running as root with full access to the system, with its own in-house developed PKI infrastructure, Ansible just uses SSH (and supports sudo as neccesssary). There is no additional attack surface and OpenSSH is one of the most peer reviewed security components out there.
|
||||
If a central server containing your playbooks are comprimised, your nodes are not -- which is NOT the case
|
||||
of these other tools, which can, more or less, turn into a botnet. Our security approach is to avoid writing custom
|
||||
crypto code altogether, and rely on the most secure part of the Linux/Unix subsystem that your machines are already using. There is no PKI subsystem to maintain, which can be a frequent source of problems, particularly when reinstalling or migrating
|
||||
hosts.
|
||||
|
||||
Systems management doesn't have to be complicated. Ansible's docs will remain short & simple, and the source will be blindingly obvious. We've learned well from "Infrastructure is Code". Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project -- bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit.
|
||||
Systems management doesn't have to be complicated. We've learned well from the "Infrastructure is Code" movement.
|
||||
Infrastructure should be easy and powerful to command, but it should not look like code, lest it acquire the disadvantages of a software project -- bugs, complexity, and overhead. Infrastructure configurations should be simple, easy to develop, and easy to audit. This is Ansible's philosophy and the main reason it's different. Read on, though, and we'll tell you more.
|
||||
|
||||
+---------------------------------------------------------------------+
|
||||
| Key Features |
|
||||
+=====================================================================+
|
||||
| Dead simple setup |
|
||||
+---------------------------------------------------------------------+
|
||||
| Super fast & parallel by default |
|
||||
+---------------------------------------------------------------------+
|
||||
| No server or client daemons; use existing SSHd out of the box |
|
||||
+---------------------------------------------------------------------+
|
||||
| Supports Kerberized SSH, jump hosts, forwarding, etc |
|
||||
+---------------------------------------------------------------------+
|
||||
| No additional software required on client boxes |
|
||||
+---------------------------------------------------------------------+
|
||||
| Can be easily run from a checkout, no installation required |
|
||||
+---------------------------------------------------------------------+
|
||||
| Modules are idempotent, but you can also easily use shell commands |
|
||||
+---------------------------------------------------------------------+
|
||||
| Modules can be written in ANY language |
|
||||
+---------------------------------------------------------------------+
|
||||
| Awesome API for creating very powerful distributed scripts |
|
||||
+---------------------------------------------------------------------+
|
||||
| Does not have to run remote steps as root |
|
||||
+---------------------------------------------------------------------+
|
||||
| Pluggable transports (SSH is just the default) |
|
||||
+---------------------------------------------------------------------+
|
||||
| Source host info & variables from files or external software |
|
||||
+---------------------------------------------------------------------+
|
||||
| The easiest config management system to use, ever. |
|
||||
+---------------------------------------------------------------------+
|
||||
|
||||
Architecture
|
||||
````````````
|
||||
|
||||
.. image:: http://ansible.github.com/ansible_arch2.jpg
|
||||
:alt: "Architecture Diagram"
|
||||
:width: 800
|
||||
:align: center
|
||||
|
||||
Features
|
||||
````````
|
||||
|
||||
* Dead simple setup
|
||||
* Super fast & parallel by default
|
||||
* No server or client daemons; use existing SSHd out of the box
|
||||
* Supports Kerberized SSH, jump hosts, forwarding, etc
|
||||
* No additional software required on client boxes
|
||||
* Can be easily run from a checkout, no installation required
|
||||
* Modules are idempotent, but you can also easily use shell commands
|
||||
* Modules can be written in ANY language
|
||||
* Awesome API for creating very powerful distributed scripts
|
||||
* Does not have to run remote steps as root
|
||||
* Pluggable transports (SSH is just the default)
|
||||
* Source host info & variables from files or external software
|
||||
* The easiest config management system to use, ever.
|
||||
|
||||
What People Are Saying
|
||||
``````````````````````
|
||||
|
||||
"I've been trying to grok Chef these last weeks, and really, I don't get it. I discovered ansible yesterday at noon, successfully ran it at 1pm, made my first playbook by 2pm, and pushed two small [contributions to the project] before the office closed... Do that with any other config management software!"
|
||||
|
||||
"Ansible is much more firewall-friendly. I have a number of hosts that are only accessible via reverse SSH tunnels, and let me tell you getting puppet or chef to play nice with that is a nightmare."
|
||||
|
||||
"This software has really changed my life as an network admin, the simplicity ansible comes with is really childs-play and I really adore its design. No more hassle with SSL keys, DNS based 'server entries' (e.g. puppet and what not). Just plain (secure!) SSH keys and one is good to go."
|
||||
:alt: "Architecture Diagram"
|
||||
:width: 800
|
||||
:align: center
|
||||
|
||||
+--------------------------------------------------------------------------------------------------------+
|
||||
| Tell Me More |
|
||||
+====================================+===================================================================+
|
||||
| Multi-node control & orchestration | Ansible is especially strong at expressing complex multi-node |
|
||||
| | deployment processes, executing ordered sequences on |
|
||||
| | different sets of nodes through :doc:`playbooks`. Performing |
|
||||
| | steps on all your webservers, then some steps on your database |
|
||||
| | servers, and then some steps on monitoring servers -- all the |
|
||||
| | while sharing variables between them is trivial. |
|
||||
+------------------------------------+-------------------------------------------------------------------+
|
||||
| Doesn't choose sides | Modules can be written in Bash, Perl, Python, Ruby, whatever. |
|
||||
| | Playbooks are not a programming language, but a data format. |
|
||||
+------------------------------------+-------------------------------------------------------------------+
|
||||
| Infrastructure Is Not Code, | Playbooks are not a programming language, they are designed to be |
|
||||
| Infrastructure Is Data | super-easy to write, and easy to audit by non-developers. You |
|
||||
| | will be able to skim and very quickly understand your entire |
|
||||
| | configuration policy. |
|
||||
+------------------------------------+-------------------------------------------------------------------+
|
||||
| Three In One | Ansible handles multiple command and control |
|
||||
| | problems in one tool. You don't need to use a config tool, a |
|
||||
| | deployment tool, and yet another ad-hoc parallel task execution |
|
||||
| | tool -- Ansible will do all three. |
|
||||
+------------------------------------+-------------------------------------------------------------------+
|
||||
| Lower Attack Surface, No Agents | Ansible is very secure. Ansible uses SSH as a transport, |
|
||||
| | resulting in a much lower attack surface, and requires no agents |
|
||||
| | to be running on managed machines. If a central server |
|
||||
| | containing your playbooks are comprimised, your nodes are not -- |
|
||||
| | which is NOT the case of most other tools, which can, more or |
|
||||
| | less, turn into a botnet. Our security approach is to avoid |
|
||||
| | writing custom crypto code altogether, and rely on the most |
|
||||
| | secure part of the Linux/Unix subsystem that your machines are |
|
||||
| | already using -- openssh. |
|
||||
+------------------------------------+-------------------------------------------------------------------+
|
||||
|
||||
Resources
|
||||
`````````
|
||||
|
|
@ -100,26 +95,34 @@ you with questions about Ansible.
|
|||
* See the presentation on `Speakerdeck <http://speakerdeck.com/u/mpdehaan/p/ansible>`_
|
||||
* Visit the `Google Group <http://groups.google.com/group/ansible-project>`_
|
||||
* Chat on `FreeNode <http://webchat.freenode.net/?channels=ansible>`_
|
||||
* Join the `Mailing List <http://groups.google.com/group/ansible-project>`_
|
||||
|
||||
.. raw:: html
|
||||
|
||||
<img src="http://groups.google.com/intl/en/images/logos/groups_logo_sm.gif" height=30 width=140 alt="Google Groups">
|
||||
<br/>
|
||||
<b>Subscribe to Ansible Project</b>
|
||||
<br/>
|
||||
<form action="http://groups.google.com/group/ansible-project/boxsubscribe">
|
||||
<br/>
|
||||
Email: <input type=text name=email> <input type=submit name="sub" value="Subscribe">
|
||||
<br/></br>
|
||||
</form>
|
||||
<br/>
|
||||
+-----------------------------------------------------------------------------------------------------------+
|
||||
| What People Are Saying |
|
||||
+===========================================================================================================+
|
||||
| "I've been trying to grok Chef these last weeks, and really, I don't get it. I discovered ansible |
|
||||
| yesterday at noon, successfully ran it at 1pm, made my first playbook by 2pm, and pushed two small |
|
||||
| [contributions to the project] before the office closed... Do that with any other config management |
|
||||
| software!" |
|
||||
+-----------------------------------------------------------------------------------------------------------+
|
||||
| "Ansible is much more firewall-friendly. I have a number of hosts that are only accessible via reverse |
|
||||
| SSH tunnels, and let me tell you getting puppet or chef to play nice with that is a nightmare." |
|
||||
+-----------------------------------------------------------------------------------------------------------+
|
||||
| "This software has really changed my life as an network admin, the simplicity ansible comes with is |
|
||||
| really childs-play and I really adore its design. No more hassle with SSL keys, DNS based 'server |
|
||||
| entries' (e.g. puppet and what not). Just plain (secure!) SSH keys and one is good to go." |
|
||||
+-----------------------------------------------------------------------------------------------------------+
|
||||
| You may get a kick out of the fact that I'm using ansible to install puppetmaster(s). I'm starting to |
|
||||
| migrate all my stuff to the much more sensical ansible. Nice work |
|
||||
+-----------------------------------------------------------------------------------------------------------+
|
||||
|
||||
|
||||
Contents
|
||||
````````
|
||||
|
||||
Documentation
|
||||
`````````````
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 3
|
||||
:maxdepth: 1
|
||||
|
||||
gettingstarted
|
||||
patterns
|
||||
|
|
@ -134,18 +137,19 @@ Contents
|
|||
faq
|
||||
who_uses_ansible
|
||||
|
||||
Presented By...
|
||||
```````````````
|
||||
|
||||
Ansible was created and is run by `Michael DeHaan <http://michaeldehaan.net>`_ (`@laserllama <http://twitter.com/#!/laserllama>`_), a Raleigh, NC
|
||||
based software developer and architect, who also created the popular
|
||||
DevOps install server `Cobbler <http://cobbler.github.com/>`_.
|
||||
Cobbler is used to deploy mission critical systems all over the
|
||||
planet, in industries ranging from massively multiplayer gaming, core
|
||||
internet infrastructure, finance, chip design, and more. Michael also
|
||||
helped co-author `Func <http://fedorahosted.org/func/>`_, a precursor to Ansible, which is used to
|
||||
orchestrate systems in lots of diverse places. He's worked on systems
|
||||
software for IBM, Motorola, Red Hat's Emerging Technologies Group,
|
||||
Puppet Labs, and is now with `rPath <http://rpath.com>`_. Reach Michael by email `here <mailto:michael.dehaan@gmail.com>`_.
|
||||
|
||||
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
| Presented By... |
|
||||
+==================================================================================================+
|
||||
| Ansible was created and is run by `Michael DeHaan <http://michaeldehaan.net>`_ |
|
||||
| (`@laserllama <http://twitter.com/#!/laserllama>`_), a Raleigh, NC |
|
||||
| based software developer and architect, who also created the popular |
|
||||
| DevOps install server `Cobbler <http://cobbler.github.com/>`_. |
|
||||
| Cobbler is used to deploy mission critical systems all over the |
|
||||
| planet, in industries ranging from massively multiplayer gaming, core |
|
||||
| internet infrastructure, finance, chip design, and more. Michael also |
|
||||
| helped co-author `Func <http://fedorahosted.org/func/>`_, a precursor to Ansible, which is used |
|
||||
| to orchestrate systems in lots of diverse places. He's worked on systems |
|
||||
| software for IBM, Motorola, Red Hat's Emerging Technologies Group, |
|
||||
| Puppet Labs, and is now with `rPath <http://rpath.com>`_. Reach Michael by email |
|
||||
| `here <mailto:michael.dehaan@gmail.com>`_. |
|
||||
+--------------------------------------------------------------------------------------------------+
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue