Ruby on Rails Deployment
Introduction
Ruby on Rails is a wonderful platform for web applications and rapid web development. That being said when running an application using the ruby interpreter as well as the plethora of deployment options one can get confused quite quickly. I am writing this post to try and clear the muddy water of deploying Ruby on Rails web applications.
Platform Choices
Disclaimer: None of the recommendations below are tested for the Win 32 platform and there is a high probability that nothing will work correctly or at all.
All of the following deployment recommendations I will be writing about are achievable on most if not all of the UNIX/Linux/BSD operating systems that are available today. Now that we have those very important logistics out of the way lets get started with the foundation for rails deployment!
Note: Mac OS X Leopard (The next release slated for October) will ship with the Ruby on Rails stack already installed and ready to start development.
If you are running Mac OS X Tiger then head over to my Mac OS X Ruby on Rails setup How-To to get yourself up and running with an optimized server-grade Ruby on Rails installation.
Don't be too thrown off by that title because it can be used on any UNIX/BSD Operating System. Just switch up to a source based installation or use the package manager built into your OS.
Foundation
I have two recommendations for optimized Ruby on Rails hosting. I will go over the benefits of each and when to choose one over the other. Both options require an external listening web server and a process to access the Ruby on Rails web application.
Web Servers
I have two favorite WebServers that I use currently. One which runs the blog and one that I run on my internal servers. Each of the below web servers each offer their own advantages to the mix which you can weigh and choose the one based on your requirements.
- Nginx (Pronounced "Engine X")
- LiteSpeed
For example LiteSpeed is not open source and there are two version one which is "more optimized" which costs quite a bit of money. Both the free and commercial versions are managed via a web interface. There is also an option at the time of installation to enable AWstats to monitor the traffic on your website. This is quite simple to setup and maintain. The upgrade process detailed blow is extremely simple to do and requires minimal time and effort.
Ruby on Rails Dispatcher
There are two methods of dispatching the Ruby on Rails web application that I use. One which is handled though an API which is installed via a gem (Ruby LSAPI) and one that runs a backend server which handles the dynamic Ruby content (Mongrel).
- LiteSpeed Ruby LSAPI
- Mongrel HA Cluster
If you have never setup a High-Available cluster before don't worry mongrel makes this process very simple. The configuration for a mongrel cluster is also extremely easy to create and understand. The config file itself can be as small as three lines. I would recommend against this as there are some options that would allow for a more secure mogrel cluster. As you can see below mine is a little bit longer but still you can agree with me that it is quite easy.
---
cwd: /path/to/railsapp/
log_file: log/mongrel.log
port: "8000"
environment: development
address: 127.0.0.1
pid_file: tmp/pids/mongrel.pid
servers: 3
Comparison
Both of the above options are very good choices when deploying Rails web applications. Each have drawbacks. For example if you are on a resticted VPS or other RAM limited server then the choice would be to use the Ruby-LSAPI because it requires only one ruby process to be run thus saving you tons of memory. On average a ruby process takes about 32MB of RAM. This can be quite detrimental if you only have 256MB on a VPS if you are running a 3 server HA mongrel cluster which would require (you guessed it) 96 MB of RAM! That is without the web proxy running which is required by mongrel cluster to proxy between the mongrel servers.
On to the comparison of the web servers that we use as a reverse proxy, Litespeed and Nginx. Both are wonderful web servers that are efficient and have a very small memory footprint. Each taking about only 2MB of RAM to run with minimal load. As the load increases the RAM usage does not increase that much. That being said Litespeed with Ruby-LSAPI is a wonderful choice when RAM is a consideration. When running development mongrel and Nginx might seem more responsive depending on the load and the amount of mongrel servers you have running in the cluster.
Tip of the Day - Compiling in Solaris
I have a few tips that you might find useful in my experiences with building open source application under solaris 10.
On a default install solaris supplies the GCC tool-chain. You need to have the following two directories in your path. Put the following in your .profile.
export PATH=/usr/ccs/bin:/usr/sfw/bin:$PATH
I have also had more success with working in the bash shell over tcsh. This might just be the fact that I am more familiar with bash.
Installing Subversion 1.4.5 From Source on Solaris 10 1
Introduction
This guide will go through the installation process of building subversion from source on Solaris 10 machine. These instructions can be ported to almost any platform supported by subversion. Subversion is used in many development areas when losing progress and tracking changes is important. Which is basically all the time. That being said I use subversion for all my development projects because it is very efficient version control system, also it can be used over SSH without even setting up Web_DAV access or running the included svn server. Enjoy the post and by all means enjoy subversion. You will never look back.
Download Source
wget http://subversion.tigris.org/downloads/subversion-deps-1.4.5.tar.bz2
wget http://subversion.tigris.org/downloads/subversion-1.4.5.tar.bz2
Extracting Source
bunzip2 subversion-1.4.5.tar.bz2
tar -xf subversion-1.4.5.tar.bz2
bunzip2 subversion-deps-1.4.5.tar.bz2
tar -xf subversion-deps-1.4.5.tar.bz2
Configure, Compile and Install
cd subversion-1.4.5
./configure --prefix=/opt/local --without-neon
Note: This guide will build subversion without berkeley db and uses FSFS as the default repo type (IMHO this is a much better solution anyway) There is also no mod_dav support.
make
make install
Conclusion
I do not use subversion with web_dav access. This will soon change because Nginx has a DAV extension and it extremely fast. If you require access to you repository I would recommend either a code browser like the following fabulous coe browsers depending on your preference.
Project Management and Code Browsers
Code Browser
I prefer to use Retrospectiva because I then do not need to mess around with python and can just setup another vhost in my Nginx/mongrel cluster and runs fine. Also the features included in Retrospectiva are more polished IMHO.