Run Ruby on Rails on Microsoft Windows Azure

Run a Ruby on Rails open source application within Windows Azure worker roles

Zoiner Tejada

August 25, 2011

9 Min Read
ITPro Today logo

Recently, I had a client who was interested in usingWindows Azure. However, for reasons that were related to the client's ISP, he had to run Ruby applications. To run Ruby on Rails on Azure, our approach was to take the Ruby binaries, include them with the client's web role, and start them from the command line within the role's RoleEntryPoint code to run the Ruby on Rails logic. To fully describe our approach in this article, I will use the default WEBrick server to host the Ruby on Rails application, and I'll also use the RubyInstaller for Windows 1.8.7 distribution.

Set Up Ruby on Rails


Several Ruby distributions are available. I recommend trying IronRuby first. Although IronRuby has some serious limitations, including some that can prevent you from installing and using certain gems (ruby code packages)—such as Mechanize and Nokogiri, it is worth trying because of its ability to directly use .NET assemblies within Ruby and because its integration with Visual Studio feels familiar. In this article, I will use IronRuby to help with the project setup and management, but I will use Ruby to run the Ruby code. Because you may want to use either IronRuby or the standard Ruby distribution, I include the syntax for both distributions wherever possible. Let's begin by choosing and installing a distribution.

IronRuby 1.1 installation. For the best experience in Visual Studio 2010, you should use IronRuby 1.1. Even though this is an alpha release, I believe it is the easiest implementation for a Visual Studio developer to start using. IronRuby 1.1 installs various project and item templates—shown in Figure 1, an interactive mode for running your Ruby programs, a debugger, and syntax highlighting. We'll use IronRuby for the development experience, and we'll use another Ruby distribution at runtime. Both run happily side by side.


Figure 1: Visual Studio templates included with IronRuby 1.1



Download IronRuby 1.1. The installation is straightforward, and IronRuby binaries will be added to your PATH environment variable, so that any new command prompts that you open can execute IronRuby programs. After the installation is finished, IronRuby tools are fully integrated with Visual Studio.

RubyInstaller 1.8.7 installation. Download the RubyInstaller distribution, then install it. This installation is also straightforward.

Ruby on Rails 2.3.4 setup. If you decide to use Ruby on Rails, automatically download and install it by using the standard Ruby package manager (known as RubyGems). Typically, you will install the ActiveSupport gem and the related Rails gem. The commands vary slightly, depending on your choice of Ruby distribution. For IronRuby, use the two commands that are shown in Figure 2. For a standard Ruby distribution, use the commands that are in shown in Figure 3.

Figure 2: IronRuby commands to install Ruby on Rails

Install ActiveSupport:

igem install activesupport --version="2.3.8"


Install Rails:

igem install rails --version="2.3.4"


Figure 3: Ruby commands to install Ruby on Rails


Install ActiveSupport Gem:

gem install activesupport --version="2.3.8"


Install Rails Gem:

gem install rails --version="2.3.4"




Set Up a Visual Studio Cloud Project


For our project, we'll create an empty Windows Azure project and configure it to include your Ruby on Rails application. Specifically, it will include a simple Ruby on Rails application that uses scaffolding. Add a worker role to the empty Cloud Project. Note that you could add a web role instead, but our project doesn't use Microsoft IIS for hosting Ruby on Rails.

Create and run a sample Ruby on Rails project. At a command prompt, move to your worker role's project directory, then run the following command:

rails myapp

In this command, myapp is the name of a Ruby on Rails project that has scaffolding. The command creates a Ruby on Rails project that is named myapp in the project directory.

Next, test this new project. At a command prompt, navigate to the myapp folder and run one of the following commands, as appropriate for the program that you are using.

For IronRuby:

ir script/server

For Ruby:

ruby script/server

When you run this command, the console displays a startup sequence that resembles the one in Figure 4.

Figure 4: Output when starting a WEBrick-hosted instance of Ruby on Rails


C:WindowsAzureProjectRailsWorkerRolemyapp>ruby script/server
=> Booting WEBrick
=> Rails 2.3.4 application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
[2011-05-23 06:49:15] INFO  WEBrick 1.3.1
[2011-05-23 06:49:15] INFO  ruby 1.8.7 (2011-02-18) [i386-mingw32]
[2011-05-23 06:49:15] INFO  WEBrick::HTTPServer#start: pid=5248 port=3000


