[sf-perl] Third party Perl rpms for enterprise Linux distros

[Michael Friedman]

Fred,

My office has run into this often. What we ended up doing, finally, is creating a master configuration for an entire server using cfengine, and then cloning it into a VM, and then running that on a RHEL machine. This adds a couple of layers of indirection, but we're not CPU-bound anyway. 

Benefits of this approach for us:
1. We install our own copy of perl and any CPAN modules once, on the master.
2. Because we're only running virtualized servers, we can control exactly what the VM thinks it has: CPU, Memory, Disk, etc. Each and every one is an exact duplicate, so they all work the same way.
3. Running one VM per server doesn't suck away much performance.
4. Running in a VM isolates us from anything the IT group might do to the server itself.
5. cfengine has a way of updating clones that it has created, so when we install a new CPAN module in the master copy it gets distributed out to all the clones automatically. (Or so I hear -- I don't know if we've tested this yet.)
6. You install things once and then can use them on dozens of servers.
7. Bringing up a new machine is really fast. If it can boot, we just copy the VM to it and fire it up, pre-configured.

Downsides:
a. We've got a guy who is working nearly full-time on making cfengine work, defining what goes into the master copy, etc.
b. Virtualization does slow things down a bit. We're IO-bound, though, so the VM is more than fast enough for us.
c. This works best when you're talking dozens of machines. It's overkill for just a few.

In the end, though, it's just a big wrapper around "don't use the system perl, install your own copy". I think it makes that prospect a bit easier to maintain, though.

-- Mike
______________________________________________________________________________
Mike Friedman | HighWire Press, Stanford Univ | friedman at highwire.stanford.edu

On May 11, 2011, at 1:37 PM, Fred Moyer wrote:

> A repeating theme that I have been seeing with enterprise scale perl
> applications is that deploying rpm based versions of Perl modules in
> production environments has several problems that seem to remain
> unsolved.
> 
> For instance, if you are running a Centos/Fedora production
> environment, and your application depends on a certain version of
> DBIx::Class (used as an example), the following events may happen:
> 
> 1) An update to that module version may become available which is
> incompatible with the version of DBIx::Class that your application is
> tested with.
> 
> 2) If you use CPAN, perlbrew, or cpanminus to install a specific
> version of a module, it may cause compatibility issues with modules
> installed via yum or rpm (this has been documented publicly by the
> Fedora Perl module maintainer).
> 
> 3) If you need to make a slight change to a module which is installed
> as an rpm, that may cause problems as well.
> 
> 4) Updating a module may break another part of the system which
> depended on a specific version, and now you have a broken Linux box.
> 
> In addition, there is the consideration that Fedora/Centos ships a
> threaded version of Perl as the system perl binary, and that can be
> 10-25% slower than a non-threaded version (from benchmarks I have
> run).
> 
> My thinking has gotten me to the point where I believe that installing
> a separate perl binary in /opt or somewhere else can solve all of
> these problems.  However, building a perl rpm takes some elbow grease,
> and additionally one would need a set of rpms built against that
> binary that could be managed via yum/rpm.  ActiveState offers their
> ppm based modules as an alternative solution, but from what I have
> read their set of architectures and support is somewhat limited - you
> can't roll a newer ppm version of a module if you really need it.
> 
> Has anyone seen a good solution to this problem?  The Ovid module on
> CPAN has some rpm generation functionality one can work with, but it
> seems that having a non-system perl rpm is needed as a prerequisite.
> _______________________________________________
> SanFrancisco-pm mailing list
> SanFrancisco-pm at pm.org
> http://mail.pm.org/mailman/listinfo/sanfrancisco-pm