Posted by ezmobius
Tue, 23 Dec 2008 18:21:00 GMT
Wow this has been a hectic, emotional week. The Rails and Merb core teams have been silently working together towards this monumental announcement. The announcement is that Merb is Rails and Rails is Merb.
Merb and Rails are joining forces and merging the two code bases for Rails-3.0. We’re targeting RailsConf for the first cut of this magic.
When I first started merb way back in the day it was just a fun little project to hack on. But it became more serious as I explored the options. I always considered merb-core a clean room rewrite of ActionPack and I think this tended to upset some people who were very attached to rails.
Fast forward to current day and Merb-1.0 has been out for a while and there is a whole brouhaha of Rails VS Merb memes on the twitters and blogs. This has to stop as it is tearing apart the community and is very non productive.
So our two teams started talking to see if we could put our differences aside and come together for the common good. We’ve laid out a roadmap of what and how to integrate merb’s best features into rails-3.0. I think we have a great plan that will make Rails the best framework in existence. It will be a blend of the best things we have discovered while working on merb, while keeping the Rails aesthetic people have grown to love.
You can expect to get a kick ass, fast, memory efficient version of rails(merb) this spring!
Merb folks will not be left out in the cold. We will continue to support bug and security fixes for the merb 1.0.x line. And we will provide a clear upgrade path to Rails 3.0 for merb apps. We still have quite a few merb apps running internally at ey and will want an upgrade path for our own apps as well.
This is going to be a lot of work for everyone involved but in the end I think this may just be the most inspiring open source story in history.
I’m so impressed with everyone involved. All the core team members from both sides have been able to put away the weapons and egos and really come together, committed to making this transition work seamlessly.
2009 is going to be a seriously strong year for the ruby community. With everyone working together, we have such a kick ass team of smart people that this whole framework thing is going to be a solved issue.
Merb is dead, long live Merb(Rails-3.0)!
Posted by ezmobius
Sun, 07 Dec 2008 19:55:00 GMT
Going into 1.0, Merb has changed the way it handles options and processes. This tends to break people’s existing monit configs. So today I’m releasing a custom Engine Yard monit script for controlling merb master/worker processes.
You can get the script from here: monit_merb_mpc. Put this somewhere in your $PATH, or make it live here: /engineyard/bin/monit_merb_mpc and make sure it is executable.
In order to make proper use of this script it assumes certain paths are setup. In this example we will assume you have an app called ‘iggy’ that lives at /data/iggy/current, where /data/iggy is the main app dir that contains the capistrano releases and current directory. The script assumes these paths so if you want top use different paths you will need to hand edit the script as desired.
This script also assumes a logging directory of /var/log/engineyard/$appname, you can edit the script if you want to change this as well.
You need to have one master configured per app, as well as monit configuration for each worker.
check process merb_iggy_master
with pidfile /var/log/engineyard/iggy/iggy-production-merb.main.pid
start program = "/engineyard/bin/monit_merb_mpc iggy start_master -c3 -n5000"
stop program = "/engineyard/bin/monit_merb_mpc iggy stop_master"
#if totalmem is greater than 80.0 MB for 2 cycles then restart # eating up memory?
Note that the start program needs to be adjusted if you need more/less instances or want to run the workers on different ports /engineyard/bin/monit_merb_mpc iggy start_master -c -n . Also, memory monitoring is turned off for this process because the memory includes all processes under its control, including the workers and they are already monitored.
Worker Config (one for each port)
check process merb_iggy_5000
with pidfile /var/log/engineyard/iggy/iggy-production-merb.5000.pid
start program = "/engineyard/bin/monit_merb_mpc iggy register_worker 5000"
stop program = "/engineyard/bin/monit_merb_mpc iggy restart_worker 5000"
if totalmem is greater than 80.0 MB for 2 cycles then restart # eating up memory?
How it works
Since Merb 1.0 (actually version 0.9.8 and above) uses a master process and a spawner process in addition to the worker processes, the monit_merb_mpc (multi-process-control) script needs to control the master process separately from the worker processes. To accomplish this, there is a fair amount of trickery to make monit treat the merb processes in a way monit was never intended to be able to handle. When the master process is started, it will create all the worker processes, so when monit starts the worker processes, they are infact already started – so the start command for the worker simply “registers” the worker – in other words, it just ensures that the pid files contains the worker pid. Also since the master process will automatically restart the worker processes, the stop action for the workers is actually a restart.
Although this looks like it should use the monit dependency directive, the scripts are actually written to not need it, and making the worker processes dependent on the master process, it will cause problems during shutdown.
since the master specified the number of worker processes using the -c option, you can’t simply shutdown a single worker process by stopping it with monit – it will simply restart by itself and operate unmonitored, thus making it a possible runaway process.
Thanks to all the EY support guys who worked on this one to make it smooth. Hopefully this clears up how to deploy merb with the master/worker server cluster setup under monit.