Ruby on Rails on Windows in production

Windows environment has been traditionally treated as no-way for Ruby developers, especially when it comes to production. In the following article I will show how easy and efficient it could be setting up your Ruby environment in Windows for both development and production purposes using Helicon Zoo. And performance tests at the end of the article will show whether Windows system can be treated seriously as a production environment.

This article covers following topics:

• Installing development environment.
• Writing a simple application.
• Preparing your application for deployment.
• Deploying the application to the production server.
• Compare performance with Windows Server 2008 with IIS 7.5 and Ubuntu Linux with Apache and Nginx.

Setting-up development environment

Before we can publish our application to the world, at least we need to test if it works in our environment. And here how you can set up working Ruby environment that will use IIS as a web server. Windows XP, Vista, Windows 7, Windows 2003, Windows 2008 (R2) and Windows 2012 are supported.

First please download and install Microsoft Web Platform Installer ( WebPI ), run it and click Options. Add the link to Helicon Zoo Feed http://www.helicontech.com/zoo/feed.xml into the «Custom feeds» field.

Please note web server choice – IIS Express or IIS. The main difference is that IIS Express runs as interactive user application which usually means Administrative permissions if you are logged in as Administrator. This simplify development process and decrease number of possible issues you may encounter with insufficient NTFS permissions to run application. With IIS web applications are executed as a restricted user and may require additional permissions tuning, but you will get environment that is more close to those which will be used to run application in production. In this article we will be using IIS Express with WebMatrix as a development environment and IIS for production.

After adding custom feed new Zoo tab will appear with Applications, Templates, Packages, Modules and Engines sections in it.

• Applications –  are some ready to use web applications that are included into Helicon Zoo feed, that come with all required dependencies and can be installed on a clean system in a few clicks. You can use this section if you simply need to install one of these applications on your server.
• Templates section contain empty projects for each web application technology that is currently supported by Helicon Zoo. You use these templates as a starting point to develop application of particular technology or to host existing application. For example in this article we are going to use Ruby project template.
• Packages include complete Hosting Packages for each web application technology that is supported by Zoo. You install one or more hosting package from this section to enable hosting of the whole technology class on the server. Each package contains all dependencies that may be needed. For example Ruby Hosting Package contain Ruby 1.8, Ruby 1.9, Ruby 2.0, Dev Kit, Helicon Zoo Module and some other modules that may be needed and have to be installed globally. We will be installing Ruby Hosting Package in a production environment later.
• Modules contains some useful applications and modules that are usually installed on server globally, like Helicon Ape, MongoDB, PostgreSQL, RabbitMQ, etc. Some of these modules are not intended to be installed separately from Hosting Packages.
• Engines section contains engines itself, like Ruby, Python, Perl. Please note that installing these engines will not enable them in IIS environment. You should not install these engines manually, please use corresponding Hosting Package or Template instead.

Creating simple Ruby application

The good thing about Helicon Zoo is that creating new application and installing application environment is done in one step because application will check and install all needed dependencies automatically. Please go to Zoo –> Templates, choose Ruby project and install it.

Depending on the server chosen (IIS or IIS Express) and your system configuration many components may be downloaded and installed first time. Hopefully everything goes right and all sites with required components will be online, so your environment should be configured soon.

Warning: If you have already manually configured Ruby environment, please use packages that come with Helicon Zoo through the feed and Web Platform Installer instead. The Helicon Zoo packages has nothing magical inside, we simply install Windows Ruby Installer and DevKit packages from official web site in default locations (like C:\Ruby19, C:\Ruby18, C:\Ruby20) which is important since these locations are hardcoded in some other components, set correct NTFS permissions for IIS_IUSRS group, etc. And even though it is possible in theory to use your custom Ruby installation with Helicon Zoo, our experience shows that it will most likely bring numerous issues. Helicon Zoo requires default Ruby configuration and needs no globally installed gems – this is the idea of isolation. If you configure your Ruby instance manually we may be unable to provide support for it.

If you have chosen IIS Express as a web server, after installation is finished the WebMatrix will be launched automatically and you should see project’s index page with further instructions. With IIS installations additional step is required where you choose port and host name bindings, a folder on disk where to put web site, etc. IIS Express web sites are created in \Documents\My Web Sites\.

