Home arrow Ruby-on-Rails arrow Page 4 - Application Deployment
RUBY-ON-RAILS

Application Deployment


Before an application can make it onto the Internet, it needs to go into a production environment and be deployed. This multi-part article series will show you how to do this for the Ruby-on-Rails ecommerce application we've been working on. It is excerpted from chapter 12 of the book Practical Rails Projects, written by Eldon Alameda (Apress; ISBN: 1590597818).

Author Info:
By: Apress Publishing
Rating: 5 stars5 stars5 stars5 stars5 stars / 2
August 05, 2010
TABLE OF CONTENTS:
  1. · Application Deployment
  2. · Connecting to the Production Server: SSH
  3. · Installing the Web Server: LightTPD
  4. · Installing the Application Server: Ruby on Rails and FastCGI

print this article
SEARCH DEVARTICLES

Application Deployment - Installing the Application Server: Ruby on Rails and FastCGI
(Page 4 of 4 )

The application server is where Emporium is running inside one or more Ruby processes that use the FastCGI protocol to communicate with the web server. These processes, also referred to as dispatchers, listen for incoming requests, process the request, and then send the response back to the web server. The processes are then made available for processing the next request.

FastCGI (http://www.fastcgi.com/) is an open extension to CGI. The biggest problem with CGI comes from the fact that each request to the web server starts a new process, and each process requires some startup and cleanup tasks to be performed. As its name implies, FastCGI removes most of the performance and scalability problems associated with CGI by using a pool of long-running processes.

FastCGI also promises security enhancements. Multiple load-balanced FastCGI processes can run on remote machines instead of locally on the web server like CGI. This means that you can run the FastCGI processes and the web server under different users. Then a hacker trying to gain access to your system must hack into both accounts: the one running your web server and the one running the FastCGI processes.

To install the FastCGI library, download the source for the latest stable version fromhttp://www.fastcgi.com/dist/, and then compile it according to the installation instructions found in theINSTALLandREADMEfiles, which are located in the root of the distribution package:

$ tar zxvf fcgi-x.x.x.tar.gz
$ cd fcgi-x.x.x
$ ./configure
$ make
$ sudo make install


Note  FastCGI can also be installed through a binary distribution on most platforms. However, installing from source usually works better.


You also need to install the Ruby-FastCGI library to allow your Ruby on Rails application to communicate with the web server. First, download the latest version of the Ruby-FastCGI library fromhttp://raa.ruby-lang.org/project/fcgi. Then change the current directory to where you downloaded the package and execute the following commands:

$ tar zxvf ruby-fcgi-x.x.x.tar.gz
$ cd ruby-fcgi-x.x.x
$ ruby install.rb config
$ ruby install.rb setup
$ sudo ruby install.rb install

If you are having problems installing the library, check theREADME file. Some systems might require that you specify where the FastCGI headers and library files are located. You can do this by executing theinstallscript with the following parameters:

ruby install.rb config -- --with-fcgi-include=/usr/local/include➥
--with-fcgi-lib=/usr/local/lib


Note  The Ruby-FCGI library can also be installed through the RubyGems packaging system by executingsudo gem install fcgi.


The Ruby-FastCGI library contains two different implementations: one native implementation written in C and one written in pure Ruby. In a production environment, you want to use the native implementation because of the performance benefits it provides. By default, the native implementation will be used, but only if the FastCGI shared library can be found. This shared library is created when you compile and install FastCGI from source. To verify that Ruby-FastCGI uses the native implementation of FastCGI, execute the following commands in the interactive Ruby console,irb:

$ irb
require 'fcgi.so'

=> true

The linerequire 'fcgi.so'should returntrue, as shown here. If it returnsfalse, it means it cannot find thefcgi.solibrary, and so it will run using the pure Ruby implementation.

If you get an error sayingfcgi.socannot be found, you might need to add the path to/usr/local/libto/etc/ld.so.conf and runldconfig.

You can verify that the pure Ruby (slower) version is found by executing the following inirb:

$ irb
> require 'fcgi'

=> true


ALTERNATIVES TO LIGHTTPD, FCGI, AND MYSOL

You have a multitude of options to choose from when planning your producton environment. Most often, the best strategy is to follow Ruby on Rails best practices and to concentrate on keeping the architecture simple.

Running your application on LightTPD is a safe option, as it is used by many existing Ruby on Rails applications,
and can be considered to be fairly simple to install and maintain. But LightTPD is by no means the only option. Apache (httpd.apache.org) might be a better option for some applcations and platforms; for example, Basecamp (www.basecamphq.com) runs on Apache. Other alternatives include any web server that supports FastCGI or that can act as a proxy for Mongrel.

Mongrel (mongrel.rubyforge.org), an alternative to using FastCGI, is a fast HTTP library and server that is slowly becoming the de facto standard for new Rails production deployments. With Mongrel, there’s no need for FastCGI, because Mongrel itself talks HTTP and acts as a web server. This simplifies the deployment and maintenance of applicatons. Note that at the time of writing, the author of Mongrel, Zed Shaw, recommends using Apache, rather than LightTPD, with Mongrel, because of problems with its mod_proxy module. This will probably be fixed when the new mod_proxy_core module is released. See Coda Hale’s blog post (http://blog.codahale.com/2006/06/19/time-for-a-grown-up-server-rails-mongrel-apache-capistrano-and-you/) for a write-up on Mongrel, and how to use it together with Apache and Capistrano.

Ruby on Rails plays well with most of the popular database servers found on the market today, both open source and commercial. If you’re looking for an open source database server similar to MySQL, we recommend
PostgreSQL (www.postgresql.org)


Please check back tomorrow for the continuation of this article.


DISCLAIMER: The content provided in this article is not warranted or guaranteed by Developer Shed, Inc. The content provided is intended for entertainment and/or educational purposes in order to introduce to the reader key ideas, concepts, and/or product reviews. As such it is incumbent upon the reader to employ real-world tactics for security and implementation of best practices. We are not liable for any negative consequences that may result from implementing any information covered in our articles or tutorials. If this is a hardware review, it is not recommended to open and/or modify your hardware.

blog comments powered by Disqus
RUBY-ON-RAILS ARTICLES

- Ruby-on-Rails Faces Second Security Flaw in ...
- Ruby 2.0 Prepped for February 2013 Release
- Why LinkedIn Switched from Ruby on Rails
- Adding Style with Action Pack
- Handling HTML in Templates with Action Pack
- Filters, Controllers and Helpers in Action P...
- Action Pack and Controller Filters
- Action Pack Categories and Events
- Logging Out, Events and Templates with Actio...
- Action Pack Sessions and Architecture
- More on Action Pack Partial Templates
- Action Pack Partial Templates
- Displaying Error Messages with the Action Pa...
- Action Pack Request Parameters
- Creating an Action Pack Registration Form

Watch our Tech Videos 
Dev Articles Forums 
 RSS  Articles
 RSS  Forums
 RSS  All Feeds
Write For Us 
Weekly Newsletter
 
Developer Updates  
Free Website Content 
Contact Us 
Site Map 
Privacy Policy 
Support 

Developer Shed Affiliates

 




© 2003-2018 by Developer Shed. All rights reserved. DS Cluster - Follow our Sitemap
Popular Web Development Topics
All Web Development Tutorials