Ruby Enterprise + Phusion Passenger on Slicehost Screencast

Still relatively new, although they are on version 2.0, Phusion Passenger (mod_rails) and Ruby Enterprise Edition look like the easy-to-configure and preferred way to deploy rails applications. I won’t go over the benefits of passenger, since there are many resources available already. And if you want true performance without using too much memory, Phusion Passenger + Ruby Enterprise Edition is the way to go.

And despite the relatively easy installation, some people are reluctant to try out new scary things. Below, I have a screencast of me setting up Phusion Passenger + Ruby Enterprise Edition on a new slice and deploying a fresh rails app.

You can view the low-quality video inline below or you can download the high quality quicktime movie.

Get the Flash Player to see this player.

Note: If you didn’t watch the movie, some features I use in my sprinkle script are experimental features from my own fork of Sprinkle. Therefore, in the download below I have the .gem file which can be installed locally to get the benefits of all these features. Hopefully they will soon be merged into the main Sprinkle release branch.

For the customized sprinkle gem and files used with the screencast above, click here to download it.

Posted at 2:49 AM | Written by Mitchell Hashimoto | 3 Comments made.

“Request Expired” error in ElasticFox

I just want to make a quick post regarding this error to help fellow google searchers since I could not find anything to help me If you are constantly getting an error saying “request expired” in ElasticFox, it is because your system time is too far forward or too far back! My Mac’s system time gets messed up all the time thanks to boot camp and I’ve gotten to the point where I just ignore it. However, if you want to use ElasticFox, make sure you fix it!

Posted at 10:25 AM | Written by Mitchell Hashimoto | No Comments made.

Create an Elastic Server in MINUTES!

I feel like “elastic” has become the latest top buzzword, and with good reason, because it really will be the future of the internet. One of the greatest helpers towards an elastic web has been Amazon with their web services. EC2 gives you an easy pay-as-you-use infinitely scalable server, S3 gives unlimited storage, SQS gives a queue service, and their new SimpleDB provides a document-oriented database system. I’m currently working on a project I will be deploying to EC2, so I was investigating how to get started with this process…

Unfortunately, despite Amazon providing you with default AMI (Amazon Machine Image, think of it like a copy of your OS), building your own is tough work! Don’t get me wrong, compiling software and hooking it up is pretty fun but I’d rather spend my hours programming and enhancing my applications rather than just publishing them on the web!

In comes Elastic Server On-Demand, an amazing website which you can use to build your own elastic server, ready for deployment not only on EC2, but also many other virtualization platforms! You literally “check the boxes” and click build and you’re off!

Go elastic.

Posted at 9:50 PM | Written by Mitchell Hashimoto | 1 Comment made.

God is Watching My Processes. Is he watching yours?

Having worked for CitrusByte for a couple months now, I can safely say that I’m back in the rails business. And with great power comes great responsibility! And who better to handle my responsibility than God Himself! Anyone who has used rails for 5 minutes has (besides create a full and running website in that limited time) felt the woes of deploying and maintaining rails applications.

After about three years, the defacto rails deployment method is nginx + mongrel. Additionally, and quite often, you also have maybe a Merb or Sinatra server running alongside your rails mongrel processes to handle file uploads. That is a lot of background processes running! On a recent personal site I have worked on (and I am still working on), I had a total of six background applications running: nginx, mysql, mongrel (3 of them), sinatra, beanstalkd, and a worker. I used nginx as the web proxy, mongrel for the rails server, sinatra as my upload server, beanstalkd to queue the uploads that went to sinatra, and a worker to process those jobs. That is a lot of processes to maintain!

And any experienced unix administrator knows that processes are bound to fail at one point or another for some reason or another, let it be over-using memory, over-using CPU, hanging, etc. In the past, to manage processes, we’ve had monit. I’ll admit I have very limited experience with monit (though it was a good experience). This time, I decided to go with God, a ruby-based process manager. Its written in Ruby and its configuration is written in ruby so you can take advantage of all the cool ruby features to configure your own personal God!

The reason God is so amazing is because when I’m developing an application that requires 6 processes to run, its tough to manually start/stop them all to test my code! Using God, its a simple start/stop command and I have a whole development server running on my local machine Additionally, I use a separate (different paths) God configuration file for production, and it runs it just as well!

God has a great little tutorial on their home page, but the coolest thing about God in my opinion is that it auto-daemonizes scripts that aren’t daemons by default. So a Sinatra server, for example, is not a daemon, but that’s no problem for God, it handles it perfectly!

The big reason this is such a big issue for me is that beanstalkd doesn’t output its PID file anywhere, and although ps aux | grep ‘beanstalkd’ | awk ‘{print $2}’ is the cool kids way of doing things, its a bit too… hackish for me. So I just dropped this watch into my God configuration file:

God.watch do |w|
  w.name = 'beanstalkd'
  w.interval = 30.seconds
 
  # I do NOT specify the -d parameter which daemonizes beanstalkd.
  # I do this so God can make it a daemon for me!
  w.start = "beanstalkd -l 0.0.0.0 -p 11300"
 
  w.start_if do |start|
    start.condition(:process_running) do |p|
      p.interval = 5.seconds
      p.running = false
    end
  end
end

And God automatically takes care of beanstalkd for me

Anyways, the moral of this post is YOU should take a look at God, and see how easy it can make your process management!

Posted at 2:54 AM | Written by Mitchell Hashimoto | 1 Comment made.