
Ansible Simply Kicks Ass - hunvreus
http://devo.ps/blog/2013/07/03/ansible-simply-kicks-ass.html
======
rurounijones
> Doing this with Chef would probably mean chasing down a knife plugin for
> adding Linode support, and would simply require a full Chef stack (say hello
> to RabbitMQ, Solr, CouchDB and a gazillion smaller dependencies)

It is throwaway lines line that where you really need to be careful since, no,
you don't need to RabbitMQ, solr, couchdb etc. You can just use chef-solo
which can also be installed with a one liner (albeit running a remote bash
script)

When comparing two products (especially in an obviously biased manner) you
need to make sure you are 100% correct. Otherwise you weaken your case and
comments like this one turn up.

~~~
tptacek
From the docs:

chef-solo is a limited-functionality version of Chef and does not support the
following:

* Node data storage

* Search indexes

* Centralized distribution of cookbooks

* Environments, including policy settings and cookbook versions

* A centralized API that interacts with and integrates infrastructure components

* Authentication or authorization

* Persistent attributes

~~~
otterley
To be fair, I don't think Ansible has any of those, either.

~~~
mpdehaan2
We're also adding some neat things around authentication and access control in
a forthcoming product release, if you do decide you want those kind of
"serverey" things. See here: [http://www.ansibleworks.com/ansibleworks-
awx/](http://www.ansibleworks.com/ansibleworks-awx/)

But yes, you don't need these, Ansible can exchange variables between hosts in
memory without needing a database, etc.

~~~
23david
Ansible is licensed as GPLv3. But it sounds like AnsibleWorks-awx is a
commercial-only product? Are future 'pro' features going to only be released
and maintained in commercial variants of AnsibleWorks or separate related
projects? Would love more transparency about the relationship between open and
closed-source products at AnsibleWorks.

I made a similar clarifying request on the Ansible user group forum a few
weeks ago but my message was not approved. I believe that these are fair
requests and deserve clarification.

~~~
mpdehaan2
We've posted quite a lot about this to the list in the past, I'm not sure what
happened to your post.

Ansible is GPL, and we're totally going to keep it just the way it is, and
continuing to make it more awesome. (The application is just invoking ansible-
playbook).

Why is it commercial? A lot of the stuff we are building is mainly interesting
to enterprises -- RBAC, reporting, things like that.

The core things everybody needs to use Ansible today, all the modules, are
free software and we will continue to add loads more there. Ansible received
over 50 new modules in the last 2 releases.

~~~
23david
K cool. Thanks for clarifying. Keep up the good work. :-)

------
piffey
Another Ansible convert here. Our entire team uses it, we love it. We have a
semi-unique situation where we have to do a lot of finagling to access some
machines, don't always have control over what sits in front of them, and
frequently have to comply with outside regulations. I won't go into too much
detail, but Ansible is flexible enough and expandable enough to fit our needs.
We were able to have Ansible reading from our custom inventory system in under
a day, have expanded it to tie in with tons of internals, and all with very
minimal effort. What would've taken weeks setting up with Puppet or Chef just
falls into place. It's a beautiful thing. Highly recommend giving it a try,
even if just to have a quick way of setting up your own dev machines.

~~~
benjamincburns
> I won't go into too much detail

Actually, can you? I don't mean can you give me an exact lay of the land, but
what kinds of problems in this arena are you facing? I presently work in gov't
contracting and so far you've defined my exact deployment scenario. That is,
infrastructure architecture requirements (hardware/network config) are ever
changing, and won't stabilize for some time.

If you can't be more specific as to your problems, maybe you could at least
let me know what about Ansible has made this easier to deal with?

------
StavrosK
The only weak point Ansible has is that its documentation doesn't show enough
real-life scenarios. Fortunately, it's really easy to grok and extend when you
see a script, so I wrote this to help:

[http://www.stavros.io/posts/example-provisioning-and-
deploym...](http://www.stavros.io/posts/example-provisioning-and-deployment-
ansible/)

