|Do you know where your variables are?|
I got bitten this week with the Better Way(tm) bug after a clients server had to be swapped out to a new system. I realized that I really didn't want to have to remember and do all the hand (re)placement of files in all the various directories like I had in the past. I remembered hearing and reading a little bit about PAR and thought I would give it a try.
PAR stands for Perl ARchive. A PAR is a zip file of your application and/or a stand alone executable. When used in conjunction with Apache::PAR it mimics in some ways how a Java WAR (web archive) file works.
This is a summary of my inital experience with the above modules. PAR and especially Apache::PAR are emerging Perl tools that are still improving so this document maybe out of date sooner rather then later. Anyway on to the fun.
Current application deployment model was less then perfect, relied on installing modules and scripts in several directories that might not be available on server that are not owned or operated by my client.
Put as much of the application components as possible into a single directory structure and turn that into a PAR file, which in turn can be used by Apache::PAR (Apache::PAR only works on a mod_perl enabled server)
The first step is good development practice regardless of whether you want to use PAR or not, but it is required if you want to use PAR. Which is move all your files into a single directory tree. The PAR documentation outlines the directories followed by default (you can add anything you like beyond the *magic* ones), these are important because they will be auto included in your @INC (lib location), or used as the default location of scripts. See PAR docs for complete details.
In my case I didn't want to disrupt my current development model in case something went horribly wrong so I created a script to pull in my existing files (or update in the future) to create my par and then copy it to its final location. The final location is something that you will want to give some thought to since the web server will need to access it, but you don't want to make it available for download most likely.
So what you will wind up with is something like this:
Once you have your files in place you can create the PAR itself. There are a number of ways you can do this and various parameters you can pass to get different files or locations included. My needs and personal taste allowed for:
As you might notice a PAR is really "just" a zip file and can be created with the zip utility. If you need to include core modules or CPAN modules outside of your directory tree you will need to use the par.pl utility to create you PAR file, again the documentation covers this in detail.
Add Apache::PAR to the Mix
Now that we have the PAR file we can add it as a self contained unit to Apache with just a copy of changes to the httpd.conf file or your perl startup file**.
See the Apache;:PAR docs for details on this. Basically I did this:
1) Inside of my web.conf file I put:
The ##PARFILE## is replaced with the name of par file it found the web.conf in. See below for issues with Embperl pages and an alternate work around. 2) Inside of my perl startup file I added:
That is all that is required for the magic to happen. Notice the location is a directory and not a file. You can specify a single .par file if you need to, you specific a directory all .par files will be included. The 'Alias' directive is important because it tells
The process above works fine for Apache::Registry or Apache::PerlRun based projects, but if you use Embperl, Apache::ASP, Mason , etc. you run into a problem since those apps are not PAR aware. At the time of this writing there is a module available to allow for Mason to be used in a PAR environment. I contacted the author in regards to the other template/framework modules and he happened to be working on the problem already. In the mean time I put together a quick hack to replace Apache::PAR with a module called Apache::PARTemp that will extract your PAR files into a directory on load. This allows me to package up my Embperl based projects into a single file and have them extracted to the directory of my choice when Apache starts up. My workaround was more proof of concept then production grade, but the future looks bright.
Apache::PAR will hopefully open some doors for distributing Perl based web applications with less fuss, have fun.
* There is a way to pull in existing modules, but I am not covering that here. This node assumes you are working on systems with a full install of Perl and will be sharing modules with
** A perl startup file is a file that contains perl code indicating addtional configuration options for Apache, two of its benefit are. 1) it is a Perl script and not Apache directive/conf markup 2) it lives outside of the httpd.conf