Rails: Up and Running, 2nd Edition

The Web Server

Now that we’ve got a project, let’s start the web server. If you haven’t already done so, type cd chapter-1 to switch to your project directory. Use the script/server script to start an instance of the Mongrel server configured for development. If you’re running Windows, each time you see a command that’s prefaced with the script directory, preface the call instead with ruby, using forward or backward slashes. If you’re using most other platforms, you can omit the ruby keyword. From here on out, we’ll skip the ruby part of the command. Type script/server now:

$ script/server

=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready.  TERM => stop.  USR2 => restart.  INT => stop (no restart).
** Rails signals registered.  HUP => reload (without restart).  It might not work well.
** Mongrel 1.1.1 available at 0.0.0.0:3000
** Use CTRL-C to stop.

Notice these details:

• The server started on port 3000. You can change the port number and other startup details with command-line options. See the sidebar “Configuring the Server” for more configuration options.

• We started an instance of Mongrel, the default web server. You can configure Rails to start many kinds of web servers.

• Ruby will also let you use a backward slash as a path delimiter on the command line, but on Unix, you must use the forward slash. Some prefer the backslash on Windows because it allows you to use the tab completion feature in the MS-DOS command prompt.

Configuring the Server

If you need to, you can configure the port, the directory for public files, and other server features with command-line options. You can see the options by adding the --help switch. Here are the default options for Rails 2.0:

> script/server --help
=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
Usage: server [options]
    -p, --port=port                  Runs Rails on the specified port.
                                     Default: 3000
    -b, --binding=ip                 Binds Rails to the specified ip.
                                     Default: 0.0.0.0
    -d, --daemon                     Make server run as a Daemon.
    -u, --debugger                   Enable ruby-debugging for the server.
    -e, --environment=name           Specifies the environment to run this server 
                                     under (test/development/production).
                                     Default: development

    -h, --help                       Show this help message.

You won’t need to customize this script directly. The command-line switches should give you everything you need.

Point your browser to http://localhost:3000/. You’ll see the Rails welcome screen pictured in Figure 1-1. Don’t worry about the details of the request yet; for now, know that Rails is running and working correctly.

Figure 1-1. The Rails welcome screen

So far, you’ve already set up the build environment, typed a few words, and verified that the server is running. In the development environment, you’ll normally leave the server up, rebooting only to make major configuration changes for things such as new gems or a changed database configuration.

Choosing a Server

Rails will run on many different web servers. Most of your development will be done using Mongrel, but you’ll probably want to run production code on one of the alternative servers. Let’s look briefly at the available servers.

Apache

Although WEBrick is the most convenient choice, it’s not the most scalable or flexible. The Apache web server is the most widely deployed web server in the world. You can choose from an incredible array of plug-ins to run dozens of programming languages or serve other kinds of dynamic content. Apache scales well, with outstanding caching plug-ins and good support for load balancers (machines that efficiently spread requests across multiple web servers). If you’re looking for a safe solution, look no further than the Apache web server.

nginx

Apache is a good general-purpose web server, but it’s not the most specialized one. nginx has replaced lighttpd in the Rails community as the lightweight web server that’s built for one thing: speed. It serves static content such as HTML web pages and images very quickly, and it supports applications through Mongrel and Mongrel Cluster. nginx does not have nearly as many flexible plug-ins or the marketing clout of the Apache web server, but if you’re looking for a specialized server to serve static content and Rails applications quickly, nginx could be your answer. It’s fairly young, but it has a great reputation for speed among Rails enthusiasts.

Mongrel

Although Apache and lighttpd are very fast and scalable production servers, configuring them to serve your Rails application can sometimes be challenging, and it is never as simple as WEBrick. Mongrel changes all of that. Mongrel combines the advantages of WEBrick (because it’s written in Ruby) and nginx (because it’s written for speed and clusters well). This combination could make Mongrel an excellent choice for development and production. You can quickly cluster Mongrel with MongrelCluster. Be careful, though—Mongrel does not serve static content very quickly. For demanding deployments, you’ll want to combine Mongrel with one of the web servers mentioned above, likely Apache or nginx.

WEBrick

WEBrick, once the default development server for Rails, is written entirely in Ruby. It supports the standards you’ll need—HTTP for communications, HTML for web pages, and ERb for embedding Ruby code into web pages for dynamic content. WEBrick is generally not used anymore, even in pure development mode. Mongrel has taken its place.

Other web servers

Theoretically, any web server that supports CGI can serve a Rails application. Unfortunately, CGI with Rails is dead slow, so it is really not suitable for production. However, if you are running in a specialized environment that has its own web server, you can probably get it to serve your Rails application using the FastCGI or SCGI interfaces. Do a web search first, because it’s very likely that someone else has already done it and posted instructions. For example, if you must deploy your Rails application on Microsoft’s IIS, you will find that many developers have done this already. You’ll probably see other web servers rapidly move to support Rails. You can also find plenty of information on lighttpd with FastCGI. Deploying Rails applications is far beyond the scope of this book.

Now that your server is up, it’s time to write some code. We’ll focus on simple controllers and views in the rest of this chapter.