Make a note of the port (which WEBrick chose by default) and the process identifier (PID). We'll use these two values to host and manage WEBrick within your Azure worker role. Next, open the port in your browser (in this case, http://localhost:3000). When you do this, the output resembles the contents of Figure 5.


Figure 5: Default content for a Ruby on Rails application



Include the Ruby on Rails application in the role. With the exposure of this port in mind, you might be tempted to open Visual Studio, right-click the new worker role, add a new existing folder, and select your Ruby on Rails application. Do not do this! If you do, a huge number of entries will be added to the project file. Also, you will not be able to easily swap out the folder contents, which is often necessary during Ruby on Rails development. Instead, unload the Worker Role project, right-click the unloaded project in Solution Explore, and click Edit MyProj.csproj. Next, directly within the Project element, add an entry that is similar to the one shown in Figure 6.

Figure 6: Project file contents including a Ruby on Rails application


 
   
      PreserveNewest
   
 


Then, save and reload your project. After you do this, the Ruby on Rails application files are copied over to your output directory whenever you build, but you do not have to manually add new files to (or remove deleted files from) the Visual Studio project. Instead, you will have to make these changes in the file system.
 
At this point, even if you've set up your development environment to build and run Ruby, you need to consider how Azure roles will install the Ruby binaries when the role starts. You must also consider where your Ruby programs will reside. Your options include the following:

  • Use a start-up task that installs a Ruby deployment, then installs any required gems, such as rails.

  • Use a deployment package that includes Ruby and any required gems.

  • Use a hybrid of the first two options, one that includes a startup task that accesses your standard deployment from a cloud drive.

For our purposes, we can use the same approach that we used to include the Ruby on Rails application. Copy the Ruby folder from the C:Ruby187 folder (or wherever your distribution installed it) into the Worker Role project folder in a folder that is named, for example, Ruby. Add an ItemGroup element for the folder and its contents in the project file so that it resembles the one in Figure 7.

Figure 7: Project file contents including Ruby runtime files


 
   
      PreserveNewest
   
   
      PreserveNewest
   
 


To speed up your builds, I recommend that you delete all the documents in your gems1.8 folder. The only subfolders n the Ruby folder that you really need are the bin folder (which contains Ruby.exe) and the lib folder (which contains gems). I also recommend that you keep the file path of your solution files short. Build failures can occur if this file path is too long. If you experience build failures, consider moving your solution files to the root of a drive.




Create RoleEntryPoint Code and Configure Endpoints

When you host Ruby on Rails within a worker role, you are starting a Ruby process. In the Run method of the RoleEntryPoint, you build a loop where you are checking that the process is still running (and restarting the process if it is not). Beyond that, you want to externalize the port that the WEBrick host listens on, externalize the relative path of your Ruby runtime files, and externalize the relative path of your Ruby on Rails application by loading these settings from your service configuration. When you build the absolute path of the runtime files or of your Ruby on Rails application, you should take advantage of the RoleRoot environment variable that is defined for you, which automatically points to the root directory for the worker role. For code that you can use for this purpose, see Figure 8. Note that your files are located in this folder, inside the AppRoot folder.

Now that you have WEBrick starting on a configured port, you must configure the role endpoints so that requests from the web actually reach your Ruby on Rails application. For a Worker Role application, define a TCP endpoint with a public port (e.g., port 80), and leave the private port blank. Note that worker roles do not currently support HTTP input endpoints, so you must use TCP. When your worker role starts, WEBrick will use the port that is assigned behind the load balancer (e.g., port 5100), but your application can be accessed through the public port.

Deploy to Azure

After you have followed this process, deployment is easy—just follow the steps that you typically use to deploy from Visual Studio, from a Windows PowerShell script, or manually via the Azure Management Portal. Voila, Ruby on Rails on Azure!

Zoiner Tejada ([email protected]) is president of TejadaNET, is recognized as a Microsoft Industry Influencer, and is an advisor to the Microsoft Connected Systems Division. Zoiner has a degree in computer science from Stanford University and blogs at TheWorkflowElement.com.

Read more about:

Microsoft
Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.

You May Also Like