Congrats to the unmitigated badasses on the Ansible team! You know who you be!
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.
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.
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.
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
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.
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).
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.
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.
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. =)
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.
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.