Running bibapp in production

Our assumption here is going to be that if you're willing to run an application on the web in production then you have at least some idea what you're doing. So this information will be less about exact recipes for running Bibapp in production and more an assessment of the kinds of strategies that you might use, assuming that you can work out the details for yourself once your team has taken all of the relevant factors with your situation into account.

Note that you should be familiar with the information on installing Bibapp, as you need to (for example) make sure that solr and delayed_job are running.

Direct connection to the web

There are a number of ways to run Rails applications directly on a port right now. This may be useful if this is the only web application that your server is serving. Probably the simplest way to do this is to use Passenger in standalone mode. To do this with Bibapp you'd need to add gem 'passenger' to your Gemfile and update your bundle. Then cd into your Rails directory and run passenger start -h to see the various options. If you wanted to (say) run it on port 8080 as a daemon in production mode you'd use a command like:

bundle exec passenger start -p 8080 -e production -d 

What is really going on is that the passenger gem will pull down a copy of the nginx web server and run that on port 8080 with Bibapp running via passenger behind it. Since nginx + passenger is considered a perfectly fine method of deploying Rails apps, this should get you going. Just write some init/start/stop scripts etc. and you're ready to go. Passenger can be restarted in the usual way, by touching tmp/restart.txt. That means this should work nicely with capistrano deployments as well.

Behind reverse proxy

You can deploy Bibapp locally using either the above strategy (except not exposing the port to the outside) or using something like a cluster of thins or mongrels. Then stick a reverse proxy like nginx or apache in front of it and configure them to send the right URLs to the right ports. The advantage here is that you can serve other applications as well and use url matching/rewriting, named hosts, or whatever to direct the Bibapp traffic to the right place. The advantage over using Passenger directly with your web server is that in this scheme each Rails application can use its own version of ruby and set of gems (e.g. using RVM). This is either harder or impossible with, say, Apache running passenger itself. In this case you'll probably need to add whatever webserver (passenger, thin, mongrel, etc.) you'll be using to the Gemfile and update the bundle and of course write scripts to start/monitor/etc. the webserver(s) behind the proxy. Don't forget that typically you'll want to use 'bundle exec' to run things in the context of the bundle.

Apache (or nginx) / Passenger

Here you would use the standard Apache/Passenger (or nginx/Passenger) integration. There are scenarios where this might be important, e.g. Apache might be performing some authentication directly that wouldn't work as well in the reverse proxy scenario. Also once you get it set up and configured the Passenger integration is really automatic. Bibapp works fine in this configuration too.

Regardless of the choice you make here, if you do a Capistrano deployment you may have to work on your deploy.rb file to assure that everything gets started/stopped/etc. properly. The deploy.rb.template file provided with Bibapp is geared towards the situation at the University of Illinois, which is Apache/Passenger.