> > On Thu, 14 Apr 2011 16:34:56 +0100, Duncan Garland > <[email protected]> wrote: > > Do we conclude from this that most people use RPMs? >
*Option 1 - RPMs* * * * Many larger places running Redhat/Centos do. It's so that they can automate rollout and rollback and if the upgrade goes wrong they can uninstall the rpm and reinstall the previous one. More lately it's become popular to use a tool like puppet to remote install these to large numbers of target hosts http://www.puppetlabs.com/ * See how to make rpms of CPAN modules by Dave Cross (he gave an excellent talk here at MiltonKeynes.pm on this) http://www.slideshare.net/davorg/perl-in-rpmland-presentation The automatically building repository he runs that holds >100 CPAN modules http://rpm.mag-sol.com If any module you need is missing you can write an rpm .spec file per his instructions and he'll probably add it. *Option 2 - build/deploy infrastructure* An alternative approach you can consider if you have a reasonably heterogenous set of servers is to build sets of shareable system libraries and perls and perl libaries specific to each particular (operating system version, perl version, app name and version). - use perlbrew to build the different versions of perl you require and target them to run from /opt/rh51/myperl588, /opt/rh55/myperl588, /opt/rh55/myperl510, /opt/deb6/myperl512 etc. and not use /usr/lib/perl5 at all (that example is one version of perl5.8.8 for redhat 5.1, one of perl 5.8.8 for redhat 5.5, one for perl 5.10 on redhat 5.5, one for perl 5.12 on debian 6) - install most system libraries like GD to /usr/lib64 and share across all perls (then you can use yum or apt-get to install these) - install problematic system libraries where you need different versions for different perls to specific dirs below /opt/rh51/mylib588, /opt/rh55/mylib510 etc. and have your perlbrew point to the shareable library directories or use LD_LIBRARY_PATH in the environment - use local::lib to create builds of complete sets of CPAN modules your apps need on a per-app and per-perl specific basis, e.g. /opt/rh51/cpan/myperl588/myappfoo, /opt/rh51/cpan/myperl588/myappbar, /opt/rh55/cpan/myperl510/myappfoo, /opt/rh55/cpan/myperl510/myappfoo_v2 - collect all the above onto your build master and then you can easily create a base install image for a particular o/s using g4l and then when you get a new host you image install it then rsync the /opt directories across and start using your apps http://search.cpan.org/perldoc?App::perlbrew http://search.cpan.org/perldoc?local::lib http://sourceforge.net/projects/g4l/ What we're doing in our team at BBC WS is a simpler variant of the second. The main part of the BBC uses the first approach. Regards, Peter http://perl.dragonstaff.co.uk
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
