CFEngine vs Puppet

There are lots of links online, CFEngine seems to be very powerful and well thought out, it is the grandfather of configuration management. What convinced me to go Puppet:

http://www.oreillynet.com/sysadmin/blog/2007/02/sysadmin_models_1.html

For instance, take one of the big differences between cfengine and Puppet; cfengine focuses mostly on managing textfiles, while Puppet manages semantically more powerful constructs like users, services, and packages. Thus, Puppet has higher-level models than cfengine, and if you accept my premise that model power derives from how high-level it is, that generally makes Puppet a more powerful tool than cfengine.

and

What really sets Puppet apart from Cfengine isn’t that it models higher-level resources instead of files, it’s that it allows you to model the relationships between those resources. Puppet’s lowest layer is responsible for the resource modeling (e.g., what it means to be a User on Solaris vs. OS X), but its language handles the high-level relationships between those resources, including how they’re grouped (e.g., they’re all part of the class of resources that makes apache work) and how they relate (e.g., apache should restart if its configuration file changes, and changes to the file should happen before the service is checked).

Puppet seems to handle more complex tasks, at the possible expense of more complex configuration, at least initially, but it can then handle "higher-level" funtions, like package management. This will be important to us if we are doing cross-platform (Linux as well as FreeBSD) management.

Interesting articles from people who have migrated from CFEngine to Puppet:

http://lists.apple.com/archives/Macos-x-server/2007/Jul/msg00249.html

I view cfengine more as a framework to manage and deploy your own scripts. Cfengine will never allow you say "install the Office package" but will help you deploy a shell script you've written that installs the office package on all of your machines.
I'd say both tools are comparable when distributing flat text configuration files, but once you start doing more high level things like package deployment or if you need a strict order of operations, e.g. Make sure Radmind is installed, then run ktcheck, then run fsdiff, then run lapply, then you should probably focus on Puppet.

Also good transition links:

• http://divisionbyzero.net/blog/2009/01/18/from-cfengine-to-puppet-a-retrospective/
• http://reductivelabs.com/trac/puppet/wiki/TransitioningFromCfengine

Responses

Patrick ✆ to me
show details 4:11 PM 07/08/2010
Hi James,

I must say that I find your article a litle biased towarts puppet, and you clearly did not do your homework about Cfengine, Cfengine can handle installation of packages verry well. even on different platforms and architectures. But this is only on of the many benifits of Cfengine, to name a few:

Cfengine is much much faster the puppet (about 20 times)
Cfengine uses only 30MB of system memory
Cfengine has almost no dependencies.
Cfengine doesnt rely on an external interpreter
Cfengine has a verry good security track record
Cfengine let's you decide howto solve a problem
Cfengine can make your work a lot easier,but you need to learn to understand it's syntax

Maybe you should fiddle arround a litle more with Cfengine and do some more research before you jump to conclusions

I'm not saying that puppet is a bad product, but you should be a little more cautious when putting these kind of thing's online, sure you have a right to an opinion, but in the future make sure that you gathered some solld facts to publish instead of some unfundamented ramblings

Regards,
Patrick
Senior Unix Engineer

Note, I was indeed biased towards puppet, and my main conclusion based on Internet research (as opposed to direct implementation experience) was that puppet has a higher-level model of system concepts and richer configuration language. I never said Cfengine couldn't install packages. I think they are probably very functionally equivalent. I'm willing to concede that cfengine less resource intensive and faster, probably because it doesn't deal with higher level abstractions as succinctly.