Hi all,
The Rails book talks about running Rails under Apache, but is there a
(relatively) easy way to deploy it to either Tomcat or JBoss? Is the
CGI
servlet the only option?
Thanks,
Ken
–
Kenneth A. Kousen, Ph.D.
President
Kousen IT, Inc.
Only Java applications can be deployed to Tomcat and JBoss.
Sky Y. wrote:
Only Java applications can be deployed to Tomcat and JBoss.
Thats not entirely through, there are also bridges one can use to get
PHP working, for example, wich then runs in fastcgi mode and is
contacted by a servlet.
It should be possible to construct such a bridge also for ruby - or is
there anything like this already on the web?
Gregor M. wrote:
Thats not entirely through,
entirely true, ouch…
Ken K. wrote:
The Rails book talks about running Rails under Apache, but is there a
(relatively) easy way to deploy it to either Tomcat or JBoss? Is the
CGI servlet the only option?
Sounds like a relatively easy way to set yourself up a very bruised
forehead. First, running Rails in CGI mode is anticlimatic at best. The
setup of the Rails environment on each request would be painful. So,
you’d really want some Servlet that ran FCGI. And, even if one exists
(which, quite frankly I don’t know if one does), just thinking about it
makes my head hurt. Setting up Rails in a production environment can be
challenging enough.
Even if you get it working, it’s not the right tool for the job. If
you’re just trying to dink around with Rails, use WEBrick. If you want
to put something up for real, use Lighty[1] or Apache. If you want to
set up a server with some requests going to Rails and other requests
going to some Servlets, set up Apache with connectors to send some
requests to Tomcat and others to Rails via FCGI.
That’s interesting. One of the big reasons to use J2EE is that servlets
scale much better than CGI scripts because only a single instance of each
servlet is used to service all requests. Does that mean that using Rails
with Apache is going back to the CGI approach? The Rails book lists FastCGI
as an alternative to CGI. Does that change the situation?
FastCGI != CGI. The ability to have a long running program serve
multiple requests is exactly what FastCGI[2] is all about.
Bottom line: This is a very different world than the Servlet one,
especially when it comes to setting things up. Lots of learning and
grappling with some very different concepts has to be done to make the
transition well. But don’t worry, it can be done.
[1] http://duncandavidson.com/essay/2005/12/railsonlighty
[2] http://cryp.to/publications/fastcgi/
Okay, that makes sense. It really comes down to using a web server with
plugins for the dynamic elements. I do that in the Java world anyway,
but mostly for load balancing and other administrative purposes. I’ve
often thought separating the web server from the application server was
sometimes too many layers of indirection for small systems. It seems
now that I need an app server for the J2EE components and something else
(FastCGI, I guess) for the Rails applications.
A J2EE app server does more than just executing the servlets and JSPs.
It also provides a wide range of services, like naming, security,
transactions, resource pooling, and all the other so-called enterprise
services that the big vendors charge so much for.
(Other than open source JBoss, but you get the idea.)
It sounds to me, then, that there is no “Rails Application Server”.
Instead, the Rails framework builds those services into each web
application individually. That must be what convention over
configuration is all about. FastCGI handles the multithreading of web
apps, but everything else is in the framework itself.
It’s hard not to feel like we’re going backwards there, but the gain in
simplicity and productivity is wonderful.
I do wonder, though, whether that means there will eventually be a
market for a Rails Application Server, though.
Thanks for your help,
Ken K.
James Duncan Davidson wrote:
Ken K. wrote:
The Rails book talks about running Rails under Apache, but is there a
(relatively) easy way to deploy it to either Tomcat or JBoss? Is the
CGI servlet the only option?Sounds like a relatively easy way to set yourself up a very bruised
forehead. First, running Rails in CGI mode is anticlimatic at best. The
setup of the Rails environment on each request would be painful. So,
you’d really want some Servlet that ran FCGI. And, even if one exists
(which, quite frankly I don’t know if one does), just thinking about it
makes my head hurt. Setting up Rails in a production environment can be
challenging enough.Even if you get it working, it’s not the right tool for the job. If
you’re just trying to dink around with Rails, use WEBrick. If you want
to put something up for real, use Lighty[1] or Apache. If you want to
set up a server with some requests going to Rails and other requests
going to some Servlets, set up Apache with connectors to send some
requests to Tomcat and others to Rails via FCGI.That’s interesting. One of the big reasons to use J2EE is that servlets
scale much better than CGI scripts because only a single instance of each
servlet is used to service all requests. Does that mean that using Rails
with Apache is going back to the CGI approach? The Rails book lists FastCGI
as an alternative to CGI. Does that change the situation?FastCGI != CGI. The ability to have a long running program serve
multiple requests is exactly what FastCGI[2] is all about.Bottom line: This is a very different world than the Servlet one,
especially when it comes to setting things up. Lots of learning and
grappling with some very different concepts has to be done to make the
transition well. But don’t worry, it can be done.[1] http://duncandavidson.com/essay/2005/12/railsonlighty
[2] http://cryp.to/publications/fastcgi/
I agree with everything said here, but for reference, an FCGI does
exist:
http://www.caucho.com/resin-3.0/thirdparty/php.xtp#Configuring-FastCGIServlet
Might actually work well, anyone try it?
Ken K. wrote:
I’ve often thought separating the web server from the application server was
sometimes too many layers of indirection for small systems. It seems
now that I need an app server for the J2EE components and something else
(FastCGI, I guess) for the Rails applications.
I agree about not wanting layers of indirection for small systems. But
if you’re to the point of needing to integrate J2EE components and Rails
and whatever else onto a server, you’re outside the scope of a small
system. For example, in a Rails-only setup, you could just run Lighty
with the right config and be done with it. It’ll manage everything for
you. One process to start, one to kill.
But, when you start mixing things, it gets complicated. For example,
I’ve got a server on which i serve Subversion repositories as well as
some Rails apps. In that case, I use Apache and do enough configuration
voodoo to make it work well. At this point, there’s no “easy”. Just
“possible”.
A J2EE app server does more than just executing the servlets and JSPs.
It also provides a wide range of services, like naming, security,
transactions, resource pooling, and all the other so-called enterprise
services that the big vendors charge so much for.
Oh, I’m quite familiar with what a J2EE-compliant implementation
provides.
It sounds to me, then, that there is no “Rails Application Server”.
Instead, the Rails framework builds those services into each web
application individually. That must be what convention over
configuration is all about. FastCGI handles the multithreading of web
apps, but everything else is in the framework itself.
No, Rails isn’t a server. Rails is a framework. The server is Lighty or
Apache or whatever you want it to be (as long as you can configure it
up). The framework handles requests that the server forwards to your
application. Once you step from development into production, there are
many choices of how to deploy your application based on the Rails
framework. Over time, I expect that there will be some choices to help
ease this. Just as in the early days of using Java Servlets there
weren’t a lot of ways to run them except for Jeeves (aka Java Web
Server). That changed rapidly as servlets were adopted.
We’ve just hit 1.0 of Rails. There’s still some figuring out how things
are best done. But, it’s early days still. It’s still somewhat DIY. It’s
still a bit of a frontier.
It’s hard not to feel like we’re going backwards there, but the gain in
simplicity and productivity is wonderful.
It’s not backwards. Just different. If you were to use a much simplier
web application framework built in Java, you’d feel a bit of the same
feeling.
One data point.
Paul B. wrote:
I agree with everything said here, but for reference, an FCGI does
exist:http://www.caucho.com/resin-3.0/thirdparty/php.xtp#Configuring-FastCGIServlet
Might actually work well, anyone try it?
Heh. That’s interesting. I’ve got mad respect for the Caucho Resin
guys… Thanks for the pointer. Maybe somebody will give it a spin.
James Duncan Davidson wrote:
Ken K. wrote:
I’ve often thought separating the web server from the application server was
sometimes too many layers of indirection for small systems. It seems
now that I need an app server for the J2EE components and something else
(FastCGI, I guess) for the Rails applications.I agree about not wanting layers of indirection for small systems. But
if you’re to the point of needing to integrate J2EE components and Rails
and whatever else onto a server, you’re outside the scope of a small
system. For example, in a Rails-only setup, you could just run Lighty
with the right config and be done with it. It’ll manage everything for
you. One process to start, one to kill.But, when you start mixing things, it gets complicated. For example,
I’ve got a server on which i serve Subversion repositories as well as
some Rails apps. In that case, I use Apache and do enough configuration
voodoo to make it work well. At this point, there’s no “easy”. Just
“possible”.
Yup, I get that. I’m going to have to do the same, since I have several
Java apps already and want to use Rails in a big way now too.
A J2EE app server does more than just executing the servlets and JSPs.
It also provides a wide range of services, like naming, security,
transactions, resource pooling, and all the other so-called enterprise
services that the big vendors charge so much for.Oh, I’m quite familiar with what a J2EE-compliant implementation
provides.
Sorry, I never meant to imply that you didn’t. If anyone does, it’s
you. 
It sounds to me, then, that there is no “Rails Application Server”.
Instead, the Rails framework builds those services into each web
application individually. That must be what convention over
configuration is all about. FastCGI handles the multithreading of web
apps, but everything else is in the framework itself.No, Rails isn’t a server. Rails is a framework. The server is Lighty or
Apache or whatever you want it to be (as long as you can configure it
up). The framework handles requests that the server forwards to your
application. Once you step from development into production, there are
many choices of how to deploy your application based on the Rails
framework. Over time, I expect that there will be some choices to help
ease this. Just as in the early days of using Java Servlets there
weren’t a lot of ways to run them except for Jeeves (aka Java Web
Server). That changed rapidly as servlets were adopted.
Yes, I understand that. I’m just trying to learn how do deploy to
existing servers rather than new ones… and wow, I haven’t thought
about Java Web Server in years.
We’ve just hit 1.0 of Rails. There’s still some figuring out how things
are best done. But, it’s early days still. It’s still somewhat DIY. It’s
still a bit of a frontier.It’s hard not to feel like we’re going backwards there, but the gain in
simplicity and productivity is wonderful.It’s not backwards. Just different. If you were to use a much simplier
web application framework built in Java, you’d feel a bit of the same
feeling.One data point.
I’m sure you’re right. I’m just trying to anticipate the questions from
clients who already have a web server (probably Apache or IBM Http
Server – which is of course the same thing) and don’t want to change it
just to do Rails development.
Thanks again for your help. And by the way, thanks so much for your
development of Ant and Tomcat. I can’t even imagine making a
contribution of that magnitude.
Ken K.
Ken K. wrote:
I’m sure you’re right. I’m just trying to anticipate the questions from
clients who already have a web server (probably Apache or IBM Http
Server – which is of course the same thing) and don’t want to change it
just to do Rails development.
The best answer to those questions from your clients is probably to
proxy the functionality in. It creates the least impact on an existing
setup and lets you run Rails in the best possible way which, right now,
is Lighty as far as I’m concerned.
Thanks again for your help. And by the way, thanks so much for your
development of Ant and Tomcat. I can’t even imagine making a
contribution of that magnitude.
Not a problem.
I think JRuby will soon allow Java backends from Rails, inc. Tomcat
Jruby, anyone?