As others have said, in the end, it's a matter of personal preference (e.g. vim or emacs). You could spend a week reading articles and forum discussions comparing all the different tools; but until you've really used them, it will mostly be an academic exercise. Of course, the particulars of your environment might naturally lend itself to one tool or the other, so it's certainly worth spending some time getting an overview of the "idiom" of each tool.

That said, we are working on moving away from dozens of little homegrown management scripts to Ansible. It just feels "right" to me, like how I would have designed such a system. I like that it's built on top of ssh. Any sysadmin should be fairly intimate with ssh, so why not build your CMS on top of a familiar tool? (But, of course, Ansible is flexible enough that you don't have to use ssh.) I might even go so far as to call it a "platform" rather than a tool. Out of the box, you can quickly get going having it do useful work by reading the docs/tutorials on the website. And just going through those exercises, you'll start to see that there's a ton of flexibility available, which is your option to exercise or not.

And that perhaps is one of the drawbacks. We're actually somewhat in "analysis paralysis" mode with Ansible right now. Because there is so much flexibility, we are constantly second-guessing ourselves the best way to implement our fairly complex and diverse environments. In particular, how to group configuration "profiles". E.g., this server needs to be a DNS master, this server needs to be a DNS slave, this server needs MySQL + DNS slave, this server needs these packages installed, this server needs those packages but not these, etc etc. But I always prefer a tool with too much flexibility over something that forces you in to a specific way of doing things: that makes it our problem, not the tool's.

The only other one I have any experience with is CFEngine. I tried---and I mean really tried---to get something going with CFEngine3. I just couldn't get my head around it. The wacky DSL it uses for expressing configs just wasn't intuitive to me; the whole bootstrapping processes seemed to be overly-complex; I found the documentation managed to be lengthy yet still lack real substance. By contrast: everything I've wanted to do in Ansible I was able to do quickly (and usually in several ways); on the client side, the only thing needed for an Ansible bootstrap is ssh; and the docs for Ansible have met or exceeded all expectations.

My colleague and I were even able to quickly hack on some of the Ansible Python code to add some functionality we wanted. At least the pieces we looked at appeared to be quite straightforward. I have 15 years of C/C++ programming experience and wouldn't even consider messing with the CFEngine code. Maybe it's fine, but the complexity of the rest of the system is enough to scare me away from looking at the source.

To be fair, it was *many* years ago that I looked at CFE3; maybe many of my issues have since been addressed. But, at this point, Ansible checks all my boxes, so that's where we're staying.

Again, that's just my taste/experience. If you have the time, I'd spin up some VMs and play with the different tools. Try to implement some of your key items, see how hard/easy they are.

On Thu, May 12, 2016 at 8:27 AM, Fabian Arrotin arrfab@centos.org wrote:

On 12/05/16 10:21, James Hogarth wrote:

...

On 12 May 2016 at 08:22, Götz Reinicke - IT Koordinator < goetz.reinicke@filmakademie.de> wrote:

...

Hi,

we see a growing need for a better Configuration management for our servers.

Are there any known good resources for a comparison of e.g. Puppet, Chef, Ansible etc?

What would you suggest and why? :)

Puppet is great for central control with automatic runs making systems right and keeping them in line, it's not an orchestration tool though - however it's commonly supplemented with something like rundeck and/or mcollective to assist here.

Chef is great for a ruby house - you'll need to brush up on your ruby as writing cookbooks is heavily tied to the language. Historically it was very debian focused with issues like selinux problems. I believe these have been generally resolved though.

Ansible is a great orchestration tool and excellent for going from base to a configured system. It is less of a tool to keep things inline with a base however with no central automated runs (ignoring Tower which is not FOSS yet).

Ansible is also much simpler to get into given the tasks are just like following through a script for defining how to make a system, as opposed to learning an actual DSL like required for understanding puppet modules.

There's a growing pattern of using ansible for orchestration alongside puppet for definitions as well (there's a specific ansible module to carry out a puppet run).

I've not looked at salt at all personally.

Came across this article a while back: http://www.infoworld.com/article/2609482/data-center/data-center-review-pupp...

+1 on your comments around those ones. After that, it's up to the sysadmin (and also sharing with the group of colleagues working in the infra team) to test and see which one fits the bill. Some people really dislike ansible, while personally I like it more than puppet, but it's also a personal feeling with the tool : do you prefer green or red (and then someone will answer "blue" !) ? both are colors, but we have a preference. Same for cfgmgmt tools, assuming that they do what you want them to do too.

-- Fabian Arrotin The CentOS Project | http://www.centos.org gpg key: 56BEC54E | twitter: @arrfab

---

CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos