Suggestions For Config Management Tool

Home » CentOS » Suggestions For Config Management Tool
CentOS 9 Comments

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? :)

Thanks and Regards . Götz

9 thoughts on - Suggestions For Config Management Tool

  • 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

  • Ansible is now owned by Redhat so I would expect its feature set to be specifically aligned towards the administration of RHEL type operating systems over time.

    We’ve previously been using Saltstack to great effect but we are gently sliding towards Ansible. Both are YAML defined and coded in python which makes life really easy.

    I believe Chef and Puppet to be demons incarnate. Only ruby mavens seems to be able to effect any kind of control on these beasts. Ruby is the work of satan.

    Cheers,

    Andrew

  • Personally, I think it is important to try one in a prototype mode. There are many changes to how you operate systems as you bring in configuration management that any of the packages you propose should be an improvement over running scripts or hand configuration.

    We chose Puppet around 3 years ago and have been very happy with it, managing 10,000s of machines with it. We’ve got over 200 people making regular changes to the configurations and a lot of good upstream modules in production.

    I don’t think there is one size fits all but the tools you suggest have all been used successfully.

    Tim

  • Hi,

    I’ve chosen ansible over the others for two particular reasons:
    – you can quickly dive into it. I think it’s the easier to use at first being a complete beginner in config management tools.
    – no daemon server or client side.

    HTH, Laurent.

    Le 12 mai 2016 09:22:09 GMT+02:00, “Götz Reinicke – IT Koordinator” a écrit :


    Sent from my Android device with K-9 Mail. Please excuse my brevity.

  • –11l6CABTaQ1j7M5OptgroWNp4GffAvraG
    Content-Type: text/plain; charset=windows-1252
    Content-Transfer-Encoding: quoted-printable

    +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.

  • 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.

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

  • https://bitbucket.org/gordonmessmer/config-comparison/overview

    I wrote one for my current employer, when I started, in order to get consensus from my coworkers on which system to use. The comparison described a specific set of tasks that were common, under 5 config management systems.

    Obviously, I do not have extensive experience with all of the systems, and some of the solutions described may not be the solutions that an expert would provide. If anyone wants to submit changes, I’ll add them. Also, the document is somewhat out of date. Since I wrote it, I’ve submitted a substantial number of fixes to bcfg2 to address almost all of the deficiencies that I identified.

    If I were in that position again, though, I think Ansible would be the easy choice. There are a whole lot of things I like about bcfg2, but development is mostly inactive.

  • We currently use puppet at work, but it’s a situation I inherited and my colleagues are fine with it (and, truthfully, it does some things very well).

    That said, I used cfengine 1 then 2 and then 3 at prior gigs. The language for cfengine 3 is “backwards” from prior versions, but it’s really powerful (much more so than puppet’s in many cases), esp. its built-in recursion abilities.

    Bootstrapping cfengine is complex — true. Documentation lengthy … lack real substance — often true.

    I’ve found the best tutorial for cfengine’s language to be the standard cfengine library (cfengine_stdlib.cf). It shows some best practices and neat tricks that the documentation really doesn’t explain.

  • Hi,

    As no one else seem to have mentioned it, I would highly recommend https://saltstack.com/community/ particularly in you have good in house python skills. It is easy to get started but also amazingly flexible. It has a helpful active community.