Deploying Plack apps

March 06th, 2012 - 04:40 pm ET by Kjetil Kjernsmo | Report spam
Dear all,

I've been somewhat involved in Perl module packaging, now I'm mostly doing
coding work on Semantic Web Perl modules. Jonas and Florian has packaged most
of our core modules, and I've been following it closely. This is really great
work, and I can assure you all that upstream appreciates your efforts!

Now, I figured I should give you a heads up on a future issue: Deploying Plack
apps. I have seen that you have already put a lot of effort into packaging
Plack, which is great, I think it has a lot of potential. I have discussed
very superficially with Jonas, and it doesn't seem there is a straightforward
way for end users to get their apps running.

My module, RDF::LinkedData, which is in Debian, and a module RDF::Endpoint,
which has an ITP, are basically Plack apps (they can do more, but most users
will just do that). My ambition is that when Debian freezes for Wheezy, we'll
have a suite of modules that can set up a state-of-the-art Linked Data server
based on Perl modules in Debian.

Now, there are many ways that Plack apps could be deployed. That's actually
the key strength of Plack, it creates a separation of concern between
developers, who worry about the app and sysadmins who worry about deployment
and tuning. But this means that there isn't a single way to just throw up a
Plack app, even though in many cases it is very straightforward, it usually
requires some manual intervention.

What would obviously be very nice is if debconf could check the servers that
are installed (Apache mod_perl, fastcgi, lighthttpd, nginx, starman, etc) and
just ask you how you want to deploy things, and off you go. :-) I really have
no idea how to proceed, but I'd like to get you started discussing it. :-)

Basically, how I'd like to do it is that I want to have a very small .psgi
that only serves to load some Plack::App::*s and some Plack::Middleware::*.
So, the .psgi is pretty much a config thing, it just contains what should be
loaded and possibly some config loading, that's it. But it should be possible
to create one binary package that has a simple no-deps .psgi. This would
typically be used for only deploying RDF::LinkedData. In addition, it would be
great to have another binary package that depends on more modules, like
certain middleware and both RDF::LinkedData, RDF::Endpoint, etc, and a more
advanced .psgi that would set up all these modules to form the ultimate
server.

I don't have much time to contribute to discussing this before June or
something like that, but I hope this gives you guys some ideas. :-)

BTW; please CC any replies, I'm not on this list.

Best,

Kjetil


To UNSUBSCRIBE, email to debian-perl-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: http://lists.debian.org/3416810.09paTh2efV@owl
email Follow the discussionReplies 3 repliesReplies Make a reply

Similar topics

Replies

#1 Paul Wise
March 06th, 2012 - 06:40 pm ET | Report spam
There is wwwconfig-common, which was designed for the webserver side
of your question.

Here is my standard rant about web-based software & Debian, please consider it:

There is no way to know which filesystem path, database names, domain
name and HTTP path the sysadmin wants a web-based app to be run at.

Ideally, in the upstream code there would be a script/command that can
be used to setup an instance of the software at a particular URL, with
data stored in particular locations.

Ideally, in the relevant Debian package there should be debconf
prompts that act as input about whether to run and how to run the
upstream instance setup script.

bye,
pabs

http://wiki.debian.org/PaulWise


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/CAKTje6GLAgKH4J15gam=
Replies Reply to this message
#2 Kjetil Kjernsmo
March 08th, 2012 - 04:10 pm ET | Report spam
On Wednesday 7. March 2012 07.34.19 Paul Wise wrote:
There is wwwconfig-common, which was designed for the webserver side
of your question.



So, that could in principle be extended to accommodate for all the different
deployment options of Plack apps?

Here is my standard rant about web-based software & Debian, please consider
it:

There is no way to know which filesystem path, database names, domain
name and HTTP path the sysadmin wants a web-based app to be run at.



Right.

Ideally, in the upstream code there would be a script/command that can
be used to setup an instance of the software at a particular URL, with
data stored in particular locations.

Ideally, in the relevant Debian package there should be debconf
prompts that act as input about whether to run and how to run the
upstream instance setup script.



Yeah, that'd be nice. I don't know how easy it would be to get upstreams
(beyond myself) to support something like that, but at least, it is worth
thinking about, especially if it is doable for Wheezy.

Kjetil


To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
Replies Reply to this message
#3 Jonas Smedegaard
March 13th, 2012 - 05:00 pm ET | Report spam

On 12-03-06 at 10:34pm, Kjetil Kjernsmo wrote:
Now, I figured I should give you a heads up on a future issue:
Deploying Plack apps. I have seen that you have already put a lot of
effort into packaging Plack, which is great, I think it has a lot of
potential. I have discussed very superficially with Jonas, and it
doesn't seem there is a straightforward way for end users to get their
apps running.



Sorry - I realize now (thanks to Kjetil on IRC) that an obvious to me
point wasn't raised:

This issue on Plack apps seems less relevant for this list than for the
debian-webapps list: http://lists.debian.org/debian-webapps/ .


Hope that helps,

- Jonas

* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private





To UNSUBSCRIBE, email to
with a subject of "unsubscribe". Trouble? Contact
Archive: http://lists.debian.org/
email Follow the discussion Replies Reply to this message
Help Create a new topicReplies Make a reply
Search Make your own search