WWW.LINUXJOURNAL.COM / FEBRUARY 2014 / 67
apt-get, the required packages to compile the Ruby distribution. In this article, I use the stable official Ruby distribution called MRI, Matz Ruby Interpreter (derived from the name of Ruby’s creator, Yukihiro Matsumoto).
Now, you’ll likely need to add to your future Rubies some basic libraries typically needed by some complex gems or software. Setting up such libraries immediately will guarantee that the Ruby software will never complain that the system libraries are old or incompatible, generating annoying errors.
Previously, you would have installed these extra packages via the rvm pkg install <pkg> command, but now RVM deprecates this. Instead, simply enable autolibs to delegate to RVM the responsibility to build coherent and not-buggy distributions:
$ sudo rvm autolibs enable
You finally are ready to provide your environment a full Ruby distribution.
For example, let’s install the latest stable version of the official MRI interpreter, the 2.0.0 version:
$ sudo rvm install 2.0.0
If everything goes well, the
distribution is available for root and
the system users. If not, it’s commonly a $PATH problem, so adjust it in
the /etc/profile.d, and also to avoid deployment pitfalls, verify that the
'%-?(/-% VARIABLE IS EXPORTED TO the correct gem path. In practice, if something is not working properly, set the following variables like this:
if [ -d "/usr/local/rvm/bin" ] ; then
PATH="/usr/local/rvm/gems/ruby-2.0.0-p353@global/bin:
´/usr/local/rvm/bin:$PATH"
GEM_HOME="/usr/local/rvm/gems/ruby-2.0.0-p353@global"
fi
You can list the available Ruby versions with this command:
$ rvm list known
On a system running multiple Rubies, users and system processes may load other environment versions with a command like this:
$ rvm use jruby-1.7.1
And set the default system distribution in this way:
$ rvm --default use 2.0
The Web Server
Ruby on Rails, like Sinatra and many other popular Ruby frameworks
or Domain Specific Languages, is based on an interface named Rack. Rack provides the minimal abstraction possible between Web servers supporting Ruby and Ruby frameworks. Rack is responsible for invoking the main instance of your application as specified in the startup file, config.ru.
So, a Web server hosting Ruby Web applications will have to understand how Rack talks. With a stable and clean Ruby environment, you’re ready to build your Web server that is
capable of speaking Rack.
With Ruby, you can choose between many Web servers. You may have heard of Mongrel, Unicorn, Thin, Reel or Goliath.
For typical Rails deployments, Passenger is one of the most
popular choices. It integrates well with Apache and Nginx, so in this EXAMPLE LETS SET UP AN !PACHE Passenger configuration.
Passenger Installation
Passenger, developed by Phusion, also formerly known as mod_rails or mod_rack, is a module that allows you to publish Ruby applications in the popular Web server containers Apache or Nginx. Passenger is available as a “community” free edition and as an enterprise release,
which includes commercial support and advanced features.
If you chose to install Ruby through packages, Passenger is conveniently AVAILABLE THROUGH 20- OR $%"
repositories, and yum or apt-get will install all the required software.
On an RVM-customized system, to install the free version of Passenger, you need to add the gem through Ruby gems:
$ sudo gem install passenger
Now you can install the server
module (the latest version at the time OF THIS WRITING IS BY EXECUTING a script provided by the gem:
# passenger-install-apache2-module
Let’s select Ruby only, and let’s skip Python, Node.js and Meteor support. If your system misses software requirements, the script will give you a tip to the exact
command line for yum or apt-get to meet those dependencies.
After some compile time, you will be introduced to Passenger configuration with useful and self-explanatory output. Specifically, copy to the directives that load Passenger into Apache in your main Apache configuration file (apache2.conf
WWW.LINUXJOURNAL.COM / FEBRUARY 2014 / 69
or httpd.conf):
LoadModule passenger_module
/usr/local/rvm/gems/ruby-2.0.0-p353/gems/passenger-4.0.33/
´buildout/apache2/mod_passenger.so
PassengerRoot /usr/local/rvm/gems/ruby-2.0.0-p353/gems/
´passenger-4.0.33
PassengerDefaultRuby /usr/local/rvm/wrappers/ruby-2.0.0-p353/ruby
Finally, restart Apache. Et voilà, now you can host Ruby Web applications.
Virtual Hosts
If your goal is to host one or more Ruby applications on the same server, you should activate each instance as a virtual host. The most significant directive with Ruby hosting is the DocumentRoot. It’s mandatory that it points to the public/ directory in the application’s root project directory.
The public/ directory is the default public path of a Rails application.
So let’s say you have a Kolobok application made in Rails, and you have to deploy it to the DNS zone kolobok.example.com on the kolobok.example.com server. Here is an example VirtualHost:
<VirtualHost *:80>
ServerName kolobok.example.com DocumentRoot /srv/www/kolobok/public <Directory /srv/www/kolobok/public>
# This relaxes Apache security settings.
AllowOverride all
# MultiViews must be turned off.
Options -MultiViews </Directory>
</VirtualHost>
Now, if you have put your
application in /srv/www/kolobok, and it’s well configured (configured and binded to the database and so on), enable the virtual host, reload Apache, and your application is published.
Automating Software Deployments Ages ago, it was common to deploy Web applications by doing a bulk copy of files via FTP, from the developer’s desktop to the server hosting
space, or by downloading through Subversion or Git. Although this approach still works for simpler PHP applications, it won’t fit more complex projects made using more complex frameworks, such as Rails.