~~~
mpdehaan2
I agree, we need to fold more playbook examples into the docs for sure.

Folks might be interested in checking out [http://github.com/ansible/ansible-
examples](http://github.com/ansible/ansible-examples) for some full-stack use
cases showing playbooks that we do have.

~~~
georgebashi
I've just picked up ansible, and one thing I found lacking was an example
ansible repository with a standard directory layout and config documented on
the site or on github. For example, it's not obvious from the docs that a nice
way to set things up is:

    
    
        site.yml
        ansible.cfg
        hosts
        host_vars/*
        group_vars/*
        roles/*/{files,templates,tasks,handlers,vars}

~~~
mpdehaan2
Have you seen
[http://www.ansibleworks.com/docs/bestpractices.html](http://www.ansibleworks.com/docs/bestpractices.html)
?

Just noticed these don't mention "vars" in the roles directory, do need to fix
that :)

~~~
georgebashi
I hadn't, doh! Thanks. Might be worth adding a link to that at start of the
docs, because I found I was hesitant to start writing yamls without knowing
the "right" structure for them.

------
3amOpsGuy
This is definitely cool but the real hard problem isn't in these simple easily
scripted cases. The real hard to solve problem is managing all the complexity
of similar-but-different hosts.

This article could just as easily have taken the complete opposite view of
Ansible by saying things like "parallel ssh sessions don't scale, strong
encryption costs too much CPU time; push can never work reliably therefore
pull is the only viable model; etc. etc."

I feel one of Ansible's strongest points to champion is the low barrier to
entry. It takes minimal understanding to get going, compare that with at least
1 month hands on with cfengine or perhaps 2 weeks puppet before you would
consider yourself proficient enough. With Ansible it's 20 mins or so.

~~~
mpdehaan2
We've got quite a few users managing hundreds and thousands of hosts, so I'm
not seeing these kinds of compliants. If I would, I'd feel it, but we don't :)

One of the things many people want to do is rolling updates too, and Ansible
is remarkably good at them, having a language that is really good for talking
to load balancers and monitoring and saying, "of this 500 servers, update 50
at a time, and keep my uptime". Folks like AppDynamics are using this to
update all of their infrastructure every 15 minutes, continuously, and it's
pretty cool stuff.

For those folks that do want to do the 'facebook scale' stuff, ansible-pull is
a really good option. One of the features in our upcoming product is a nice
callback that enables this while still preserving centralized reporting.

Happy to have the conversation, but definitely I've never heard the CPU time
compliant. I think the one thing we see is a lot of users are happy that
Ansible is not running when it is not managing anything, rather than having
daemons sucking CPU/RAM/etc, and folks are actually getting a little better
performance from avoiding the thundering herd agent problems.

~~~
MichaelSalib
I just did some consulting on helping another team improve their hadoop
cluster performance and the first thing I noticed is that all 40 boxes in the
cluster were burning a CPU core with a puppet agent process that was running
at 100% CPU for months.

~~~
mpdehaan2
That's one of the nicer things about the no agent setup, when Ansible is not
managing something, there is nothing eating CPU or RAM, and you don't have a
problem with your agents falling over (SSHd is rock solid), so you get out of
the 'managing the management' problem as well as the 'management is effecting
my workload performance' problem.

In particular with virtualization, running a heavy agent on every instance can
add up. (reports of the ruby virtual machine eating 400MB occasionally occur).

------
njharman
Used Chef before. In current gig, it's just me managing stuff. I picked
Ansible over Chef and Puppet cause it's low(no) barrier to entry and
simplicity. Also ability to ad-hoc commands means I didn't have to use another
tool for that.

In the 1year since, Ansible has exploded in capability. It isn't quite as low
barrier anymore (more to config language) but still gobs lower than others.
While adding much sophistication.

I wouldn't even consider Puppet or Chef anymore. Salt or Ansible. Although,
Python guy, so biased more than a little.

------
mncolinlee
Unfortunately, we were forced to toss out Ansible immediately in our tool
selection process because it did not support Windows OS clients without
Cygwin.