This Welcome page is displayed when no Ruby application is present in the folder using URL Rewriting Module, therefore Microsoft URL Rewriting Module is a dependency for Ruby project template, otherwise you may see the error. When application with a config.ru file appears in the folder this page will be substituted by a real index page.

The initial project’s content is very simple:

An empty console folder that is simple placeholder if you wish to configure authentication for web console access later. Public folder that is used to store static files (including welcome page), deploy_sample.rb file that we will talk on later and web.config file that is essential to configure Zoo application in this folder. If you have some existing Ruby Rack application you can simply copy it’s files into the root folder keeping existing files intact and it should start working with very little or no modifications at all.

The instruction on Welcome page asks us to click on a link and start Web console, but we will learn one more tool before – Helicon Zoo Manager. Go to Start menu, Helicon –> Zoo –> Helicon Zoo Manager (either for IIS or IIS Express depending on the server type you are using). This manager lists all your current web sites and here you can modify configuration of Helicon Zoo Module, enable or disable engines, set environment variables, start Web Console or IDE, etc. By default Helicon Zoo will run Ruby application using Ruby 1.9 Rack and you can change this using Helicon Zoo Manager. After launching the manager select the web site you are currently working with in the left tree. The only application named ruby.project will be pre-selected, so let’s click on Edit button and change RACK_ENV environment variable from production to development. Press Apply on the properties window and Apply on the main window to save settings into web.config. Production mode ensures faster operation, but with development mode we don’t need to restart IIS Express application every time we modify some files in the application and additionally we get more verbose error messages. With some hosting services you can have two different web.config files for production and development environment which is convenient.

Then click Start web console button to launch console for this application.

You may ask why using this web console if I can just run cmd.exe or any other IDE to run commands? The answer is because Helicon Zoo web console is designed to run commands in the isolated environment of your application, so all these commands are applied to the application you are working with, using local folders and environment variables and executed by the same interpreter and same IIS Application pool user that runs the application itself. This is needed to keep applications portable because all modules and components are installed into the application folder and execution environment is easily replicable with Helicon Zoo Hosting Packages installations on other machines. On the other hand if you launch Windows console from start menu you may actually have number of environments and interpreters installed on your machine, like several different versions of Ruby and Python. With Windows console when you run a command you can’t tell for sure what exact version of interpreter you are calling, where it is located, where will it store it’s settings, etc. IDEs and commands to install modules will usually install them globally into the system, so your application will lose portability. There could be conflicts between different versions of engines or modules installed in the system when you run global command line interface. This is why it is always recommended to install web application engines like Ruby or Python distributions using Helicon Zoo repository, for example by installing Hosting Packages, instead of installing engines manually. And use of Helicon Zoo web console or launching IDE from Helicon Zoo Manager may also be essential if you want to avoid version conflicts and retain application portability.

This console runs by Zoo Module as HTTP application in your browser. Anonymous remote requests to console is prohibited by Zoo engine for security reasons. So if you wish to access console on a remote server you will have to enable one of the authentication methods for the console folder (or whatever location you have configured as a console). Or you can use IIS Manager to connect to remote server and start console from Helicon Zoo IIS Manager snap-in. The Helicon Zoo Manager installs snap-in for Internet Information Services Manager, which you can use even in remote mode, when IIS Manager is connected to a remote server.

The one-time hash code will be used to authenticate console session and will be invalidated when you close the console window. The ability to start web console can be enabled or disabled globally and for individual applications which is useful for hosters. Please read more about web console here.

So start web console and type:

gem install rails

And go get some coffee, because this command takes really, really long and works mostly silently. Please be patient and don’t try to restart the console, honestly, it is working. For me sometimes it takes about 20 minutes of ‘installing Rails’, which I guess, depends on internet speed, system configuration, etc. If you close console window it will kill the console process on the remote server within 10 minutes and all spawned processes as well. Same if you click on Cancel button in the bottom right corner – this will kill console and all child processes on remote (or local) machine immediately and restart the console. This button is useful if something went really wrong, like a command hang. After command is finished you should see normal output of ‘gem install’ command.

