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 Zygmuntowicz" <[EMAIL PROTECTED]> To: <rubyonrails-deployment@googlegroups.com> Sent: Wednesday, March 05, 2008 5:48 PM Subject: [Rails-deploy] Re: Monit trumps mongrel_cluster ? > > Greg- > > > On Mar 5, 2008, at 4:55 PM, Greg Willits wrote: > >> >> 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 > > 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- > > - Ezra Zygmuntowicz > -- Founder & Software Architect > -- [EMAIL PROTECTED] > -- EngineYard.com > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Deploying Rails" group. To post to this group, send email to rubyonrails-deployment@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-deployment?hl=en -~----------~----~----~----~------~----~------~--~---
