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.
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
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.
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:
/private/var/log/apache2/error.log. Not that that’s bad, but you’re probably not used to looking for Rails logs there.
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.
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'
Interested in learning more about our basic and advanced Back-End Courses?
Learn from the experts at a Big Nerd Ranch Bootcamp!
Interested in leveling up your coding skills from the same authors of the Big Nerd Ranch Guide? Subscribe to The Frontier today!