Also, none of the "VM lifecycle management" tools we needed like Foreman or
its commercial equivalents had any integrations with Ansible.

These concerns left Ansible dead on arrival for us. It sounds like a decent
tool if it matches your needs.

~~~
mpdehaan2
(note: Ansible creator here)

Yeah, there's no Windows now. If we do it, I'd want it to push powershell over
native means. I'm still not 100% convinced it's something Windows admins want
to do in a large enough number to focus on it, but input is always good and
would be interested in hearing more about use cases folks want.

As for lifecycle, Ansible has significantly less provisioning integration
required than some of the other systems because all you need to do is get your
SSH keys in there -- less bootstrapping. It also has a pluggable inventory
system so you can get your list of hosts/variables from things like EC2 or
OpenStack, so with things like cloud-init, that is usually what folks need.
And there are some modules for spinning up new guests in various systems. (I'd
like to see a vcenter inventory plugin too).

I'm also the original author of Cobbler and there's integration with that on
the provisioning side, and for something else similar, it's largely the case
of writing an inventory plugin and making sure the key is installed.

~~~
csears
I think there is significant demand for a good Windows solutions in this
space. Chef and Puppet have Windows support, but I don't see much community
momentum around it.

Powershell is the obvious choice, and, as of v3, I think it would be a viable
transport for Ansible. If you or anyone on this thread wants to put some ideas
on paper for a PoC, I'd be glad to help. Email in profile.

PS. Thanks for your work on Cobbler. We used it recently for automating VM
template builds.

~~~
kryten
There is already SCOM+SCCM for this but you better have some bars of gold
lying around that you can afford to toss out of the window.

------
sbt
I think you can think of these tools on a spectrum from pull-based to push-
based. I say spectrum, because many of them are in reality hybrid. Tools
running agents are naturally pull-based, where as with push you don't
necessarily need an agent (consider sand blasting ssh commands).

CFEngine is by far the most pull-based tool as it is underpinned by a theory
mandating this behavior. Puppet is pull-based but with more push, Chef is even
more push based, and Ansible and Salt are (I guess) mostly push.

In the end it depends on what is more practical for your situation. If you
have a few machines, then more push will be practical, but the more machines
you have, pull-based solutions scale better.

~~~
mpdehaan2
Slight correction, ansible has a pull based mode, called ansible-pull, which
simply scales with git. It's there if you want it! ansible-pull can also be
easily deployed with regular ansible as well, if you want to do that, there's
an example playbook.

If you want solid reporting with pull mode, we're going to have a product
release in the next month that has a cool callback based feature, where you
get centralized reporting and nodes can still phone in any time and request
configuration of themselves. Easy to bootstrap, it will just require a one-
line wget to invoke a configuration request.

I would not characterize SS as being push based in the same way, one of the
things Ansible is really good at doing is orchestrating things "like an
orchestra", so if you want to talk to the woodwinds, brass, percussion, and
then go BACK to the woodwinds, you can. It's not simply saying this-than-that,
etc. This enables things like the rolling update feature, and doing some
pretty intricate multi-tier work.

One of the major inspirations for Ansible was when I was building Func at Red
Hat and wanting to build a multi-tier architecture management system. I still
strongly believe you need a push based system for that, because you don't want
to wait 30 minutes + 30 minutes + 30 minutes for all of those changes to stack
up.

Some other tools try to solve this by glueing layers on top, with Ansible, at
least the intent is to build that in.

So yeah, I think there are definitely times when you need both.

~~~
sbt
Yes, I think you need both pull and push, the ratio depending on the situation
at hand.

A senior sysadmin once told me that he asked all incoming recruits about what
this proportion generally should be. The answer: 1/6 (16.6%) push and 5/6 pull
(83.3%). I found that answer slightly amusing as it seemed overly general. On
the other hand, he felt very strongly about that point and was quite annoyed
with juniors' natural inclination to use push by default when pull could
practically be used.

