[dancer-users] Multiple apps with Plack and Apache

Amelia Ireland aireland at lbl.gov
Wed Jul 13 23:51:06 BST 2016


What do your app.psgi scripts look like? Would it be feasible to combine
them into a single file that mounts all your apps?

e.g.
use Plack::Builder;

builder {
mount "/app1" => $app1->();
mount "/app2" => $app2->();
};

If you haven't found it yet, the PSGI/Plack advent calendar has a lot of
useful recipes for running and mounting different apps on the same server:
http://advent.plackperl.org/2009/12/index.html


On 13 July 2016 at 11:25, janet davis <oscarjwoofer at gmail.com> wrote:

> Yes, it would be fantastic if this method worked and I have tried but I
> get the following error when switching between app1 and app2.  Yes Perl
> 5.14 sadly, we are due to update to Debian 8 shortly which will bring us up
> to 5.20.2.
>
> Error while loading /var/www/webapp/app2/bin/app.psgi: Can't locate
> app2.pm in @INC (@INC contains: /var/www/webapp/app1/bin/../lib /etc/perl
> /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5
> /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14
> /usr/local/lib/site_perl . /etc/apache2) at
> /var/www/webapp/app2/bin/app.psgi line 8.\nBEGIN failed--compilation
> aborted at /var/www/webapp/app2/bin/app.psgi line 8.
>
> App2 will work after a refresh, but them going back to App1 I get:
>
> and
>
> Error while loading /var/www/webapp/app1/bin/app.psgi: Can't locate
> app1.pm in @INC (@INC contains: /var/www/webapp/app2/bin/../lib /etc/perl
> /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5
> /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14
> /usr/local/lib/site_perl . /etc/apache2) at
> /var/www/webapp/app1/bin/app.psgi line 8.\nBEGIN failed--compilation
> aborted at /var/www/webapp/app1/bin/app.psgi line 8
>
> Here's my Apache config:
> <Location /app1>
>                 SetHandler perl-script
>                 PerlResponseHandler
> Plack::Handler::Apache2
>                 PerlSetVar psgi_app
> /var/www/webapp/app1/bin/app.psgi
> </Location>
>
>  <Location
> /app2>
>                 SetHandler
> perl-script
>                 PerlResponseHandler
> Plack::Handler::Apache2
>                 PerlSetVar psgi_app
> /var/www/webapp/app2/bin/app.psgi
> </Location>
>
> On Wed, Jul 13, 2016 at 5:14 PM, Chad Wallace <cwallace at lodgingcompany.com
> > wrote:
>
>> On Wed, 13 Jul 2016 14:28:23 +0100
>> janet davis <oscarjwoofer at gmail.com> wrote:
>>
>> > Thanks for both of your input, it has really helped a lot.
>>
>> You're welcome!  But I have another suggestion...
>>
>> After re-reading your original post, I looked up the
>> Plack::Handler::Apache2 option, and it looks like it might be better.
>> It's at least worth exploring.
>>
>>  From the example in the deployment guide you mentioned, it looks like
>>  all you'd have to do to your existing virtual host is add a <Location>
>>  section for each of your apps, like this:
>>
>> <VirtualHost>
>>     ServerName www.myserver
>>
>>     [...]
>>
>>     <Location /app1>
>>         SetHandler perl-script
>>         PerlResponseHandler Plack::Handler::Apache2
>>         PerlSetVar psgi_app /websites/app1/app.psgi
>>     </Location>
>>     <Location /app2>
>>         SetHandler perl-script
>>         PerlResponseHandler Plack::Handler::Apache2
>>         PerlSetVar psgi_app /websites/app2/app.psgi
>>     </Location>
>>     <Location /app3>
>>         SetHandler perl-script
>>         PerlResponseHandler Plack::Handler::Apache2
>>         PerlSetVar psgi_app /websites/app3/app.psgi
>>     </Location>
>>
>>     [...]
>>
>> </VirtualHost>
>>
>> That way, your plack apps will start and stop with your apache server.
>>
>> I don't have any experience with this approach, so hopefully someone
>> else can weigh in on the pros and cons.  It seems much simpler to me.
>>
>> One drawback I can think of is that your apache processes would all
>> load a copy of perl, Plack, Dancer and all the rest.  It may be better
>> for memory usage to use the proxy method, especially if you have dozens
>> of apache workers, but only need a few Dancer workers.  The impact of
>> that would depend on the relative weight of your existing website vs.
>> the new apps, and also whether you already use mod_perl and a lot of
>> the same modules....
>>
>> You should definitely try both methods and see which is best.  And be
>> sure to let us know what you find!
>>
>>
>> > On Wed, Jul 13, 2016 at 12:25 AM, Chad Wallace
>> > <cwallace at lodgingcompany.com> wrote:
>> >
>> > > On Tue, 12 Jul 2016 22:07:56 +0100
>> > > janet davis <oscarjwoofer at gmail.com> wrote:
>> > >
>> > > > The only problem is the uri_base doesn't point to the public
>> > > > directory in my application root it points to / so no css/js etc.
>> > > >
>> > > > I have:
>> > > > ProxyPass /app1 http://localhost:5000
>> > > > ProxyPassReverse /app1 http://localhost:5000
>> > > > And I can reach app1 on myserver.com/app1
>> > > >
>> > > > Is there anywhere in the config that I can specify the correct
>> > > > uri_base per app?
>> > >
>> > > There's the behind_proxy config option (see Dancer2::Config).
>> > >
>> > > > I will try using Plack Builder with some example apps.  Are there
>> > > > any performance implications if I run a lot of Dancer apps in
>> > > > this way (15+) alongside my cgi scripts?  I don't want to go down
>> > > > this route and then discover that I have issues with server
>> > > > resources.
>> > >
>> > > I'm guessing you'll get better performance with them combined.  They
>> > > should at least use less memory that way, because the single process
>> > > would load all modules only once, rather than loading one process
>> > > per app, each with its own copy of perl, Plack, Dancer, Moo, etc.
>> > >
>> > > Adding the mounts with Plack::Builder probably doesn't add too much
>> > > overhead.  From what I've seen, Plack and Dancer are both designed
>> > > to perform and scale well.
>> > >
>> > > You could test both methods and compare the results.
>> > >
>> > >
>> > > > On Tue, Jul 12, 2016 at 9:21 PM, Chad Wallace
>> > > > <cwallace at lodgingcompany.com> wrote:
>> > > >
>> > > > > On Tue, 12 Jul 2016 19:55:31 +0100
>> > > > > janet davis <oscarjwoofer at gmail.com> wrote:
>> > > > >
>> > > > > > Hi there,
>> > > > > >
>> > > > > > I have a web server running Apache with a single vhost that
>> > > > > > serves a lot of Perl cgi scripts from cgi-bin.
>> > > > > >
>> > > > > > I've been trying out Dancer, which I really like, but I can't
>> > > > > > figure out the best way to deploy apps in my Apache
>> > > > > > environment. I want to keep my Apache cgi configuration to
>> > > > > > serve legacy scripts but I want to start building new
>> > > > > > projects based on psgi in something like Dancer.
>> > > > > >
>> > > > > > I want Apache to use www.myserver/cgi-bin/appname/script.pl
>> > > > > > for old code (which currently works) and www.myserver/app1
>> > > > > > for newer Dancer based apps. Please don't think I'm being
>> > > > > > lazy by asking, I have read the documentation and looked at
>> > > > > > the example for deploying multiple apps via fcgi but I am
>> > > > > > still confused as I have limited experience with Apache - I
>> > > > > > am working on that. What's the best way to set this up,
>> > > > > > bearing in mind that I may want to run say 10-15 Dancer apps
>> > > > > > from my server alongside my cgi-scripts? Do I have to set up
>> > > > > > a vhost for each app?  I have Apache::Plack::Handler but I'm
>> > > > > > not sure whether I should be using Plack::Builder to mount my
>> > > > > > apps (which is mentioned in an older Dancer Cookbook, but not
>> > > > > > the current deployment guide. Can someone help me get on the
>> > > > > > right track please?
>> > > > >
>> > > > > I'm not sure it matches what you currently have in mind, but
>> > > > > what I would do is set up www.myserver/app1 with mod_proxy to a
>> > > > > standalone Plack/Dancer process for the app.  You would need
>> > > > > something like this in your VirtualHost for each app:
>> > > > >
>> > > > >     ProxyPass  /app1  http://localhost:5000/app1
>> > > > >
>> > > > > You'd also have to manage starting, stopping and reloading each
>> > > > > of your apps on its own, with a dedicated port, like 5000 in
>> > > > > the line above.
>> > > > >
>> > > > > If you wanted to combine your apps into one, you can do that
>> > > > > with Plack::Builder in a single app.psgi script.  Then you get
>> > > > > the benefit of only having one script to start and stop, and
>> > > > > one port. I currently do that with one of my apps to separate
>> > > > > the AJAX-specific stuff, based on code I found in
>> > > > > Dancer2::Cookbook[1]:
>> > > > >
>> > > > > #!/usr/bin/env perl
>> > > > >
>> > > > > use strict;
>> > > > > use warnings;
>> > > > >
>> > > > > use FindBin;
>> > > > > use lib "$FindBin::Bin/../lib";
>> > > > >
>> > > > > use Plack::Builder;
>> > > > > use newtlc;
>> > > > > use newtlc::API;
>> > > > >
>> > > > > builder {
>> > > > >     mount '/'    => newtlc->to_app;
>> > > > >     mount '/api' => newtlc::API->to_app;
>> > > > > };
>> > > > >
>> > > > >
>> > > > > [1]
>> > > > >
>> > > > >
>> > >
>> https://metacpan.org/pod/distribution/Dancer2/lib/Dancer2/Cookbook.pod#App-specific-feature
>> > >
>> > >
>> > > --
>> > >
>> > > C. Chad Wallace, B.Sc.
>> > > The Lodging Company
>> > > http://www.lodgingcompany.com/
>> > > OpenPGP Public Key ID: 0x262208A0
>> > >
>> > > _______________________________________________
>> > > dancer-users mailing list
>> > > dancer-users at dancer.pm
>> > > http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>> > >
>>
>>
>> --
>>
>> C. Chad Wallace, B.Sc.
>> The Lodging Company
>> http://www.lodgingcompany.com/
>> OpenPGP Public Key ID: 0x262208A0
>>
>> _______________________________________________
>> dancer-users mailing list
>> dancer-users at dancer.pm
>> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>>
>
>
> _______________________________________________
> dancer-users mailing list
> dancer-users at dancer.pm
> http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.preshweb.co.uk/pipermail/dancer-users/attachments/20160713/cfaf32eb/attachment-0001.html>


More information about the dancer-users mailing list