Re: [Dancer-users] perl dance multiple hosting @dotgeek
Gordon has been kind enough to test the system and everything works fine apparently (http://gordon.2.ai) question: do dancer developers usually develop locally and can then drop their app in our free hosting via SFTP or is SSH access a must (I don't see how thou as other services just give git push to deploy) just thought i would ask before running more tests :) Best Regards David
On Tue, Aug 14, 2012 at 9:35 PM, Assaf Gordon <gordon@cshl.edu <mailto:
gordon@cshl.edu>> wrote:
Hello David,
I'd be happy to test it, I can put my dancer+bootstrap+fontawesome
template ( http://cowbell.cancan.cshl.edu ) as an example.
-gordon
gurugeek wrote, On 08/14/2012 03:26 PM: > okay I found my own answer :) > all is needed is mod_perl and Plack ! > Test is live at http://dancer.2.ai > this is a simple test using a dancer self-contained one file app
(using the tutorial from the advent calendar).
> > Dave I would be thankful if you and/or others would be willing to
test it with some other code. If you email me directly I will be glad to give you the SFTP login/pw.
> Best Regards > David > > > > On Tue, Aug 14, 2012 at 7:26 PM, gurugeek <gurugeekphp@gmail.com<mailto:
gurugeekphp@gmail.com> <mailto:gurugeekphp@gmail.com <mailto: gurugeekphp@gmail.com>>> wrote:
> > or actually I just need > mod_perl and Plack::Handler::Apache2 > as per : >
http://lists.perldancer.org/pipermail/dancer-users/2010-August/000199.html
> > ? > > I was confused as the mod_apache is still listed in the plack
website :)
> > > On Tue, Aug 14, 2012 at 11:24 AM, David Precious <
davidp@preshweb.co.uk <mailto:davidp@preshweb.co.uk> <mailto: davidp@preshweb.co.uk <mailto:davidp@preshweb.co.uk>>> wrote:
> > On Mon, 13 Aug 2012 20:01:30 +0200 > gurugeek <gurugeekphp@gmail.com <mailto:
gurugeekphp@gmail.com> <mailto:gurugeekphp@gmail.com <mailto: gurugeekphp@gmail.com>>> wrote:
> > > hello, > > we are finalising a totally free hosting service for
programmers (
> > dotgeek.org <http://dotgeek.org> <http://dotgeek.org>).
We used to run this in 2004-2005 with PHP 5 etc. and we
> > are now trying to extend the service to offer, in
addition to PHP,
> > MySQL and Ruby (Sinatra, Camping) with Dancer. > > > > I did try it yesterday and today and I think it is very
interesting
> > and we would like to add support for dancer. > > That's awesome - I'll be happy to provide whatever help I
can.
> > > > I have a quick question regarding the best solution for
a multiple
> > hosting environment (we are using apache with a and we
have a proper
> > security system in place). According to your deployment
guide the
> > PSGI + Apache setup will require the application URL in
the vhost
> > configuration > > > > PerlSetVar psgi_app /websites/myapp.example.com/app.pl<
http://myapp.example.com/app.pl> <http://myapp.example.com/app.pl>
> > > > this might be an issue if the user rename the
application. In sinatra
> > with a passenger deployment (aka mod_ruby) you can
define a full
> > public folder and through the config.ru <
http://config.ru> <http://config.ru> file, that is easier to edit
> > from the users that will have only SFTP access, you
define which
> > application you wish to run. > > > > Is there a similar option with Dancer or there is a
need to declare
> > the app name in the apache vhost configuration ? > > You could probably set up e.g. /home/$username/app.pl <
http://app.pl> <http://app.pl> or similar which
> they can edit, which loads the appropriate app; they
could edit that to
> choose which app to load, perhaps? > > Or use some Apache trickery to extract a subdomain from
the query and
> use that as the path, as people often do with mass
name-based virtual
> hosting, so e.g. app1.user.dotgeek.org <
http://app1.user.dotgeek.org> <http://app1.user.dotgeek.org> is /home/$user/$app1/bin/app.pl <http://app.pl> <http://app.pl>
> etc - that way they could just upload a new app and hit > $appname.$user.dotgeek.org <http://user.dotgeek.org> <
http://user.dotgeek.org> or similar and have it Just Work (in theory).
> > > I would also welcome any feedback about this service
that will
> > essentially offer dancer + mysql + sqlite totally free.
Do you think
> > it would be interested and help users to get started ? > > Certainly - the ability for a user to try out their first
Dancer app
> for free without having to install stuff is likely to be
of use to
> people I think. This is something I sort of toyed with
the idea of
> trying to offer myself, but I decided I didn't have the
time to
> implement it in a secure enough way and manage it closely
enough to
> limit abuse etc (and to deal with the users, who from
past experience
> will expect the moon on a stick, even though they're not
paying a
> penny...) > > I note you've got reCAPTCHA which should keep out some
users though, as
> it's become almost unusable these days :) > > Anyway - I, and the other Dancer core devs, will be happy
to provide
> whatever assistance we can to you in order to get Dancer
support into
> dotgeek.org <http://dotgeek.org> <http://dotgeek.org>. > > Cheers! > > Dave P > > -- > David Precious ("bigpresh") <davidp@preshweb.co.uk<mailto:
davidp@preshweb.co.uk> <mailto:davidp@preshweb.co.uk <mailto: davidp@preshweb.co.uk>>>
> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter<
http://www.preshweb.co.uk/twitter> <http://www.preshweb.co.uk/twitter>
> www.preshweb.co.uk/linkedin <
http://www.preshweb.co.uk/linkedin> <http://www.preshweb.co.uk/linkedin> www.preshweb.co.uk/facebook <http://www.preshweb.co.uk/facebook> < http://www.preshweb.co.uk/facebook>
> www.preshweb.co.uk/cpan <http://www.preshweb.co.uk/cpan>
<http://www.preshweb.co.uk/cpan> www.preshweb.co.uk/github < http://www.preshweb.co.uk/github> <http://www.preshweb.co.uk/github>
> > > _______________________________________________ > Dancer-users mailing list > Dancer-users@perldancer.org <mailto:
Dancer-users@perldancer.org> <mailto:Dancer-users@perldancer.org <mailto: Dancer-users@perldancer.org>>
>
http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
> > >
On Wed, 15 Aug 2012 21:29:35 +0200 gurugeek <gurugeekphp@gmail.com> wrote:
Gordon has been kind enough to test the system and everything works fine apparently (http://gordon.2.ai) question: do dancer developers usually develop locally and can then drop their app in our free hosting via SFTP or is SSH access a must (I don't see how thou as other services just give git push to deploy) just thought i would ask before running more tests :)
I generally expect SSH, but that's probably from years of using my own servers; if I was a new developer, I might not need/expect that - especially from a free service :) As for deployment, if you can git push to it or similar, that's an easy way to do it. What about database control? Do users get to connect to MySQL from outside the service to e.g. set up their schema? What about dependencies? If a user wanted to use a CPAN module which isn't installed, is there any process to install it locally (or request that it be installed) or is it a case of "tough"? (That would be fair enough for free hosting :) ) -- David Precious ("bigpresh") <davidp@preshweb.co.uk> http://www.preshweb.co.uk/ www.preshweb.co.uk/twitter www.preshweb.co.uk/linkedin www.preshweb.co.uk/facebook www.preshweb.co.uk/cpan www.preshweb.co.uk/github
On Wed, Aug 15, 2012 at 11:20 PM, David Precious <davidp@preshweb.co.uk>wrote:
I generally expect SSH, but that's probably from years of using my own servers; if I was a new developer, I might not need/expect that - especially from a free service :)
Obviously professional developers will mostly have their own server/EC2
instance so they would not be so attracted by this but perhaps to many people starting it is a simple way to share your local dancer application by simply dropping all the files via SFTP. chrooting ssh is possible but I wouldn't want to go that route for now (but very willing to give SSH access to trustable people :) )
What about database control? Do users get to connect to MySQL from outside the service to e.g. set up their schema?
each user has one MySQL database. We have implemented a quota for the DB
size just in case. Within their database they can do what they want.
What about dependencies? If a user wanted to use a CPAN module which isn't installed, is there any process to install it locally (or request that it be installed) or is it a case of "tough"? (That would be fair enough for free hosting :) )
I think the request to be installed would be the best way for now but I did install many modules and will be happy to add more that are commonly used so let me know if you see something important missing :)
gurugeek@i-781936be:/home/testme/www/public$ cpanlist $VAR1 = 'AppConfig'; $VAR2 = 'Authen::SASL'; $VAR3 = 'CGI::FormBuilder'; $VAR4 = 'Class::Inspector'; $VAR5 = 'Class::Load'; $VAR6 = 'Class::Singleton'; $VAR7 = 'Clone'; $VAR8 = 'DBD::SQLite'; $VAR9 = 'Dancer'; $VAR10 = 'Dancer::Plugin::Database'; $VAR11 = 'Dancer::Plugin::DebugDump'; $VAR12 = 'Dancer::Plugin::Email'; $VAR13 = 'Dancer::Plugin::SimpleCRUD'; $VAR14 = 'Data::Dump'; $VAR15 = 'Data::OptList'; $VAR16 = 'Date::Time'; $VAR17 = 'DateTime'; $VAR18 = 'DateTime::Locale'; $VAR19 = 'DateTime::TimeZone'; $VAR20 = 'Devel::StackTrace'; $VAR21 = 'Devel::StackTrace::AsHTML'; $VAR22 = 'Digest::HMAC'; $VAR23 = 'Dist::CheckConflicts'; $VAR24 = 'Email::Address'; $VAR25 = 'Email::Date::Format'; $VAR26 = 'Email::MIME'; $VAR27 = 'Email::MIME::ContentType'; $VAR28 = 'Email::MIME::Encodings'; $VAR29 = 'Email::MessageID'; $VAR30 = 'Email::Send'; $VAR31 = 'Email::Simple'; $VAR32 = 'Email::Stuff'; $VAR33 = 'File::ShareDir'; $VAR34 = 'File::Slurp'; $VAR35 = 'File::Type'; $VAR36 = 'Filesys::Notify::Simple'; $VAR37 = 'HTML::Table'; $VAR38 = 'HTML::Table::FromDatabase'; $VAR39 = 'HTTP::Body'; $VAR40 = 'HTTP::Server::Simple'; $VAR41 = 'HTTP::Server::Simple::PSGI'; $VAR42 = 'Hash::Merge'; $VAR43 = 'Hash::MultiValue'; $VAR44 = 'IO::Socket::SSL'; $VAR45 = 'List::MoreUtils'; $VAR46 = 'MIME::Types'; $VAR47 = 'Math::Round'; $VAR48 = 'Module::Implementation'; $VAR49 = 'Module::Metadata'; $VAR50 = 'Module::Runtime'; $VAR51 = 'Net::SMTP::SSL'; $VAR52 = 'Net::SMTP::TLS'; $VAR53 = 'Net::SSLeay'; $VAR54 = 'Package::DeprecationManager'; $VAR55 = 'Package::Stash'; $VAR56 = 'Package::Stash::XS'; $VAR57 = 'Params::Util'; $VAR58 = 'Params::Validate'; $VAR59 = 'Perl'; $VAR60 = 'Perl::OSType'; $VAR61 = 'Plack'; $VAR62 = 'Return::Value'; $VAR63 = 'Sub::Exporter'; $VAR64 = 'Sub::Install'; $VAR65 = 'Sub::Uplevel'; $VAR66 = 'Template'; $VAR67 = 'Template::Plugin::Markdown'; $VAR68 = 'Test::Deep'; $VAR69 = 'Test::Differences'; $VAR70 = 'Test::Exception'; $VAR71 = 'Test::Fatal'; $VAR72 = 'Test::NoWarnings'; $VAR73 = 'Test::Output'; $VAR74 = 'Test::Requires'; $VAR75 = 'Test::SharedFork'; $VAR76 = 'Test::TCP'; $VAR77 = 'Text::Diff'; $VAR78 = 'Text::Markdown'; $VAR79 = 'Try::Tiny'; $VAR80 = 'URI'; $VAR81 = 'YAML'; $VAR82 = 'prefork';
An important question would be restarts, IMHO. Since you're doing this properly (PSGI, FastCGI, Starman, etc.), you'll have a service (fcgid, Starman, whatever) running all the time, you'll need to make it possible for the users to restart it. Also, what about allowing them different web server backends? If you let them run Twiggy, for example, they could write asynchronous Dancer code with AnyEvent (which is an asynchronous framework), or using POEx::Role::PSGIServer they could write asynchronous code with Dancer and POE or Reflex (other asynchronous frameworks). On Thu, Aug 16, 2012 at 12:46 AM, gurugeek <gurugeekphp@gmail.com> wrote:
On Wed, Aug 15, 2012 at 11:20 PM, David Precious <davidp@preshweb.co.uk>wrote:
I generally expect SSH, but that's probably from years of using my own servers; if I was a new developer, I might not need/expect that - especially from a free service :)
Obviously professional developers will mostly have their own server/EC2
instance so they would not be so attracted by this but perhaps to many people starting it is a simple way to share your local dancer application by simply dropping all the files via SFTP. chrooting ssh is possible but I wouldn't want to go that route for now (but very willing to give SSH access to trustable people :) )
What about database control? Do users get to connect to MySQL from outside the service to e.g. set up their schema?
each user has one MySQL database. We have implemented a quota for the DB
size just in case. Within their database they can do what they want.
What about dependencies? If a user wanted to use a CPAN module which isn't installed, is there any process to install it locally (or request that it be installed) or is it a case of "tough"? (That would be fair enough for free hosting :) )
I think the request to be installed would be the best way for now but I did install many modules and will be happy to add more that are commonly used so let me know if you see something important missing :)
gurugeek@i-781936be:/home/testme/www/public$ cpanlist $VAR1 = 'AppConfig'; $VAR2 = 'Authen::SASL'; $VAR3 = 'CGI::FormBuilder'; $VAR4 = 'Class::Inspector'; $VAR5 = 'Class::Load'; $VAR6 = 'Class::Singleton'; $VAR7 = 'Clone'; $VAR8 = 'DBD::SQLite'; $VAR9 = 'Dancer'; $VAR10 = 'Dancer::Plugin::Database'; $VAR11 = 'Dancer::Plugin::DebugDump'; $VAR12 = 'Dancer::Plugin::Email'; $VAR13 = 'Dancer::Plugin::SimpleCRUD'; $VAR14 = 'Data::Dump'; $VAR15 = 'Data::OptList'; $VAR16 = 'Date::Time'; $VAR17 = 'DateTime'; $VAR18 = 'DateTime::Locale'; $VAR19 = 'DateTime::TimeZone'; $VAR20 = 'Devel::StackTrace'; $VAR21 = 'Devel::StackTrace::AsHTML'; $VAR22 = 'Digest::HMAC'; $VAR23 = 'Dist::CheckConflicts'; $VAR24 = 'Email::Address'; $VAR25 = 'Email::Date::Format'; $VAR26 = 'Email::MIME'; $VAR27 = 'Email::MIME::ContentType'; $VAR28 = 'Email::MIME::Encodings'; $VAR29 = 'Email::MessageID'; $VAR30 = 'Email::Send'; $VAR31 = 'Email::Simple'; $VAR32 = 'Email::Stuff'; $VAR33 = 'File::ShareDir'; $VAR34 = 'File::Slurp'; $VAR35 = 'File::Type'; $VAR36 = 'Filesys::Notify::Simple'; $VAR37 = 'HTML::Table'; $VAR38 = 'HTML::Table::FromDatabase'; $VAR39 = 'HTTP::Body'; $VAR40 = 'HTTP::Server::Simple'; $VAR41 = 'HTTP::Server::Simple::PSGI'; $VAR42 = 'Hash::Merge'; $VAR43 = 'Hash::MultiValue'; $VAR44 = 'IO::Socket::SSL'; $VAR45 = 'List::MoreUtils'; $VAR46 = 'MIME::Types'; $VAR47 = 'Math::Round'; $VAR48 = 'Module::Implementation'; $VAR49 = 'Module::Metadata'; $VAR50 = 'Module::Runtime'; $VAR51 = 'Net::SMTP::SSL'; $VAR52 = 'Net::SMTP::TLS'; $VAR53 = 'Net::SSLeay'; $VAR54 = 'Package::DeprecationManager'; $VAR55 = 'Package::Stash'; $VAR56 = 'Package::Stash::XS'; $VAR57 = 'Params::Util'; $VAR58 = 'Params::Validate'; $VAR59 = 'Perl'; $VAR60 = 'Perl::OSType'; $VAR61 = 'Plack'; $VAR62 = 'Return::Value'; $VAR63 = 'Sub::Exporter'; $VAR64 = 'Sub::Install'; $VAR65 = 'Sub::Uplevel'; $VAR66 = 'Template'; $VAR67 = 'Template::Plugin::Markdown'; $VAR68 = 'Test::Deep'; $VAR69 = 'Test::Differences'; $VAR70 = 'Test::Exception'; $VAR71 = 'Test::Fatal'; $VAR72 = 'Test::NoWarnings'; $VAR73 = 'Test::Output'; $VAR74 = 'Test::Requires'; $VAR75 = 'Test::SharedFork'; $VAR76 = 'Test::TCP'; $VAR77 = 'Text::Diff'; $VAR78 = 'Text::Markdown'; $VAR79 = 'Try::Tiny'; $VAR80 = 'URI'; $VAR81 = 'YAML'; $VAR82 = 'prefork';
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Thu, 16 Aug 2012 11:11:13 +0300 sawyer x <xsawyerx@gmail.com> wrote:
An important question would be restarts, IMHO. Since you're doing this properly (PSGI, FastCGI, Starman, etc.), you'll have a service (fcgid, Starman, whatever) running all the time, you'll need to make it possible for the users to restart it.
Indeed. Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps. Wouldn't work so well for someone SFTP'ing their app up of course :)
Perhaps something like supervisor, or nodemon, but adapted to Perl frameworks, could be of use : http://www.hacksparrow.com/node-js-restart-on-file-change.html http://remysharp.com/2010/10/12/nodejs-rapid-development-nodemon/ They're small utilities which restart your node.js server when they detect that a js file has been modified. 2012/8/16 David Precious <davidp@preshweb.co.uk>
On Thu, 16 Aug 2012 11:11:13 +0300 sawyer x <xsawyerx@gmail.com> wrote:
An important question would be restarts, IMHO. Since you're doing this properly (PSGI, FastCGI, Starman, etc.), you'll have a service (fcgid, Starman, whatever) running all the time, you'll need to make it possible for the users to restart it.
Indeed.
Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps.
Wouldn't work so well for someone SFTP'ing their app up of course :) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On 16/08/12 10:30, Stéphane Wenric wrote:
Perhaps something like supervisor, or nodemon, but adapted to Perl frameworks, could be of use :
http://www.hacksparrow.com/node-js-restart-on-file-change.html http://remysharp.com/2010/10/12/nodejs-rapid-development-nodemon/
They're small utilities which restart your node.js server when they detect that a js file has been modified.
well there's Module::Refresh (which is already built into dancer), but you could put the following in a specific route and it would reload the code afaik: get '/restart' => sub { Module::Refresh->refresh; }; or something? a
2012/8/16 David Precious <davidp@preshweb.co.uk <mailto:davidp@preshweb.co.uk>>
On Thu, 16 Aug 2012 11:11:13 +0300 sawyer x <xsawyerx@gmail.com <mailto:xsawyerx@gmail.com>> wrote:
> An important question would be restarts, IMHO. > Since you're doing this properly (PSGI, FastCGI, Starman, etc.), > you'll have a service (fcgid, Starman, whatever) running all the > time, you'll need to make it possible for the users to restart it.
Indeed.
Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps.
Wouldn't work so well for someone SFTP'ing their app up of course :) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org <mailto:Dancer-users@perldancer.org> http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Module::Refresh gave us problems, which is why we advise against using it. If you want reloading, there's always plack's reloading option and Plack::Handler::Shotgun which is the best solution for that: compilation on request. None of those are recommended for production. On Thu, Aug 16, 2012 at 12:33 PM, Alex Knowles <alexk@moonfruit.com> wrote:
On 16/08/12 10:30, Stéphane Wenric wrote:
Perhaps something like supervisor, or nodemon, but adapted to Perl frameworks, could be of use :
http://www.hacksparrow.com/node-js-restart-on-file-change.html http://remysharp.com/2010/10/12/nodejs-rapid-development-nodemon/
They're small utilities which restart your node.js server when they detect that a js file has been modified.
well there's Module::Refresh (which is already built into dancer), but you could put the following in a specific route and it would reload the code afaik:
get '/restart' => sub { Module::Refresh->refresh; };
or something?
a
2012/8/16 David Precious <davidp@preshweb.co.uk>
On Thu, 16 Aug 2012 11:11:13 +0300 sawyer x <xsawyerx@gmail.com> wrote:
An important question would be restarts, IMHO. Since you're doing this properly (PSGI, FastCGI, Starman, etc.), you'll have a service (fcgid, Starman, whatever) running all the time, you'll need to make it possible for the users to restart it.
Indeed.
Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps.
Wouldn't work so well for someone SFTP'ing their app up of course :) _______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
Indeed.
Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps.
Wouldn't work so well for someone SFTP'ing their app up of course :) _______________________________________________
I have just opened http://dancer.2.ai/perl connecting via SFP and using cyberduck (edit with) and added a yes <li><font color=B8C76F> YOUR WEBSPACE IS READY yes </li> http://dancer.2.ai/perl without restarting anything it loads the new text but again this is fairly simple test app :) still from my tests it looks like you do not need a restart with Plack::Handler::Apache2 ?
The reason you don't need restarts is because it loads everything on every request, like with CGI. That's slow and horrible. mod_perl has startup.pl[1] which helps deal with it, and on the Plack::Handler::Apache2[2] there's an example in the synopsis on handling the same thing[3]. [1] http://perl.apache.org/docs/1.0/guide/config.html [2] https://metacpan.org/module/Plack::Handler::Apache2 [3] <Perl> use Plack::Handler::Apache2<https://metacpan.org/module/Plack::Handler::Apache2> ; Plack::Handler::Apache2->preload("/path/to/app.psgi"); </Perl> On Thu, Aug 16, 2012 at 2:20 PM, gurugeek <gurugeekphp@gmail.com> wrote:
Indeed.
Depending on the deployment method, it may be possible to add a hook to restart the app automatically on git push or similar perhaps.
Wouldn't work so well for someone SFTP'ing their app up of course :) _______________________________________________
I have just opened http://dancer.2.ai/perl connecting via SFP and using cyberduck (edit with) and added a yes <li><font color=B8C76F> YOUR WEBSPACE IS READY yes </li> http://dancer.2.ai/perl
without restarting anything it loads the new text but again this is fairly simple test app :) still from my tests it looks like you do not need a restart with Plack::Handler::Apache2 ?
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Thu, Aug 16, 2012 at 3:37 PM, sawyer x <xsawyerx@gmail.com> wrote:
The reason you don't need restarts is because it loads everything on every request, like with CGI. That's slow and horrible. mod_perl has startup.pl[1] which helps deal with it, and on the Plack::Handler::Apache2[2] there's an example in the synopsis on handling the same thing[3].
I see well I am using what is available in the guide at http://search.cpan.org/dist/Dancer/lib/Dancer/Deployment.pod
Let me try and be more accurate and understandable. There's a difference between "slow and horrible" and incorrect. You're not doing anything incorrectly! :) The set up you have with Plack::Handler::Apache2 is correct but not optimal and has its disadvantages. If you can do it differently (such as having persistency) it will be more worthwhile. The deployment document was mostly written by the community and contains practical information about situations people encountered, sometimes without any ability to change it. Our most recommended set up is Varnish <-> Nginx <-> Starman <-> Dancer. However, sometimes you're using Apache, sometimes you don't have a reverse proxy, sometimes you don't have caching up front, sometimes you can't run a Perl webserver (like Starman). These are all limitations you might face, and the deployment procedure tries to help you with that. On Thu, Aug 16, 2012 at 5:14 PM, gurugeek <gurugeekphp@gmail.com> wrote:
On Thu, Aug 16, 2012 at 3:37 PM, sawyer x <xsawyerx@gmail.com> wrote:
The reason you don't need restarts is because it loads everything on every request, like with CGI. That's slow and horrible. mod_perl has startup.pl[1] which helps deal with it, and on the Plack::Handler::Apache2[2] there's an example in the synopsis on handling the same thing[3].
I see well I am using what is available in the guide at http://search.cpan.org/dist/Dancer/lib/Dancer/Deployment.pod
_______________________________________________ Dancer-users mailing list Dancer-users@perldancer.org http://www.backup-manager.org/cgi-bin/listinfo/dancer-users
On Thu, Aug 16, 2012 at 4:36 PM, sawyer x <xsawyerx@gmail.com> wrote:
Let me try and be more accurate and understandable.
There's a difference between "slow and horrible" and incorrect. You're not doing anything incorrectly! :)
Absolutely :)
The set up you have with Plack::Handler::Apache2 is correct but not optimal and has its disadvantages. If you can do it differently (such as having persistency) it will be more worthwhile.
The deployment document was mostly written by the community and contains practical information about situations people encountered, sometimes without any ability to change it. Our most recommended set up is Varnish <-> Nginx <-> Starman <-> Dancer. However, sometimes you're using Apache, sometimes you don't have a reverse proxy, sometimes you don't have caching up front, sometimes you can't run a Perl webserver (like Starman). These are all limitations you might face, and the deployment procedure tries to help you with that.
I understand the difference very well as I did test for months the nginx reverse proxy (it was for ruby and thin but it is the same principle) and I decided against it. The first issue I have even with 100 users you will end up running many instances that are not used by anyone. More importantly, after several trials i realised that nginx wants to run everything as his own user and, as far as I could find, doesn't allow the permissions setting where user a won't be able to read what is on user b. It needs permission for the whole tree.
Given that some people seems to have the aim to break anything that you give them for free "just because they can" I have tried to make a setup that is as secure as possible without having to go through the virtualization route (which to me seems pointless as you do have excellent free options even with EC2). In my setup you can run safely ruby, php and dance with the Plack::Handler::Apache2 even side by side without any major risk. But please do not get me wrong :) I see your point completely and my experience with dancer is very limited to run some test scripts. I agree that reloading the whole up each time is less than ideal. I don't know why the Plack::Handler does that (this is not the case with Passenger as a process is in memory and users can restart the app by simply doing touch /home/me/tmp/restart.txt (which I enabled in the admin panel). I think it is probably an issue with offering several languages at the same time vs. developing an optimal system only for dancer that, unfortunately and due to my limited knowledge in using it, seems unrealistic at this stage. I just wonder why the Plack::Handler behaves in this "slow and horrible way". This can't be good I think because most servers will run Apache and I don't think they will be so willing to throw it away for Varnish <-> Nginx <-> Starman <-> Dancer :) Thanks for your suggestions and letting me know. I really appreciate that. I thought that installing Mod_perl and Plack::Handler was too easy to make this the best solution ! :)
On Thu, Aug 16, 2012 at 10:11 AM, sawyer x <xsawyerx@gmail.com> wrote:
An important question would be restarts, IMHO. Since you're doing this properly (PSGI, FastCGI, Starman, etc.), you'll have a service (fcgid, Starman, whatever) running all the time, you'll need to make it possible for the users to restart it.
I am using mod_perl Plack::Handler::Apache2 and not the starman reverse proxy option. From my test it looks like the dancer application restarts automatically e.g. you upload a new version and is refreshed.
With phusion (aka mod_ruby) restarts are needed but apparently not with Plack::Handler::Apache2. If you wish to test it just drop me a line and I can open you a test environment or we can ask gordon how it works for his space http://gordon.dotgeek.org Best Regards David
participants (5)
-
Alex Knowles -
David Precious -
gurugeek -
sawyer x -
Stéphane Wenric