Automate Your Rails Deployment

Mitchell Hashimoto on July 18th, 2008 13 Comments

I’m a big fan of researching and playing with new technologies (hey! I remember rails 0.7) so its no surprise that I’ve been playing a lot with Ruby Enterprise Edition and Phusion Passenger (mod_rails) and researching it as a viable rails deployment solution. For those of you who are staying with the tried and true Nginx + Mongrel, let me offer a brief introduction to Phusion Passenger (mod_rails). But first… let’s take a trip down memory lane:

Rails Deployment History

Phusion Passenger is super easy to install and setup as an Apache mod and immediately simplifies the deployment of rails. It allows you to deploy a rails application without splitting your attention between the web server and app server, such as Nginx and Mongrel. You literally upload a configuration which looks like the following block of code to Apache and it manages your rails application for you.

<VirtualHost *:80>
  ServerName  myrailssite.com
  ServerAlias www.myrailssite.com
 
  DocumentRoot /var/www/rails-project/current/public
</VirtualHost>

Passenger gives rails the same ease of deployment as mod_php and mod_perl. And when you want, it will automatically reload your app if you deploy changes.

But the real gem is using Phusion Passenger with Ruby Enterprise Edition, which is a rewrite of the Ruby MRI with optimization for mod_rails in mind. The initial benchmarks show that using both together results in lower memory usage and increased requests per second. Since then, passenger has had a myriad of early adopters reporting their results. DreamHost praised Phusion for finally solving their rails deployment, after complaining only 4 months earlier of how rails deployment options were a joke. Other websites have boarded the Phusion Passenger train too, reporting easy setup and even easier deployment.

The results look good: Dead easy rails deployment with great performance.

So how do you get started? For dead easy server provisioning, check out Sprinkle, a gem which provisions servers for you. I’ve been hard at work implementing new features and patches to Sprinkle, which you can see in my fork. I have already created the sprinkle scripts to automatically setup this entire stack on a fresh ubuntu server:

  • Rails (and Ruby, Rubygems)
  • sqlite3 or mySQL
  • Apache2
  • Phusion Passenger (mod_rails)
  • Ruby Enterprise Edition

If you’re interested in the automatic setup solution, I recommend checking out the screencast I made detailing the entire process. It requires a custom version of the sprinkle gem (from my fork), which the screencast covers.

If you plan on trying it out and have any questions, leave a comment or feel free to contact me at mitchell.hashimoto [at] citrusbyte [dot] com and I’ll happily provide any assistance you may need.

Tags: , , , , , ,

This entry was posted on Friday, July 18th, 2008 at 3:41 pm. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

« Keep your site as fresh as your code || TakeFive Interviews Ari Lerner »

13 Responses to “Automate Your Rails Deployment”

  1. Alistair Holt Says: July 19th, 2008 at 3:45 pm

    Thanks Mitchell. Nice article and screencast. Perfect timing for me now that I’ve just started looking into slicehost.

  2. Martin Says: July 19th, 2008 at 3:48 pm

    Detail: I would guess the last box in your (nice) graph should say ‘Apache2′ (and not ‘Apache’).

  3. Mitchell Hashimoto Says: July 19th, 2008 at 3:52 pm

    @Martin: You’re correct, Apache2 it is! Unfortunately I didn’t save an easy editable version of the image. But good catch.

    @Alistair: Thank you! If you’re interested in slicehost you should follow my fork of Sprinkle at github:

    http://github.com/mitchellh/sprinkle/tree/master

    Sprinkle was made with provisioning slicehost specifically, though it can be used to sprinkle any time of server.

  4. Juston George Says: July 19th, 2008 at 3:52 pm

    I’ve actually done something similar using my Deprec2 fork, installing the stack as

    Nginx -> Swiftiply -> Thin

    which has the advantage later that you can break nginx and swiftiply out to a seperate machine(s) as a load balancer / static cache later.

    The bonus with deprec is you can edit the script to install/configure any of:

    apache daemonize god heartbeat iptables logrotate memcached mongrel monit mysql nagios nginx ntp php postfix rails ruby sphinx ssh svn swiftiply thin trac adding/removing/managing users xen

  5. Mitchell Hashimoto Says: July 19th, 2008 at 3:52 pm

    Justin, because Sprinkle is still new, a lot of those packages aren’t created yet but the functionality to do this is all there. I plan on creating a comprehensive set of packages for Sprinkle once I finish documenting and adding a couple more features. Compared to deprec (and deprec2), Sprinkle is still very young. Development on Sprinkle started in late March of this year, whereas deprec has been around for years. Deprec is a great gem, but the eloquence of Sprinkle appealed to me.

  6. Malko Says: July 21st, 2008 at 3:55 pm

    Mitchell,

    Thanks for this. Getting this setup on my slicehost was a breeze. I found one error that I can’t quite shake. It seems that none of my rubygems are taking hold. If I go into an irb prompt and do require ‘haml’ for instance, I’m getting errors that it doesn’t know how to load this. Now I know I can require ‘rubygems’ before hand, but do you have any idea how to solve this issue so that you don’t need that require ‘rubygems’ like it is on my local machine?

    Thanks!

  7. Ari Lerner Says: July 21st, 2008 at 3:57 pm

    The newest fixes (including a gem fix) have been pushed into the latest sprinkle release so:

    gem install sprinkle

    should work once again (thanks marcus)

  8. Daniel Fischer Says: August 7th, 2008 at 3:37 pm

    I am just starting to use passenger for my production environment.

    I tried it for local development, but I don’t think that is the best application to use it. Typing out script/server is a lot easier.

  9. links for 2008-08-09 [delicious.com] « Amy G. Dala Says: August 9th, 2008 at 6:31 am

    [...] Official CitrusByte Blog » Blog Archive » Automate Your Rails Deployment (tags: rails deployment reference) [...]

  10. Mitchell Hashimoto Says: August 14th, 2008 at 7:50 pm

    Daniel, how is typing 

    script/server

    easier than making an alias to touch tmp/restart.txt?

    Another benefit for development is if you’re running multiple rails servers you can run all of them on port 80 at the same time, so you don’t have to play with port 3000, 3001, etc.

  11. Daniel Says: August 15th, 2008 at 11:31 am

    Because you still have to create a vhost directive for each site.

    Process of passenger on OSX w/ Passenger preference:

    1) Open up apple preferences
    2) Drag rails directory to preference
    3) Make alias to tmp/restart.txt

    Lame!

  12. Mitchell Hashimoto Says: August 16th, 2008 at 10:53 am

    I suppose, but with the preference pane it sets up the vhost for you so that is a plus. And you can’t beat running your application components all at the same time, without having to worry about ports being taken up. I have client work, personal work, etc. all sitting idle all the time with my apache, so I just go to “somework.loc” in my browser and it boots up the rails process for me, without me having to terminal in and script/server it. Additionally, coding URLs to use “.loc” instead of “.com” is a lot easier than worrying about ports.

    And if you just put this alias in your bashrc file:

    alias prestart="touch tmp/restart.txt"

    Then typing that instead of ^c then script/server and waiting for it to boot everytime is a great resource.

  13. automate rails deploy and provisioning — award tour Says: August 19th, 2008 at 10:09 am

    [...] Official CitrusByte Blog » Automate Your Rails Deployment. some interesting scripts for automating provisioning too. [...]

Leave a Reply