Attempt to explain reason for project more on the home page.
This commit is contained in:
Michael DeHaan
parent
ace55c6160
commit
1a5aa89be8
6 changed files with 31 additions and 18 deletions
18
index.html
18
index.html
|
|
@ -171,20 +171,24 @@ 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 1000 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 Examples</em></a>.
|
||||
Where Ansible excels though, is expressing complex multi-node
|
||||
tasks, quickly firing off commands against nodes. See <a class="reference internal" href="examples.html"><em>Command Line Examples</em></a>.</p>
|
||||
<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>.</p>
|
||||
<p>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 scripts or programs that return
|
||||
simple JSON. It’s also trivially easy to just execute useful shell
|
||||
commands.</p>
|
||||
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 could 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>Other deployment 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), and 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 something else? (Puppet, Chef, Capistrano, 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.</p>
|
||||
<p>Systems management doesn’t have to be complicated. Ansible’s docs
|
||||
will remain short & simple, and the source will be blindingly obvious.</p>
|
||||
<p>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>
|
||||
<div class="section" id="architecture">
|
||||
<h2>Architecture<a class="headerlink" href="#architecture" title="Permalink to this headline">¶</a></h2>
|
||||
<img alt=""Architecture Diagram"" src="http://ansible.github.com/ansible_arch.jpg" style="width: 648px; height: 464px;" />
|
||||
|
|
|
|||
|
|
@ -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="id420379"></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
|
||||
<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="id396007"></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>
|
||||
|
|
|
|||
|
|
@ -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="id571043"></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="id421710"></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>
|
||||
|
|
|
|||
|
|
@ -424,9 +424,9 @@ be a relative or absolute path.</li>
|
|||
<ul class="simple">
|
||||
<li>Optionally sets the description of the user</li>
|
||||
</ul>
|
||||
<p><em>gid</em>:</p>
|
||||
<p><em>group</em>:</p>
|
||||
<ul class="simple">
|
||||
<li>Optionally sets the primary group GID. The user module will also be able to manipulate this.</li>
|
||||
<li>Optionally sets the user’s primary group, takes a group name.</li>
|
||||
</ul>
|
||||
<p><em>shell</em>:</p>
|
||||
<ul class="simple">
|
||||
|
|
|
|||
|
|
@ -26,14 +26,20 @@ Ansible's core is a little over 1000 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`.
|
||||
|
||||
Where Ansible excels though, is expressing complex multi-node
|
||||
deployment processes, executing ordered sequences on
|
||||
different sets of nodes through :doc:`playbooks`.
|
||||
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 could 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.
|
||||
|
||||
Extending ansible does not require programming in any particular
|
||||
language -- you can write :doc:`modules` as scripts or programs that return
|
||||
simple JSON. It's also trivially easy to just execute useful shell
|
||||
commands.
|
||||
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.
|
||||
|
||||
Other deployment 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), and 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 something else? (Puppet, Chef, Capistrano, etc?) Ansible will have far
|
||||
less code, it will be (by extension) more correct, and it will be the
|
||||
|
|
@ -41,7 +47,10 @@ easiest thing to hack on and use you'll ever see -- regardless of your
|
|||
favorite language of choice.
|
||||
|
||||
Systems management doesn't have to be complicated. Ansible's docs
|
||||
will remain short & simple, and the source will be blindingly obvious.
|
||||
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.
|
||||
|
||||
|
||||
Architecture
|
||||
````````````
|
||||
|
|
|
|||
File diff suppressed because one or more lines are too long
Loading…
Reference in a new issue