Notice short path in console – these are needed because many Ruby scripts don’t work well with long path. And forget about umlauts and other national characters in file names. If you need them in links, you can add them later using URL mappings. The ‘gem install’ command can not only download and install gems, but thanks to DevKit can also compile native C-gems right on your system.

Let’s look into our project file structure now. You may need to hit F5 on the root node in WebMatrix to refresh it.

Notice new GEM_HOME folder – this is where all gems have been installed. When the application is executed Helicon Zoo will use gems from this folder. The sad thing here is that you will have to repeat ‘gem install’ operation for each application you are working on. Though you can still have global gems it is not recommended. But the good thing is that you may have different versions of gems for each application. You may have different versions of Rails, Sinatra or anything else for every application with no conflicts. You can update Rails for one application and still have your legacy code running on older versions in other sites. Isolation – is the key feature of Zoo.

So rails and other dependent gems are installed, but this is not a Rails application yet. Let’s create one by running the following command:

rails new .

Now if we look at web site content we’ll see new folders and files – new Rails application is finally created.

Refresh the application page in the browser and you should see Ruby on Rails welcome page now (may require IIS Express application restart sometimes):

Integrated Development Environment

Another useful feature of Helicon Zoo Manager is the ability to start IDE for the application environment. This is not just a shortcut to your favorite IDE. Before launching IDE Zoo Manager will configure environment according to the environment variables of the selected application. Most current IDEs can read these environment variables to configure locations correctly. Locations like gem installation folders, working directories, Path variable with correct locations of Ruby interpreter of required version, etc. Open Helicon Zoo Manager and click on Start IDE. When you do this first time for the application a small Select IDE dialog will appear. By default it opens Windows Command Line (cmd.exe) and this is a convenient replacement for the Web Console if you develop application locally. This command line interface will be launched with all path configured for your application, therefore ‘gem install’ command will install gems into the application folder same as with web console. The difference with web console is this cmd.exe is executed as interactively logged on user, while web console is executed as IIS application pool user, which may differ in permissions significantly. So for development purposes and on local machine using Start IDE command is even more convenient than web console.

But instead of using ascetic command line you can configure your favorite IDE to start with this command. Environment variables will be configured before launching application and IDE will know correct locations of files, like GEM_HOME, location of Ruby interpreter, etc. For example to start Aptana with the project’s folder already open you can use following command:

AptanaStudio3.exe "%APPL_PHYSICAL_PATH%

If you prefer IDE with debugger and refactoring tools, we recommend one of the following options:

