Before the question(s), let me stress that I don’t have ANY biases in
any direction on this subject. I’ve been learning RoR and am very
impressed by it; this is just a request to learn - not any type of flame
bait.
I can see (some of) the advantages to developing w/RoR. I say some
because I’m pretty sure that I’m just scratching the surface. There is
no question that it is an incredibly powerful development engine. It’s
the deployment side of it that bothers me. I see people talking about
switching to lighthttp or some other server just so they can use RoR. I
see a FAQ page that actually has a question about how to have more than
one Rails application on a single server. If that question even has to
be asked, it seems something is wrong. If RoR is so specialized that the
most common web server in use (Apache) isn’t in the first choices for
hosting, something seems wrong.
A quick (and it was very quick) google shows me that there are
alternatives. There are frameworks for Python and Perl … and I’d be
surprised if a closer look wouldn’t show more frameworks for Ruby and
any other languages that have a current following (I guess that rules
out Cobol ). Considering what appears to be the deployment problems
of RoR, why is this a good / better general purpose framework. If I’m
wrong about the deployment problems, I’m willing to learn.
Remembering that I REALLY don’t want to start a flame-war, would some
of you that have been using RoR for a while be willing to fill in what
are my obvious gaps?
May be…I am not the correct person to answer this, but currently
Apache-2.2.3 is the standard way of serving Ruby on Rails
application.Justuse a cluster of mongrel application servers as a
backend(for your own good
actually).
Lots of commercial sites are being run like this. Its scalable, fast and
works as a charm.There ain’t any point in stressing this…but for
serving ASP.NET applications you must use IIS, so does that makes
ASP.NETapplications total crap to deploy?
May be…I am not the correct person to answer this, but currently
Apache-2.2.3 is the standard way of serving Ruby on Rails
application.Justuse a cluster of mongrel application servers as a
backend(for your own good
actually).
OK, I’ll look at this. Seems a bit heavy handed to need multiple boxes
just because you’re running more than one application (if I understand
you). I thought we left that requirement behind back in the 1970’s.
Whoever said that is wrong. You don’t need multiple boxes to run more
than one application. Rails applications usually use either FCGI or
Mongrel where you get x number of Rails processes lined up for
Apache/lighttpd/litespeed/whatever-with-a-decent-proxy-or-fcgi-implementation
lined up.
This does in general require more memory than, say, mod_php, though.
May be…I am not the correct person to answer this, but currently
Apache-2.2.3 is the standard way of serving Ruby on Rails
application.Justuse a cluster of mongrel application servers as a
backend(for your own good
actually).
OK, I’ll look at this. Seems a bit heavy handed to need multiple boxes
just because you’re running more than one application (if I understand
you). I thought we left that requirement behind back in the 1970’s.
Lots of commercial sites are being run like this. Its scalable, fast and
works as a charm.There ain’t any point in stressing this…but for
serving ASP.NET applications you must use IIS, so does that makes
ASP.NETapplications total crap to deploy?
I dont think so.
I do. ASP.NET is a nightmare; I’d NEVER use it as an example of a good
framework. It - combined with the IIS requirement is a security hole
inviting people in. Just because Microsoft is big doesn’t mean they’ve
got the best answers.
you). I thought we left that requirement behind back in the 1970’s.
mongrel_cluster is a piece of software that essentially starts and
stops multiple instances of mongrel on different ports. You don’t
need to have them on separate hardware, although you could if you
want.
On the front-end, you’ll want to use something like Apache or Pound to
proxy requests to the appropriate app server(s).
May be…I am not the correct person to answer this, but currently
Apache-2.2.3 is the standard way of serving Ruby on Rails
application.Justuse a cluster of mongrel application servers as a
backend(for your own good
actually).
OK, I’ll look at this. Seems a bit heavy handed to need multiple boxes
just because you’re running more than one application (if I understand
you). I thought we left that requirement behind back in the 1970’s.
Whoever said that is wrong. You don’t need multiple boxes to run more
than one application. Rails applications usually use either FCGI or
Mongrel where you get x number of Rails processes lined up for
Apache/lighttpd/litespeed/whatever-with-a-decent-proxy-or-fcgi-implementation
lined up.
Sorry. Like I said, I’m looking for information and the post said
“cluster of Mongrel servers”. From “cluster”, I extrapolated -
apparently incorrectly.
This does in general require more memory than, say, mod_php, though.
Which doesn’t necessarily bother me. Memory is cheap today (I can’t
believe I started on a box that filled a computer room and had 32K of CORE memory)
the deployment side of it that bothers me. I see people talking about
switching to lighthttp or some other server just so they can use RoR. I
see a FAQ page that actually has a question about how to have more than
one Rails application on a single server. If that question even has to
be asked, it seems something is wrong. If RoR is so specialized that the
most common web server in use (Apache) isn’t in the first choices for
hosting, something seems wrong.
It often is the first choice, whether via FastCGI, mod_proxy_balancer,
or
even mod_ruby. Rails scales best as a pool of Ruby processes, so
running a
cluster of FastCGI instances or proxying a pack of Mongrel makes a lot
sense.
A quick (and it was very quick) google shows me that there are
alternatives. There are frameworks for Python and Perl … and I’d be
surprised if a closer look wouldn’t show more frameworks for Ruby and
any other languages that have a current following (I guess that rules
out Cobol ). Considering what appears to be the deployment problems
of RoR, why is this a good / better general purpose framework. If I’m
wrong about the deployment problems, I’m willing to learn.
You haven’t actually stated any deployment problems. What’s wrong with
Rails
deployment is that it’s a little bit different and therefore scary. Wait
until you get to what’s right: migrations and Capistrano. Good luck.
jeremy
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.