[Catalyst-dev] Tutorial Fails under Apache Mod_Perl

Jillian Rowe jir2004 at qatar-med.cornell.edu
Fri Dec 6 07:04:45 GMT 2013


Hi William,

I have found deployment on different machines definitely raises some issues, and I feel like there are some best practices.

If you can I would say skip the sqlite and go straight for a mysql database. I believe there are converters that can convert your schema and input your data. Then your connection data will always be the same and you won't have to deal with file paths. 

File paths in general are a pain with deployment. Either avoid them or see if you can have a setup where you have a filesystem that is shared between your development and production machines. 

In any case your testing is better served by either using the catalyst testing suite (which is very comprehensive!), a git post hook, or both. 

Static content! If you are going to have multiple applications sharing the same domain you do not want the usual  MyApp/root/static, but instead something like MyApp/root/myapp/static. Then if you deploy using apache you will have something like:

         Alias /myapp1/static   /var/www/MyApp1/root/myapp1/static
        <Directory /var/www/MyApp1/root/static>
                Options Includes FollowSymlinks Indexes
                 Order allow,deny
                 Allow from all
        </Directory>

         Alias /myapp2/static   /var/www/MyApp2/root/myapp2/static
        <Directory /var/www/MyApp2/root/static>
                Options Includes FollowSymlinks Indexes
                 Order allow,deny
                 Allow from all
        </Directory>

And in your application your urls will look like : $c.uri_for("/myapp/static/file.css"). In fact I wish this would be changed when the original skeleton is built using catalyst.pl MyApp. 

This is probably not applicable if you prefer to have all of your static content served out of your apache document root, but I prefer to keep mine on a per application basis and keep the whole thing under version control.

I have also found deployment to be MUCH, MUCH easier since I setup my environment so my development and production matched each other almost exactly. This is especially true if you are using javascript libraries. Not everyone writes their code so it knows when the path is being prefixed by something else, and often I have had to go in there and hardcode the url. We have productions set up with Apache and FastCGI, and use  Catalyst::TraitFor::Request::ProxyBase.

If you are using SSL and want your path prefixed by /myapp (www.example.com/myapp1/stuff) your apache config should look something like this for development.

(This really took some doing to figure out. Is there any way it could be put into the catalyst wiki?)

#DEVELOPMENT
<VirtualHost *:443>
        ProxyRequests On
        ProxyVia On
        ProxyReceiveBufferSize 16384
        ProxyPass /myapp/static !
        Alias /myapp/static   /var/www/MyApp/root/myapp/static

        <Location /myapp>
            # You must have mod_headers enabled for that
            # RequestHeader set X-Request-Base /preview
                SetEnv force-proxy-request-1.0 1
                SetEnv proxy-nokeepalive 1

                SSLRequireSSL
                SetHandler perl-script
                RequestHeader set X-URL-SCHEME https
                RequestHeader set X-Request-Base https://development.com/myapp
        </Location>

        ProxyPass /myapp http://localhost:3000
        ProxyPassReverse /myapp http://localhost:3000
</VirtualHost>


#PRODUCTION
        Alias /myapp/static   /var/www/MyApp/root/myapp/static
        <Directory /var/www/MyApp/root/myapp/static>
                Options Includes FollowSymlinks Indexes
                 Order allow,deny
                 Allow from all
        </Directory>

        Alias /myapp /var/www/MyApp/script/myapp_fastcgi.pl/
        <Directory /var/www/MyApp/script/>
                SetHandler fcgid-script
                Options +ExecCGI
                # Customize the next two directives for your requirements.
                Order allow,deny
                Allow from all
        </Directory>

I really love developing in catalyst in any case, even if this stuff was a bit hard to figure out. 

If you are using Ubuntu as your production server you need to enable the fastcgi and suexec modules as well. 

The only other 'big' thing I have done is I no longer keep my model logic within the application because I have several applications that use the same database and do many of the same things. Instead I h2xs to create myself a perl module skeleton. In this case it is AdvComp-AdminModel. Then cd to that directory and run the following

perl -MDBIx::Class::Schema::Loader=make_schema_at,dump_to_dir:./lib -e 'make_schema_at("AdvComp::AdminModel", { debug => 1 }, [ "dbi:mysql:administrationdb:mysqlhost.com","user", "password" ])'

Then in your Model/ADMIN.pm (I think the tutorial uses DB.pm or SCHEMA.pm or something).

package MyApp::Model::ADMIN;

use strict;

use lib "Path/to/AdvComp-AdminModel/lib";
use AdvComp::AdminModel;

use base 'Catalyst::Model::DBIC::Schema';

__PACKAGE__->config(
    schema_class => 'AdvComp::AdminModel',
    
    connect_info => {
        dsn => 'dbi:mysql:administrationdb:mysqlhost.com',
        user => 'user',
        password => 'password',
        AutoCommit => q{1},
    }
);

Then your models will work as usual with $c->model('ADMIN::Table').

In general I find a lot of my apps are doing at least a few common things, and instead of keeping that login in the controller or even in a Moose role I have a separate module (created with h2xs again) called Web::Worker, and in that I add the common things I need. Only url mapping and things unique to the application stay within the catalyst structure.

I hope it goes without saying all my separate perl modules/models are under version control as well!

Happy coding!

Best,
Jillian

________________________________________
From: William Anderson [william_anderson at yahoo.com]
Sent: Friday, December 06, 2013 1:51 AM
To: Development of the elegant MVC web framework
Subject: Re: [Catalyst-dev] Tutorial Fails under Apache Mod_Perl
is is 
Hi,

Application is not running in a distribution directory. Well, yes the base directory that the application was running in moved when I moved it to the actual web server, i.e, moved from /home/catalyst on the tutorial virtual machine to /home/testsite on the test web server virtual machine.

However, the whole contents of the Catalyst project was moved, including the Makefile.pl and the generated Makefile. Also, I ran perl Makefile.pl and make several times while i found and installed the perl modules that were not included in any Ubuntu packages. Should this not have updated the paths?

Anyway, there must be a method where you can take a Catalyst application, developed using the development server script, and deploy it onto an actual web server that does not cause such problems. I will continue reading, experimenting, and learning about Catalyst.

Thank you for your help,

William

________________________________
From: Carl Franks <carl at fireartist.com>
To: Development of the elegant MVC web framework <catalyst-dev at lists.scsys.co.uk>
Sent: Thursday, December 5, 2013 3:04 PM
Subject: Re: [Catalyst-dev] Tutorial Fails under Apache Mod_Perl

It sounds like the app's no longer running in a distribution directory
(containing a Makefile.PL)
see the docs for the "-HOME" switch for how to handle this:
http://search.cpan.org/~jjnapiork/Catalyst-Runtime-5.90051/lib/Catalyst.pm#-Home
Carl



More information about the Catalyst-dev mailing list