Hacker News Reader

Comment by karlmdavis | Hacker News Reader

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.

View on HN

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.

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

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.

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/

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

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.

Reply on news.ycombinator.com