Setting up apache proxy + mongrels, while not impossible, is also not brain-dead easy.
Also, in virtual private server scenarios RAM may be a hot commodity (slicehost, for instance) -- so in theory this should help you run more rails sites with less RAM, since you won't have to spin up individual mongrel clusters for each ___domain.
for web hosting providers only giving ftp/sftp access, there's really no other way to signal a restart than to upload another file. you have no control over the processes and using some web-based administration too complex.
Just noticed that the "Passenger blog":http://izumi.plan99.net/blog/index.php/2008/04/11/phusion-pa... mentions that Dreamhost has been beta testing Passenger. If thats true, and Dreamhost rolls it out (soon!), then Rails is going to become as ubiquitous as PHP for hobby-coders that don't enjoy playing sysadmins. I'm probably one of them.
And if you want to do the same-ish thing with similarly little configuration (indeed, less) with any framework (not just Rails) or even with a non-Ruby language, check out SwitchPipe: http://switchpipe.org/
The answer to this is probably obvious, but, can someone sell my on why I want mod_rails? What's wrong with the tag-team app server / web server architecture?
- Deployment is only a matter of uploading application files. No Ruby on Rails-specific server configuration required!
- Built on the industry standard Apache web server.
- Allows Ruby on Rails applications to use about 33% less memory, when used in combination with Ruby Enterprise Edition (optional).
- Zero maintenance. No port management, server process monitoring or stale file cleanup required. Errors are automatically recovered whenever possible.
- Designed for performance, stability and security. Passenger should never crash Apache even in case of crashing Rails applications.
- Well-documented, for both system administrators and developers!
What I have been wondering is what happens to the memory footprint? It says somewhere on the site it is reduced by 33% - is that a typical reduction?
Also, if this is like mod_perl, deployment wasn't really as simple as it seemed. The general advice on mod_perl was to proxy requests from your front end 'static' webserver to the mod_perl one, because each apache process had to effectively run a Perl interpreter, giving them a big memory footprint. You don't want to use your expensive mod_perl/ruby processes to serve images etc.
I also think there are other advantages to running expensive processes behind a proxy (I may be wrong on this one), but I think that slow clients tend to tied up the front end process as it streams the data to them.
If you have appServer -> proxy -> slow client, the app server sends the data to the proxy at LAN speed, freeing it to serve another request, and the proxy ties up a process streaming the data to the client.
I am not trying to criticize, I am interested in whether they solved these problems (if they even are problems anymore) and how.
"In addition to the GNU General Public License v2 licensing terms, we explicitly grand [sic] you the permission to run any application on top of Passenger, regardless of the application's own licensing terms. The application will not be bound to the terms of the GPL in any way. That is, the GPL only applies to Passenger itself, and not to applications that are run through Passenger."
Sounds like they are just clarifying an aspect of GPL that comes up frequently in FAQ. People wouldn't be distributing Passenger code with their application. They're just using it, like many developers use Linux but don't have applications on Linux bound by Linux's GPL license.
Err... no, I typed too quickly. Still, I really don't see the point of GPL'ing it under version two with that clause unless they think that it will mean hosting providers have to feed their changes back...
Perhaps something like the Affero GPL would have been more appropriate in that case? Maybe you have access to better legal advice than I do, but my reading of the GPL is that if you're not redistributing it, you're not required to give back your modifications, and I'm not sure that running mod_rails on your own servers counts as redistribution. Perhaps you're simply aiming to stop people from selling binary-only versions, but that doesn't seem like nearly as likely a scenario as some hosting provider boasting of a mod_rails with extra secret sauce that they're not sharing.
I'm not a license zealot, and think they all have their places, but I should also say a word or two in favor of the BSD/Apache style licenses: in the Apache Software Foundation, we don't rely on licenses to "keep people in line" (in terms of proprietary forks), but a strong, diverse community that has the potential to outdevelop anyone who tries to make a proprietary fork. They realize that if they fork, they're going to fall behind the community driven version, which is moving faster. Of course, that's not possible in all cases, but I think that a potentially important project like mod_rails certainly has a good shot at attracting that kind of community. You guys probably know more about the people in the rails hosting market than I do though, so maybe your fears are based on a concrete threat.
this is huge, although i think this needed to come out earlier. rails deployment has already been generally pegged as 'hard' or a 'pain'. I have gotten use to getting a rails app coded fast then getting ready to spend some time deploying.
Do note that this is not the first attempt at this, however it looks. My own system (I say "my" loosely, it's public ___domain and open source) SwitchPipe: http://switchpipe.org/ is already in widespread usage, but its focus is a little different.
That is why i said it seems a little late. I remember stabbing my eyes out when i first got into rails once i tried deploying stuff, back in the fastcgi/lighttpd days.
btw, switchpipe is going to rule the world in a few months, the support for all the other frameworks looks awesome.
To be fair, fastcgi wasn't /too/ bad IF you actually had it running well at least once g and that varied incredibly from machine to machine, alas. It did use a similar underlying mechanism to most of these other alternatives, just in a rather messy way.
I don't think SwitchPipe will rule anything, but perhaps once it's up on Github (instead of SVN) and I release the next version, more baby steps can be made. I'd love to make it even more simple somehow, and perhaps port it to a much faster base (probably Python).
Yeah, I've had good luck with mod_fcgid, actually. I don't have that much traffic, but I like the fact that the software takes care of setting up and tearing down new instances of the application server, rather than having to take a wild guess at how many mongrel instances might be needed per virtual host. This is something that mod_rails also promises to do well.
I assume you mean over using mod_rewrite to do proxying direct to backend app servers?
If so:
- SwitchPipe controls backend app server processes. If an app isn't being used, it doesn't need to be running.
- If an app is under heavy demand, I want more instances (up to a limit) to be launched to deal with it.
- SwitchPipe deals with all of the port numbers. No port numbers to deal with as a user.
Just some minor points, but with big usability gains.
