On 26/02/10 11:27, Tommy Butler wrote:
Hello all,
I will be deploying a catalyst app onto several dozens of servers in the
next months, which will probably turn into more than that eventually.
It is a year in the making, and quite complex in terms of all the things
it requires to run (libraries).
Given that, a PAR distribution file seems like a great way to go. Yet
my co-worker told me that this has been frowned on as of late-- that
there has been a shift in opinion about deploying cat apps as PARs.
What's the downside of this? How is this going to pose a problem for
me? Installing from subversion and then CPANning all the required libs
into the system via the makefile is terribly slow and error prone.
There's an obvious negative there. What's the negative with using PAR
when compared to this other method of deployment?
The main problems are that PAR doesn't actually work very well.
Firstly, it is severely broken on perl 5.10.0, so you'll either need to
stick with perl 5.8.x or go to perl 5.10.1. (Or backport fixes from perl
5.10.1 to .0, but there lies insanity.)
Secondly, PAR is a nightmare. It's meant to automatically locate all
your dependencies, but in practice this never finds all of them.
Eg. Building a catalyst_par for a fastcgi-based app is broken out of the
box. (It doesn't pick up Catalyst::ScriptRunner)
So you'll need to go through a long cycle of
* build par
* attempt to run it, and discover which modules are missing
* add those modules to list of extras
* Repeat. A lot.
You'll also need to explicitly list all the /var/lib/* things you need,
like libpq.so, libxml.so, etc as those aren't picked up.. and all their
dependencies manually too.
I really don't like deployment methods that are based on
trial-and-error. It doesn't give me any confidence that we did manage to
find all the extra modules to list as inclusions.. and so you can bet
that there's one more missing, that won't be discovered until your app
is crashing in production.
So, there are some negatives for PAR.
The question is, do they outweigh the negatives for using CPAN to
install random, latest-and-possibly-broken packages via the Makefile
every time?
Some shops have a rule that you must only use the versions of modules
that are available pre-packaged for the operating system.
This gets around the problems of having to install everything by hand,
and also means you get consistent versions of modules..
However it also means you're stuck with a small subset of CPAN, and
usually very old versions as well. (For eg, Debian is still on Catalyst
5.7 I believe.)
My own solution was a fourth option:
Build your own Perl, and all the required modules, installed into a
custom directory - and then ship this with your application.
It'll blow the size out by a hundred meg or so, but at least you know
it'll work, and it's using known-good versions of CPAN modules.
-Toby
_______________________________________________
List: [email protected]
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/[email protected]/
Dev site: http://dev.catalyst.perl.org/
