Passenger, AKA mod_rails
- Despite reports to the contrary, Passenger installed just fine with Leopard’s built-in Apache (I’m running Apache 2.2.8).
- Setup is very easy, as advertised.
- My default doc root(~/Sites) is works exactly as it did before. I do some HTML and PHP work there, so it was key that it continue to work properly.
Since the install process itself is quite easy, I wanted to offer a few tips for utilizing Passenger in a typical dev environment – i.e., what you need after you get your first Passenger-powered Rails app up and running.
Your Brain on Passenger
As you know,
script/server starts your Rails app on a specific port. If you bounce around between a number of applications at any one time, you’re probably used to either starting them on different ports, or control-c’ing your current mongrel, cd’ing to another app’s directory, and script/server’ing again. This familiar pattern changes when you’re running passenger. All your apps are available at any one time, as long as you have your vhosts configured.
If you’re like me, you usually hit your currently running Rails app on http://localhost:3000. That also changes when you’re running Passenger. Instead, you’ll hit a unique URL for each app, which you’ve configured in /etc/hosts to just go to 127.0.0.1
Setting up a new app
I set up a lot of Rails apps in my dev environment. With Passenger, in exchange for the on-demand convenience of accessing any of your apps any time, there are a few additional setup steps to take whenever you introduce a new app into your dev environment.
- create your rails project as usual
- add a new vhost. I configure mine in
- add the host in /etc/hosts
- restart apache: sudo apachectl restart
Here’s a vhosts example with two apps I’m running locally. You can set up as many apps as you want this way:
<VirtualHost *:80> DocumentRoot "/Users/andre/projects/rails/hotspotr/public" ServerName dev.hotspotr.com ErrorLog "/Users/andre/projects/rails/hotspotr/log/error.log" </VirtualHost> <VirtualHost *:80> DocumentRoot "/Users/andre/projects/rails/shapewiki/public" ServerName dev.shapewiki.com ErrorLog "/Users/andre/projects/rails/shapewiki/log/error.log" </VirtualHost> </code>
Two things to note here:
- The ErrorLog line is optional. If you don’t include it, the error output for this app will go to
/private/var/log/apache2/error.log. Not that that’s bad, but you’re probably not used to looking for Rails logs there.
- I decided to go with the convention of dev.[PRODUCTION_URL].com. You can use anything here, as long as it matches up with an entry in /etc/hosts (see below)
And here’s an example
/etc/hosts addition to match the two virtual hosts above:
127.0.0.1 dev.hotspotr.com 127.0.0.1 dev.shapewiki.com
That’s it! Go to (for example) http://dev.hotspotr.com, and you’re hitting you local development app. There is nothing to start and stop. The first request for any app you hit will take a moment. Subsequent requests will feel quite snappy.
Let’s Set up some Aliases to Make it all Flow
Here are the aliases I added to my
.bashrc file to give me quick access to everything I needed for a new, Passenger-centric workflow in my development environment:
# Use this in any RAILS_ROOT dir. That restart.txt file tells mod_rails to restart this app. # You'll want to do this when (for example) you install a new plugin. alias restart_rails='touch tmp/restart.txt' # By default, your app's error log now goes here. Unless you configure your apps otherwise, # it's helpful to have an alias to take you to your error log quickly. alias apache_logs='cd /private/var/log/apache2/' # You'll be adding to your vhosts configuration everytime you introduce a new Rails app. # Might as well make it a shortcut alias vhosts='sudo vi /private/etc/apache2/extra/httpd-vhosts.conf' # Dito with hosts alias hosts='sudo vi /etc/hosts' # You'll need to restart apache whenever you make a change to vhosts. # You can also click System Preference->Sharing->Web Sharing, but this is quicker. alias apache_restart='sudo apachectl restart'