
On Ansible - _pius
http://benscofield.com/on-ansible/
======
WestCoastJustin
Anyone wanting to play around with Ansible should really check out Vagrant
too. Quickly spin up Vagrant instances (VirtualBox, etc VMs) in seconds to
test things. I use Vagrant heavily to test puppet manifests/modules, and have
thrown together several screenscasts about Vagrant @
[http://sysadmincasts.com/episodes/4-vagrant](http://sysadmincasts.com/episodes/4-vagrant)
and one about Learning Puppet with Vagrant @
[http://sysadmincasts.com/episodes/8-learning-puppet-with-
vag...](http://sysadmincasts.com/episodes/8-learning-puppet-with-vagrant) but
you can do the same things with Ansible.

See Vagrant & Ansible docs @
[http://docs.vagrantup.com/v2/provisioning/ansible.html](http://docs.vagrantup.com/v2/provisioning/ansible.html)

~~~
jwn
Agreed, I set up our dev team on Vagrant+Ansible+Github to ensure that we all
have identical development deployment environments. Now pushing out
configuration changes is as simple as doing a git push and telling everyone to
pull and re-deploy their dev hosts.

------
mbenjaminsmith
Hope no one minds me sharing this here:

[http://lattejed.com/first-five-and-a-half-minutes-on-a-
serve...](http://lattejed.com/first-five-and-a-half-minutes-on-a-server-with-
ansible)

I'm not surprised most of the comments are positive. Ansible is a great tool.
I recently started using it and would recommend it without qualification.

The linked post contains a simple Ansible playbook for hardening a virgin
(Linux, Ubuntu in this case) install as well as how to install Ansible (on OS
X) and some of the basics.

~~~
joeyh
I was a bit put off by the very first thing being a download of unverified
source code over a non-encrypted protocol, which was then run as root. Later
worked out that you only did that on the ansible server, not on every server
you deploy, but still.

The use of files in /tmp in the ansible rules is also asking for trouble
(unless ansible goes to lengths to securely write to files in /tmp without eg
following symlinks). debconf-set-selections can read from stdin, or you can
put the file somewhere better.

~~~
mpdehaan2
Just to be clear -- by "unverified source code", you mean a github checkout.
You can definitely clone github by HTTPs if you like.

Ansible does in fact use your home directory for writing files by default and
the locations are not predictable.

There are also OS packages available.

------
rvanniekerk
Can't say enough good things about Ansible. Just finished migrating 90% of our
provisioning scripts away from Chef (they were due an overhaul anyways) to
Ansible.

It feels liberating to say the least and knowing that I no longer have to
train people to use Chef or worry about my remote Chef server going down
unexpectedly is a big benefit.

Ansible:

\- faster

\- drop-dead simple syntax (easily extendable with modules)

\- did I mention modules? There are a TON.

\- readable playbooks

\- just plain fun

------
nwj
We've also been using Ansible where I work and it's great. Chef/Puppet are
probably more powerful, but I also found them more complicated to setup and
use.

Ansible seems to hit this sweet spot between easy of use, flexibility, and
functionality that is really great for people or organizations that are
managing modest numbers of servers. Cases where Chef/Puppet would be overkill.

~~~
julnepht
That is the feeling I get from Ansible, its seems easier to get up and running
but I wonder if it is more powerful than Puppet as you expand beyond the
initial phase. I have been implementing Puppet at work and the ramp up was
hardeous but I am now at a state where I can do powerful things with
Puppet(ENC, Hiera, Dashboard).

------
pjan
If you're new to ansible, I just released a quite extensive set of roles
(basic server setup, security hardening, firewall, mailserver, nginx from
source, oracle jdk, scala, monit, ...) on github [shameless plug]. I was
missing these when I started out, so I hope it will help others. There's even
a complete personal cloudbox setup (including an extensive idiot-proof
tutorial) based on this included, as well as a vagrantbox to test the others.

[https://github.com/pjan/the-ansibles](https://github.com/pjan/the-ansibles)

~~~
mpdehaan2
Thanks for sharing! Looks like you can eliminate the playbooks in the 'roles'
directory with all of the manual includes if you've moved over to roles.

~~~
pjan
Hi Michael. You're welcome.

Tried working with roles, but it didn't allow me the fine-grained control I
was looking for, at least not at the scale I'm currently using them.

I like to have the ability of just adding a new 'role' (wrong official
terminology, but applicable to this use) to a machine (so adding it in a
[x:children] in my examples here) without having to create a
specific/exceptional role for it, yet also keep track of it (rather than just
pointing a role to a machine without an audit trail). - If this makes any
sense (Happy to discuss on another channel if you're willing to :-))

------
smoyer
I had a very similar "epiphany" when I was looking choosing a CM tool (see
[http://www.selesy.com/news/14](http://www.selesy.com/news/14)). I'd add one
reason to your list (and it's a biggie for me) - You don't have to install a
client on every machine. Since I'm already using public/private keys for
access, I'm ready to provision new machines immediately.

Recently I've been pairing Vagrant and Ansible so that developers'
workstations are provisioned by the same playbooks that build the production
infrastructure. This is a huge win as there's no variation in how someone set
up their machine.

My next step is to use Cobbler to actually manage booting new machines and
adding them to specific profiles (the phase prior to Ansible's CM role). In
essence, cobbler provides the hosts file for Ansible.

Nice article and please share tips and tricks as you go!

~~~
bscofield
(Post author here) Re: agents -- yep. I should've called that out explicitly,
as it further supports the provisioning vs. ongoing factor in my decision-
making.

------
karlmdavis
I've been using Puppet on a project for a few months now, and I'm definitely
not 100% on it: it's... very rough around the edges, and far more fussy than
it should be. But it does have one major thing going for it: wide OS support,
specifically including Windows.

Ansible doesn't seem to have this, which makes it a non-starter for me. The
project mentioned above that I'm working on is a build farm, and that farm
includes Ubuntu, RHEL, and Windows boxes. Ansible also doesn't look like it
was designed to shield Playbook writers from the underlying OS much, either.
At least, it doesn't seem to have any analogue to Puppet's OS-independent
`package` resource; Playbooks all call yum or apt specifically.

That's a shame, because it does look a lot simpler to get up & running with.
Learning Puppet and building up useful manifests for it has been a real slog.

~~~
mpdehaan2
Actually ansible has quite a few abstractions available, namely you can use
the 'group_by' module to dynamically select machines by OS, and 'roles' which
allow abstracting away behavior from applying state. The 'when' conditional
can also be used for OS variance.

One thing you may want to look at are the playbooks that we use to set up AWX,
our UI, which works on both CentOS and Ubuntu and has some very different
steps in place.

You can also see some examples in github.com/ansible/ansible-examples

We don't believe in hiding too many OS details from you -- for instance, not
only do package names vary between distributions but think about how Apache is
managed so very differently between Ubuntu and CentOS -- in fact, we've
observed in many cases that trying to pave over those things can make content
a lot harder to work on.

Generally people know what infrastructure they are running on and I think it's
best when you take advantage of that, though you can easily have certain steps
(see the 'when' conditional) that apply to specific OSes.

Another thing Ansible does is make it easy to do conditionals at runtime, such
as "if this file is present, then do this", etc.

~~~
karlmdavis
Sorry, but I'm not finding a link to those playbooks anywhere in the Ansible
docs. The only cross-platform example I could find in the examples was the
riak one [1].

Based on that example and the modules you mentioned, I'm guessing that the
only real mechanism for multi-OS playbooks are separate sets of YAML files for
each OS? If so, that's not exactly a great abstraction, though I'll agree it
is workable. Still seems to be leaving Windows out in the cold altogether, as
well, which is a show-stopper for my mixed environments.

[1] [https://github.com/ansible/ansible-
examples/tree/master/riak](https://github.com/ansible/ansible-
examples/tree/master/riak)

~~~
mpdehaan2
Edited my response above a bit.

We're going to be adding Windows support this year but have been concentrating
on *nix operating systems as that's the core of our user base.

Definitely would like feedback on what specifically on Windows you are
managing and for what use cases.

~~~
karlmdavis
Well, I've got two main use cases for configuration management tools: 1)
managing CI build farms, and 2) managing my home network.

Both of those environments are mixed-OS. The build farms are composed of a
Jenkins master with multiple slaves of various OSes: Ubuntu, RHEL, and
Windows. My home network is running Kerberos and OpenAFS (amongst many other
random things [1]) on Ubuntu and Windows.

> We don't believe in hiding too many OS details from you -- for instance, not
> only do package names vary between distributions but think about how Apache
> is managed so very differently between Ubuntu and CentOS -- in fact, we've
> observed in many cases that trying to pave over those things can make
> content a lot harder to work on.

I don't know... the Puppet module for Apache [2] seems to do a reasonably good
job of managing this. Admittedly, pretty much none of the "main" Puppet
modules support Windows, but the underlying resource system absolutely does,
so adding that support is just a matter of submitting pull requests to the
modules.

[1] Everything's documented here:
[https://justdavis.com/karl/it/](https://justdavis.com/karl/it/)

[2]
[https://forge.puppetlabs.com/puppetlabs/apache](https://forge.puppetlabs.com/puppetlabs/apache)

~~~
mpdehaan2
Yeah that's in a module. This would be akin to a role in Ansible.

If you are looking at the core language for either, it doesn't hide those
things but you can put whatever logic you want in the
role/playbook/manifest/etc.

Hope this explains things!

Thanks for more info.

------
mattjaynes
Just finished writing a book where I compare the experience of using Puppet,
Chef, Salt, and Ansible. I use each tool to build an identical system so you
can get a sense of how each one approaches the same problem.

The most valuable thing I got from that project was my introduction to
Ansible. It was really a shining star in the pack.

I have to give credit to its predecessors (CFEngine/Puppet/Chef) and its
competitor Salt all for being great tools in their own right. But it is
Ansible that has the power and simplicity to really take on the ultimate
competitor: manual installs and hodge-podge shell scripts.

Many of you would be shocked at how many tech companies still don't use any
kind of configuration management (CM) tool.

When you think about it, a company's server setup is essentially the
foundational "app" that the actual business app runs on. So, not using a CM
tool is kinda like having no tests and no version control for your most
important software.

Sound insane? It is.

Most developers would laugh at a company that had zero tests and didn't
version control or even backup their code. But that's exactly what many
companies do with their systems.

Yet, for many businesses, they don't realize the astronomical risks and costs
of this neglect.

At a recent client job, the former system administrator set up all their
servers manually and left ZERO documentation. I had to spend a few weeks
devining what he did and try to capture everything into a CM tool (Chef in
this case). Not one week after I finished doing that, one of their key servers
inexplicably failed. Fortunately, I had done the work needed and they were
able to bring up a replacement within minutes. Had that work not been done,
the company would have been severly crippled and might have even died due to
the days of downtime that would have been inevitable.

That's just a tiny example. The cost savings for a business are huge when the
team uses a CM tool. When it takes a couple minutes to bring up a new server
instead of hours/days/weeks, that's a huge savings (assuming your engineers
cost greater than $0).

With Ansible, there is no more an excuse for not using a CM tool. It's so
simple that it can actually be _easier_ than doing a manual install or writing
a shell script. Some of the more complex CM tools take difficult weeks to
learn, but with Ansible you can be up and running with confidence in a couple
hours.

Not only that, but Ansible gives you robust remote execution capabilities
right out of the box along with a lot of other cool stuff.

Shameless plug:

If you want to see Ansible in action and how it compares to the other CM
tools, check out my book. Just barely launched a few days ago:
[http://devopsu.com/books/taste-test-puppet-chef-salt-
stack-a...](http://devopsu.com/books/taste-test-puppet-chef-salt-stack-
ansible.html)

~~~
DannoHung
I'm probably going to buy your book because getting our servers to be managed
in a sane way is something I'm slowly trying to drive at our company. But I
noticed you mentioned that if you have more than 100 servers then it's not
really a great resource for understanding what's going on with the different
tools.

Where _can_ I gain that perspective?

~~~
mattjaynes
Hi Dan,

It really depends on your situation. Please shoot me an email and we can
discuss in more detail: matt@nanobeep.com

All of the tools will scale to at least several thousand servers, but they
each have slightly different ways of doing it.

I'd recommend choosing the tool that makes the most sense for you at your
current scale since they all can probably scale to what you need.

I mention that the book is for folks with less than 100 servers because I
don't go into how to set up these tools for higher scale in the book.

So, to get the info on how to scale up to very large pools of servers it'd
probably be best to first pick a tool and then look at its specific
documentation for scaling up.

------
jonpaul
Shameless plug (just wrote it yesterday): Getting Started with Ansible on
Digital Ocean - [http://procbits.com/2013/09/08/getting-started-with-
ansible-...](http://procbits.com/2013/09/08/getting-started-with-ansible-
digital-ocean) (instructions will work with just about any remote Linux
server)

------
nitins
Yes, found Ansible to be really simple compared to salt stack which I used
earlier.

~~~
bastop
I'm finding quite the opposite. IMHO saltstack, more importantly sls files are
insanely simple and clear whereas ansible playbooks appear very "busy" for
lack of a better term. It's likely a personal preference in my case but I've
found salt to have a relatively clean interface and to be very readable even
when coupled with templating.

~~~
mpdehaan2
Ansible is generally designed around being maximally auditable. For instance,
an IT manager said he can write a list of tasks and take them to someone and
it's easy for him, not knowing Ansible, to see what is going on. That's
important to us because they are quick to prototype and don't end up looking
like Perl.

Generally we discourage templating except in playbooks, because we don't like
the idea of playbooks turning into code, and I don't like the idea of mixing a
lot of Jinja2 syntax along with YAML syntax at the same time.

Playbooks can be broken up into small files if they get long.

This also keeps them machine readable, so if you wanted to later write a
script to analyze them, you could. So it's very important for us that our
files are actually valid YAML.

Because they are, they aren't a description that gets compiled for one server
at a time, but are instead a process, so it's easy to have the steps on one
server influence a server later on down the line.

I'm not sure of an example of a 'busy' playbook you've seen, but I'd suspect
it's probably just needing some whitespace in between lines.

To me, while they may have taken some interesting choices here and there, I
don't care for their format since it seems to have taken Puppet syntax and
made it more obscure -- and the idea of mixing template loops and such in
there and having two interlaced languages is too much.

------
sohooo
The widespread use of Puppet also has some benefits:

\- lots of documentation

\- Foreman ( [http://theforeman.org/](http://theforeman.org/) , backed by
Redhat) as a great alternative to Puppet Enterprise

\- projects like GitHub's Boxen (
[http://boxen.github.com/](http://boxen.github.com/) ) to bootstrap your devel
machine

\- a large repository of modules available:
[https://forge.puppetlabs.com/](https://forge.puppetlabs.com/)

\- a couple of books, training, conference, if you like those things

However, I'm very aware of those ugly warts, so there's a lot of potential for
a successor.

~~~
mpdehaan2
Yeah, to us it's not just a configuration focus.

One of the focuses in creating Ansible was to have an easy-to-use system where
it was just as easy to push apps, so you don't have to strap things like
Fabric and Capistrano on top.

Another major example is how easy it is to do zero-downtime rolling upgrades
on top, from the core language, without having to provide any glue on top to
get there -- so it can easily say "target 50 out of my 500 servers at once",
and work with load balancing and outage windows to walk across your
infrastructure and upgrade production applications.

------
bradhe
Ansible is great, but I've just burned an entire day (well, half a day)
fighting bugs in it after doing a pip install --upgrade. So IMHO: The model is
sound but it's still really unstable.

~~~
mpdehaan2
Hmm, that's interesting, and not something I hear often at all. What github
bugs have you filed? Have you stopped by the mailing list to ask for help?

------
bradleyland
Sprinkle deserves a mention if you're looking for to visioning only. It's
Ruby, so it may be more appealing for Rubyists.

* DSL and wrappers for common shell tasks

* Uses Capistrano, which you're probably already familiar with

* Uses eRB for templates (more familiar friends)

* Does not require Ruby on the server

* Simple application structure (easy to extend)

[https://github.com/sprinkle-tool/sprinkle](https://github.com/sprinkle-
tool/sprinkle)

------
drsintoma
the thing that keeps me away from ansible is the pricing model. I find
100$/year/server way too much. and nobody can ensure me that the OSS version
is all I'll always need.

~~~
andrewflnr
I find this a curious objection. Would you still have hesitated when, as was
the case until very recently, there was only the OSS version?

~~~
drsintoma
Probably I wouldn't have. I now they have to monetize the product, and for a
software with simplicity as the strongest selling point, doing it through
consulting/support I guess would be a conflict of interests. But when I saw
the prices I was a bit shocked, and made me doubt about the company's strategy
in the long term.

~~~
mpdehaan2
Hey guys, I'd suggest you look at some competitors for pricing and come back
with me, they aren't really that different.

We're not going to be holding back on anything in Ansible, in fact, we're
seeing several hundred contributors each month and are adding an average of 20
new modules to core each release.

This release also adds role dependencies and lots of nice new performance
features.

For those looking for better solutions to things from proprietary software
vendors, this provides a lot of options. If you're looking to not need those
kind of features, Ansible is still there.

One thing we're not going to do is keep making Ansible more and more
complicated over time -- there's a major focus on keeping it simple. When I
started this project I said "if I can make a consultancy out of this I'm doing
it wrong" :)

Actually being a company is good for us -- it allows us to hire extra people
to work on Ansible, and it's allowing us to do more for the community not
less!

------
andyl
I converted from Puppet to Ansible - best decision ever. Much easier to
maintain - much easier to train others.

------
benatkin
Ansible still has this problem:
[http://david.heinemeierhansson.com/posts/6-why-theres-no-
rai...](http://david.heinemeierhansson.com/posts/6-why-theres-no-rails-inc)

It's also GPLv3. The WordPress community (oops nevermind, they aren't in the
community because Matt Mullenweg says they aren't </s>) has plenty of problems
with GPLv2. The GPLv3 is even longer and has more possible interpretations.
I'm sure someone could interpret the GPLv3 such that YAML playbooks are GPLv3.

~~~
deckiedan
YAML playbooks can be under whatever licence you choose.

They aren't /linked/ in to or in any way part of ansible.

They are completely input to ansible. Saying that playbooks would be
'infected' or something is absurd. It would be like saying if I use GNU tar to
compress a file, that file is now GPL.

And, after all that, even if your playbooks were GPL, there is no reason at
all that you'd have to release them. It's perfectly fine to have internal non-
released mods to GPL software.

~~~
benatkin
Most of the talk about linking is gone from the GPLv3. It's mentioned multiple
times in the GPLv2 [1] but only once in the GPLv3 [2]. This to me means that
it doesn't matter much whether it's a compiler or an interpreter.

As for your tar example, the input to tar, to me, is pretty clearly data. The
YAML from ansible, on the other hand, straddles the line between code and
data. If I consider it to be code, though, in most cases it calls out to
Ansible's GPLed modules. If it was Python doing this it would be pretty clear
to me that it would fall under the GPL. I'm not sure I see the distinction
between a sequence of function calls in Python and a sequence of tasks in YAML
for ansible.

When you flatly state that "YAML playbooks can be under whatever license you
choose" you are doing something common in the GPL world, which is making a
specific interpretation for the GPL for a specific project. This has been done
with WordPress. The distinction between JavaScript, CSS, and PHP code has been
made by the leaders of the WordPress project. It doesn't come directly from
the GPL. I don't like this at all. I think if they want specific rules they
should state them in the license, and not do some hand waving so it looks like
they're just using a standard license.

[1]
[http://www.gnu.org/licenses/lgpl-2.1.html](http://www.gnu.org/licenses/lgpl-2.1.html)
[2]
[http://www.gnu.org/licenses/gpl.html](http://www.gnu.org/licenses/gpl.html)

~~~
deckiedan
GPL3 - .5:

> 'A compilation of a covered work with other separate and independent works,
> > which are not by their nature extensions of the covered work, and which
> are > not combined with it such as to form a larger program, in or on a
> volume of > a storage or distribution medium, is called an “aggregate” if
> the > compilation and its resulting copyright are not used to limit the
> access or > legal rights of the compilation's users beyond what the
> individual works > permit. Inclusion of a covered work in an aggregate does
> not cause this > License to apply to the other parts of the aggregate.'

Doesn't that cover it pretty much?

You can distribute a GPL program, such as Ansible, and even bundle it _with_
your playbooks, modules, etc, as those are explicitly NOT extensions of
ansible, they are separate, you now have an "aggregate". And as long as you
aren't modifying the original GPL program, then "Inclusion of a covered work
in an aggregate does not cause this License to apply to the other parts of the
aggregate". So you could licence your modules and playbooks in whatever
licence you want. To be honest though, you don't need to licence them at all,
if they are just for internal company use. And if you're going to distribute
them, it doens't matter what licence it is.

Next, you aren't actually in 90% of circumstances, actually distributing
ansible, or your playbooks. You're running it yourself (either you, or your
company). That's actually one nice thing about it, you aren't installing
extraneous software on the machines you're managing.

GPL covers the distribution of software, and requires the source to also be
distributed along side it. It does not cover the use of it.

Wordpress, et al, are a slightly different situation. There, you actually are
distributing and installing it on multiple computers. You're also distributing
parts of it, in that quite a bit of it (javascript, templates, etc) are going
to and from client machines, and even running bits of it on client computers.
It's a bit more complicated.

