Rails is a Model View Controller (MVC) framework. As you can imagine from the name, applications written using Model View Controller frameworks have three main components: a model, which represents the data and associated logic; the view, which represents how a user interacts with the application; and the controller, which contains all of the business logic that drives the application. This is an artificial distinction, of course, but it is a powerful one.
You'll need Apache 2.0+ and MySQL installed on your Red Hat Linux computer to run these examples.
How do you install Rails?
The first, most basic requirement for running Rails is having the Ruby programming language installed. All recent distributions of Fedora™ Core or Red Hat® Enterprise Linux® include Ruby. You can check to see if Ruby is installed by running the command:ruby -v
wget ftp://ftp.ruby-lang.org/pub/ruby/ruby-1.8.4.tar.gz
tar -xzvf ruby-1.8.4.tar.gz
cd ruby-1.8.4
./configure
make
make install
wget http://rubyforge.org/frs/download.php/11289/rubygems-0.9.0.tgz
tar -xzvf rubygems-0.9.0.tgz
cd rubygems-0.9.0
ruby setup.rb
gem install -y railsgem help.One more thing: since we'll be using MySQL as our database backend, we'll need to install the MySQL gem. This will let Ruby scripts--such as our application--access MySQL databases. We can do this easily using this command:
gem install mysqlDeveloping a simple Rails application
Our sample application will track entries in a checkbook, showing how quickly you can create real-world applications in Rails. You can add and delete entries, view descriptions, and even see a running total at the bottom of your application.First, we'll create the skeleton for the application using the Rails command:
rails checkbookappcheckbookapp--under the current directory, then fill it with the essential files needed for a Rails application.Most Rails applications will use a database--so will ours. By default, Rails uses a MySQL backend. Most Rails applications will use three different databases--one for development, one for testing, and one for production. We'll only use one: the development database. By default, it will be called
checkbook_development--the name of our app, an underscore, and then the word development. Rails does not create the MySQL database for us, nor does it create our tables for us, so we'll need to do that next.We need to create the database like this:
mysqladmin create checkbookapp_developmentWe could create the structure using SQL directly, but migrations have a number of advantages. For one, they are database agnostic; they can be used to deploy on any number of database backends. For another, they are versioned--you can incrementally change your database schema and use the "rake migrate" command to update any database to the most recent version. You can even migrate backwards to an older migration.
We create a blank migration as follows:
ruby script/generate migration InitialSchema
class InitialSchema < ActiveRecord::Migration
def self.up
create_table :entries do |t|
t.column :memo, :text
t.column :amount, :decimal, :precision => 9, :scale => 2
t.column :when, :date
end
end
end
def self.down
drop_table :entries
end
For our database, these settings mean that it stores up to $999,999.99. The precision refers to the total number of digits (in decimal), and the scale refers to the number of digits after the decimal point.
Note that Rails automatically adds an additional column for us: id, an artificial primary key that uniquely identifies each row. Although some database developers prefer natural key, this is a Rails convention that helps productivity. If you don't want an artificial primary key, or if your table doesn't require it, you can drop the column afterwards using the drop_column method. (Join tables, for example, wouldn't typically have an id column.)
Now that we've created the migration, we need to activate it. The "rake migrate" command does this for us; the following command will migrate the database for us:
rake migrateOur MySQL database now has a entries table. Now we need a model for this table. The model represents the table in code. In other web frameworks, we'd need to specify the table name, primary key, fields, and field types in the model. Rails, though, can figure out this information from the database itself, although you can override behavior if it doesn't fit your needs. You only need to modify the class if you want to add behavior, such as a relationship to another table or a method that performs custom calculations. We can create a model for our table like this;
ruby script/generate model entryruby script/generate scaffold entryrm public/index.htmlmap.connect '', :controller => "entries"ruby script/serverLet's add one more feature to our application: a sum at the bottom of the listing. We can create this by adding just one line to the "app/views/entries/list.rhtml" file. Add this line right before the tag:
Total: <=@entries.inject(0) { |s,v| s+=v.amount }>Deploying our application on Apache
We just learned how to test a Rails app using WEBrick, but for a production deployment, you need to use a more powerful solution. A very common and powerful combination for production deployment is Red Hat Enterprise Linux, Apache, and Mongrel. This combination is high performance, easy to maintain, and can be scaled easily to more application and database servers when necessary.Typically, Apache will serve static files--HTML, CSS, images, and so forth--and the Rails requests will be sent to Mongrel. Mongrel will typically handle either a whole domain/subdomain or a single directory. In this example, we'll serve only Mongrel requests but you could easily have Apache serve other content side-by-side with the Rails content. In this case, we will use mod_proxy_balancer to automatically distribute requests to our Mongrel processes.
First, let's install Mongrel. We can do so as as follows:
gem install mongrel
gem install mongrel_cluster
The second gem install command installs the "mongrel_cluster" plugin to Mongrel, which lets us use the Mongrel cluster support.
We're going to create a number of Mongrel instances--five, in our case, although you could use more. Since Rails isn't thread-safe, this will maximize performance--each process can execute only one backend call at a time. Mongrel has built-in tools to manage a number of mongrel instances, called a "cluster." We're going to set up a cluster using the following commands:
mongrel_rails cluster::configure -p 6001 -N 5
mongrel_rails cluster::start
mod_proxy_balancer and the other modules we will require--mod_proxy and mod_proxy_http--are installed with Apache 2.x by default. We can load and configure them as follows:
The first three lines load the module we need. TheLoadModule proxy_module modules/mod_proxy.so LoadModule proxy_balancer_module modules/mod_proxy_balancer.so LoadModule proxy_http_module modules/mod_proxy_http.soBalancerMember http://127.0.0.1:6001 BalancerMember http://127.0.0.1:6002 BalancerMember http://127.0.0.1:6003 BalancerMember http://127.0.0.1:6004 BalancerMember http://127.0.0.1:6005 ProxyPass / balancer://checkbookapp/ ProxyPassReverse / balancer://checkbookapp/
The final
If you start Apache, you should be able to browse to http://localhost:80 and view your application. This approach is fast and easy to maintain--and you can easily add additional application servers by adding new entries to the
If things go wrong
If you have problems with your Rails application, there a few steps you'll want to take. First, have you recently upgraded your Rails version? If so, this may have broken your Rails application. You can change the version of Rails your application uses by editing the "config/environment.rb" file and changing the RAILS_GEM_VERSION variable--RubyGems saves your old Gems for that kind of situation.If you haven't changed your version of Rails, there are a number of log files you can check. You can check your Apache error logs in /var/log/httpd, of course, but you also want to check the log directory in your Rails application. It should contain a number of files, as both Mongrel and WEBrick will log there. If you use WEBrick in debug mode--which is the default--then you will also get more debugging information when an error happens, which is helpful. Note that even if you are in production, full debugging information will be outputted to any local machine--so if you access the web application from the same server it's deployed on, you'll get full debugging information.
