[afandian]

I went to the Ansible conference in London last year. We were looking into whether or not to use Ansible, thinking that going to the conference would shed some light.

To be honest, we were put off by the (I use this word advisedly) fanboyism. There was a huge amount of "Ansible is amazing!" and (in my opinion) not much actual substance. It felt like there was lots of back-slapping.

Toward the end of the day there was a presentation which presented features (possibly new ones) demonstrating how they were contorting (presumably declarative) YAML into a new programming language with control structures (and templating, my memory is hazy). It felt like "our deployment scripts were over-complicated so we took out the complexity and put it in a declarative non-executable format. Then we had to put the features back because we needed them after all, except now it's in new less powerful language".

Anyway, the conference was informative, but probably not in the way intended.

That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.

[eropple]

This is pretty much where I'm at. By the time you bolt back in everything that Ansible removes "for simplicity" because you realize that, hey, you stepped on that rake and would like to not step on it again, you've more or less reinvented Chef with YAML (I forget who around here called YAML the new S-expressions, but it's uncomfortably true) instead of a usable programming language as your DSL. The overwhelming volume of the community (edit: I called them "fanboys" before, and that's not fair; I think they're unreasonable but I'm not in their heads) makes me wonder at times whether or not it's trying to ignore picking the slower horse by being really enthusiastic about it.

My current client paid me to drop Ansible and rewrite the experimental Ansible service in Chef, and it's under half the lines of committed code in our repo and they don't have to deal with the bogus state of Ansible dependency management.

[mjolk]

>That said, if you can give some substantial reasons why to use Ansible, it would be great to hear them.

I'm using Ansible, but with a handful of powerful plugins that I developed and haven't contributed back (sorry, but I don't have the time to do support for that ugly-ish code).

I use it because:

- Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)

- The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it

- N-number of SSH Bastion/Ansible-runners fed from a git branch scales better than Chef Server

- I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need

- Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"

- I plan on taking the YAML that my team generates and feeding it into a different system and the fact that it's in a popular format makes that easier than the alternatives

I had the same experience as you after attending an AnsibleFest and dialed-back on my time spent supporting users in IRC and contributing to the project after. I expected a collection of hackers and instead came away disheartened by the number of sales or marketing bros/chicks and how corporate-smarmy it all felt.

[eropple]

> - Having an agentless setup is ideal (anyone that tells you that Chef/Puppet agents have never cost him/her time is either a new user or trying to sell you something)

An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage. Most of my clients don't, and chef-server is the closest thing. My own systems use chef-zero, which is agentless; since they're generally immutable servers, this just gets dropped into AWS userdata, much as I do when I use Ansible, for a one-shot configuration and I'm off to the races.

> - The YAML, then Jinja2 parse can be annoying, but it's ultimately not that painful once you're used to it

It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions, to say nothing of a parsed configuration spec that you can do transforms over, is a decent bit more useful in the general case. Faster to write, easier to read, and, over the long term, I tend to think it's easier to maintain.

I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)

> - I'm a Python developer and I've found it reasonably easy to "monkey-patch" in behaviors that I prefer/need

This is really the big plus to Ansible that I can see; if you're a Python person and not a Ruby person, I can see some value here. (I am a Ruby person.)

> - Ansible doesn't force a workflow on you, so you can just focus on "getting shit done"

Chef Zero here too (though Berks tends to be helpful anyway). Running chef-zero over `ssh` is a pretty fair approximation of what most folks use Ansible for.

All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)

[mjolk]

>An agentless setup is ideal iff you have an effective method of service discovery and strongly consistent data storage.

Sure, or use tag and/or have AWS (aws can be used as a node classifier).

>It's significantly worse than "if (var) { block }", though, yeah? I mean, yes, it works, but I think that having a programming language with conventionally understood data structures and functions

I'm not sure what you mean -- it's YAML + Jinja2. It's just powerful enough that you can hand it off to an Ops team and they can get stuff done.

>I mean--I'm a programmer. Programming things is easier for me than maintaining YAML files. =)

Agreed. I actually hit a point that I said "fuck this" and almost just wrote chunks of python to stitch together with jinja includes, then base64, send and run. I didn't because with Ansible, I can just point others at a doc that I don't maintain (not to say the docs aren't garbage).

>(though Berks tends to be helpful anyway)

Ha -- petty, but I hate the amount of memes like "berkshelf" in the Ruby/Chef toolchain. "berks" is enough to make me involuntarily scoff.

>All that said, I'm not saying you shouldn't use Ansible, and I dig that you have some perspective about it. Just offering a different point of view. =)

Didn't take it that way :) I spent over a year with Chef+agent/Chef-zero/Chef-solo, about a year with Puppet, before using Ansible. I find that Ansible "just goes away" with less effort and doesn't just grow until it eats your entire ops team.

[shuzchen]

There are a lot of reasons to use ansible, but in my opinion the one thing that sets it apart from other orchestration frameworks (saltstack, puppet, chef) is that it's agentless. You don't need anything installed on the node servers except for ssh and python 2.4+ (which means pretty much any major distro but coreos). There is no master node to keep up, and no specialized daemons running on the managed nodes.

Because of this difference it's really easy to incorporate into an existing infrastructure with no current frameworks. Pretty much every job i've had started off with a bunch of existing servers they set up ad-hoc, which we then wanted to add automated orchestration to.

