The main point of the article is true. All configuration management software is lacking in some regard. However, the article ignores the fact that configuration management systems are focused on a much wider swath of OS support than RHEL and Debian based distributions. Most enterprises (and especially large enterprises) have Linux, Solaris, AIX, HP-UX and Windows that they need to manage. Managing more than one solution for configuration management solution is antithetical to a well run infrastructure. The real problem with configuration management solutions is managing the solutions themselves. Most of the widely deployed solutions are based on DSLs making the learning curve steep and the chance for error high. The commercial options (CFengine NOVA, chef and puppet) all offer GUI based management consoles but the solutions are expensive for all and often prohibitively so for smaller shops. It's a crowded space but there is still room for a well designed, easy to deploy, easy to manage commercial solution that solves these problems.
Another commenter here also pointed out Windows and niche Unices. That's probably more the domain of IBM and CA. Cfengine can do it if you want to put in the time. But how often does Cfengine come up on this site? It's too barren by default. A promise lib that targets the EL/Debian majority shop and makes opinions and assumptions based on the smaller problem set would be welcome by many. Even if Windows is in play, it's probably self-contained in most shops. Let the big timers support themselves if you want to unify niche commercial OS.
There is probably a need for a more targeted promise lib for EL/Debian that does some of the simple stuff out of the box. However, it's a slippery slope because part of the problem with the configuration management domain is the mindset you exhibit. Windows and other Unix operating systems are not niches. Excluding operating systems because you don't see them being used or deployed will result in an ever growing list of small point solutions that don't solve very many problems. Then as soon as you outgrow that solution you have a larger problem on your hands.
It's no harder to manage, say, Solaris using CFengine than it is to manage EL/Debian. You're right that CFengine isn't mentioned here very often and that's most likely because it's not new web 2.0 startup-o-fied ruby fanboi cool. It's been around since 1993. So in almost 20 years the problem of configuration management hasn't been solved in a satisfactory manner. It's a very difficult problem to solve.
Thanks for bringing up this important area, Kevin. This is a relatively new and growing field and there is definitely lots of room for improvement.
I was surprised you found "severe incompatibilities" between point releases of CFEngine 3 -- I've been using 3 since 3.0.2 and have not seen severe incompatibilities. What did you run into?
Regarding CFEngine being barren by default -- I know what you mean. CFEngine is a configuration management FRAMEWORK. The CFEngine standard library is an example of using that framework. It does take a bit of work to use all this, but once you do, the benefits are enormous (labor and sanity saving, increased efficiency as a sysadmin, more power over the systems, infrastructure as code, etc. -- all the usual benefits of configuration management, plus the added benefits peculiar to CFEngine - support for over thirty operating systems, small memory and power footprint, very few dependencies and the resulting ability to run on a very wide range of hardware, from embedded to supercomputer).
Is there something you want to do with CFEngine that is not in the standard library? (Please give some concrete examples.) Maybe I could help with that.
FYI, CFEngine, Inc. grew this year from 4 to 30 staff and are still hiring. I think you're going to be seeing a lot from CFEngine the company in the near future.
Incidentally, I'm looking for CFEngine professional service engineers to help with CFEngine 3 deployments. Details at http://www.verticalsysadmin.com/pse.htm
I also run a free 2 hour webinar "Getting Started with CFEngine 3" - email me and I'll let notify you of the next one. aleksey at verticalsysadmin dot com
Configuration Management is an actively growing field right now, all the major players are doing a lot to improve their products. It's going to get better, stick with it.
I believe I started using a 3.x.1 distro package and on the other end a 3.x.5 package if memory serves (this was in April). The minor versions contained tons additional new features. If there's something 3.x.y can't do that 3.x.y+1 can't do, the middle number NEEDS to be incremented to signify this change. The promises from the later tail number would not work on the older one.
Some things I think would be useful to ease Cfenfgine adoption:
* .conf.example files that can be jockeyed around quickly to produce useful working samples within 15 minutes.
Specific areas for the above include: installing a file from cfmaster to a host, installing packages using the native package manager, starting services using the native service manager
* Reading about promise theory and Cfengine lingo is neat and all but if I'm not convinced of the benefits and have it running in 15 minutes, the install process/doc is flawed. Fixing this will get you much more market share.
* All of the above doesn't mean Cfengine can't handle n-th order complexity and diversity. Instead what I am suggesting is to make it very easy to try on in the simplest cases, and wear well with experience and age in tougher environments.
* Some simple config enumerator scripts. Run yum, dpkg, etc and get a list of all packages. Output this into a config file that the user can edit and put into use right away.
I'll dig through your Cfengine examples some time and see how it's going.
Thanks for your thoughtful reply, Kevin. I agree with you on the version numbering, on incrementing the middle number for bigger changes.
I'll talk to the CFEngine, Inc. guys about bundling my example config files into the package, having simple practical workable examples (that one can adopt to ones own use) would go a long way in helping people get started.
Agreed we need to improve the whole "up and off the runway" process.
Thanks again for your constructive feedback.
If you have any suggestions on my Cfengine example collection, drop me a line - aleksey at verticalsysadmin dot com
To be "that guy" this is not at all a new area. CFengine is almost 20 years old and certainly wasn't the first bit of software to try and solve the problem. There is definitely a lot of room for improvement.
Well, shaggy, from my talking to sysadmins at large, most are not using any kind of automated configuration management at all. They are using ssh for loops, and that's their automation. Pushing changes.
So when I say configuration management is a new field, I mean the ideas are just starting to go from niche to wider adoption.
This year was the first year at LISA (Unix sys admin conference) where most people had some kind of configuration management solution -- and LISA is to a large extent early adopters.
So now the early adopters have adopted the technology -- it will take years for the rest of the field to catch up.
Just out of curiosity, I'm not aware of any configuration management software preceeding CFEngine - kindly share?
I agree there is a lot of room for improvement, and I see improvement happening, in all the modern tools, this is great.
There is one thing that will completely fix configuration management in Linux, and that is: all software projects should bundle pre-cooked CM recipes. The problem of course is which CM tool should they support?
Until one tool ends up winning over all (and it does look like Puppet is in the lead) we should probably just start a wiki with "community approved" examples for all popular server software in each CM tool's config language. With some prodding the 3rd party vendors might just pick them up and package them, making it a de-facto standard that ships with the distro. Well, one can dream anyway.
I've been playing with Blueprint (which someone suggested on my comments) + Puppet and am liking this combo quite a bit more than anything else so far.
Wow. So many things incorrect..let's just look at one.
"The set operating systems used in the enterprise is fairly small: RHEL5, RHEL6, Debian 6, Ubuntu LTS."
In germany and portions of europe, add SUSE.
In korea, add HPUX.
If you're in pharma or health insurance, add AIX.
Dealing with enterprises in the US? You also need to deal with Windows environments.
While the problem seems simple, it's extraordinarily complex due to everyone's environment / way of doing things / "special snowflake syndrome".
Sorry if this seems kurt, but i've had to write commercial software in this space. You don't want to know how many times I've gotten in arguments with various enterprises about how stupid is it to do X, Y, or Z. Doesn't matter...your software needs to support it.
It is easy to fall into the trap of imagining all enterprise environments are like your own, and even when "special snowflake syndrome" is based on a false assumption, there are huge differences globally in terms of dominant OSes, even if you only think about Linux.
The original author is largely correct when it comes to the US in my opinion though. That subset of OSes does cover the vast majority of US enterprises on Linux.
"As a Ruby project, it unsurprisingly has vocal hipster fanboys."
This isn't my experience. Puppet Labs certainly doesn't promote their products as hip Ruby projects. That would be counterproductive, since their marketing is aimed at the enterprise sysadmin and his managers.
"in no time flat you’ll start seeing full blown Ruby programs intermingled"
On the puppet-users lists, questions that require writing Ruby are infrequent. For my repository, the filetype breakdown is
The comments about the difficulty of sharing modules rings true. I think the puppet developers made a mistake by not having a way to separate data from the "code" as a core, recommended feature early on. Full-heartedly embracing extlookup a couple years ago might have helped, but that didn't happen either (see http://groups.google.com/group/puppet-users/browse_thread/th... for their reasoning).
We're still building out the plan, and will be sending it out to the community soon for comment, but the basic idea is that parameterized class parameter lookup will automatically consult a hierarchical store like Hiera if values are not supplied directly.
Much like Hiera has now, there will also be an easy function to grab arbitrary data values outside of class parameters.
Kevin, thanks for pointing out many truths about the current state of configuration management. It is indeed a very important topic.
(disclaimer: I work at CFEngine AS)
I agree that there is definitely room for improvement in all the configuration management solutions, although all three major players (CFEngine, Chef and Puppet) have made great progress. For a good overview, I recommend reading the excellent series of articles posted recently by Sean OMeara from Opscode: http://blog.afistfulofservers.net/post/2011/12/30/cfengine-p...
CFEngine 3 has been built with the intention of lasting for decades - as a framework more than a pre-built solution. You mention that "A configuration system should be opinionated", and I fully agree with you. This is one of the reasons reason why I like CFEngine: it is strongly opinionated, and those opinions are based on years of experience and careful thought about the problems of configuration management. You can twist CFEngine's metaphorical arm and have it do anything you want, but life is much easier if you learn to "think in CFEngine" and appreciate all the work that it does for you behind the scenes. Things like normal ordering (https://cfengine.com/manuals/cf3-reference.html#Normal-order...) and the lack of explicit flow control constructs (https://cfengine.com/manuals/cf3-reference.html#Loops-and-li...) are the result of distilling configuration management to its basic concepts, and building a tool based on them.
I should mention, because it seems to be a common misconception, that CFEngine 3 is a completely new and different beast than CFEngine 2. The policy language was completely redesigned, and is now much more extensible, generic and flexible. With CFEngine 3, you can have a top-level policy that says "build me a datacenter", building upon lower-level policies that take care of different components, down to the lowest level where the actual implementation takes place (package installation, editing files, setting permissions, creating users, etc.)
As a framework, CFEngine requires a larger initial investment in time, but once you put in that time, you have a system that allows extreme flexibility and scalability.
Having said this, it is indeed true that there needs to be a good collection of higher-level components that makes it easier for users to get started, and to get a good feeling for the power of the tool. We are working on some ideas and infrastructure that will allow us to address this problem, and on improving the standard libraries (which, by the way, are included by default with CFEngine). The guys at Chef have also done an excellent work in this respect, and you can see a lot of pre-built cookbooks at http://community.opscode.com/cookbooks.
However, the devil in the details! It may be true that "the set operating systems used in the enterprise is fairly small: RHEL5, RHEL6, Debian 6, Ubuntu LTS", but how about the parts that aren't? And even then, those operating systems are used in an infinity of configurations, architectures and layouts. You want a configuration management system that is able to manage 100% of your infrastructure, and this is where the low-level control that you get with a tool like CFEngine gives you a lot of power: you can use the higher-level components for those systems that match, but you can also drill down to specify the details that are necessary for those systems that don't. Plus CFEngine runs literally everywhere - we showed at LISA'11 a proof of concept of CFEngine running in an embedded device, it runs on anything that has a Unix-like operating system, including cygwin under Windows (the commercial version has native Windows support).
Also, CFEngine has a fantastic user and developer community. I invite you to drop by the forums (https://cfengine.com/forum/) if you have specific questions or comments about the tool.
And finally, a shameless plug: my book "Learning CFEngine 3" from O'Reilly is now in Early Release (final version will be out around March). All the examples from the book are available at http://cf-learn.info/code.html.
Yes, I bought your ebook last night pre-rant and gave it a quick once over. It's was pretty low level. I hope you might consider adding some labs at the end to tie it together at some point.
Cfengine looks like it's in for the long haul. I think with a proper framework it would even be useful in the single rack applications I desire. Think Ruby on Rails vs. roll your own everything. That's what I'd like to see on top of something like Cfengine.
Thanks for the feedback on the book. If you have any detailed comments, please let me know, preferably over at http://cf-learn.info/discussion.html.
CFEngine is definitely in for the long haul. There are many users of CFEngine that have built and manage complex infrastructures using it, and have built their own high-level components. We are now starting a more organized effort to bring more of these components to the community.
