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