It's also really easy to use your defined playbooks against different contexts (just use the hosts file switch to run against staging, or a cluster of test vms, or a bunch of lxc containers).

[eropple]

Chef needs to be installed, but it can be (easily!) run in an agentless mode via chef-solo or chef-zero. It can be installed from Rubygems and requires no master node.

[badmadrad]

I think using sshkit and chef-solo you could easily achive the agentless model ansible provides with a more mature toolset and community. I never really understood peoples aversion towards agents though. You literally can create a golden image with chef-client and your done. There is very little cpu or memory overhead from the chef-client and it only runs when requested unless you run it in daemon mode. I think Ansible capitalized on people's wariness/lack of experience using chef rather than there experience causing them to look for an alternative.

[shuzchen]

Sure, even salt supports an agentless mode, but these are designed as afterthoughts. When you look at all the agentless mode versions of these tools you find that it doesn't fully support everything the framework is capable of (i.e., see the main page of chef-solo). Thus, the adoption is low and you'll likely find breakage as the tool matures (new features being developed without consideration of the audience using it in an agentless mode) and you're likely to find little help when you ask for it. Contrast this with ansible, where this is the basis of the framework, so everything built around it works in agentless mode.

So no, nobody is saying you can't run chef/salt in agentless mode, but in practice nobody wants to because it's a lot of work. And it's not like ansible doesn't also run in a managed-by-master-node mode, that's the entire basis of ansible tower.

And to be clear, it's not that I like ansible because it's agentless. It's because the benefits of the tool being designed-from-the-ground-up as agentless leads itself to beneficial properties.

> You literally can create a golden image with chef-client and your done

This is a lot more work than you let on. That client needs to be configured to point to a particular master node. So yes, you can create a golden image, and it'll talk to one master node, and run on one platform. Good luck getting your golden AMI to run locally in VMWare, or virtualbox, or in a LXC container. Good luck adding in the functionality to make your client dynamically select a different master. It's not impossible, it's just not dead easy. The fact that this is an annoying thing to do is proven by the existence of salt-bootstrap (it's a tool that SSH'es into a node and sets it up as a salt client, hrm, now where else have we seen a tool that manages a node only using ssh?)

> I think Ansible capitalized on people's wariness/lack of experience using chef

I think this is a rather unfair generalization to make. I've personally had many years of production experience with chef/puppet/fabric and the only reason I have no actual production experience with salt is because ansible came out soon after (I still follow their development with interest). In my experience, the people I know who use ansible are neckbeard admin types with battle scars from other orchestration frameworks.

[ryan_lane]

I use SaltStack masterless extensively. It works very well. It's not an after thought and numerous salt contributors use salt in a masterless setup.

[chucky_z]

I can only compare Ansible to Puppet, but I've had great success with rewriting a ton of hacky bash stuff directly in Ansible and having it feel much more 'maintainable.'

Perhaps if you're already using puppet/chef/salt it's not completely worth it to just suddenly switch to it, but it does feel "simple" to use; in my opinion it's worth use over Puppet solely due to the fact that you can really crank up the errors and get good messages.

[boundlessdreamz]

Yeah. Same here. I used puppet but it's documentation is horrible (at least for newbies),the errors are not informative, the simple stuff is complicated and the puppet did not run things in order IIRC. In the end, I had a very fragile puppet based system and some bash scripts which I could not rewrite in puppet.

I moved everything to ansible and couldn't be happier. The documentation is excellent and since ansible executes in the order you specify, the flow is much easier to follow

[vacri]

I had the same problem with puppet (which I ran agentless). One downside to Puppet that Ansible solved for me was no dependency graph. When Puppet breaks, it's error messages are sometimes completely uninformative as to why or even where. When Ansible breaks, you know exactly where it broke and usually why.

The second downside of Puppet was that it freaks the hell out and refuse to work if it sees the same command in two different places. If I have two roles and in those roles I'm installing a single package in the same manner, Puppet throws a wobbly and won't run, even if the conf for them is identical. The official answer is "write a module for anything used twice", but sometimes it's just so trivial.

In any case, I think Ansible is certainly much better suited to small deployments than (agentless) Puppet.

[upbeatlinux]

I went to Ansible Fest 2014 in SF. IMO, the conference was pretty worthless outside talking to DeHaan and a few of the core developers. It was very sales focused and lacked much technical depth (what tech conference actually goes into any depth these days?).

This being said don't let that deter you. Ansible itself is an excellent project. I won't rehash what's already been said but both our dev and ops teams were able to transition off Chef and onto Ansible within a week. The time to onboard is miniscule compared to Chef, Puppet or CFEngine. There's been very little friction building customizing modules or contributing to an otherwise fantastic community.

As someone who moved from CFengine to Puppet to Chef and now Ansible I've been extremely happy.

FWIW, I'd argue that it's easier to fix a Python/YAML/Jinja error in your Ansible play/role/template than it is to try to track down attribute precedence and override issues or Ruby behaviors which aren't very Ruby like in Chef.

[detaro]

Sort of agreed. I'm not convinced the alternatives are actually that much better, and I really like the agent-less design, but it has tripped me up in unexpected ways often enough to be quite wary. ("Why doesn't this variable substitution work?", core modules clobbering config files because they are not allowed to contain specific magic strings, ...) And a lot of it seems like stuff that a better encoding than YAML could probably fix. Right now it feels like an awkward mix of a programming language and a not powerful enough encoding that's great for simpler stuff.