Puppet is *not* cfengine rewritten in Ruby
Konstantin, your assertion that puppet is a “cfengine lookalike written in Ruby,” could not be farther from the truth. There is a long list of reasons why that is not the case; the comparison on the puppet site does a good job at explaining the most important of them.
For me, the most important features of puppet that make it not a cfengine lookalike, and instead a uniquely useful tool, are that
-
configurations can be expressed in a modular fashion, so that you can keep all the bits that make up your webserver config like which packages to install, what config files to put down, which network file systems to mount etc. in one place
-
configuration ‘classes’ can be modified through subclassing and overriding particular aspects of the base class — this feature is incredibly useful and important since it helps keeping duplication to a minimum. It makes it possible, for example, to take a complicated definition of a webserver and change where one of its config files comes from in a very concise manner
-
vastly different conditions on what config to apply to a host are properly separated in the language — the fact that something should only be done for RHEL3 and Solaris hosts becomes an if statement in the configuration whereas what times these should be applied becomes a schedule
-
the configuration of a client is assembled on the server — the client only gets to see its own configuration, not that of the entire site; that obviously is needed to provide some semblance of security
-
the information about a client that the server uses to assemble the client’s config is well-defined in a separate library (facter) and can be easily extended
-
the library of ‘native types’ that is responsible for dealing with low-level config munging can be extended cleanly, and pretty painlessly even for a Ruby n00b (and this is pretty much the only time where it matters in what language puppet is implemented, plus hacking Ruby is actually fun, though that’s clearly a personal preference)
As to whether people should write complex configurations in XML files or not, you’re on your own ;) I wouldn’t want to do that, though I wouldn’t base my choice of tool on file formats alone — more on whether I can understand what I wrote in those files three months from now, which doesn’t just depend on format and XML or not, but also on overall organization and clarity.
Watzmann.Blog by David Lutterkort is licensed under
a Creative Commons Attribution-Share Alike 3.0
United States License.
Generated with Jekyll