Why Puppet is Intrinsically Better Than Chef
Two words: it's declarative.
Longer answer: Puppet lets you specify what configuration you want without worrying about how to get it. In that way, it is similar to SQL (where you specify what data to retrieve) or Nagios (where you specify what you want to monitor on the network). This is a higher level of abstraction than a procedural language like Chef -- kind of like saying, "Climb that mountain" without concerning yourself with the details of what approach to take, what gear to bring, etc. (Matter of fact, Chef might make a dandy implementation language for a Puppet clone.)
As someone who has programmed professionally in languages ranging from assembly to Perl, Java, and PHP, dealing with excessive details are a killer in getting projects done fast and done right. You could program a complete implementation of PREMIS metadata in assembly -- but you wouldn't want to. (Or at least, most of us wouldn't.) Most of the time, we developers care mainly about our programming tasks, not the specifics of how you configured your test system(s). Puppet -- unlike Chef -- removes the burden of those specifics from you. Just as a high-level language lets you think in terms of iterating over a set of patients rather than concerning yourself with register allocations, stack management, and so on (the kind of fiddly little details computers excel at handling), Puppet lets you say "what" is to be configured without having to spend skull sweat on the "how".
Does this mean Puppet is without problems? Heck no. (Repeat after me, "There is no silver bullet. There is no silver bullet. There is no silver bullet.") If there are bugs in Puppet (and as a non-trivial program, it will have bugs), you may not end up with the exact configuration you desired. Additionally, Puppet does not encompass the whole universe of software, so you may need to write some software to help Puppet create the configuration you want. (As Puppet is Open Source, if you wish to you can enhance Puppet to do precisely what you need it to do.)
Now, I suspect a lot of system administrators are either thinking that I am preaching to the choir -- or that I'm full of pond water. And that's fine. If we were all little clones of each other (or even big clones of each other) we'd never create the incredible richness of our current software ecosystem. So try Puppet -- you just might like it.
Perl/CPAN user since 1992.
What do you recommend to let Puppet install CPAN modules? I ended up experimenting after stumbling on a server with SunOS 10 that does not even include Perl 5.10, so Puppet would first have to install another Perl (parallel to the existing to not break things).
sex, drugs and rdist.
I've just started using Rex; we have a fair bit of infrastructure written in Perl and I figured that it would be easier to use from a configuration automation system written in Perl.
I wonder where Rex lies on the declarative-imperative continuum relative to Puppet and Chef. You declare tasks which are implemented imperatively, but not being a user of the others I don't know.
I can't comment on the best way to use Puppet to install CPAN modules, but I can say the best practice nowadays is to install a version of Perl for your application use, rather than to build on the Perl that may or may not be installed with the OS. The system Perl should be ignored since it is under control or the system and may be updated at random, breaking your application.
You'll be a lot happier if you ignore the system Perl and just install a version of Perl you like under a user level directory. You'll never need to reach for sudo when installing Perl distributions again!
I'm not sure where the urge to install your own private $X should stop. Do you link against a static libc? Do you force all XS modules to be statically linked? Does "best practice" abhor dynamic linking?
Even if you have to install your own Perl, it would help to know how to do so with Puppet.
By the way my application is a command line application that should be made available to all users at all servers, so installing it as another user is unlikely going to work. I thought that Puppet is great for distributing software - it looks like Perl software is more complicated to distribute (?).
Going to try and answer a bunch of people's questions in one shot.
First off - Puppet is not a build system. It's also not *really* much of a deployment system (though it can be made to be one if you need). It's certainly not an orchestration system, and yes I know about marionette and foreman, and I haven't yet used them, but those aren't puppet so they're out of scope for this comment :)
So...
* Installing your own perl
* It's as easy or difficult as you want to make it. I suggest one of these options:
1. Write a shell script that does it for you and call that using the "exec" resource. Use the "creates" parameter with the directory where you're putting the installed perl. Note that each time perl needs to be installed or upgraded, you're gonna have to wait for it to finish.
2. Create or obtain an RPM or Deb or whatever of the desired Perl that's either relocatable or installs under someplace like /opt or /usr/local and have puppet install that for you with the "package" resource. This is my preference. (see here: http://j.mp/1kqxDCq )
* Static linking a custom-built perl, at least on a RedHat-based system, is just asking for a *world* of pain when you need to install XS-based deps that link against libraries like libnetsnmp or imagemagick or ($deity forbid) Wx!
Per is no harder to distribute than any other piece of software - you just have to package it for the target platform, or provide a simple wrapper script to download/unpack/configure/make/install as you see fit. However, Puppet isn't suited for that kind of "distribution".
Puppet's forte is to take your manifest, a description of what files, packages, and configuration parameters you want on your system, and manipulate the system to make it match what you asked for.
Now, I'm not exactly in love with puppet. It has a *lot* of weaknesses, but if you use it just for its strengths, it's a great, useful tool. Also, learning some ruby to create your own facter plugins and custom resources and functions is invaluable. You'll get a *lot* more out of puppet that way.
One word - perlbrew.