Monit trumps mongrel_cluster?

Rails Deployment
1

I’ve been reading through the book “Deploying Rails Applications,”
studing a setup done by someone els, and creating my own new setup.

In the end it appears that mongrel_cluster (deemed “required” by these
setups) actually has no purpose in my final setup.

Looking for validation or a counter opinion.

In each case the deployment ends up with the OS launching monit at
startup (launchd on OS X Server in my case), and monit with a repetitive
config block that launches one instance of mongrel/rails.

In the book, they use mongrel_cluster, but each “cluster” is just one
mongrel. In the live example I have to look at, they just stuck with
mongrel_rails to launch each one.

Now, the book goes through these stages of showing how to launch one
mongrel, then mongrel_cluster, then mongrel_cluster_ctl, and finally
monit – which just takes us right back to essentially launching one
mongrel at a time again.

I’ve been creating my own new setup, and I went with mongrel_rails per
monit config block like this:

start program =
“/usr/bin/mongrel_rails start -d
-e production -p 8100
-a system.local -t 30
-P /MY/RAILS/ROOT/log/mongrel.8100.pid
-c /MY/RAILS/ROOT”

After having done all that, I’m left wondering what the whole point of
mongrel_cluster is. I now have a mongrel_cluster and mongrel_cluster_ctl
config setup that appears to be useless now that I have monit
controlling them.

So, is the book just showing various techniques as exercises (doesn’t
read that way)? Perhaps one would choose not to use monit? but then how
control these leaky beggers?

Seems to me there was no need to even install mongrel_cluster, and at
this point I may as well rip it out and eliminate the extra work of
installing and configuring it. Which in my case means a clean install of
OS X Server has everything I need right out of the box except for monit
(which a quick compile solved that).

Am I missing something?

– gw

2

Greg-

On Mar 5, 2008, at 4:55 PM, Greg W. wrote:

startup (launchd on OS X Server in my case), and monit with a
mongrel at a time again.

– gw
What you are missing is the fact that mongrel_cluster has the --clean
option while mongrel itself does not. So if your mongrels crash and
don’t clean up their pid file then they will not restart when monit
tries to restart them.

So mongrel_cluster in this case is only used for the --clean option.
We will be adding a --clean option to momngrel itself for the next
release so this is not needed anymore.

Cheers-

3

What you are missing is the fact that mongrel_cluster has the --clean
option while mongrel itself does not. So if your mongrels crash and
don’t clean up their pid file then they will not restart when monit
tries to restart them.

So mongrel_cluster in this case is only used for the --clean option.
We will be adding a --clean option to momngrel itself for the next
release so this is not needed anymore.

Ah, yup. Back to the config files it is…

thx

– gw

4

I followed Ezra’s book, ending up wth the monit setup and it works
awesome.
Restarts are finally truly graceful and I don’t have to babysit the
mongrel
intances anymore. It finally feels like a real web server. Thanks Ezra!

My environment:

  • dell servers
  • centos 4.6
  • nginx
  • mongrel
  • mongrel_cluster
  • monit

Raul

----- Original Message -----
From: “Ezra Z.” [email protected]
To: [email protected]
Sent: Wednesday, March 05, 2008 5:48 PM
Subject: [Rails-deploy] Re: Monit trumps mongrel_cluster ?

5

Gregg,

Due to Rails not being thread safe, you will end having at least a

couple of Mongrel processes to handle a bunch on simultaneous incoming
requests. Even if you can start with just one Mongrel instance, having
the cluster setup is a good policy.

You could also take a look a Thin (I supports clusters out of the

box), or Ebb (look damn fast)as replacements for Mongrel (I have tried
Thin and it is doing great) also you could try God instead of Monit,
it provides a behavior to clean stale pid files, so you could go back
to single Mongrel instance without the cluster support if you decide
so.

http://code.macournoyer.com/thin/
http://ebb.rubyforge.org/
http://god.rubyforge.org/

You are lucky to have Ezra's book, before that, there were only

his blog posts to show some light in the darkness of Rails
deployment :wink:

–
Aníbal Rojas

http://anibal.rojas.com

On Mar 6, 7:55 pm, Greg W. [email protected]

6

I added a function to my mongrel init script to clean stale pids
(there were a lot of cases where I ran into stale pids no matter what
I used).

PID_DIR=/var/run/mongrel
RUBYBIN=/usr/bin/ruby

clean_stale_pid ()
{
for PIDFILE in ls $PID_DIR/*.pid; do
if [ -e $PIDFILE ]; then
PIDDIR=/proc/$(cat $PIDFILE)
if ! [ -d ${PIDDIR} -a “$(readlink -f ${PIDDIR}/exe)” =
$RUBYBIN ]; then
#echo “removing stale pid: $PIDFILE”
rm -f $PIDFILE
fi
fi
done
}

I call the function from monit and other functions in my mongrel init
script. I keep mongrel_cluster around though as I often like to shut
off monit to debug certain things and still maintain control of the
entire cluster. You can totally replace mongrel_cluster with monit/
god and a reworked mongrel init file (or control script).