Forum: Ruby on Rails AWD page 624-626 Understanding how Apache, Mongrel and Rais

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
BraveDave (Guest)
on 2007-04-10 20:00
(Received via mailing list)
I'm trying to understand the 'Big Picture' of how Ruby on Rails
applications are deployed and operate in distributed environment (one
deployment server, many remote servers).
I follow AWD by Dave T.' explanation from pages 624-626. From
reading these pages I have these questions;

1. How does the RonR instance on the 'remote' server gain access to
the program logic to process the HTTP request?

2. Is Mongrel the actual program running that receives the HTTP
request and runs the code against the RonR libraries and the
application code?

3. How does Mongrel know where the 'remote' servers are located?

4. Where is Mongrel running when there's an environment like this, on
the deployment or remote server?

5. How does Apache know what port to send the request out on? In his
example they have ports 8000 and 8001.

6. If Apache's job is to send the requests out on a particular port,
then why does it need to know where the program code resides (as shown
in it's page 626 script).

David
Ben M. (Guest)
on 2007-04-10 23:06
(Received via mailing list)
BraveDave wrote:
> I'm trying to understand the 'Big Picture' of how Ruby on Rails
> applications are deployed and operate in distributed environment (one
> deployment server, many remote servers).
> I follow AWD by Dave T.' explanation from pages 624-626. From
> reading these pages I have these questions;
>
> 1. How does the RonR instance on the 'remote' server gain access to
> the program logic to process the HTTP request?

Not sure I understand this question. Once you deploy your rails app to a
a remote server, it *is* the program logic to process the HTTP request.
For now, maybe don't worry about "remote"... try to get your head around
what apache and mongrel do.

> 2. Is Mongrel the actual program running that receives the HTTP
> request and runs the code against the RonR libraries and the
> application code?

The standard port for the WWW is 80. So something needs to respond to
web requests on port 80 on your server. Rails code is single-threaded,
so in order to handle concurrent requests using mongrel, you have to
start multiple mongrel processes. These can't all answer on port 80, so
you need a web server (or just a load balancer) like apache (or nginx,
pen, pound, lighttpd, etc.) to receive the request on port 80 and
forward it to one of your mongrel instances.

> 3. How does Mongrel know where the 'remote' servers are located?

Mongrel *is* on the remote server.

> 4. Where is Mongrel running when there's an environment like this, on
> the deployment or remote server?

The remote server... One could always have a more sophisticated setup
with separate machines for different roles... uh, but no one usually
speaks of a "deployment" server. The idea of capistrano is that you run
commands on you local machine and it executes them on the server
(including checking out code from a repository server).

> 5. How does Apache know what port to send the request out on? In his
> example they have ports 8000 and 8001.

You configure mongrel_cluster (usually in
/etc/mongrel_cluster/myapp.yml) to start a certain number of instances
on certain ports. You set up the apache config to proxy the requests to
the ports that you configure mongrel to listen on.

> 6. If Apache's job is to send the requests out on a particular port,
> then why does it need to know where the program code resides (as shown
> in it's page 626 script).

I think you mean the sample apache config on page 625 (at least in my
copy of the pdf)... as in setting the DocumentRoot. If so, this is the
other reason for putting a web server in front of mongrel... it can
(theoretically) serve static files faster.

Notice that that config ends in /current/public... it is setting the
rails app's public directory -- with all the images, stylesheets and
other static resources as the document root for this virtual host.

Hope some of this helps....

b
This topic is locked and can not be replied to.