------
dschep
The main thing that irks me (last I tried it) is that the pkg repo
functionality uses add-apt-repo. This makes it not work on Debian (6 was
stable at the time) or with any repo that doesn't have a matching src repo.

edit: docs indicate it's still a problem
[http://www.ansibleworks.com/docs/modules.html/#apt-
repositor...](http://www.ansibleworks.com/docs/modules.html/#apt-repository)

~~~
mpdehaan2
We've got a pull request to fix that one up, somewhat in progress -
[https://github.com/ansible/ansible/pull/3117](https://github.com/ansible/ansible/pull/3117).

~~~
dschep
Awesome! Might be switching from Salt soon. I _really_ like that I can just
pip install it.

------
peterwwillis
I'm sorry, but even as fairly smart tech guy this page was not helpful to me.
It didn't tell me anything useful about Ansible. I was left wondering "....
how the hell does it work? how do I use it?" and basically had to investigate
their homepage to figure out why I should care. If it was a sales pitch to get
me interested, it worked, but what the hell are sales pitches doing on HN?

~~~
mpdehaan2
If you want to find out more, perhaps you want to read
[http://ansibleworks.com/docs](http://ansibleworks.com/docs) instead?

~~~
peterwwillis
Well, that's my point... why have a page which basically just says "Ansible is
cool! Go check it out!" I mean, that's cool that they like Ansible, but there
wasn't any real content... it was just link bait, basically. I just find
blatant advertisement or marketing to not be useful. I would rather they have
posted a cool thing you can do with ansible, or really anything of any value
other than a brief outline and a link.

------
serverascode
I love ansible. Very straightforward to use--only problem is it's moving so
fast I can't keep up. :) Good problem to have though.

It's also the first open source project I've committed code to. Huge fan. I
use it to run a small 8 node openstack system, as well as deploy Apache VCL.

------
smoyer
I agree ... Ansible is awesome.

I'm using a single set of playbooks for my infrastructure with Jenkins to
check out changes and push them to production machines. The same
infrastructure definitions are used with Vagrant to give each developer an
exact copy of the production system.

~~~
herge
How do you let jenkins install packages and make changes to the machine?
Passwordless sudo?

~~~
smoyer
I turn off password access to production machines, so nobody accesses them
without a known key anyway. Ansible has its own key installed on the servers
and its account is allowed to sudo without a password.

~~~
herge
So if I can break into your ci machine (or just get jenkins to run random
commands on your prod server, which is probably easier), I then have sudo
access to your prod server?

Using ansible from a local machine is fine, because you can make your devs
type in passwords and etc, but I can't think of a secure way to do it with
continuous integration.

~~~
jessaustin
Don't assume that breaking into his CI instance is easier than breaking into
the prod server. It's probably on a private subnet, in the first place.

------
bsaul
anyone with both ansible and saltstack experience to compare ?

~~~
maheart
I've used and continue to use, both. I like both tools, it's hard to choose
one.

Ansible advantages:

+1 no client required. Python libraries may be required on the client machine
to take advantage of certain modules (e.g. Python's postgresql library to use
some parts of the postgresql module)

+1 roles. A nice, best practice way to package up logical configurations (e.g.
files, templates, tasks).

+1 separate host files for prod/uat/dev/whatever you like. Keep all generic
configuration tasks/roles host-agnostic.

+1 very easy to write (and distribute) additional modules

+1 uses SSH for all transport. I love that it uses something tried and true,
secure, and robust like SSH. Based on comments on Salt's Github, Salt may be
receiving something similar soon. A ZeroMQ mode (aka Fireball mode) is
available in Ansible for speed.

+1 sticks to Linux (Unix?) only. I like that Ansible is not targeting Windows
(for now?); The Windows ecosystem is a very different community; with its own
mindset and tools, and they'd prefer to use their own vs. something from
Linux-land. This also allows Ansible to concentrate on getting really good on
Linux/Unix.

Salt stack advantages:

+1 (+1 +1 +1) allows you to use Python (with Jinja2 templates) to express
logic in configurations. Some people are against this (and tools like Puppet
and Ansible try to hide programming from the user), but I feel this is a
terrible idea. All that you end up doing is writing a configuration language
that's Turing complete [joking!]). Some people will say: logic doesn't belong
in configuration! But when you need to express conditions or loops, let me use
a (standard, i.e. Python) programming language. I don't want to have to learn
your DSL (which only your specific community knows about).

So in summary, I'd love a tool, that has:

\- Ansible's "no client" setup

\- Ansible's logical way to package up configurations (roles)

\- Ansible's separate host file setup

\- Ansible's simplicity of writing (and distributing) modules

\- uses SSH (currently only Ansible, but might be available in Salt shortly)

\- Salt's templating being available in Salt states (Ansible's "playbooks").
__This point alone puts Salt on even ground with Ansible __. I cannot stress
this point enough. This is the reason one of the main reasons I don 't use
Puppet and Chef.

~~~
mpdehaan2
As for logic, to me, it's important that the language remain a data format and
be parseable and auditable, i.e. "human readable for non programmers".

We had one manager describe it as "automation even a manager can understand".
I'm a developer, but I'm jaded about software development, and I definitely
agree with the approach Ansible (and Puppet) take about describing
infrastructure with a model, rather than making it a program. I'm not really
even trying to make it turing complete, I want to create a language that
allows modelling how you want to describe the datacenter, but it's not trying
to be a programming language. In fact, I'm rebelling against it trying.

There's a difference to a developer vs sysadmin mindset, but as something in
between, I want to write applications code when I'm writing code, rather than
writing infrastructure automation code. Code should be minimized, and that
makes things more reliable in the long run, and enforces consistency IMHO.

I'm a little unclear about what you say about putting host specific
information in Ansible roles. Pretty sure you can't do that, but I may be
misunderstanding the question :)

~~~
maheart
Hi Michael, thanks for all your work.

About the second point (host specific information in Ansible roles): I was
referring to this:
[http://www.ansibleworks.com/docs/playbooks.html#roles](http://www.ansibleworks.com/docs/playbooks.html#roles)
\-- I was (incorrectly) under the assumption that you could put host file
variable overrides (as you would in host_vars) under the vars/ section, but it
looks like that's more of a generic, non-host, non-group specific variable
directory? I have edited my comment and removed the incorrect section.

~~~
mpdehaan2
Sure thing -- basically the 'vars/' directory on a role loads in variables
that are always set, basically constants.

------
boothead
One unanswered question for me is how to manager packages on different
systems. Apache for example has a different name on RPM vs apt based systems,
or you might have a different command to go the install (arch vs ubuntu for
example).

Can ansible do this? Can I easily migrate a playbook from using say apt-get to
pacman?

~~~
elbac
Typically your playbooks are more specific then 'do something vague' for
example, install apache. You would say specifically, using 'apt' install the
package 'httpd'.

To see the package managers Ansible supports OOTB look at:

[http://www.ansibleworks.com/docs/modules.html#packaging](http://www.ansibleworks.com/docs/modules.html#packaging)

For examples on how this can be abstracted to handle multiple platforms see:
[http://www.ansibleworks.com/docs/bestpractices.html/#operati...](http://www.ansibleworks.com/docs/bestpractices.html/#operating-
system-and-distribution-variance)

------
voltagex_
I found Ansible quite tricky to use.

I was trying to set up [https://github.com/pas256/ansible-
ec2](https://github.com/pas256/ansible-ec2) to manage some EC2 instances and
it seems like I needed to replace a static config file with a script? Wouldn't
that prevent me doing anything that wasn't EC2 with that instance of Ansible?

Debian also moved the inventory files around in their package so that made
things confusing.

------
minsight
I've been using Ansible in an EC2 environment and it's been fantastic. It's
powerful enough, but its requirements are slight and you don't end up fussing
with bootstrapping it into being. A server with Python (and a few little
things that can be installed via Ansible/Python) will get you to a place where
your instances are being populated.

------
AaronBBrown
I'm very curious about the breakdown of developers versus operations people
who are in the middle of this love affair with Ansible.

~~~
zhynn
I'm ops, but the cool thing about ansible is that it is easy to get devs to
help. They know their software packages, I don't, but I can point them at a
playbook and they can fairly easily fill out the basics, I can work on the
orchestration after they have done the initial playbook design and testing.

Chef (and formerly Puppet) had (for us) a much higher barrier to entry when it
comes to getting an unfamiliar dev on board. We basically had to get reqs from
the dev, and then we would build the recipes.

------
lucaspiller
> means minimal dependency on install (Python is shipped by default with
> Linux).

I love how the Ansible "Getting Started" guide [0] first says you need to
install Puppet 2.6, as 2.4 on CentOS / RHEL is not supported :)

[0]
[http://ansibleworks.com/docs/gettingstarted.html](http://ansibleworks.com/docs/gettingstarted.html)

~~~
IanCal
s/Puppet/Python

There's a _very_ big difference given the nature of this article. I thought
that Ansible was dependent on Puppet and was quite confused.

~~~
mpdehaan2
Yeah the web page does not say that unless you have a really sneaky IRC proxy
in the way :)

Python 2.4 is all you need on remote nodes, but on the control machine you do
need Python 2.6.

~~~
jessaustin
I have also needed a JSON lib installed on the target for python < 2.6. Is
there some way around that?

~~~
mpdehaan2
Easiest is probably to use ansible's "raw" module to install it with yum, by
feeding the [http://](http://) URL to yum, unless you have EPEL already
configured.

------
v5out
We really wanted to use Ansible but couldn't get it to work with
virtualenvwrapper. Has anyone done this (easily)?

~~~
mmgutz
Wierd, I haven't had any issues in my virtualenv. All I did was `pip install
ansible`. The only hiccup was I had to `apt-get install python-dev` on Debian.

~~~
e12e
For those new to python/Debian this is an important point -- with python-dev
and python-virtualenv installed (and also look out for "gcc" and/or "build-
essential") -- generally a virtualenv made with "\--no-site-packages" should
have a fully working "pip" for installing most things.

Gcc is sometimes needed to build (often optional) c extensions.

------
quicksilver03
Is there any automated or semi-automated way to create an /etc/ansible/hosts
file from a ssh config file? Not fully supporting the ssh config file is a
real drag for me, I currently have several dozen hosts configured and I just
don't want to retype everything for ansible to work.

------
GowGuy47
We use this over at useartisan.com and though I'm not one of the Dev ops
oriented people here everyone who is using it seems to be really psyched on
it. Glad people are contributing and it's gaining steam!

------
airtonix
Not ruby therefore instant awesome. Man! I really don't like ruby.

------
vacri
My run-in with Ansible was that it was incredibly slow. What took puppet 1
minute to do took Ansible 7 minutes. Not great for pushing changes. Sure, it
could probably use some tuning, but then we're out of the realm of 'just
works' and into 'chasing down -foo-'. It certainly looks like it has its use-
cases though.

~~~
mpdehaan2
Interesting. I'd like to hear more if you stop by the list and I would have
hoped you would have brought it up so we could have explored more. Still want
to do that.

Not a lot of data to go on in the above, but if you are specifying -c ssh,
ControlPersist is good! Perhaps you were also trying to manage an AWS cloud
from outside AWS. Better to install a control node inside the cloud in that
case. Otherwise, I don't know, maybe a DNS issue? I'd need to know where your
issues were to dig further.

One thing ansible is pretty sharp at is grouping yum transactions, so if you
had every package in a seperate line, with_items is a good thing to use too,
that can make deployments extra zippy.

Another thing you might be interested in is 'fireball mode' which uses SSH for
key exchange and uses a more direct transport for making subsequent changes.

~~~
vacri
Unfortunately I wasn't the one that set it up, so i don't know the details.
The coder who set it up left, and the other coders who picked up his project
were complaining about the time it took to push changes to staging. After
trying it in puppet, it turned out to be much faster, and we moved onto other
things. I don't know any further details, sorry.

