<h1>Frequently Asked Questions<aclass="headerlink"href="#frequently-asked-questions"title="Permalink to this headline">¶</a></h1>
<divclass="section"id="what-inspired-ansible">
<h2>What inspired Ansible?<aclass="headerlink"href="#what-inspired-ansible"title="Permalink to this headline">¶</a></h2>
<p>Back when I worked for Red Hat and working on <aclass="reference external"href="http://cobbler.github.com/">Cobbler</a>, several of us identified a gap between
provisioning (Cobbler) and configuration management solutions (cfengine, Puppet, etc).
There was a need for a way to do ad-hoc tasks efficiently, and various parallel
SSH scripts were not API based enough for us. So we (Adrian Likins, Seth Vidal, and I)
created <aclass="reference external"href="http://fedorahosted.org/func">Func</a>– a secure distributed command framework.</p>
<p>I always wanted to have a configuration management system built on Func, but never
built it due to needing to spend time on Cobbler and other projects.
In the meantime, a John Eckersberg developed Taboot,
a deployment framework of sorts that sat on top of Func, using a YAML syntax very
much like what Ansible now has in <aclass="reference internal"href="playbooks.html"><em>Playbooks</em></a>.</p>
<p>After trying to get Func running again recently at a new company, I got tired
of some SSL and DNS issues and decided to create something a bit simpler, taking
all of the good ideas from Func, and merging them with experience I learned from
working at Puppet Labs. I wanted something that was easy to pick up and was installable
without any bootstrapping, and didn’t suffer from the “I don’t want to learn X” mentality
that often impacted adoption of tools like Puppet and Chef among certain ops teams.</p>
<p>I also spent some time working with a couple of sites that needed to do large webapp deployments,
and noticed how complex various configuration management and deployment tools were to these
companies, compared with what they actually needed. Release processes were too complex
and needed something simple to straighten them out – but I really didn’t want to train
all the dev(ops) on Puppet or Chef, and they really didn’t want to learn them either.</p>
<p>I kept thinking, is there a reason for these programs to be so large and complicated?
Well, systems management is a little complicated, but no. Not really.</p>
<p>Can I build something that a sysadmin can
figure out in 15 minutes and get going, and then extend in any language he knows?
That’s how Ansible was born. It sheds ‘best practices’ for ‘you know your infrastructure
best’, and distills all of the ideas behind all of these other tools to the core.</p>
<p>Not only is Ansible very simple and easy to learn/extend, it’s configuration management, deployment, and ad-hoc tasks all in one app. And I think that makes it pretty powerful. It hasn’t really been done before.</p>
<p>I’d like to know what you think of it. Hop by the mailing list and say hi.</p>
</div>
<divclass="section"id="comparisons">
<h2>Comparisons<aclass="headerlink"href="#comparisons"title="Permalink to this headline">¶</a></h2>
<divclass="section"id="vs-func">
<h3>vs Func?<aclass="headerlink"href="#vs-func"title="Permalink to this headline">¶</a></h3>
<p>Ansible uses SSH by default instead of SSL and custom daemons, and requires
no extra software to run on managed machines. You can also write modules
in any language as long as they return JSON. Ansible’s API, of course, is
heavily inspired by Func. Some features, like delegation hierarchies, are
not supported, but Ansible does have an async mode. Ansible also adds
a configuration management and multinode orchestration layer (<aclass="reference internal"href="playbooks.html"><em>Playbooks</em></a>)
that Func didn’t have.</p>
</div>
<divclass="section"id="vs-puppet">
<h3>vs Puppet?<aclass="headerlink"href="#vs-puppet"title="Permalink to this headline">¶</a></h3>
<p>First off, Ansible wouldn’t have happened without Puppet. Puppet took configuration
management ideas from cfengine and made them sane. However, I still think they can
be simpler.</p>
<p>Ansible playbooks ARE a complete configuration management system. Unlike Puppet, playbooks
are implicitly ordered (more like Chef), but still retain the ability to signal
notification events (like Puppet). This is kind of a ‘best of both worlds’ thing.</p>
<p>There is no central server to promote scaling, and Ansible is
also designed with multi-node deployment in mind from day-one – something that is difficult
for Puppet because of the pull architecture. Ansible is push based,
so you can do things in an ordered fashion, addressing batches of servers
at one time, and you do not have to contend with the DAG. It’s also extensible in any language
and the source is designed so that you don’t have to be an expert programmer to submit a patch.</p>
<p>Ansible’s resources are heavily inspired by Puppet, with the “state” keyword being a more or less
direct port of “ensure” from Puppet. Unlike Puppet, Ansible can be extended in any language,
even bash ... just return some output in JSON format. You don’t need to know Ruby.</p>
<p>Unlike Puppet, hosts are taken out of playbooks when they have a failure. It encourages
‘fail first’, so you can correct the error, instead of configuring as much of the system
as it can. A system shouldn’t be half correct, especially if we’re planning on configuring
other systems that depend on that system.</p>
<p>Ansible also has a VERY short learning curve – but it also has less language constructs and
does not create it’s own programming language. What constructs Ansible does have should be enough to cover 80% or so of the cases of most Puppet users, and it should scale equally well (not having a server is
almost like cheating).</p>
<p>I also suspect some Ansible users will actually use Ansible to trigger Puppet – using the git
module to checkout a Puppet module hierachy from source, and the command module to run
‘puppet apply’. That’s ok too, but you may find playbooks do all you need.</p>
<p>Ansible does support gathering variables from ‘facter’, if installed, and Ansible templates
in jinja2 in a way just like Puppet does with erb.</p>
</div>
<divclass="section"id="vs-chef">
<h3>vs Chef?<aclass="headerlink"href="#vs-chef"title="Permalink to this headline">¶</a></h3>
<p>Much in the ways Ansible is different from Puppet. Chef is notoriously hard
to set up on the server, and requires that you know how to program in Ruby to
use the language. As such, it seems to have a pretty good following mainly
among Rails coders.</p>
<p>Like Chef (and unlike Puppet), Ansible executes configuration tasks in the order
given, rather than having to manually specify a dependency graph. Ansible extends
this though, by allowing triggered notifiers, so Apache can, be restarted if needed,
only once, at the end of a configuration run.</p>
<p>Unlike Chef, Ansible’s playbooks are not a programming language. This means
that you can parse Ansible’s playbooks and treat the instructions as data. It also
means working on your infrastructure is not a development task and testing is easier.</p>
<p>Ansible can be used regardless of your programming language experience. Both
Chef and Puppet are around 60k+ lines of code, while Ansible is a much simpler
program. I believe this strongly leads to more reliable software and a richer
open source community – the code is kept simple so it is easy for anyone to
submit a patch or module.</p>
<p>Just like with puppet, some users may wish to use Ansible to trigger chef-solo to
avoid using the server, after checking out some chef content using Ansible’s git
support.</p>
<p>Ansible does support gathering variables from ‘ohai’, if installed.</p>
</div>
<divclass="section"id="vs-capistrano-fabric">
<h3>vs Capistrano/Fabric?<aclass="headerlink"href="#vs-capistrano-fabric"title="Permalink to this headline">¶</a></h3>
<p>These tools aren’t really well suited to doing idempotent configuration and are
typically about pushing software out for web deployment and automating steps.</p>
<p>Meanwhile Ansible is designed for other types of configuration management, and contains some
advanced scaling features.</p>
<p>The ansible playbook syntax is documented within a page of text and also has a MUCH lower learning curve. And because Ansible is designed for more than pushing webapps, it’s more generally
useful for sysadmins (not just web developers), and can also be used for firing off ad-hoc tasks.</p>
</div>
</div>
<divclass="section"id="other-questions">
<h2>Other Questions<aclass="headerlink"href="#other-questions"title="Permalink to this headline">¶</a></h2>
<divclass="section"id="how-does-ansible-scale">
<h3>How does Ansible scale?<aclass="headerlink"href="#how-does-ansible-scale"title="Permalink to this headline">¶</a></h3>
<p>Whether in single-execution mode or using ansible playbooks, ansible can
run multiple commands in seperate forks, thanks to the magic behind
Python’s multiprocessing module.</p>
<p>If you need to address 500 machines you can decide if you want to try
to contact 5 at a time, or 50 at a time.
It’s up to you and how much power you can throw at it, but it’s heritage
is about handling those kinds of use cases.</p>
<p>There are no daemons so it’s entirely up to you. When you are aren’t using
Ansible, it is not consuming any resources.</p>
<p>If you have 10,000 systems, running a single ansible playbook against all of
them probably isn’t always appropriate, but most users shouldn’t have any problems.
If you want to kick off an async task/module, it’s probably fine.</p>
<p>If you’d like to discuss scaling, please hop on the mailing list.</p>
<h3>Are transports other than SSH supported?<aclass="headerlink"href="#are-transports-other-than-ssh-supported"title="Permalink to this headline">¶</a></h3>