• Aptana (free, http://aptana.org)
• NetBeans (free, http://netbeans.org)
• RubyMine (commercial, http://www.jetbrains.com/ruby/)

Each of these offers a bunch of development and testing tools for Ruby apps and supports version control.

For those who will make do with simpler solutions there are:

• KomodoEdit (free, http://www.activestate.com/komodo-edit)
• Redcar (free, http://redcareditor.com/)
• SciTE (free, http://www.scintilla.org/SciTE.html)
• E TextEditor (commercial, http://e-texteditor.com/)

For our app we used Aptana:

MVC

Ruby on Rails is based on the MVC architecture (model, view, controller). This approach has several advantages:

• Isolation of business logic from interface;
• Less code repetition (DRY principle — don’t repeat yourself);
• Relatively simple development hanks to strict code distribution based on purpose (e.g. the code for HTML form output is not mixed with the code for DB processing).

Model defines the database structure in terms of object-oriented programming. In Rails model is an ordinary class inheriting all necessary functions from ActiveRecord::Base class. Instance (object) of this class defines one line from the corresponding database. Thus, models conceal the peculiarities of interaction with particular DBMS from developer.

View is the interface shown to users. On this stage developer creates templates which are transformed into HTML, CSS orJavaScript code.

Controller connects model with view. It’s usually controller that contains the main logic. Essentially, controllers are Ruby classes. Each public method of controller is called action. If you have controller named “Home” and it contains the method named “index”, then running /home/index in browser will evoke “index” action.

When a request comes to the application, the routing mechanism (in config/routes.rb file) decides which controller cares about that type of requests. Aside from the URL a set of other conditions may be taken into consideration, e.g. you can assign different controllers for different browsers, for mobile clients etc.

So, having chosen the controller, it defines what action will process the request. At this point one can also apply numerous conditions. The action itself performs some calculations and DB-related operations. When the action is finished the view comes on the scene. The data from DB or some result are transmitted to the templates. Then the HTML page is generated from the templates (there are templates from CSS and JavaScript as well) and the response page in sent to the user.

Writing the application

The classic example of Rails app is the simplest blog. We won’t ignore this tradition. So, let’s create controller “Home” with action “index” – this is going to be the blog main page. This is done with the following command:

rails g controller home index

If we now request /home/index, we’ll get the page from the template created for “index” action.

Afterwards, we’ll create a simple Post model which will define each blog entry in the DB. In Ruby code the model is a class and it is represented in DB as a table. Thus, the object of Post class is a line in the corresponding table in database.

To create model you can simply run “rails g model Post…” but let’s make use of a very handy tool – scaffolding. The “rails g scaffold” command creates not only the model class itself and tests for it, but also actions drafts and views templates for adding, editing and removing model objects. If we execute this

rails g scaffold Post name:string title:string content:text

we’ll get “Post”model in app\models\post.rb, “Posts” controller in app\controllers\posts_controller.rb with actions index, show, new, edit, update, create and destroy, plus a DB migration scenario in db\migrate. The command will also have created the headers for tests and HTML templates. Notice that we haven’t yet written a single line of code!

Now we are going to install the database. In this example we use SQLite which is default for Rails. However Rails can work with many other DBMS hiding details of their cooperation from the user. Please call the following command to install SQLite:

gem install sqlite3

Next, we’ll run the command to create the database (if it’s not yet created) and the table “posts” with the fields “name”, “title” and“context”:

rake db:migrate

The command for database migration is applied for creating and editing database structure in accordance with our object model. It should be executed every time you make changes to the application model. All the magic of matching the DB structure with our model is done automatically and all the data stored in the database are retained.

Actions of “Post” controller are accessible at /posts/ address.

If you press “New post”, you’ll see the form:

After filling all fields we get to the new post page:

Note that there was still no code written. Now let’s do some editing. For instance, we may need to make post name and post title obligatory fields so that corresponding cells in the DB are always non-empty. Luckily, Rails provides very simple validation mechanism. We should just fix the model file, which is app\models\post.rb as follows:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }
end

In there we specify that “name”and“title” fields are obligatory and “title” should contain not less than 5 characters. No need to apply migration after this change as validators are not directly related to database; the check is performed on the level of Ruby code.

If you now leave the “name” field empty, you’ll get an error:

Let’s make it a little more complicated and add the comments feature. We’ll create a “Comment” model with the following command:

rails g model Comment commenter:string body:text post:references

Pay attention to “post:references” parameter. It connects «comments» table with “posts” table.

Now refresh the database:

rake db:migrate

next, we’ll set up the relation “has many” for Post model:

class Post < ActiveRecord::Base
      validates :name,  :presence => true
      validates :title, :presence => true,
                :length => { :minimum => 5 }

      has_many :comments, :dependent => :destroy
end

The code is intuitively clear. Each Post object may have a number of comments. “:dependent => :destroy” tells that when post is deleted all comments are deleted as well. As we didn’t use scaffolding this time to create a model for comments, we now need to generate corresponding controller:

rails g controller Comments

In config\routes.rb file replace “resources :posts” with:

resources :posts do
   resources :comments
end

In this way we specify how the “comments” controller will be available. In our case it’s put into “posts”, so the links will look like http://localhost:41639/posts/1/comments/3

Then we need to refresh the template app\views\posts\show.html.erb so that it will become possible to add comments. After:

<p>
  <b>Content:</b>
  <%= @post.content %>
</p>

add the following code:

<h2>Comments</h2>
<% @post.comments.each do |comment| %>
  <p>
    <b>Commenter:</b>
    <%= comment.commenter %>
  </p>
  <p>
    <b>Comment:</b>
    <%= comment.body %>
  </p>
  <p>
    <%= link_to 'Destroy Comment', [comment.post, comment],
                :confirm => 'Are you sure?',
                :method => :delete %>
  </p>

<% end %>

<h2>Add a comment:</h2>
<%= form_for([@post, @post.comments.build]) do |f| %>
  <div class="field">
    <%= f.label :commenter %><br />
    <%= f.text_field :commenter %>
  </div>
  <div class="field">
    <%= f.label :body %><br />
    <%= f.text_area :body %>
  </div>
  <div class="actions">
    <%= f.submit %>
  </div>
<% end %>

Finally, we’ll define the logic of controller operation in app\controllers\comments_controller.rb

class CommentsController < ApplicationController
  def create
    @post = Post.find(params[:post_id])
    @comment = @post.comments.create(params[:comment])
    redirect_to post_path(@post)
  end

  def destroy
    @post = Post.find(params[:post_id])
    @comment = @post.comments.find(params[:id])
    @comment.destroy
    redirect_to post_path(@post)
  end
end

And everything is ready for adding comments to the post:

The basic functionality is implemented. As the last step we’ll protect some of the actions, so that unwanted people don’t have access to them. The more comprehensive way is to use registration, sessions, cookies etc., but to stay simple we’ll take Basic authentication, the more so because in Rails we need only one line to enable it. Put the following in posts_controller.rb:

 http_basic_authenticate_with :name => "admin", :password => "123",
                              :except => [:index, :show]

We have hard coded the login and password. “:except”parameter excludes “:index” and “:show” actions as they don’t need authentication.

Deploying on production server or hosting

So, we’ve created the application and now, logically, want to publish it to the Internet. For that purpose we’ll set up Windows server to work with Ruby in production. We’ll have to repeat several steps from the beginning of the article which were used to install development environment, but this time we’ll configure production IIS server. If you are considering to organize Ruby hosting on Windows servers you will need to complete exactly the same steps as following:

1. Install Microsoft Web Platform Installer.
2. Add Helicon Zoo feed. Naturally this time you choose IIS as a target server instead of IIS Express in WebPI options.

Now install Ruby Hosting Package from Zoo –> Packages.

 

This will install Ruby 1.8, Ruby 1.9, Ruby 2.0 and Development Kit packages from RubyInstaller normally into C:\Ruby18; C:\Ruby19 and C:\Ruby20 folders respectively and set correct NTFS permissions for these folders for default IIS installations. You can update these installation packages manually then, leaving installation folders as they are, because these folders are hardcoded in some WebPI components. But remember – installation packages form Zoo repository has been tested with Zoo while you are upgrading on your own risk. You may consider that installing all three packages of Ruby is waste of resources when you need only one, but they are small and installation completes fast so it doesn’t worth worrying. Plus with Zoo system these packages will not conflict. Ruby Hosting Package may also install IIS and other required Windows components if they are not already installed in the system. Eventually it will install Helicon Zoo Module which is required to host these applications with IIS.

After these steps are completed the server is ready to host our application. For the moment the following server platforms are supported: Windows Server 2008 and 2008 R2 and Windows 2012, all 32-and 64-bit versions when applicable. The reason why older versions are unavailable is because Helicon Zoo Module uses native IIS 7 API, therefore everything prior IIS version 7 is unsupported and all newer versions of IIS should be fine.

So, at first, we create an empty web-site via IIS manager or your hosting panel. Then simply upload entire web site folder with your application to the server via FTP or Web Deploy or any other way. I would recommend to configure Web Deploy on the production server. This tool makes deployment of applications from WebMatrix or Visual Studio really easy, plus all application folders and files will be given proper permissions automatically, as they’ve been set by Helicon’s Ruby project template. Generally you may need to enable write permissions for entire web site folder for the user running application because Ruby application will want to write things sometimes. You can also use Git or any other version control system and deployment system, but that falls beyond the scope of this article, same as write permissions fine tuning.

Then, in general, you just navigate to the web site and it opens. The application will be executed on Windows Server under IIS with the help of Helicon Zoo Module. This module was initially designed as a hosting solution, so all applications are isolated and do not interfere. The module with its default options works in fully automatic mode, creating one worker process per application by default, when the load is low and increasing the number of workers up to the number of CPU cores of the server providing maximal performance under heavy loads. These settings can be changed on per-engine level using Helicon Zoo Manager.

Helicon Zoo implements the concept of engines and applications. The engines define how to run an application, which interpreter to use, which protocol and port, what maximum number of workers are allowed and other global settings which are defined in applicationHost.config, so if the user has no write permissions to applicationHost.config then he can’t change engine settings. Then, Helicon Zoo application ‘uses’ the engine by referencing it from web.config file from inside web site folder. Each engine may have list of parameters – Environment Variables, which users can set. This concept allows for separation of hosting administrator duties from the clients’ burden (and client from client as well). You can learn more about Helicon Zoo Module configuration here.

Sometimes, when your application is not just an empty database-less blog as in our example, simply copying files to the production environment is not enough. For example, your application may use external database server and you may need to execute database migration tasks in production environment before the new code could be executed. For this purpose Helicon Zoo offers very convenient tool called deploy scripts. Please notice DEPLOY_FILE=”deploy.rb” environment variable in the Helicon Ruby project template. This means every time when Helicon Zoo engine finds deploy.rb file in the root of the web site it will do the following:

• All currently running Ruby processes will be shut down using soft-shutdown sequence.
• All running requests and transactions will be allowed to run till they are finished, unless soft-shutdown timeout is exceeded.
• All newly coming HTTP requests to the application will receive 503 Application Maintenance status.
• These new requests will see the “Application deployment in progress” page.
• When no running workers left, the deploy.rb file will be executed in a separate process using same interpreter (i.e. Ruby) and same user as declared in web site’s configuration.
• After deploy script execution is finished with no errors all users currently seeing “Application maintenance” message will be redirected to the pages they where originally requested.
• The deploy.rb file is renamed to deploy_done.rb.
• New worker processes will be started and application execution continues.

Here is how Application deployment in progress message looks by default:

In Ruby project template there is a file named deploy_sample.rb. This file contains common deployment instructions for database migrations, etc. So to initiate deployment process you will only need to rename that file from deploy_sample.rb into deploy_rb and push it to server. You may want to make it your last change to the project when you upload changes so to make sure all other scripts and files has been updated before deployment process initiates. If the RACK_ENV environment variable is set to production, Ruby will not load updated code files unless restarted, so initiating deployment process will do all things synchronously – migrate database and then load new code into engines. This is so-called “cold application maintenance” which is needed because if other user requests (with either new or old code) will be running while database migrations and other deployment tasks are executed the data could be corrupted or user could get unpredicted responses. Helicon Zoo minimizes application downtime to even seconds and automates whole deployment process so it becomes easy to deploy large applications across array of servers.

Please read more about deployment scripts in Helicon Zoo documentation.

Performance tests

Machine used as a server contained Core 2 Quad 2.4 Ghz, 8 Gb RAM, 1Gb LAN. For load generation we took more powerful PC and Apache Benchmark tool with a command “ab.exe -n 100000 -c 100 –k”. For Apache and Nginx servers we used Ubuntu 11.04 Server x64. IIS 7 tests were run on Windows Server 2008 R2. No virtual machined where used – bare hardware.

We’ve conducted three test scenarios:

1. Rails had to output the current time in high resolution. The time was chosen to ensure the response doesn’t come from cache;
2. Rails read from MySQL database and;
3. Rails performed writing into MySQL  database.

We performed tests with Ruby 1.9.3, Rails 3.1.1 and MySQL 5.1.54. in case of HTTP transport, Thin acted as a backend HTTP service. Neither Unicorn nor Passenger work for Windows. So, there were three configurations for testing: Windows + IIS 7.5 + Helicon Zoo + Thin, Ubuntu + Apache + Passanger, Ubuntu + Nginx + Thin.

Below are tests results (in requests per second):

  

Here are more detailed ab graphs for the first test (time output):

Resume

Ruby on Rails proved itself a perfect framework for quick and easy web development. Of course, Ruby is not the one and only. In the next articles we’ll shed some light on Goliath and Sinatra.

We would also like to underline that Windows is a mighty platform for both development with Ruby and running Ruby-apps in production. And if earlier the difference in Ruby performance on Linux and Windows was dramatic, now the performance, as well as convenience of Ruby on Rails for Windows has significantly improved to a degree that performance is no more a key criteria for choosing the platform.