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@xxxxxxxxxx> wrote:
> On 12/05/16 10:21, James Hogarth wrote:
>> On 12 May 2016 at 08:22, Götz Reinicke - IT Koordinator <
>> goetz.reinicke@xxxxxxxxxxxxxxx> 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-puppet-vs-chef-vs-ansible-vs-salt.html
>
> +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@xxxxxxxxxx
> https://lists.centos.org/mailman/listinfo/centos
>
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
