rubyon windowsazure

©arton Windows Azure における Ruby on Rails の活用

1

Ruby on Rails on Windows Azure 2011 年 10 月

日本 Ruby の会

arton

目次

Ruby on Rails を Windows Azure で使用する ......................................................... 3

はじめに ......................................................................................................... 3

本ホワイトペーパーの目的 ............................................................................... 3

Windows と Ruby の微妙な関係について .......................................................... 4

本ホワイトペーパーの構成 ............................................................................. 10

Part１：Ruby、Ruby on Rails と Windows .......................................................... 11

Ruby on Rails の特徴 ..................................................................................... 11

少ないコード .............................................................................................. 11

Ruby on Rails の弱点 ................................................................................... 14

まとめ ....................................................................................................... 15

Ruby と Windows ......................................................................................... 15

Ruby のマルチスレッド ................................................................................ 16

GVL と拡張ライブラリ .................................................................................. 17

マルチプロセス ........................................................................................... 19

まとめ ....................................................................................................... 21

Part2：Windows Azure を意識した Ruby on Rails アプリケーションの開発 ................ 23

開発用 PC のセットアップ ............................................................................... 23

NougakuDo のインストールと展開 .................................................................... 25

NougakuDo の特徴 ..................................................................................... 25

NougakuDo のポリシー ............................................................................... 26

NougakuDo のインストール .......................................................................... 27

アプリケーションの開発 ................................................................................... 30

コマンドプロンプトの実行 ............................................................................. 31

アプリケーションの新規作成 .......................................................................... 31


2

データベースの準備１ ................................................................................. 32

データベースの準備２ ................................................................................. 35

データベースの準備 3 .................................................................................. 36

サーバーの起動 ........................................................................................... 37

アプリケーションの作成 ................................................................................ 43

バッチによるサーバー起動 ................................................................................ 47

production モードでの実行 ........................................................................... 47

まとめ ....................................................................................................... 49

運用時の選択 ................................................................................................. 49

仮想ホストでの運用 ..................................................................................... 50

サブディレクトリでの運用 ............................................................................. 53

まとめ ....................................................................................................... 54

Part3：Windows Azure への Ruby on Rails アプリケーションのデプロイと実行 .......... 56

NougakuDoCompanion の用意 ........................................................................ 56

NougakuDoCompanion について .................................................................. 56

NougakuDoCompanion の実行環境 ............................................................... 57

Azure 開発環境の準備 .................................................................................. 57

Azure Storage Explorer のインストール ......................................................... 58

NougakuDoCompanion ソリューションの読み込みとビルド ................................ 59

NougakuDoCompanion を利用したデプロイ ....................................................... 60

NougakudoSetupTool の実行 ....................................................................... 60

NougakuDoCompanion の実行 ..................................................................... 64

Blob ストレージへのアップロード .................................................................. 66

NougakuDoCompanion の実行（2） .............................................................. 67

AdminWeb の利用 ...................................................................................... 69

Windows Azure へのデプロイと実行 ................................................................. 71

NougakuDo アプリケーションの修正 .............................................................. 72

データベースの作成 ..................................................................................... 73

NougakuDoCompanion の配備 ..................................................................... 74

まとめ ....................................................................................................... 75


3

Ruby on Rails を Windows Azure で使用する

はじめに

このホワイトペーパーでは、Windows Azure で Ruby on Rails を効果的に実行する方法につ

いて解説します。

なお、読者はプログラミング言語 Ruby1 と、Ruby on Rails2 （Ruby で Web アプリケーシ

ョンを開発、実行するためのフレームワーク）について、実際に開発に利用したことは無くても

それが何かを知っている程度の知識があることを想定しています。また、本ホワイトペーパーの

目的は、Windows で効果的に Ruby on Rails を稼働させることなので、相当技術的な詳細に

立ち入ります。

本ホワイトペーパーの目的

このホワイトペーパーの目的は、Ruby on Rails 上で動く Web アプリケーションを既に持っ

ている、あるいは Ruby on Rails を利用した Web アプリケーションの開発体制ができている

／作ろうとしている、という開発者の皆さんを対象に、クラウドプラットフォームとして

Windows Azure が利用できるかどうか良くわからない、あるいは利用しようとしたがパフォ

ーマンスが出なくて困っているという疑問に対する解決方法を提示することです。もちろん、

Ruby on Rails に興味があるので、どれだけ実用的に実行できるか試してみたいという場合や、

使い慣れた Windows プラットフォームでの運用を計画しているといった場合にも役に立ちま

す。

最初に結論を言いますと、もちろん Windows Azure は、Ruby on Rails を実用的に実行でき

る優れたプラットフォームです。本ホワイトペーパーでは、そのために必要となるサーバー側の

ソフトウェア構成について、理由や仕組みを交えて解説します。

1 http://www.ruby-lang.org/

2 http://rubyonrails.org/

http://www.ruby-lang.org/

http://rubyonrails.org/


4

Windows と Ruby の微妙な関係について

はじめに、Ruby、Ruby on Rails と Windows の関係について簡単に紹介します。

Ruby の Windows サポート

Ruby はオープンソース3のプログラミング言語です。

オープンソースであることは、オープンソース文化とは異なる文化のもとでソフトウェアを開発

してきた開発者にとって、得体が知れないもののような印象を与えている面があるようです。そ

のため、Windows で動くのか？であるとか、Windows はサポートされていないのではない

か？といった疑問を持つ方もいます。

それを踏まえて、最初に、Ruby の「Windows サポート」という言葉の意味について明らかに

しておくほうが良いでしょう。

重要な点を最初に説明すると、「サポート」＝「問題が発生した場合の責任主体」という意味に

おいて、Ruby にはサポートはありません。それは Windows に対してだけではなく、Linux や

Solaris といった他のプラットフォームについても同様です。必要であれば、「サポート」を提

供するサービス企業と契約を結ぶことは可能ですが、そのようなサービス企業の紹介は、このホ

ワイトペーパーの対象外です。

Ruby における「サポート」とは、対象のプラットフォームで、Ruby コア開発チームが決定し

たテストスペックを可能な限り満たすという意味です。具体的には、正しいツールと手順を踏ん

で Ruby のリリース版ソースファイルから対象のプラットフォーム上の対象コンパイラなどを

利用して生成したバイナリファイルが、リリース版ソースファイルに添付されたテストプログラ

ム群をパスすることです。また、バグ報告があれば、その報告を吟味し必要と認めた場合に修正

されるということも意味します。

以上の点を前提として、2011 年 9 月時点、Ruby は Windows を Best effort レベルでサポ

ート4しています。 Best effort レベルというのは、リリース版に致命的と判断されないテスト

エラーが残っている可能性があるレベルという意味です。したがって、Windows については、

Windows 用コードのメンテナンスをするコア開発者がいて、リリース版ソースファイルからバ

イナリファイルをビルド可能であることが、2011 年 9 月時点では保証されています。

Windows での Ruby on Rails の実行

3 現在は Ruby 固有ライセンスまたは GPL-2.0 でライセンスされています。ただし次期リリース版からは GPL-２.0

から宣伝条項抜きの BSD ライセンス（2-clause BSDL）への移行が決まっています。

4 http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa

http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa

http://redmine.ruby-lang.org/projects/ruby-19/wiki/SupportedPlatformsJa


5

前の節で Ruby は Best effort レベルで Windows をサポートしているということを説明し

ました。

このため Ruby で開発したアプリケーションはアプリケーション自体にバグがなければ、

Windows で実用上の問題なしに動作します（少なくとも動作すべきです）。同様に人気がある

Web アプリケーションフレームワークの Ruby on Rails も Windows で実行可能です。これ

は Ruby on Rails が、プログラミング言語 Ruby の上で動作するように開発されているから

です。

したがって Windows のクラウドプラットフォームの Windows Azure で Ruby on Rails を

利用することにも問題はありません。

ただし、ここで問題がないと言っているのは、Ruby 処理系が Ruby で開発した Web アプリ

ケーションを正しく実行するという点だけだということに注意が必要です。つまり、実用的な動

作をするかどうかは、Ruby の Windows サポートとは別のレベルで考慮しなければなりませ

ん。

具体的には、Web アプリケーションの実行環境、つまり、Web サーバーや RDBMS5 の選定

やインターフェイスの選択です。

ここで問題となるのは、Linux や Mac OS X などに比べると、Windows 上での Ruby の実

行方法について、それほど実用的なノウハウが知られているわけではないことです。特に Ruby

on Rails の場合、入手が容易な情報は、リバースプロクシとして Apache HTTP サーバー6を

利用する方法を紹介したものがほとんどです（図 1）。

図 1 Rails アプリケーションは Thin などの Web サーバー7上で

5 Relational Database Management System

6 http://projects.apache.org/projects/http_server.html

7 図中の Thin（http://code.macournoyer.com/thin/）および Mongrel（http://rubyforge.org/projects/mongrel/）

http://projects.apache.org/projects/http_server.html


6

Apache からのリクエスト転送を待ち受けるプロセスとして常駐

図 1 の接続方法は、以下の特徴を持ちます。

仮想ホストを利用したアプリケーションの分割

仮想ホスト単位での停止/起動が容易

マルチプロセスで Web アプリケーションを構成可能

Ruby のスレッドが持つ並行実行の制限を受けずに並行動作が可能

ここで示した特徴が、アーキテクチャとして Ruby on Rails および Ruby アプリケーション

実行のベストプラクティスを構成しています。

しかしお気づきのように、このような Web サーバーの構成方法は Windows ユーザにはそれ

ほど馴染みがあるわけではありません。たとえば IIS8 が仮想ホストをサポートしたのは 6.0 以

降です。また、リバースプロクシを実装するために必要な URL 書き換えを IIS の機能として

提供したのは 7.0 以降です。結局、良く知られた方法で Ruby on Rails を動かそうとすると、

以前の IIS では利用できない機能が必要でした。

このような Windows で Ruby on Rails を実行するための情報の乏しさは、Ruby on Rails を

以下のような望ましくない方法で実行する原因となります。

IIS から CGI で Ruby on Rails を利用する（図 2）

Ruby 標準添付の WEBrick（Web サーバー）を利用する（図 3）

は、軽量 Web サーバーで、Apache Web サーバーはクライアントからのリクエストを HTTP ヘッダーのホスト変数

を参照して転送する。

8 Internet Information Service、あるいは Internet Information Server


7

図 2 Rails アプリケーションを CGI で実行クライアントからのリクエストの都度プロセスを起動

図 3 WEBrick を利用して実行

このホワイトペーパーで後述するように、上記のような実行方法では Ruby on Rails のパフォ

ーマンスを引き出すことはできません。むしろ実行を阻害すると言っても過言ではありません。

それが原因で、Windows では Ruby on Rails を実行できないといった誤った結論が導かれる

ことすらあります。

それでは、他のプラットフォームでの実績に基づいた Web サーバーの組み合わせを利用すれ

ば良いのでしょうか？

これは必ずしも悪い方法ではありません。 Apache や Mongrel については Windows 用のバ

イナリ配布も存在します。実際、これらを組み合わせることで、最初に示した望ましくない方法

とは比較にならないパフォーマンスを得られます。その一方で、この方法には致命的な問題があ

ります。

それは HTTP が利用するポート 80 を IIS と Apache で共有できないことです。このため、

Apache を導入すると決めると、同じ Web サーバー上で ASP.NET を利用する、あるいは過

去の資産の ASP9 を動かすといったことが容易にはできなくなってしまいます。

また、Web サーバーのようなインフラを OS とは独立して導入することは、システムのメン

テナンスポイントの増加を意味します。特に Web サーバーは、直接クライアントからのリクエ

ストを受ける必要があるため、システムにとってもっともクリティカルな問題の発生点となりま

す。したがって、運用においては Windows のサービスパックやセキュリティパッチなどの導

9 Active Server Pages


8

入とは別に、セキュリティパッチやバージョンアップについて考慮しなければなりません。この

観点からは、Web サーバーは IIS を一元的に利用することが望ましいのです。

そこで容易に考えつく Ruby on Rails を Windows で効果的に実行する方法は、IIS 7.0 の

URI 書き換えを利用したリバースプロクシです。その場合、Ruby on Rails は Mongrel など

の軽量 Web サーバー上で実行します。つまり図 1 の Apache を IIS へ置き換えた構成です。

しかし、この方法でも、インフラとして IIS とは異なる Web サーバーを導入していることに

変わりはありません。

実は、Windows にはこのようなプロセス分離した Web アプリケーションを効果的に支援す

るための機構が組み込まれています。それが Windows Server 2003（Windows XP SP2）か

ら導入された、Http.sys10 カーネルモードドライバです。 Http.sys は名前が示す通り、Web

を実現するプロトコル――HTTP を処理するドライバです。現在の IIS は、Windows 2000 以

前のものと異なり、自分でソケットを利用して直接 TCP/IP を操作しているわけではありませ

ん。ネットワーク通信や HTTP のプロトコル処理は Http.sys によって行われるからです（図

4）。

図 4 Http.sys カーネルモードドライバを共有するプロセス11

筆者の考えでは、Http.sys の利用こそが、最も効果的に Windows で Ruby on Rails を実行

する方法です。 Ruby on Rails に Http.sys をバインドすることで、ここまでに示したすべて

の問題が解決します。

10 HTTP Server API（http://msdn.microsoft.com/en-us/library/aa364510(v=VS.85).aspx）

11 Windows Communication Foundation

http://msdn.microsoft.com/en-us/library/aa364510(v=VS.85).aspx


9

本ホワイトペーパーで推奨するのは、筆者（arton）が開発した Windows の Http.sys と Ruby

on Rails をブリッジする Ennou12 というライブラリを利用した運用方法です（図 5）。 Ennou

は極めて薄いラッパで、基本的には Ruby と Win32 間のオブジェクト変換と適切なタイミン

グでの Http.sys の API13 呼び出しのみを担当します。

図 5 Ennou を利用した実行では、クライアントからのリクエストはカーネルモード

ドライバ（Http.sys）が処理し、常駐しているいずれかのプロセスに割り当てられる

Http.sys を利用することのメリットには以下のものがあります。

クライアントとの通信はカーネルモードで動作するため、ユーザアプリケーションの動作

に影響されずに安定したサービスを提供可能

脆弱性の原因となるポイント（たとえば HTTP のリクエストヘッダー解析処理）を

Windows サービスが一元的に提供することで、仮に問題が発覚しても Windows アップ

デートによって対応可能

クライアントからの送受信処理がユーザプロセスとは独立しているため、リバースプロク

シを利用せずとも複数のプロセスが Web サーバーとして動作可能

同じ Http.sys を利用する IIS と共存が可能

Ennou は、Http.sys がもたらす上記のメリットを Ruby on Rails を利用するアプリケーショ

ンに提供します。

12 https://github.com/arton/ennou

13 Application Programming Interface

https://github.com/arton/ennou


10

本ホワイトペーパーの構成

このホワイトペーパーは大きく 3 つのパートから構成されます。

最初のパートでは簡単に Ruby on Rails の特徴について説明します。次に Ruby on Rails と

Ruby の実行時の仕組みについて説明します。このパートで実行時の問題点と、それに対する解

決策について明らかにします。

次のパートでは、Windows Azure での実行を意識した Ruby on Rails の開発方法について説

明します。ここには簡単なチュートリアルを含みます。このパートの肝は、開発に利用するデー

タベースエンジンに SQL Server（Express Edition）14を最初から利用する点です。SQL Server

を利用することで、Azure 上では SQL Azure をほとんどそのまま効率よく利用できるからで

す。

最後のパートでは、開発した Ruby on Rails アプリケーションを Windows Azure にデプロ

イする方法について解説します。

14 SQL Server 2008 や SQL Server 2008 R2 でありエディションは問いません。


11

Part１：Ruby、Ruby on Rails と Windows

パート 1 では、最初に Ruby on Rails の特徴について簡単に紹介します。ここでは ASP.NET

については熟知しているが、Ruby on Rails については良くわからないといった方を対象に、

Ruby on Rails の特徴的な点について ASP.NET に似ている点と異なる点について説明します。

次に Ruby の実行モデルについて解説します。Ruby の VM15 は OS とは独立したスレッド

ハンドリングを行います。このため、Ruby の実行モデルを理解しておかないと、効果的な実行

環境を構築できません。本パートでは、Ruby の実行時の動作を示すことで、どのように環境を

構築すべきかを明らかにします。

Ruby on Rails の特徴

Ruby on Rails は、2004 年に公開された Web フレームワークです。このフレームワークは

公開と同時に大きな反響を巻き起こしました。その理由、つまり最も注目された特徴は、バック

グラウンド処理に必要なコードの量がきわめて少ないことでした。これは、Web サービス系ス

タートアップなどにとっては大きなメリットです。というのは、これらの企業にとって重要なの

は、アイディアの素早い具現化や、耳目を集められるユーザインターフェイスの構築だからです。

それに比べるとバックグラウンドで行われるデータベースとのインターフェイスなどは必要で

はあるけれど、省力化できるに越したことはありません。そのため、データベースとの決まりき

った手続き（いわゆるボイラープレート）をまったく記述しないで済ませられる Ruby on Rails

はきわめて魅力的です。

少ないコード

たとえば典型的な Ruby on Rails を利用したアプリケーションのデータベースへの書き込みは

以下のリストのようになります（バリデーションは省略しています）。

class DataController < ApplicationController

def update

@data = Data.find(params[:id])

@data.update_attributes(params[:data])

format.html { redirect_to(@data, :notice => '保存に成功しました') }

end

end

15 Virtual Machine


12

class Data < ActiveRecord::Base # 自動生成されるモデル（データベースアクセス）ク

ラス

end

上例で特徴的なのは、OR マッピング16を実現している Data クラスが完全に空のクラス定義

だということです。

一般にオブジェクト指向プログラミングでは、フレームワークが提供するクラスを継承したユー

ザクラスの記述は簡潔になります。なぜならば、フレームワーク側が基本的な実装を提供するか

らです。しかし、Rails の場合、この特徴がほとんど極限にまで推し進められています。たとえ

ば上の例でコントローラが呼び出す Data クラスの find メソッドや update_attributes メ

ソッドは、本来であれば開発者によってテーブル定義に応じた異なる実装か設定ファイルの作成

が必要です。フレームワークは標準的なコードの枠組みは提供できても、個々の実装の仕様の差

までは吸収できないからです。それに対して Rails では、設定よりも規約という方針と、Ruby

の動的メソッド生成能力を組み合わせることで、上で示した簡潔さが提供されます。なお後者の

面から、Ruby on Rails が注目を浴びると同時に、Ruby そのものも注目されるようになった

と言えます。

もっとも .NET Framework 開発者であれば、同様な処理をたとえば ASP.NET の Web フォ

ームフレームワークを利用して次のように記述できます。

Update メソッドをポストバック指定した Web フォームを作成する。

Data テーブルとフォームのコントロールをデータバインドするデータソースを作成する。

Update メソッド内でデータソースの AcceptChanges メソッドを呼び出す。

このように考えると、Ruby on Rails のコード量が少ないと言っても、 .NET Framework 開

発者にとってはそれほど大きな違いがあるようには感じないでしょう。むしろ、コードの記述量

だけに着目すると Ruby on Rails は Windows 開発者にはそれほど魅力はないかも知れませ

ん。というのは Visual Studio + ASP.NET を利用して開発すると、インテリセンスのような

コーディング補助機能が強力なために多少のコード量は気にならないからです。

このため Windows をターゲットとして考えた場合に、Ruby on Rails と ASP.NET のアプリ

ケーションの違いは、依存しているのが Ruby と Ruby on Rails か、それとも .NET

16 Object Relational Mapping


13

Framework かという点と、開発した成果物がすべて編集可能なテキストファイルか、それとも

バイナリや基本的に編集不可の XML や IDE17 用ソースファイルかどうかという点となりま

す（ASP.NET アプリケーションを Visual Studio 抜きで開発した場合もすべてテキストファ

イルとなりますが、この場合は記述量が大きくなってしまうため話が変わってきます）。具体的

には、Web アプリケーションのプラットフォーム非依存性です。

それとは別に、筆者が実感する大きな違いはソースファイルの透明性です。 Ruby on Rails は

プログラマの記述量が少ないだけでなく、上の例から明らかなように自動生成されるソースに含

まれるコードもごく少量です。これは ASP.NET が生成する型情報を含んだ XML や Web フ

ォームの aspx ファイルの複雑さとの大きな違いです。結果として、いざプログラミングが必

要となった場合に Rails のほうがいろいろやり易いと感じます。特に HTML にいろいろ仕掛け

を入れたい場合に、フレームワークとして ASP.NET の Web フォームを選択した場合に直面

する困難さは Ruby on Rail にはまったくありません18。

例として、Ruby on Rails の scaffold（ウィザードの Ruby on Rails バージョン）が作成する

一覧画面の HTML テンプレートを以下に示します。

<h1>Listing sheets</h1>

<table>

<tr>

<th>Title</th>

<th>Description</th>

<th></th>

<th></th>

<th></th>

</tr>

<% @sheets.each do |sheet| %>

<tr>

<td><%= sheet.title %></td>

<td><%= sheet.description %></td>

17 Integrated Development Environment（統合開発環境）

18 HTML を開発者が直接編集する度合いが高ければ、ASP.NET MVC を使うべきかも知れません。


14

<td><%= link_to 'Show', sheet %></td>

<td><%= link_to 'Edit', edit_sheet_path(sheet) %></td>

<td><%= link_to 'Destroy', sheet, :confirm => 'Are you sure?', :method

=> :delete %></td>

</tr>

<% end %>

</table>

<br />

<%= link_to 'New Sheet', new_sheet_path %>

Ruby on Rails が生成する HTML テンプレートは、ここで示したように <%= %> のような

ASP でおなじみの埋め込み用マークアップとシンプルなタグだけで構成されます。これは、デ

ザインは CSS、表示内容は HTML という考え方の忠実な反映であり、必要に応じた追加／変

更に開かれています。

付言すると、トライ＆エラー開発や漸進的リリースを行うには、データベースのマイグレーショ

ンの機構も持つ Ruby on Rails のほうが管理しやすくなります。

いずれにしてもここで挙げた Ruby on Rails のメリットが意味を持つかどうかは個々の案件に

依存します。そのため、ASP.NET と Ruby on Rails のどちらを使うべきかというようなこと

についてはここで結論することはできませんし、結論する意味もありません。

重要な点は、Ruby on Rails と Ruby がもたらすずば抜けて簡潔なプログラミングモデルには、

熱狂的なファンを獲得するだけの魅力があるということです。

Ruby on Rails の弱点

ここまで見たように Ruby on Rails がアプリケーションにもたらすパワーとは圧倒的なコード

の少なさです。

しかし、それには代償が伴います。

特に大きな代償は、起動に必要な時間です。これがきわめて大きなことが、Ruby on Rails を

CGI で実行してはならない理由です。

Ruby on Rails を支える設計哲学の１つに DRY（Don't Repeat Yourself）があります。文字

通り繰り返しを避けるということです。DRY が Ruby on Rails の実装に端的に表れているの

が、既存のライブラリがあればそれを利用する、既にメタデータがあればそれを利用する、とい


15

う点です。これは、バグを入りにくくする（二重管理、三重管理といったものがバグの原因の１

つであることに異論がある方はいないでしょう）、記述量を少なくする、といった良い効果をも

たらします。しかし、その反面、最適化されていない状態で大量の情報を利用することになると

いう負の側面もあります。

まず Ruby on Rails は、 Ruby で記述された多数のライブラリを利用します。Ruby のプロ

グラムそのものはテキストなので、実行時にファイルから読み込まれ VM 用にコンパイルされ

ます。これが多数の小さなファイルに対して一気に行われることが起動に時間がかかる原因の

１つです。

同様に、データベースが持つスキーマを実行時に読み取ります。あらかじめ XML に保持した

り、プログラム化しているわけではありません（前節の Data クラスを思い出してみましょう）。

なぜなら、スキーマは既にデータベース上に存在するから、別の形式で持つことは DRY に反し

ます。また二重管理になれば、実際のデータベースとプログラムや構成ファイルが持つ情報の同

期が失われてエラーとなる可能性を持ちます。したがって、実行時にデータベースからスキーマ

を読むことは明らかに正しい設計方針と言えます。しかし、これも起動処理を遅くする原因の１

つです。

結局、こういった問題を回避する方法は 1 つしかありません。それは、Ruby on Rails アプリ

ケーションを一度起動したらそのプロセスを常駐させて実行を継続させることです。CGI のよ

うに、クライアントからのリクエストの都度、起動／終了することは現実の処理に耐えられるも

のではありません。

まとめ

Ruby on Rails についてまとめると、Ruby on Rails は ASP.NET と同じように、開発者が注

力すべき点にのみ注力できるようにポイントを絞った開発を可能とするフレームワークです。一

方、ASP.NET と異なる点として、実行モデルの詳細レベルの最適化（たとえば OR マッピン

グの型変換の効率性）よりも、アプリケーションの骨格を少ない記述で組み上げることで、細部

の肉付けをできるだけ開発者の自由に任せることの重視が挙げられます。

また、Ruby on Rails を効率的に実行するには、一度起動したらそのまま実行を継続させる必

要があります。

Ruby と Windows

Ruby を効率よく実行するためにはスレッドとプロセスをうまく制御することが重要です。

特に Web アプリケーションの場合、同時に複数の異なるクライアントがリクエストを送って

きます。これをできる限り素早く同時に処理しないと、いかにも反応が悪い使えない Web ア


16

プリケーションとなってしまいます。

Ruby のマルチスレッド

Ruby はスレッドを自身の VM で処理します。このため、ASP.NET のような Windows（.NET

Framework）ネイティブな Web アプリケーションとはスレッドの動作が異なります（表 1）。

Windows ネイティブ Ruby

マルチスレッド ○ ○

ノンプリエンプティブ ○ ○

並列実行 ○ △

表 1 Ruby のマルチスレッド

表 1 で示したように、Ruby はプログラミング言語としてマルチスレッドをサポートしていま

す。また、スレッドの切り替えはノンプリエンプティティブ（横取り制御――切り替えのための

特別な API を呼び出さなくてもスレッド切り替えが行われること）です。

しかし複数のスレッドの並列実行については条件付きでしかサポートされません。しかもその場

合の並列というのは、あるスレッドが IO19 を実行している（別の言い方をすればプログラム上

のコードの実行は停止している）間に他のスレッドに制御が移る、というレベルです（図 6）。

これはシングル CPU の場合と等しい動作であって、最近のマルチコア CPU を利用してもその

ままでは真の意味での並列動作はできないということを意味します。

なぜ Ruby がこのようにスレッドを制御しているかというと、基本的には C20 で書かれた拡張

ライブラリのサポートのためです。

19 I-O（Input-Output、入出力）

20 C 言語のことで、以降では C と表記します。


17

図 6 Ruby のマルチスレッド動作

現時点の Ruby は、JIT21 を利用した VM コマンドの機械語への置き換えは行っていません。

このため、やろうと思えば VM 内でプログラムがアクセスする変数の競合の回避や他のスレッ

ドへの反映を処理できます。したがって、Ruby で記述されたプログラムの動作については並行

動作を実行することに特に設計上の問題があるわけではありません。

しかし、C で開発された拡張ライブラリについては、話が異なります。スレッドが並行して動

作すれば、同じメソッドを同時に複数のスレッドがアクセスできてしまいます。このため、スタ

ック上やスレッドローカルに確保していない変数は競合を回避するように考慮しなければなり

ません。しかし、Ruby は以前から C の拡張ライブラリについて、C レベルの関数呼び出し中

はスレッドの切り替えを行わない（行えない）ということを打ち出しています。このため、以前

のバージョン22用に作成された C 拡張ライブラリの互換性を維持するためには、拡張ライブラ

リを呼び出している間は他のスレッドへ制御を移すことはできません。そうでなければ拡張ライ

ブラリの中でさまざまな競合問題が発生してしまいます。

GVL と拡張ライブラリ

前節で説明したように、Ruby はノンプリエンプティティブなスレッド切り替えを行いますが、

21 Just In Time コンパイラ

22 Ruby 1.8 までは Ruby は OS が用意したスレッドを利用せずに独自実装のスレッドを利用していました。


18

拡張ライブラリの呼び出し中はスレッドを切り替えられません。このような制御を行うためには、

現在実行中のスレッドを何らかの方法で他のスレッドと区別する必要があります。

Ruby がこのために利用するのが、GVL（グローバル VM ロック）または GIL（グローバルイ

ンタプリタロック）と呼ばれる、Windows のミューテックスに相当するオブジェクトです。

プロセス内のスレッドは GVL を共有し、GVL がシグナル状態となったスレッドのみが実行権

を握ります。つまり、あるスレッドが GVL を持っている（シグナル状態の）間は、他のスレッ

ドは一切動作できません。これによって、Ruby がプロセス内で同時に動作するスレッドをただ

1 つに制限しています。

ところが、前節で説明したように、Ruby はあるスレッドが IO を実行している間は他のスレ

ッドに制御を移せます。

これは Ruby の IO ライブラリが、スレッドセーフに作られているからです。このため、Ruby

プログラムの部分から Ruby の IO ライブラリ（ファイルやソケット）を呼び出した場合は、

IO 待機前に GVL を解放することが可能です（図 7）。

図 7 GVL と解除

現在、GVL 解除のための API については公開と周知が始まっています。このため、今後は拡

張ライブラリのマルチスレッド対応が進むことが考えられます。そのように準備が進めば、自然

の流れとしてスレッドの並行実行機能も実装されることになると考えられます。


19

ちなみに Ennou も Http.sys に対して待ち状態となる API 呼び出し前に GVL を解除して

います。

Note: WEBrick と Ruby on Rails

ここまでの内容を理解すると 1 つ疑問が出てきます。それは、なぜ Ruby 標準添付の Web サ

ーバーである WEBrick の利用が勧められないのかということです。

WEBrick はピュア Ruby による Web サーバーの実装です。当然、利用しているソケットは

Ruby が標準で用意したものです。つまり、サーバーがクライアントからのリクエストを受信待

ちとなる間や、レスポンスを送信している間は GVL が解放されます。したがって、効率よく

複数のリクエストを割り当てられたスレッドを処理できます。

また、Web サーバーとしての完成度はきわめて高く、HTTP のサーバー側に求められる機能を

網羅しています。現在は既知の脆弱性も存在しません。

問題は、まさにその Web サーバーとしての完成度にあります。サーバーに求められる膨大な

処理をピュア Ruby で記述しているため、同時に処理可能なリクエスト数、1 リクエストあた

りの所要時間ともに他の高速なサーバー実装、たとえば Http. sys や Apache と比較すると 1

桁以上の差があります。

このため、他に優れた代替がある以上、WEBrick を実働環境用の Web サーバーとしては勧め

ないのです。

マルチプロセス

ここまで説明したように、Ruby は、CPU のコア数と無関係に同時実行可能なスレッドを 1 つ

に制限しています。しかも、GVL について考慮していない拡張ライブラリの中で長時間に及ぶ

待機状態が続くと、その間は一切の処理が中断してしまいます。

後者については、 GVL 解除の方向＝スレッドセーフな実装によって解決しますが、前者の制限

については後者の実装が進まなければ、過去のアプリケーション資産に対する互換性を保証する

ために撤廃の決定は難しいものがあります。

このため、現時点での Ruby でマルチコアな CPU を効果的に利用するベストプラクティスは、

マルチプロセスでの実行です。

マルチプロセスであれば、当然ですが、個々のプロセスは互いに独立して実行できるため、マル

チコア CPU を活用できます。

以前はメモリ空間が 32 ビットであったため、多数のプロセスを同時に実行することはメモリ

不足による効率低下を考慮する必要がありましたが、64 ビット対応がなされた現在では、メモ

リ不足に頭を悩ます必要はほとんどありません。

しかしマルチプロセスで実行するには、それなりの考慮が必要です。特に Web アプリケーシ


20

ョンの場合は、クライアントからのリクエストを HTTP サーバーで受け付けなければなりませ

ん。

すると、以下の諸点について考慮しなければマルチプロセスで稼働させることは不可能です。

受信ポート

プロセス制御

セッション情報

リソース共有

それでは、上記のそれぞれについてみてみましょう。

最初の受信ポートとは、TCP/IP を利用する通信で、クライアントからのリクエストを受け付け

るための識別子のことです。TCP、UDP といったソケットを利用するプロトコル単位に１番

から 65535 番までが利用できます。たとえば HTTP は TCP の 80 番ポートを利用します。

このように受信ポートは、コンピュータの外部から特定アプリケーション／サービスといったエ

ンドポイントを示すために使われます。このため特定のポートは、ある時点で 1 つのプロセス

にしか割り当てられません。たとえばリバースプロクシを利用する場合であれば、リバースプロ

クシのプロセスがポート 80 を持ち、実際にリクエストに対してサービスを提供するプロセス

はそれぞれ異なるポート番号を利用して、リバースプロクシからリクエストの転送を受けます。

これが通常の利用方法です。

しかし Http.sys を利用する場合は、これには当てはまりません。というのは、ポート 80 を

持つのがカーネルモードドライバの Http.sys だからです。Http.sys は一元的にポート 80

へ送られてきたリクエストを受け付けます。そして HTTP ヘッダー解析などの下処理をした後

に、リクエスト URI をキーとして個々のプロセスへリクエストを転送します。このため、

Windows では Http.sys を利用することで、同時に複数のプロセスがポート 80 を共有でき

るのです。このことからも、Http.sys の利用が有効であることがわかります。

プロセス制御は、複数のプロセスから構成される Web アプリケーションを同時に起動したり

停止したりできることで、HTTP サーバーがこの機能を提供する必要があります。Ennou の場

合は、マルチプロセスで実行する場合、最初に起動されたプロセスがブレークシグナル（コンソ

ールに対する Ctrl-C23 の入力）を監視し、シグナルを受信すると他のプロセスを順次停止させ

ます。

セッション情報は、クライアントからのリクエストとリクエストの間の状態を保持するために利

用するデータベースです。シングルプロセスであればクライアントの IP アドレスと紐付けたメ

モリ上の領域を利用することが多く、複数のコンピュータで構成された大規模な Web ファーム

23 Ctrl キーと C キーを同時に押すことを意味します。


21

であれば RDBMS を利用することが良くみられます。Ruby on Rails は初期の頃はセッション

情報をファイルで保持していましたが、現在はクッキーを利用することでクライアント側に持た

せます。いずれにしても Ruby on Rails は元々リバースプロクシで稼働させられるように設計

されているため、セッション情報についてアプリケーションは特に気にする必要はありません。

むしろ、REST24 アーキテクチャとの関係で、認証情報のような特殊な情報を別として、できる

だけサーバーの状態に頼らないようなアプリケーションを設計するほうが良いでしょう。

リソース共有は、RDBMS や KVS25 のようなクライアントサーバー形式のデータベースを利

用することで解決できる問題です。もっとも更新処理の効率に問題はあるものの、SQLite3 の

ようにマルチプロセスでの利用を考慮してあるインプロセス型 RDBMS も利用可能です。リソ

ース共有は、どちらかというと個々のアプリケーションがそれぞれの要件に応じて考慮すべき問

題です。本ホワイトペーパーでは SQL Server（SQL Azure）の利用を前提としているため、

SQL Server のロック機能にプロセス（リクエスト）間の排他制御を任せれば問題はありません。

まとめ

Ruby は、マルチスレッドプログラミングをサポートしていますが、同時に１つのスレッドだ

けを実行可能状態とします。また、IO 待機時に別のスレッドを実行可能状態へ切り替えること

ができますが、そのためにはネイティブコードライブラリがマルチスレッドと GVL を意識する

必要があります。このため、IO 待機が発生するライブラリには、GVL を意識したものを利用

すべきです。

また、マルチコア CPU コンピュータで、同時に複数のクライアントからのリクエストを処理す

る必要があれば、マルチプロセスで実行する必要があります。

これは、Ruby on Rails を実行する OS が Windows かどうかを問いません。しかし、Apache

をリバースプロクシで利用するというベストプラクティスが確立している他の OS と異なり、

Windows という OS を生かすベストプラクティスを確立しているとは言えません。

Windows の特徴を生かした Ruby on Rails の実行のキーとなるのは、Http.sys カーネルモ

ードドライバの利用です。

Http.sys を利用することで、Windows の特徴を生かしたマルチプロセス実行が可能となりま

す。また、マシンパワーに余裕があれば、同時に IIS ＋ ASP.NET アプリケーションや、WCF

ホストプロセスを同一マシンで共存させることもできます。

このとき、Ruby on Rails と Http.sys の組み合わせで考慮しなければならないのは、クライ

24 Representational State Transfer

25 Key Values Store


22

アントからのリクエスト待ちの間に他の既に受信済みのリクエストを処理できるように、GVL

の解除を行うライブラリが必要だということです。そうでなければ、リクエスト待ちになった時

点で既に受信したリクエストの処理が停止してしまうからです。Ennou を利用することで、こ

の問題は解決します。


23

Part2：Windows Azure を意識した Ruby on Rails

アプリケーションの開発

パート 2 では、Ruby on Rails の実行に必要なプログラムを 64 ビット版 Windows 用にパ

ッケージした NougakuDo を利用して、Windows Azure をターゲットとした Web アプリケ

ーションの開発方法について説明します。

このパートの内部は、さらに 2 つのパートから構成されます。

最初のパートでは、NougakuDo のインストールと Rails アプリケーション作成の簡単なチュ

ートリアルを示します。

次のパートで、アプリケーション設計で考慮が必要となるサブディレクトリモードと仮想ホスト

モードについて説明します。この 2 つのモードは、どちらを選択するかでアプリケーション設

計から運用まで大きく影響されるため、本ホワイトペーパーで導入した用語です。

サブディレクトリモードとは、Rails アプリケーションを IIS などの他の Web アプリケーシ

ョンと同一ドメインで並列させる運用方法を指します。一方の仮想ホストモードは、Rails 標準

の運用方法で、Rails アプリケーション単位に仮想ホストを用意します26。

NougakuDo は、64 ビット Windows 用に Visual C++ 2010 でビルドした Ruby を中心

に、Ruby on Rails とパート 1 で紹介した Ennou、SQL Server 接続用ライブラリの tiny_tds

といったオープンソースソフトウェアから構成されます。NougakuDo は MSI 形式でパッケ

ージ化されているため、容易にインストール、アンインストールができます。また Ruby on Rails

アプリケーションの開発に必要なソフトウェアを一通り揃えているため、 NougakuDo をイン

ストールするだけでインターネットへの接続が制限されている企業内の開発用 PC でもすぐに

開発を始められます。

なお、本パートで開発した Web アプリケーションは、最終的にパート 3 で紹介する

NougakuDo Companion を利用して Windows Azure へデプロイされます。そのため、

Windows Azure で Ruby on Rails を試すには、本パートで示す手順を実際に試して、デプロ

イ用の Web アプリケーションを用意してください。

開発用 PC のセットアップ

最初に開発用 PC のセットアップについて説明します。

26 仮想ホストは仮想マシンのことではなく、URI を構成するホスト名のことです。


24

開発用 PC の OS については、開発時と Azure での運用時の差をできるだけ小さくするため

に、Windows Server 2008 R2 または Windows 7 (x64) を用意してください。

セットアップすべきソフトウェアは以下となります。

NougakuDo

64 ビット版 Ruby（1.9.3.?）と、Ruby on Rails（3.1.?）、Ennou、tiny_tds などを MSI

形式で同梱したパッケージです。

なお Ruby などのバイナリは Visual C++ 2010 を利用して作成されているため、

msvcr10 C ランタイムライブラリもパッケージに含まれています。

SQL Server 2008 Express

NougakuDo は、sqlite3 というインプロセス型 RDBMS を同梱しています。sqlite3 は

Rails のチュートリアルなどで標準的な位置を占めているため、Rails アプリケーションは

特別な設定抜きで利用可能です。

しかし、ここでの最終目標は Windows Azure へデプロイして、SQL Azure を利用する

ことです。そのため、ほとんど SQL Azure と同様に扱える SQL Server Express27 を用

意してください。

テキストエディター

テキストエディターは、文字のエンコーディングに UTF-8 を利用できることが必須です。

それ以外の文字コードも利用できますが、データベース、プログラム、HTML 、設定ファ

イルのすべてを UTF-8 で統一することで無用なトラブルが格段に減ります。

最初のうちはメモ帳でもある程度までは開発できますが、オートインデントやマクロ機能

などのプログラミングに向いた機能が備えられたエディターを利用するほうが、圧倒的に

楽にプログラムを打ち込めます。できればそれらの機能を持つエディターを用意しましょ

う。

もちろん Visual Studio を利用することも可能です。

なお、メモ帳を利用する場合、初期状態では Rails が作成したファイルは改行コードの関

係で正しく編集できません。これは Ruby や Rails が作成するソースファイルや設定ファ

イルの改行コードがラインフィード（\n）だからです。メモ帳で編集する場合は、

NougakuDo に同梱されているツール（editable.bat）を利用して改行コードをキャリッジ

リターン＋ラインフィード（\r\n）28に変換してください。

IDE について

27 http://www.microsoft.com/express

28 キャリッジリターン（CR)、ラインフィード（LF）

http://www.microsoft.com/express


25

Ruby には特に定番の IDE というものはありません。どうしてもメソッド補完などが必要

な場合は、NetBeans29 や Aptana RadRails30 が利用できます。

また、Ruby のソース配布物には、自動インデントや字句の色分けを行う Emacs 用の

Lisp ファイルが同梱されています。参考までに筆者は Ruby プログラムの開発には、これ

らの Lisp ファイルをインストールした Emacs の Windows ポート（Meadow31）を利

用しています。

NougakuDo のインストールと展開

NougakuDo は、筆者（arton）が開発およびメンテナンスを行っている Ruby のバイナリパ

ッケージです。

Ruby のバイナリパッケージには、他にも Ruby Windwows メインテナの中村さんの zip 配

布、MinGW32（gcc）を利用するビルド環境を含めた RubyInstaller33 、筆者による ASR34 な

どがあります。

NougakuDo は、これらのジェネラルなプログラミング言語 Ruby のパッケージとは異なり、

Windows で Ruby on Rails の開発／実行を強力にサポートすることを主眼としています。

NougakuDo は具体的には以下の特徴とポリシーを持ちます。

NougakuDo の特徴

NougakuDo は、筆者が Windows に最適と考える Ruby on Rails 環境を提供します。

これは具体的には、以下の 3 点です。

Rails を Http.sys 上で実行するための Ennou と、SQL Server 用 Ruby 拡張ライブラ

リの tiny_tds （開発は Ken Collins 氏）のバイナリを同梱

配置先をユーザ固有のアプリケーションディレクトリ（APPDATA35 スペシャルフォルダ）

29 http://ja.netbeans.org/

30 http://www.aptana.com/products/radrails

31 http://www.meadowy.org/meadow/

32 Minimalist GNU for Windows で、 http://www.mingw.org/

33 http://rubyinstaller.org/

34 Active Script Ruby で、 http://www.artonx.org/data/asr/

35 環境変数は APPDATA で、以降は APPDATA や APPDATA ディレクトリと表記します。

http://ja.netbeans.org/

http://www.aptana.com/products/radrails

http://www.meadowy.org/meadow/

http://rubyinstaller.org/

http://www.artonx.org/data/asr/


26

とし、gem36 のインストールをユーザ権限で行えるように考慮

インターネットへの接続に制限がある環境での開発を考慮して、Ruby on Rails アプリケ

ーション開発に必要な基本的な gem をあらかじめ同梱

これらの特徴により、標準的な Windows ――Http.sys が存在し、RDBMS として SQL

Server（Azure では SQL Azure）が用意されている――での Ruby on Rails アプリケーショ

ンの開発と実行に、最も適切な環境を用意します。

NougakuDo のポリシー

NougakuDo は Windows 用パッケージとして以下のポリシーを持ちます。

標準の尊重

パッケージのインストールとアンインストールは Windows のインストールサービス

（MSI）を利用します。

また、緊急の脆弱性対応や OS 固有のバグ回避を除き、公開されている Ruby のソースツ

リーに手をいれずにパッケージを作成します。固有の処理／ライブラリについては追加ツ

ールまたは vendor_ruby 以下のアドオン用ディレクトリに追加します。

MSI と RubyGems の共存

Windows のインストーラ（MSI）と、Ruby のパッケージシステム（RubyGem）がイン

ストールするパッケージ（Gem）を共存させるための妥協点として、NougakuDo は Ruby

のディレクトリ構造をユーザディレクトリ（APPDATA スペシャルフォルダ）へ展開しま

す。

ただし、後から追加した Gem はアンインストール時に削除されません。

環境変数の非汚染

PATH 環境変数を書き換えるのではなく、PATH を通したプロンプト用ショートカットを

スタートメニューへ作成します。

Visual C++ 標準ランタイムライブラリの利用

NougakuDo および同梱するバイナリのライブラリにはリリースされた最新の Visual

C++ のランタイムライブラリを利用します（2011 年現在は msvcr10）。これはライブ

ラリに脆弱性が発見された場合の対応を Windows Update を通じて自動的にサポートで

きるようにするためです。

36 Ruby のパッケージシステムである RubyGems のコマンド名。


27

オフラインインストール可能（インターネット接続不可環境への配慮）

NougakuDo は単一の msi ファイルの中に最低限実行に必要なものをすべて同梱し、オフ

ラインまたはイントラネットで閉じている PC に対してインストールから実行までを可能

とします。

バイナリ配布

コンパイルが必要なソフトウェアについてはあらかじめ最新の Visual C++ を利用してビ

ルド後に配布します。これにより開発 PC に追加のツールインストールを不要とします。

NougakuDo のインストール

NougakuDo は、筆者のドメインの http://www.artonx.org/data/nougakudo/ から配布して

います（図 8）。

図 8 NougakuDo のホームページ

NougakuDo のインストールは、上述のページから NougakuDo.msi をダウンロード（または

直接実行）してください（図 9）。

http://www.artonx.org/data/nougakudo/


28

図 9 NougakuDo.msi のダウンロード

なお、NougakuDo.msi には署名を行っていないため、直接実行時には SmartScreen フィル

ターの警告（図 10）、ダウンロード後のインストール時には不明な発行元の警告が表示されま

す（図 11）。上記のサイトから直接ダウンロードした場合など、出元が明らかな場合は「実行」

をクリックしてインストールしてください。


29

図 10 SmartScreen フィルターの警告

図 11 不明な発行元に対する警告

インストール作業は、ライセンス表示（図 12）などのステップを踏みます。ただし、設定項目

は無いため、「Next」を数回クリックするだけで完了します。

図 12 NougakuDo のライセンス表示


30

NougakuDo インストーラはシステムに対して以下を実行します。

現在のユーザの APPDATA ディレクトリへ nougakudo ディレクトリを作成し、パッケ

ージ内のディレクトリツリーとファイルを展開します。

APPDATA ディレクトリは、標準構成の Windows 7 であれば、C:\Users\ユーザ名

\AppData\Roaming です。

スタートメニューに NougakuDo フォルダを作成します。

NougakuDo フォルダには次の 3 つのショートカットが作成されます（図 13）。

図 13 スタートメニューの NougakuDo フォルダ

irb

Ruby の対話型実行環境です。

NougakuDo

メニューから起動するアプリケーションとしての NougakuDo は、Ennou を利用し

て Rails アプリケーションの起動を制御するローンチャーです。NougakuDo を利用

すると、Rails アプリケーション起動用のバッチファイルも生成できます。

Prompt

Ruby on Rails を利用した開発作業を行うためのコマンドラインプロンプトです。こ

れはユーザー／システムの環境変数を汚染するのではなく、環境変数を設定したコマ

ンドプロンプトを提供するというポリシーに基づきます。

レジストリの HKEY_CLASS_ROOT 下に、64 ビット版 ActiveScriptRuby を登録します。

ActiveScriptRuby は、COM 経由で Ruby を操作するための COM サーバーです。

NougakuDo（パッケージ）は、NougakuDo（ローンチャ）の実装に ActiveScriptRuby を

利用します。

なお、ActiveScriptRuby の HKEY_CLASS_ROOT 登録は、NougakuDo を利用した開発

に利用するだけなので、完成した Rails アプリケーションを Azure へデプロイする時に

は実行されません。

アプリケーションの開発

NougakuDo のインストールが完了したら、Ruby on Rails を使ってアプリケーションを開発


31

してみましょう。

なお、本ホワイトペーパーの目的から、ここでは完全な Ruby on Rails 開発について説明する

わけではないことに注意してください。Ruby on Rails を使った Web アプリケーションの開

発（特に、Ruby on Rails 3.1）については、『Rails によるアジャイル Web アプリケーショ

ン開発（第 4 版）37』などの著作を参照してください。

コマンドプロンプトの実行

最初に、スタートメニューの NougakuDo フォルダから prompt を起動します。

すると、コマンドプロンプトが順番に 2 回開きます。このうち最初に開くコマンドプロンプト

は 2 番目に開くコマンドプロンプトの環境を設定するだけなのですぐに閉じます。

開発作業は、主として、ここで 2 番目に開いた（そしてそのまま残る）コマンドプロンプトに

対して行います。

インストールが正しく行われていれば、コマンドプロンプトのカレントディレクトリは、

APPDATA（通常、C:\Users\ユーザ名\AppData\Romaing）です。

アプリケーションの新規作成

Web アプリケーションを作成するには、rails new コマンドを実行します。

コマンドプロンプトに対して、

rails new hello --skip-bundle

と打ち込んでみましょう。

すると、次に示すようなメッセージが順に表示されてから、コマンドプロンプトに復帰します。

create

create README

create Rakefile

create config.ru

（略）

create vendor/assets/stylesheets/.gitkeep

create vendor/plugins

create vendor/plugins/.gitkeep

rails new コマンドは、引数で指定した名前のディレクトリと Web アプリケーションのプロ

37 株式会社オーム社より刊行予定です。


32

ジェクトファイルを、カレントディレクトリ下に作成します。この場合、引数で hello を指定

したため、hello という名前の Web アプリケーションのプロジェクトディレクトリと必須フ

ァイルが、現在のディレクトリ直下に作成されます。

hello の次に入力した --skip-bundle は、Rails に対して最新の Gem の確認（とインストー

ル）をスキップすることを指示します。インターネットへ接続されていない環境や、NougakuDo

にパッケージされた Gem のバージョンを利用する場合には、--skip-bundle を指定してくだ

さい。

逆に、--skip-bundle を指定しない場合は、Rails が最新の Gem をインターネットから検索

してインストールします。この場合、以下の例のように、プロジェクトファイルの作成後に、

Gem のインターネットレポジトリ38に対してバージョンチェックと必要であれば Gem のイ

ンストールが行われます。

（略）

create vendor/plugins

create vendor/plugins/.gitkeep

run bundle install

Fetching source index for http://rubygems.org/

Using rake (0.9.2.1) …… ローカルの Gem が最新であれば Using と表示

（略）

Using tilt (1.3.3)

Installing sprockets (2.0.1) …… レポジトリが最新であれば Installing と表示

Using actionpack (3.1.0)

（略）

Using uglifier (1.0.3)

Your bundle is complete! Use `bundle show [gemname]` to see where a bundled gem

is installed.

開発するプロジェクトが利用する Gem のバージョンを揃える場合には、--skip-bundle を指

定、プロジェクト作成時に最新の Gem を利用する場合は指定しない、と使い分けてください。

データベースの準備１

rails new コマンドでプロジェクトを作成したら、次に、SQL Server 用の設定と、メモ帳でフ

38 http://rubygems.org/

http://rubygems.org/


33

ァイルを編集できるようにするために、tds_setup コマンドを実行します。

コマンドプロンプトに対して、

tds_setup hello

と打ち込んでみましょう。

以下のようにメッセージが表示されます。

Gemfile converted

config/database.yml converted

config/application.rb converted

application_controller.rb converted

（略）

tds_setup は、NougakuDo にバンドルされているユーティリティで以下の作業を行います。

デフォルトで利用するデータベースアダプタを activerecord-sqlserver-adapter に変更

プロジェクトディレクトリ直下の Gemfile（プロジェクトが利用する Gem の構成ファ

イル）の sqlite3 を activerecord-sqlserver-adapter に置き換えます。

データベース設定ファイルを SQL Server 用のテンプレートに変更

データベース設定ファイル（config\database.yml）の雛形を SQL Server 用に変更しま

す。

データベース作成コマンドを登録

利用するデータベースが sqlite3 などの場合、rake db:create コマンドを利用して、デー

タベース設定ファイルで指定したデータベースの作成が可能です。しかし、 SQL Server 用

の activerecord-sqlserver-adapter は、この機能を持ちません。tds_setup を実行する

と、lib\tasks\createdb.rake という名称のデータベース作成ファイルが作成されます。

ファイルの改行コードを CRLF39 に変更

メモ帳を利用して編集作業ができるように、Rails が生成したファイルの改行コードを

CRLF に変更します。

以下のようにカレントディレクトリを hello へ移動してから、データベース設定ファイルをメ

モ帳で開いてみましょう。

cd hello

39 キャリッジリターン + ラインフィードで、以降は CRLF と表記します。


34

notepad config\database.yml

メモ帳で開いた database.yml には、以下のように SQL Server 用のテンプレートが記述され

ています。

development:

adapter: sqlserver

database: developmentdb

username: sa

password: hidden

dataserver: localhost\SQLEXPRESS

pool: 5

timeout: 5000

……

このうち、変更が必要なのは以下の項目です。なお、上のリストでは development（開発環境）

のみを示しましたが、test（ユニットテスト環境）、production（本番環境）についても同様

です。

項目説明

database プロジェクトで利用するデータベース名に変更します。

username SQL Server の設定が Windows 認証であれば「ホスト名\ユーザ名」、SQL 認

証ならば「ユーザ名」を指定します。

password パスワードを指定します。

dataserver データベースを実行しているホスト名を指定します。SQL Server Express エ

ディション利用時は、既定の設定のようにインスタンス名（SQLEXPRESS）の

指定が必要です。また、tiny_tds が SQL Server を見つけることができるよう

に、SQL Server Browser を実行してください。

表 2 database.yml の設定項目

ここでは、database 名を以下のように設定します。

development

hellodb

test

hellodbtest


35

production

hellodb

また、username と password も適切なものを設定してください。既定の状態で SQL Server

をインストールしたのであれば、Windows 認証が有効となっているはずですので、『ホスト名

\ユーザ名』の形式で指定することになります。

database.yml の設定が完了したら、上書き保存してメモ帳を終了してください。

データベースの準備２

database.yml の設置が完了したら、SQL Server が tiny_tds から利用可能かどうか確認しま

す。

ここで確認するのは、接続先 SQL Server のインスタンスと SQL Server Browser の実行状

態と、接続プロトコルです。

スタートメニューの Microsoft SQL Server 2008 フォルダの構成ツールフォルダ（またはそ

れに対応するもの）から『SQL Server 構成マネージャー』を起動してください。

『SQL Server 構成マネージャー』が起動したら、最初に『SQL Server のサービス』を選択し

て、右のペインから SQL Server（SQLEXPRESS）と、SQL Server Browser の状態が実行

中かどうか確認してください。もし、停止状態であれば、実行します。

次に、『SQL Server ネットワークの構成』から、利用するインスタンスのプロトコルを選択し、

右のペインから『TCP/IP』の状態を確認します。tiny_tds（が利用する tdslib）は、SQL Server

との接続に TCP/IP を利用します。もし『TCP/IP』が無効になっていたら有効にしてください

（図 14）。


36

図 14 SQL Server 構成マネージャー

ここまで完了したら、SQL Server 構成マネージャーを終了します。

データベースの準備 3

データベースの準備作業の最後のステップは、アプリケーションが利用するデータベースの作成

です。このステップでは、database.yml に設定したデータベースを rake コマンドを利用し

て SQL Server へ作成します。

既にデータベース作成用の Rake タスク（db:create_db）は tds_setup コマンドによって用

意されているため、ここでの作業は、コマンドプロンプトに次のコマンドを打ち込むことです。

もしカレントディレクトリが hello でなければ、最初にカレントディレクトリへ移動します。

既に database.yml の編集時に移動している場合は、最初の cd コマンドは入力しないでくだ

さい。

cd hello

rake db:create_db

実行すると、コマンドプロンプトに以下のようなメッセージが表示されます。

rake aborted!

TinyTds::Error: Database 'hellodb' already exists. Choose a different database n

ame.: CREATE DATABASE [hellodb]


37

Tasks: TOP => db:create_db

(See full trace by running task with --trace)

ここで示した設定では、上のリストが示す通り、エラーとなります。これは database.yml で

development と production に同じ hellodb というデータベースを指定したことが原因で

す。そのためエラーメッセージも、'hellodb' already exists です。つまり、このエラーが表示

されることで、hellodb データベースが正しく作成されたことが確認できます。

もし、ここで設定したように、development と production で同じデータベースを利用する場

合には、必ず上記のエラーとなります。これを回避するには、development と production で

異なるデータベースを指定するか、または、lib\tasks\createdb.rake を編集して既に存在す

るデータベースは作成処理をスキップするように修正してください。

サーバーの起動

ここまでで、以下の作業が完了しました。

Rails プロジェクト（ここでは hello）の作成

hello が利用するデータベースの作成

それでは、Rails が Web アプリケーションとして実行されるかどうかを確認してみましょう。

最初にスタートメニューの NougakuDo から NougakuDo を選択します。

NougakuDo は管理者権限で実行されるため、現在ログインしているユーザが管理者

（Administrator）でなければ、ユーザアカウント制御のダイアログが表示されます。必要に応

じて管理者のパスワードを入力し（Windows 7 の場合、通常は管理者のパスワード入力は必要

ありませんが、Windows Server でユーザとしてログインしている場合には必要です）OK（も

しくは、はい）を選択してください。NougakuDo（ローンチャー）が起動します（図 15）。


38

図 15 NougakuDo（ローンチャー）

Note：直接 rackup や rails server コマンドを実行する場合の注意

NougakuDo を利用しなくても、rackup -s Ennou や rails server Ennou で ennou をサー

バーとして起動することは可能です。

しかし、この場合、管理者権限でログインしていないとアクセス違反となります（リスト）。こ

れは Http.sys にアクセスするために管理者権限が必要だからです。

C:\Users\devl\AppData\Roaming\hello>rails server Ennou

=> Booting Ennou

=> Rails 3.1.0 application starting in development on http://0.0.0.0:3000

=> Call with -d to detach

=> Ctrl-C to shutdown server

Exiting

C:/Users/devl/AppData/Roaming/NougakuDo/lib/ruby/vendor_ruby/1.9.1/rack/han

dler

/ennou.rb:37:in `add': unknown error - call HttpAddUrlToUrlGroup for http://+:30

00/hello/ (5) (SystemCallError)

（略）


39

NougakuDo を使った起動および、NougakuDo を利用して作成した起動バッチファイルには

管理者権限への昇格処理が含まれているため、開発者としてログインしていてもサーバーを起動

できます。

『参照』ボタンをクリックして APPDATA ディレクトリの hello\config.ru を選択してくださ

い。

config.ru は、Rails が利用する Web サーバーとアプリケーションのインターフェイスを制御

する Rack というコンポーネントの構成ファイルです。このファイルは既定でプロジェクトデ

ィレクトリの直下に作成されます。

正しく config.ru を読み込むと、NougakuDo の表示は図 16 のように変わります。図 16 で

は、ユーザ名として筆者（arton）のものが示されています。

図 16 config.ru を読み込んだ NougakuDo

選択項目はそれぞれ次の意味を持ちます。

選択項目説明

Directory と表示され

たドロップダウンリス

サブディレクトリモードと仮想ホストモードの指定40。

モードについては後述します。「Host」を選択すると右側に仮想ホ

40 この 2 つの用語は、本ホワイトペーパーで導入したものです。


40

トスト名を入力するためのインプットボックスが表示されます。ディレ

クトリ（既定値）を選択した場合、アプリケーション名がそのままデ

ィレクトリ名として利用されます。

Environment development、production の切り替えを行います。

なお、選択項目に test が含まれますが、test はユニットテスト用

なので通常は選択しません。

set debugging flags Ruby をデバッグモードで実行するときにチェックします。コマンド

ラインで –d を指定することと同等です。

set warning flags Ruby の警告メッセージを有効にするときにチェックします。コマン

ドラインで –w を指定することと同等です。

index このアプリケーションのインデックスページへのリンクです。

# of processes 同時に起動するサービスプロセス数を指定します。なお、2 以上を

指定した場合、実際に起動されるプロセスは制御プロセスが加わるた

め、ここで指定した数より 1 多くなります。

Launch 指定したパラメータで Rails アプリケーションを実行します。

Save config 設定内容を config.ru へ保存します。また、プロジェクトディレク

トリにプロジェクト名と同名のバッチファイルを作成します。このバ

ッチファイルを利用することで、NougakuDo を実行しなくても、

設定内容で Rails を起動できます。

表 3 NougakuDo の選択項目

それでは、Launch をクリックしてアプリケーションを実行してみましょう。

Launch をクリックするとコマンドプロンプトが 1 つ開きます。このコマンドプロンプトはす

べてのプロセスが共通でログを出力するのに利用します。また、アプリケーションを終了するに

は、このコマンドプロンプトに対して Ctrl-C 41を入力します。

Rails の起動が完了するには数 10 秒が必要です。この間、コマンドプロンプトには何も出力さ

れません。

起動が完了すると、Ennou のメッセージが表示されます（図 17）。

41 Ctrl キーと C キーを同時に押すことを意味します。


41

図 17 Ennou が起動したメッセージ

Ennou のメッセージには「http://+:80/hello」という URI が含まれます。これが、Ennou が

Http.sys に対して指定したこのプロセス用の URI となります。

つまり、Http.sys は、+（ホスト名を問わない）ポート 80 のパスの先頭が hello で始まるリ

クエストをこのプロセスに対して通知します。

では、ブラウザーのアドレスバーに、http://127.0.0.1/hello/ と入力して既定のページを表示

してみましょう（図 18）。ここで注意が必要なのは、URI 最後の「/」が必須だという点です。

最後の「/」を省略すると『About your application’s environment』クリック時に正しく URI

が設定されないため、環境が表示できなくなります。


42

図 18 hello アプリケーションの既定のページ

Note：サブディレクトリモードの index.html 表示

他の環境で Rails の index.html を見ていると、図 18 の index.html には何かが欠けている

ことに気づかれると思います。Rails のロゴのグラフィックがありません。

これは index.html の style に Rails のロゴの URI が /assets/rails.png とハードコード

されているのが原因です。 URI の先頭が / で始まっているため、ブラウザーは

http://127.0.0.1/assets/rails.png という URI を Web サーバー（Http.sys）にリクエスト

します。ところが、Ennou が Http.sys に対して登録した URI は、http://+:80/hello であ

って、http://+:80/assets ではありません。このため、rails.png に対するリクエストは捨て

られてしまうのです。

同様なことが、本文で触れた『About your application’s environment』のクリックと URI 末

尾の / の関係でも発生します。

『About your application’s environment』の URI は、rails/info/properties と記述されて

います。

もし、最初のリクエストが http://127.0.0.1/hello/ であれば、ブラウザーは現在のページの

ディレクトリを /hello と認識し、ページのファイル名は省略されたものとみなします。このた

め、『About……』をクリックすると、現在のディレクトリとして認識している hello に

rails/info/properties を追加して http://127.0.0.1/hello/rails/info/properties をリクエス


43

トします。

ところが、最初のリクエストを http://127.0.0.1/helllo とすると、ブラウザーはルートディ

レクトリ直下の hello というファイルを表示していると認識してしまいます。すると、

『About……』をクリックすると現在のディレクトリとして認識しているルート（/）に rails 以

下を追加した http://127.0.0.1/rails/info/properties という URI をリクエストしてしま

います。この URI は Ennou が登録した http://+:80/hello とは異なるため、やはり捨てら

れてしまうことになるのです。

Ruby on Rails は、一応は、相対パスを利用した運用も考慮されています。実際、ほとんどの

処理が、環境変数 RAILS_RELATIVE_URL_ROOT で指定したパスに対する相対アクセスとし

て URI を作成します。しかし、時々、この例のように絶対パスをハードコードしていることが

あるため、注意が必要です。

なお、NougakuDo でサブディレクトリモードを選択した場合、起動時や保存時に

config\environment.rb に RAILS_RELATIVE_URL_ROOT 環境変数を自動的に設定しま

す。

index.html の標示が確認できたら、Rails を実行しているコマンドプロンプトに Ctrl-C を入

力して終了してください。

アプリケーションの作成

前項で標示した index.html は静的コンテンツでした。このファイルはプロジェクトの public

ディレクトリに配置されています。

それでは次に、簡単なデータベースを利用するアプリケーション処理を組み込んでみましょう。

ここでは単純にするために、Rails の Scaffold を利用して、ユーザが入力したあいさつを保存

して一覧表示するだけの簡単なアプリケーションを作成します。

最初に、既定のインデックスページを置き換える新しいインデックスページを作ります。新しい

インデックスページは、RailsGuides の Getting Started42 に合わせて home/index としま

しょう。

コマンドプロンプトのカレントディレクトリが hello であることを確認してから、rails

generate コマンドを入力します。

rails generate controller home index

42 http://guides.rubyonrails.org/getting_started.html

http://guides.rubyonrails.org/getting_started.html


44

以下のようなメッセージが出力されます。

create app/controllers/home_controller.rb

route get "home/index"

invoke erb

create app/views/home

（略）

上記入力によって rails generate コマンドが、home コントローラの index アクションを作

成します。

次に、URI 省略時（http://127.0.0.1/hello という入力）に、既定の index.html ではなく、

ここで作成した home コントローラの index アクションに制御が渡るように、

config\routes.rb を編集します。

ただ、そのままメモ帳で開くと、rails generate コマンドが追加した行の改行コードが CRLF

ではないため表示が崩れ、保存すると異常な改行状態となってしまいます。

これを避けるため、editable コマンドを実行します。

コマンドプロンプトへ

editable .

と入力してください。これにより、メモ帳で正しく編集できるようになります。

editable は、引数で指定したディレクトリ下のソースファイルやパラメータファイルの改行を

CRLF に揃える NougakuDo が提供するコマンドです。Rails によって新たなファイルが追加

されるつど実行しても問題ないように考慮されているので、必要に応じて実行してください。ち

なみに最初に実行した tds_setup コマンドも内部では editable を利用しています43。

それでは、コマンドプロンプトに対して以下を入力して、メモ帳で routes.rb を開きましょう。

notepad config\routes.rb

メモ帳が起動したら、コメントの

# root :to => 'welcome#index'

という行を

root :to => 'home#index'

に修正して、ルートにアクセスされたら home コントローラの index アクションを実行する

43 editable の本来の目的は config.ru や database.yml をメモ帳で簡便に編集することです。ソースファイルの編

集にはできるだけプログラミングをサポートする機能を持つエディターを利用してください。


45

ようにします。

修正が完了したら、上書き保存してメモ帳を終了します。

ここまでの作業でアプリケーション専用のインデックスページとインデックスページへの

routes.rb の設定ができたので、Rails が既定で用意した index.html は不要となりました。

最初に

del public\index.html

をコマンドプロンプトに入力して、index.html ファイルを削除しましょう。そのまま残してお

くと、routes.rb に対する設定より優先されるからです。

再度 NougakuDo から Web サーバーのプロセスを起動して、http://127.0.0.1/hello （今

度はページから相対ディレクトリ指定のリンクが張られているわけではないので、末尾の「/」

を入力する必要はありません）にアクセスすると、ブラウザーには以下のテキストが表示されま

す44。

Home#index

Find me in app/views/home/index.html.erb

これは、rails generate が生成した view の既定のテキストです。この内容を変えるには、表

示されている通りに、app\views\home\index.html.erb を編集します。

index.html.erb を編集する前に、そのページへのリンクを張る前提で、データベースをアクセ

スするページを作っておきましょう。

ここでは、hello という名前のアプリケーションにふさわしく、名前とあいさつ文を投稿できる

アプリケーションとします。

最初に rails generate コマンドで、scaffold（アプリケーションの骨組み）を作成しましょう。

コマンドプロンプトへ次のように入力します。

rails generate scaffold Greeting name:string comment:text

上記の入力で、hello に対して name と comment の 2 つのカラムを持つ greetings テー

ブル（を作成するタスク）と、それに対する CRUD45 処理を行うモデル（Greeting クラス）、

コントローラ（GreetingsController クラス）、ビューが追加されます。この様子は、入力後の

メッセージで確認できます。

invoke active_record

44 前回ローンチした Web サーバーのプロセスが残っていると、Http.sys に対する同一 URI の登録で競合するため、

後から起動した Web サーバーのコマンドプロンプトはエラーとなって自動的にクローズされます。

45 Create、Read、Update、Delete


46

create db/migrate/20111002121256_create_greetings.rb

create app/models/greeting.rb

invoke test_unit

（略）

それでは、追加されたタスクを実行して greetings テーブルを作成しましょう。

追加されたデータベース用のタスクを実行するには、rake db:migrate コマンドを利用します。

コマンドプロンプトに以下を入力します。

rake db:migrate

以下のようにメッセージが表示されて、テーブルが作成されます。

== CreateGreetings: migrating ================================

-- create_table(:greetings)

-> 0.0150s

== CreateGreetings: migrated (0.0170s) ==========================

ここまで完了したら、home コントローラの index アクションのビューを編集して、今作成し

た greetings コントローラのアクションを呼び出すように変更します。

メモ帳を利用して（もし、今作成した greetings 関連のファイルをメモ帳で参照するのであれ

ば、 editable を再実行してください）、ビューファイルを開きましょう。コマンドプロンプ

トへは以下を入力します。

notepad app\views\home\index.html.erb

メモ帳が起動したら、以下のように内容を変更して上書き保存してください。この時、『名前を

付けて保存』を選択し、『ファイルの種類』を「すべてのファイル」、『文字コード』を「UTF-8」

に設定してください（図 19）。

<h1>ようこそ！</h1>

<%= link_to "一言どうぞ", greetings_path %>


47

図 19 メモ帳で文字コードを UTF-8 にする

link_to メソッドに対して greetings_path を与えることで、先ほど追加した

GreetingsController に対するリンクが生成されます。

保存したら、ブラウザーで http://127.0.0.1/hello → 「一言どうぞ」の順にアクセスして、

メッセージを追加、削除、更新、参照などができることを確認してみましょう。

バッチによるサーバー起動

NougakuDo の「save config」をクリックすると、各アプリケーションのルートディレクトリ

へアプリケーションと同名のバッチファイル（拡張子 bat）が作成されます。

このバッチファイルを実行することで

PATH 環境変数の設定

管理者権限への昇格

指定したプロセス数、環境、モードでの Web サーバーの起動

が行えます。

production モードでの実行

Rails の開発は主として development モードで行いますが、実運用では production モード

を利用します。


48

development と production の差は、 config\environments\development.rb と

config\environments\production.rb のいずれの初期化ファイルを読み込むかです。しかしそ

の動作は大きく異なります。特に Rails 3.1 から導入されたアセットパイプラインによってア

セット（javascript や CSS などの静的ファイル）の処理が大きく変わります。具体的には、

アセットを事前コンパイルすることで、JavaScript ファイルの単一ファイルへの圧縮などが行

われます。この効果は絶大です。

また、production モードと development モードの相違点には、ファイルの更新に対する追随

があります。production モードで実行しているときに、プログラムや構成ファイルを変更した

場合は、必ず、現在のサーバー実行を停止し、Web アプリケーションを再起動してください。

アセットの事前コンパイル

Rails のアセットパイプラインを利用すると、JavaScript、CSS などをあらかじめ一本化した

り、圧縮したりすることで、クライアントへの送信効率が向上します。また、サーバーの

JavaScript や CSS が更新された場合のブラウザーのキャッシュ無効化についても、それなり

の効果を持ちます。

アセットを事前コンパイルするには、コマンドプロンプトで rake assets::precompile コマン

ドを実行します。

rake assets:precompile

実行すると以下のようにディレクトリ生成メッセージが表示され、app\assets のファイルが既

定で public\assets ディレクトリへ配備されます。

mkdir -p C:/Users/ユーザ名/AppData/Roaming/アプリケーション名/public/assets

mkdir -p C:/Users/ユーザ名/AppData/Roaming/アプリケーション名/public/assets

……

production モードでの実行

事前コンパイルが完了したら、NougakuDo の Environment ドロップダウンリストを

development から production へ変えて Rails を起動してみましょう。もし既にプロセスを

起動している場合はコマンドプロンプトへ Ctrl-C を打ち込んで終了してから、Launch ボタン

をクリックしてください。


49

なお、Rails のバージョンによってはコマンドプロンプトに sass（CSS コンパイラ）のスレッ

ド安全性に関する警告が出力されます。

この場合は、プロジェクトのルートディレクトの Gemfils に

gem "sass", :require => 'sass'

を追記してください。

また、キャッシュ対象ではないページに対してキャッシュミスのメッセージが出力されます

（2011 年 10 月現在）。

例）cache: [GET /hello] miss

このメッセージは無害なので無視しても問題ありません。

まとめ

NougakuDo をインストールすることで、あとは SQL Server（Express Edition）を用意する

だけで、x64 版 Windows ですぐに Ruby on Rails 開発を開始できます。

作業項目作業内容

Ruby、Rails を実行できるコマ

ンドプロプトを開く

スタートメニューの NougakuDo から prompt を実行。

既定のデータベースを sqlite3

から sqlserver へ変更

tds_setup を実行してから database.yml を編集。

rake db:create_db1 でデータベースを作成。

ファイルをメモ帳で編集 editable を実行して改行コードを修正。

Web アプリケーションを実行スタートメニューの NougakuDo から NougakuDo を実

行。

config.ru を読み込んで、Launch ボタンをクリック。

config.ru を読み込んで save config を実行後、作成さ

れたバッチファイルを実行。

production モードでの実行 rake assets:precompile を実行。

表 4 Rails アプリケーションの開発

運用時の選択

Windows で Rails アプリケーションを実行する場合、仮想ホストで実行するか、サブディレ

クトリで実行するかについて、事前に検討しておく必要があります。

最初にそれぞれの得失を表 5 に示します。

モード可否説明


50

仮想ホスト ○ Rails の既定の動作なのでリンク周りで問題が出ることはない

× アプリケーション毎にホスト名が必要

サブディレクトリ ○ 同一ホストの IIS や他の Rails アプリケーションとクロスドメ

イン制約にかからずに連携可能

× Gem によってはサブディレクトリに対応していないものがある

表 5 モードにおけるメリットとデメリット

仮想ホストでの運用

Rails は、個々の Rails アプリケーションを異なるホストのルートディレクトリに配備する運

用を想定して開発されています。このため複数の Rails アプリケーションを 1 台のホスト

（Web ファームの場合も実質は 1 台と考えます）で実行する場合に、仮想ホスト名が必要と

なります。

仮想ホスト名は、仮想とついていることからおわかりにように、マルチホーム(複数のネットワ

ークカードなどを持つことで、1 つのノードが複数の IP アドレスを持つ）とは異なり、1 つ

の IP アドレスに対して複数のホスト名を割り当てたものです。

IIS が仮想ホストをサポートしたのは比較的最近のことなので、もう少し噛み砕いて説明しまし

ょう。

HTTP のリクエストヘッダーには Host という変数があります。ブラウザーは、たとえば

http://foo.example.com/a/b という URI に対して表 6 のようにリクエストを組み立てます。

項目リクエストの組み立て

通信の相手 foo.example.com に相当する IP アドレス

URI /a/b

Host（ヘッダー変数） foo.example.com

表 6 http://foo.example.com/a/b に対するリクエスト

つまり、URI に記述されたホスト名は実際のリクエストを送信する時点では名前解決をした結

果の IP アドレスに置き換えられるため、元々の URI に含まれていたホスト名はヘッダー変数

に格納して送られます。

同様に、http://bar.example.com/a/b という URI に対するリクエストは表 7 となります。

項目リクエストの組み立て

通信の相手 bar.example.com に相当する IP アドレス

URI /a/b

Host（ヘッダー変数） bar.example.com


51

表 7 http://bar.example.com/a/b に対するリクエスト

ここで、foo.example.com と bar.example.com の 2 つのホストが同一 IP アドレスを持つ

場合、この 2 つのホストはそれぞれ仮想ホストです。

Http.sys を利用した場合、Http.sys はこれら 2 つのリクエストを受け付けると、Host 変数

を参照して、foo.example.com と bar.example.com を登録したプロセスに対してリクエス

トを通知します。

Ennou は、rackup コマンドと config.ru を通じて、自分が利用する URI を取得し、それを

Http.sys に登録します。

サブディレクトリモードで、a というアプリケーションを実行する場合、Ennou は Http.sys

に対して次の URI を登録します。

http://+:80/a

ここで、「+」はワイルドカードで、ホスト名を問わないという意味です。

この場合、Http.sys は上記の 2 つのリクエストを共に Ennou に通知します。これは、ディ

レクトリ名の /a が一致するからです。

それに対して、rackup の –o オプションを利用して以下のように起動すると、Ennou は

Http.sys に対してホスト名を指定して登録します。

rackup -s Ennou -o foo.example.com

上記のコマンドが実行された場合、Ennou は、http://foo.example.com:80/ という URI を

Http.sys へ登録します。

この場合、Http.sys は上記の 2 つのリクエストについて、最初のリクエスト（Host 変数に

foo.example.com が入っているもの）は Ennou へ通知しますが、後者についてはあて先不明

でエラー応答するか、または、他に http://+:80/ というワイルドカードを登録しているプロセ

スがあればそちらへ通知します。

なお、NougakuDo で仮想ホストを利用する場合、NougakuDo で『Directory』と表示されて

いるドロップダウンリストを『Host』に変更します。『Host』と変更すると出現するテキスト

ボックスに仮想ホスト名を入力すると、NougakuDo の内部では、rackup コマンドの –o オ

プションとして入力された仮想ホスト名を利用します。

Web アプリケーション側から見た仮想ホストのメリットは、URI の組み立て時に常にルートか

ら記述できる（相対ディレクトリを意識する必要がほとんどない）ことと、複数のアプリケーシ

ョンを個別に動作させたい場合に単一ノード上で異なるドメインを簡単に作れることです。


52

既に説明したように Rails は仮想ホストを利用して運用されることを前提としています。この

場合、ファイルシステム上のディレクトリ、ファイルなどは次のように解釈されます。

図 20 仮想ホストモードにおける

Rails アプリケーションのファイルシステム構造

仮想ホストを利用する場合の問題点は、同一ノードで動作する複数のアプリケーションがクライ

アントを通じてお互いに連携したい場合であっても、クロスドメイン制約にかかることです。ド

メイン管理でホスト名単位に課金が行われる場合はコストアップ要因ともなります。

また、Azure をシンプルに利用しようとすると、ロードバランサが実際に動作しているノード

のホスト名でアクセスしてくるため、元のリクエストに含まれていたホスト名が失われ、Web

アプリケーションが Http.sys からの通知を受け取れなくなるという問題もあります（図 21）。

ただし、この問題は、パート 3 で説明する NougakuDoCompanion を利用することで解決で

きます。


53

図 21 失われるホスト名

サブディレクトリでの運用

サブディレクトリモードは、NougakuDo が、Rails のアプリケーション名（rails new の引数

で与えた名前）を URI のルート直下のディレクトリ名として Http.sys に登録する方法です。

この場合、Rails アプリケーションは、同一ノードの IIS などが同時に実行している Web サ

イトの兄弟として URI に表現されます。

ホスト名サブディレクトリ説明

http://ホスト名 / IIS の既定のサイト

/aspnet-app1 ASP.NET アプリケーション 1

/aspnet-app2 ASP.NET アプリケーション 2

/WCFService Web サービス

/RailsApp1 Rails アプリケーション

表 8 サブディレクトリの URL 表現

この運用方法の利点のひとつは、アプリケーションの置き換えがスムーズにできることです。た

とえば、最初は Rails で実装しておき、後から ASP.NET によって置き換えるといった場合に、

IIS の運用を大きく変えずに済むといったことが利点となります。逆に、元々 CGI や ASP で

運用していた古いアプリケーションを Rails で置き換えるといった場合も URI そのものは変

えずに済ませられます。特に検索ランキングなどで該当の URI が上位に来ている場合には、ホ

スト名を変えることは避けられるに越したことはありません。

また、ホスト名が同じということは、HTML5 の SessionStorage が共有できることや、クロ

スドメイン制約にかかることなく Ajax を利用できることを意味します。これによって、 .NET

Framework で開発した Web アプリケーションや Web サービスと Rails で開発した Web

アプリケーションを Ajax で連携するといった設計を無理なく実装できます。


54

したがって、サブディレクトリを利用することで、Windows サーバーのメリットが最大に生か

せます。

サブディレクトリを利用する場合の問題点は、それが Rails の既定の動作ではないことです。

そのため、Rails 用プラグインによっては、サブディレクトリを利用した運用をそもそも想定せ

ずに開発されている可能性もあります。したがってプラグインを利用することを予定している場

合には、利用したいプラグインがサブディレクトリで動作するか、あるいは動作しない場合は自

力で修正することができるか、といった調査が必要です。

参考までにサブディレクトリを利用した場合、ファイルシステム上のディレクトリ、ファイルな

どは次のように解釈されます。

図 22 サブディレクトリモードにおける

Rails アプリケーションのファイルシステム構造4647

まとめ

Rails アプリケーションの運用には、仮想ホストの利用か、サブディレクトリの利用かという選

択肢があります。

仮想ホスト Rails の既定の運用方法。Rails のアプリケーション単位に異なるホスト

名を割り当てる。

46 NougakuDo が RAILS_RELATIVE_URL_ROOT 環境変数を設定しています。

47 ただし、2011 年 10 月時点では public/asstes が /proj/assets に正しくマップされていません。app/assets は、

development モードにおいて対応されています。


55

サブディレクトリ環境変数 RAILS_RELATIVE_URL_ROOT の設定値を Web アプリケ

ーションのトップディレクトリとして扱う。同一サーバーで実行する IIS

アプリケーションと同一ドメイン名を利用できるため、アプリケーション

連携が容易。

表 9 仮想ホストとサブディレクトリの特徴

それぞれ得失がありますが、Windows サーバーの特徴である多様な選択可能性（たとえ

ば .NET Framework での C#、VB、F# の共存など）をフル活用するには、サブディレクト

リの利用をお勧めします。


56

Part3：Windows Azure への Ruby on Rails アプ

リケーションのデプロイと実行

パート 3 では、NougakuDo を利用して開発した Ruby on Rails アプリケーションを

Windows Azure へデプロイし、実行を管理する方法について説明します。これには、荒井さ

んが開発された NougakuDoCompanion を利用します。

パート 3 は、さらに 3 つのパートから構成されます。

最初のパートでは、NougakuDoCompanion のセットアップ方法について説明します。

次のパートでは、Windows Azure SDK を利用したデプロイと実行方法について説明します。

最後のパートでは、Windows Azure へデプロイするにあたって必要となる各種設定について

説明します。

NougakuDoCompanion の用意

NougakuDoCompanion について

NougakuDoCompanion48 は、荒井省三さんが開発されたオープンソース（Ms-PL）のプロジ

ェクトで、NougakuDo を利用して開発した Ruby on Rails アプリケーション（以降、

NougakuDo アプリケーションと記述します）を Windows Azure へデプロイすることを目的

としたのもです。

NougakuDoCompanion は、複数のプロジェクトから構成される Visual Studio 2010 ソリュ

ーションとして配布されています。ソリューションを実行するには Windows Azure Tools for

Microsoft Visual Studio をインストールした Visual Studio 2010 が必要です。

ソリューションの内訳は以下の通りです。

プロジェクト名説明

NougakudoSetupTool 単独で実行可能なツールで、NougakuDo アプリケーションからア

ップロードファイルを作成します。

このツールは、開発マシンで実行します。

NougakuDoCompanion アップロードされた配布ファイルを元に Azure パッケージを作成

します。

NougakuDoController Azure Web Role VM 内で NougakuDo アプリケーションの配備

48 http://nougakudo.codeplex.com/

http://nougakudo.codeplex.com/


57

と制御を行います。制御と指令は後述の AdminWeb から行われま

す。

NougakudoLauncher NougakuDoController からの指令に基づいて NougakuDo アプ

リケーションの起動と停止を行います。制御と指令は後述の

AdminWeb から行われます。

AdminWeb Azure Blob Storage へ配備した NougakuDo アプリケーション

の設定を変更するための Web アプリケーションです。

表 10 NougakuDoCompanion ソリューションの内訳

NougakuDoCompanion の実行環境

NougakuDoCompanion は次の 3 種類の実行環境を持ちます。

NougakuDo アプリケーション開発環境

NougakuDo アプリケーションを開発した環境で、NougakudoSetupTool を実行し

アップロードファイルを作成します。

この実行環境は、次の Azure 開発環境と同じコンピュータと共用できます。このため、

本書では NougakuDo アプリケーションを開発したコンピュータでそのまま

NougakuDoCompanion を実行する前提で説明します。異なるマシンを利用する場合

は、後述の NougakuDo アプリケーション関連の zip ファイルをコピーすることで対

応できます。

Azure 開発環境

Visual Studio 2010 と Windows Azure Tools for Microsoft Visual Studio をイン

ストールした Windows Azure のエミュレートが可能な環境です。

SQL Azure が利用できないことやネットワークが開発環境に閉じていることを除け

ば、ほぼ Windows Azure と同等な実行環境でアプリケーションの開発／テストが可

能です。

NougakuDoCompanion を使って Azure パッケージを作成したら、まずはこの環境

でテストしてください。

Windows Azure

本番環境は、ターゲットである Windows Azure となります。

Azure 開発環境の準備

最初に、Azure 開発環境を準備します。


58

2011 年 10 月版 NougakuDoCompanion は以下のソフトウェアを利用します。

Visual Studio 2010 Professional Edition49

Visual C# と Visual Web Developer をインストールしてあること

Windows Azure SDK 1.4（2011 年 3 月版）

Windows Azure Tools for Microsoft Visual Studio 2010 1.4 (2011 年 8 月)50

ASP.NET MVC 3 RTM Tools Update （AspNetMVC3ToolsUpdateSetup_en.exe）

Visual Studio 2010 日本語版を利用時には

AspNetMVC3ToolsUpdateSetup_JPN.exe も組み込んでください。

既に Visual Studio 2010 に上記のソフトウェアを組み込んでいる場合はそれを利用できます

が、バージョンが異なる場合はアンインストールしてから、上記バージョンのソフトウェアをイ

ンストールしてください。特に、Windows Azure Tools for Microsoft Visual Studio 2010 1.4

については、NougakuDoCompanion 内のプロジェクトが直接参照しているため、他のバージ

ョンで代替できません。

ダウンロードセンターの Windows Azure SDK および Windows Azure Tools for Microsoft

Visual Studio のページには、事前に行う IIS の設定や Hotfix の導入などについての記述が

あります。インストール時には、該当ページで指定された手順で環境を構築してください。

Note：NougakuDoCompanion と Windows Azure SDK について

2011 年 10 月版の NougakuDoCompanion は説明したように、Windows Azure SDK 1.4 と

Windows Azure Tools for Visual Studio 2010 1.4 に依存していますが、最終的には

Windows Azure SDK 1.5 と Windows Azure Tools for Visual Studio 2010 1.5 へ対応する

予定です。

Azure Storage Explorer のインストール

NougakudoSetupTool を使った作成したアップロードファイルを、Azure の Blob ストレージ

へアップロードするツールとして、Azure Storage Explorer をインストールします。

Azure Storage Explorer51 は、名前の通り、Azure Storage を対象とした Explorer で、オ

ープンソース（CDDL）でライセンスされています。

49 他のエディションも利用可能です。

50 ダウンロードセンターの Windows Azure SDK 1.4 と共に配布されている Windows Azure Tools for Microsoft

Visual Studio 2010 は 1.3 のため、利用できません。

51 http://azurestorageexplorer.codeplex.com/

http://azurestorageexplorer.codeplex.com/


59

Azure Storage Explorer はバイナリ（MSI）で配布されているので、それをダウンロード、イ

ンストールしてください。

NougakuDoCompanion ソリューションの読み込みとビルド

Windows Azure Tools for Microsoft Visual Studio 2010 のインストールが完了したら、

NougakuDoCompanion.sln を Visual Studio 2010 で開きます。

このとき、Windows Azure Tools のインストールができていない、あるいは正しいバージョン

をインストールしていないと、ソリューションの読み込みに失敗します。その場合は、現在イン

ストールされている Windows Azure Tools for Microsoft Visual Studio 2010 をアンインス

トールしてから、正しいバージョンをインストールしてください。

正常に開いた場合、ソリューションエクスプローラーには、

Documents

AdminWeb

NougakuDoCompanion

NougakuDoController

NougakudoLauncher

NougakudoSetupTool

の 5 つのプロジェクトと 1 つのフォルダが表示されます（図 23）。

図 23 ソリューションエクスプローラー

この状態で、構成マネージャーで Release を選択してから52（注）、ビルドメニューのソリュ

52 デバッグモードでの実行を予定しているとしても、AdminWeb が Release ビルドの NougakuDoController など

に依存しているため、Release ビルドは必須です。


60

ーションのビルド53を実行します。

環境が正しければ、未使用変数についてなどの警告が出ますが、失敗 0 、スキップ 0 でソリ

ューションのビルドが完成します。

NougakuDoCompanion を利用したデプロイ

それでは、実際に NougakuDoCompanion を利用して、パート 2 で作成した hello アプリケ

ーションをデプロイしてみましょう。ここでは、デプロイ先として、Azure SDK のエミュレー

タを利用します。

NougakuDoCompanion を利用したデプロイは以下の手順で行います。

1. NougakudoSetupTool を利用して、NougakuDo と NougakuDo アプリケーションそれ

ぞれの zip ファイルと構成ファイルを作成します。

2. NougakuDoCompanion をデプロイ／実行します。

3. Azure Storage Explorer を利用して NougakuDo（ランタイム）とアプリケーションを

Blob ストレージへアップロードします。

4. AdminWeb を操作して Rails アプリケーションを管理します。

NougakudoSetupTool の実行

NougakudoSetupTool は、NougakuDoCompanion の他のプロジェクトと異なり、単独で実

行することを前提としたツールです。

Visual Studio のソリューションエクスプローラから「デバッグ」→「新しいインスタンスを開

始」を選択して実行してもかまいませんが、NougakudoSetupTool プロジェクトディレクトリ

54の bin\release ディレクトリから他のディレクトリへコピーしたり、あるいはショートカット

を作成するなどして、NougakuDoCompanion とは別に実行できるようにしたほうが良いでし

ょう。

図 24 は、NougakudoSetupTool を起動すると表示されるウィンドウです。

53 ビルド方法の詳細については、Documents\Readme.txt を参照してください。

54 通常であれば、マイドキュメント\Visual Studio 2010\Projects\NougakuDoCompanion ディレクトリの下にあ

ります。


61

図 24 NougakudoSetupTool

ウィンドウ上のコントロールの意味は表 11 の通りです。

コントロールの意味

Action Create New 新規にアップロードファイルを作成する場合に選

択します。

Add or Update 作成済みアップロードファイルを更新したりアプ

リケーションを追加したりする場合に選択します。

Output folder and configuration info アップロードファイルの出力先ディレクトリを設

定します。

NougakuDo Runtime info インストールした NougakuDo のインストールデ

ィレクトリを設定します。

Application root info (folder info as

exsists configu.ru)

開発した Rails アプリケーションの情報を設定し

ます。Root location には、Rails アプリケーショ

ンのプロジェクトディレクトリ（アプリケーショ

ンと同名のディレクトリ）を設定します。

表 11 NougakudoSetupTool のコントロールの意味


62

アップロードファイルの新規作成

アップロードファイル作成の手順は以下の通りです。

1. Output folder and configuration info の右のボタン（... 表示のもの）をクリックして、

アップロードファイルの作成先ディレクトリを指定します。

Version には、NougakuDo のバージョンを x.y.z 形式で指定してください。これには、

NougakuDo の配布バージョン（コントロールパネルのアプリケーションのアンインスト

ール情報で表示されるもの）を指定できます。ただしここの指定は厳密なバージョン番号

が必要なわけではありません。Azure へアップロードした NougakuDo の識別のための情

報と考えてください。

2. NougakuDo Runtime info の Installed Folder 右のボタンをクリックして、NougakuDo

をインストールしたディレクトリを指定します。通常、 C:\Users\ ユーザ

ID\AppData\Roaming\nougakudo です。

Version はアプリケーションのバージョンを x.y.z 形式で指定します。ここで指定したバ

ージョンは Azure へアップロードしたアプリケーションの識別に利用されます。

3. Application root info (folder info as exsists configu.ru)の Root location 右のボタンを

クリックして、アプリケーションのルートディレクトリを指定します。パート 2 で作成し

た hello アプリケーションを指定する場合は、 C:\Users\ ユーザ

ID\AppData\Roaming\hello となります。

Version はアプリケーションのバージョンを x.y.z 形式で指定します。ここで指定し

たバージョンは Azure へアップロードしたアプリケーションの識別に利用されます。

# of processors には、実行に利用するプロセス数を設定します。この設定は利用す

る Azure の CPU 数に 2 をかけた数を設定することを基本として、後は実際にベン

チマークを取るなどして適切な値を設定してください。

Virtual Host は、NougakuDo の仮想ホストを利用する時に指定します。55

4. 設定が完了したら、Generate ボタンをクリックしてアップロードファイルを作成します。

作成と圧縮が行われます。処理完了ダイアログが表示されたら OK をクリックします（図

25）。このダイアログは OK をクリックしてから 20 秒後に非表示になります56。

55 複数のアプリケーションを指定した時は、 Virtual Host は一つだけしか指定できません。

56 圧縮は Windows シェルの機能を利用しているために、圧縮のダイアログが表示されますので、圧縮のダイアログ

が非表示になると圧縮が完了します。


63

図 25 Generate 後の完了ダイアログボックス

5. 処理完了ダイアログのクローズを確認してから、1. で設定したディレクトリを参照してく

ださい。

アプリケーション名 .zip （パート 2 で開発したアプリケーションであれば

hello.zip）

Rails アプリケーションの zip ファイル

NougakuDo.zip

NougakuDo（Ruby と Ruby on Rails）の zip ファイル

の 2 種類の zip ファイルと configuration.xml が作成されます。

この 2 つの zip ファイルと XML がアップロードファイルとなります。

アップロードファイルの更新とアプリケーションの追加

既存のアップロードファイルの更新や、アプリケーションを追加する場合の手順は以下の通りで

す。

1. Action の「Add or Update」をチェックします。

2. Output folder and configuration info の右のボタン（...表示のもの）をクリックして、

アップロードファイルの作成先ディレクトリを指定します。

3. Load Config ボタンをクリックして、2. で指定したディレクトリ上の configuration.xml

をロードします。

4. NougakuDo を更新するばあいは、Version と Installed Folder を設定します。

5. アプリケーションの実行設定を変える場合には、Application root info (folder info as

exsists configu.ru)の Exists ドロップダウンリストから更新対象のアプリケーションを

選択し、Version、Environment、# of processors、Virtual Host の各項目を必要に応じ

て変更します。

6. アプリケーションを追加する場合は、Root location に追加するアプリケーションのディレ

クトリを設定し、Version、Environment、# of processors、Virtual Host の各項目を設


64

定します。

7. Generate ボタンをクリックしてアップロードファイルを更新します。5. でアプリケーシ

ョンを追加した場合は、該当アプリケーション名の zip ファイルが、1. で指定したディレ

クトリに追加されます。

NougakuDoCompanion の実行

アップロードファイルが完成したら、Azure エミュレータで NougakuDoCompanion を実行

してみましょう。

NougakuDoCompanion プロジェクトには、本番用の ServiceConfiguration.Cloud.cscfg お

よび開発用の ServiceConfiguration.local.cscfg の 2 つのファイルが用意されています。

AdminWeb の管理者名とパスワードは、このファイルで設定します。

設定項目備考

管理者のユーザ ID AdminUserName 初期値は、admin

管理者のパスワード AdminPassword 初期値は、 password

表 12 AdminWeb の設定項目

Windows Azure で NougakuDo アプリケーションを運用する場合、AdminWeb を利用して

アプリケーションの実行を管理することになります。このため、AdminWeb のユーザ ID とパ

スワードの設定は厳密に行う必要があります。もちろん、Windows Azure に発行する場合は、

ServiceConfiguration.Cloud.cscfg に、Account や SharedKey の設定も必要となります。

設定項目説明

Account Blob ストレージのアカウント名を設定します。

SharedKey Blob ストレージのシェアードキー。

Container Blob ストレージで、アップロードファイルの監視を行うコンテンナ名。

Interval アップロードファイルの更新をチェックするために Blob ストレージを参照す

る間隔（単位は秒）。

VirtualHost Nougakudo アプリケーションで仮想ホストを使用する場合は、Windows

Azure のコンピュートサービスの DNS 名を設定します。

表 13 Windows Azure に発行する場合の設定項目

ここでは、エミュレータで実行するため、特に設定は必要ありません。

最初に、NougakuDoCompanion を Release モードでビルドします。

ビルドが成功したら、Visual Studio 2010 のデバッグメニューから「開始」を選択してくださ

い。

最初に Azure エミュレータが起動されます。このとき、すでに Azure エミュレータが実行さ


65

れていると、「SysTray already running」という警告ダイアログが表示されます。次に、既

定の Web ブラウザーが起動され、2 つのウィンドウ（またはタブ）が開きます。

1 つは、AdminWeb です（図 26）。

図 26 AdminWeb

もう 1 つは、デバッグ用に Visual Studio が自動的に起動するページですが、実際には該当す

るアプリケーションが存在しないため、必ずページ読み込みエラーとなります。

最後に、コマンドプロンプトが開き、NougakuDoController が開始されます（図 27）。

図 27 NougakuDoController

この時点で Blob ストレージに、ServiceConfiguration.*.cscfg の Container で指定したコン

テナ（既定では nougakudo）が無ければ作られます。もしあれば、NougakuDo ランタイム


66

や NougakuDo アプリケーションの読み込みと起動が行われます。

なお、ここでの実行はあくまでも Visual Studio のデバッグ実行なので、Web ブラウザーのい

ずれかのウィンドウをクローズすると終了します。

一度、Web ブラウザーのウィンドウをクローズして、Visual Studio でのデバッグ実行を終わ

らせましょう57。

Blob ストレージへのアップロード

スタートメニューの Neudesic フォルダを開いて、Azure Storage Explorer を起動します（図

28）。

図 28 Azure Storage Exploere

最初にダイアログの『Continue』をクリックします。次に、ツールバーの『Add Acount』をク

リックして表示された『Add Storage Account』ダイアログへ必要な情報を入力して Azure

Storage へ接続します。

ここでは、開発用ストレージ（Azure エミュレータ）へ接続するので、『Developer Storage』

をチェックしてください。完了したら『Add Storage Account』をクリックして Azure スト

レージへ接続します。

なお、アカウントを登録すると以降はツールバー左端のドロップダウンリストからアカウントを

選択することで、ストレージへ接続できるようになります。

57 デバッグ実行をしたままで、Blob ストレージに NougakuDo ランタイムや NougakuDo アプリケーションなどを

アップロードすることもできます。


67

開発用ストレージに接続すると、NougakuDoCompanion の実行によって作成された

nougakudo コンテナが Azure Storage Explorer のウィンドウの左ペインに表示されます。

マウスで選択してから、『Upload』ボタンをクリックして、アップロードファイル

（NougakuDo.zip、NougakuDo アプリケーション58、configuration.xml）を 1 ファイルず

つアップロード59してください。アップロードに成功するとウィンドウ下部に緑で『Upload

complete, 1 blob added』と表示されます（図 29）。なお、図 29 ではアップロードファイル

のみが表示されていますが、通常は NougakuDoCompanion を実行することで、ログファイ

ルなどが作成されています。

図 29 アップロードの完了

開発用 Blob ストレージエミュレータの問題で、NougakuDo.zip のようにサイズの大きなファ

イルはアップロードに失敗することがあります。失敗した場合は Azure Storage Explorer の

ウィンドウ下部にピンク色で『Upload failed, 0 blobs added, 1 error』と表示されます。成功

するまで何回かアップロードを実行してください。この時、アップロードに失敗した Blob ス

トレージ上のファイルを事前に削除する必要はありません。

NougakuDoCompanion の実行（2）

Blob ストレージへのアップロードが完了したら、NougakuDoCompanion を再度実行します。

58 ここでは hello.zip になります。

59 必ず最後に、configuration.xml をアップロードします。これは、NougakuDoController が configuration.xml を

使って NiugakuDo や NougakuDo アプリケーション情報を取得するからです。


68

ブラウザーのウィンドウ（またはタブ）が 2 つ開き、今度は NougakuDoController のコマ

ンドプロンプトに、以下のようにダウンロードの開始と UnZip メッセージが表示されます。

2011-10-13 01:42:37.875 INFO NougakudoController:Start.

2011-10-13 01:42:37.892 INFO NougakudoController:Initizalize Start.

2011-10-13 01:42:37.917 INFO Runtime:Start download configuration.xml.

2011-10-13 01:42:37.919 INFO Downloader:Download started for

configuration.xml in blob.

2011-10-13 01:42:38.571 INFO Downloader:Download completed for

configuration.xml in blob.

2011-10-13 01:42:38.589 INFO Runtime:Loaded configuration.xml.

2011-10-13 01:42:38.607 INFO Runtime:Found download applications request.

2011-10-13 01:42:38.607 INFO NougakudoController:Download Start.

2011-10-13 01:42:40.371 INFO Downloader:Download completed for

NougakuDo.zip

in blob.

2011-10-13 01:42:40.672 INFO Downloader:Download completed for hello.zip in

blob.

2011-10-13 01:42:40.673 INFO NougakudoController:Download completed.

2011-10-13 01:42:40.898 INFO Installer:UnZip Start= NougakuDo.

（略）

NougakuDoController は、定期的に Blob ストレージをチェックし、新しいバージョンの

Runtime（NougakuDo.zip）や NougakuDo アプリケーションを発見するとダウンロードと

伸張を実行します。伸張に成功すると、NougakudoLauncher を利用して NougakuDo アプ

リケーションを起動します60。

ここでは、Visual Studio を利用してデバッグモードで実行しているため、これらの情報はコマ

ンドプロンプトから得られますが、Windows Azure で実行する場合は、AdminWeb を利用し

て確認できます。

60 Ruby のコンソールウィンドウが表示されます。このコンソールを終了するには、NougakuDoController のウイ

ンドウで何かのキーを入力してください。


69

AdminWeb の利用

AdminWeb の URI は、http://ホスト名:8080/ です。

ログインするには、Admin タブをクリックするか、またはページ右上の「Login」をクリック

します。

ログインに利用するユーザ ID とパスワードは、既に説明したように、NougakuDoCompanion

プロジェクトの local （エミュレータ用）または Cloud （本番用）のいずれかの

ServiceConfiguration.*.cscfg に設定します。

エミュレータ実行時は、User name に「admin」、Password に「password」を入力します。

このとき、「Remember me ?」にチェックを入れておくと、次回以降はログインを省略でき

ます（図 30）。

図 30 AdminWeb へのログイン

Admin タブは、さらに

NougakuDo Runtime & Apps

Controller Logs

NougakuDo Status

Cleanup

の 4 つのタブから構成されます。

それぞれのタブは以下の情報を持ちます。


70

NougakuDo Runtime & Apps（図 31）

図 31 NougakuDo Runtime & Apps

現在展開されている NougakuDo と NougakuDo アプリケーションの情報です。こ

こに表示される Version は、NougakudoSetupTool で指定したものです。

ページ右下の「Update」をクリックすることで、画面に入力した内容で Blob ストレ

ージの configuration.xml を更新することができます。

Controller Logs（図 32）

図 32 Controller Logs

NougakuDoController が出力したログを表示します。


71

現在実行中のインスタンスのログのみが出力されるコマンドプロンプトと異なり、シス

テムが保持しているすべてのインスタンスのログが過去から順に表示されます61。

NougakuDo Status（図 33）

図 33 NougakuDo Status

Blob からダウンロードしたすべての NougakuDo アプリケーションのインスタンス

情報を表示します。また、このタブを利用して、現在有効な NougakuDo アプリケー

ションの停止、実行、再起動を行えます。これらの処理を実行するには、各インスタ

ンス情報右端のドロップダウンリストから実行する操作を選択し、ページ右下の

「Operation」をクリックします。処理が始まるとタブが自働的に「Controller Logs」

へ切り替わるので現在の状況を確認できます。

Cleanup（図 34）

図 34 Cleanup

configuration.xml を空にすることで、現在のアプリケーション情報を初期化します。

configuration.xml を空にするには、「Cleanup」ボタンをクリックしてください。

Windows Azure へのデプロイと実行

Windows Azure で実行する場合も、基本はエミュレータで実行したことと同様となります。

ここでは、主な違いを説明します。

61 ログの表示順序は、日付の降順（新しいものが上）になります。


72

NougakuDo アプリケーションの修正

SQL Azure を利用する為に、アップロードファイルの作成前に config\database.yml の以

下の項目を修正します。

dataserver を「ホスト名.database.windows.net」に変更

azure: true を追加

hello アプリケーションの production 設定を例として示します。

（元の設定）

production:

adapter: sqlserver

database: hellodb

username: ユーザ ID

password: パスワード

dataserver: localhost\SQLEXPRESS

pool: 5

timeout: 5000

（SQL Azure 用の設定）

production:

adapter: sqlserver

database: hellodb

username: ユーザ ID ←SQL サーバー認証のログイン情報

password: パスワード

dataserver: ホスト名.database.windows.net ←修正

azure: true ←追加

pool: 5

timeout: 5000

この修正が完了したら、NougakudoSetupTool を利用してアップロードファイルを作成します。

そして、NougakuDoCompanion を Windows Azure に配備する前か、配備が完了してから

Blob ストレージにアップロードファイルをアップロードしてください。

Note：activerecord-sqlserver-adapter と SQL Azure について


73

SQL Server や SQL Azure と NougakuDo アプリケーションを接続するライブラリが、

activerecord-sqlserver-adapter となります。2011 年 10 月時点のライブラリのバージョン

が、NougakuDo 1.0.5 では「3.0.15」で、NougakuDo 1.1.7 では「3.1.1」です。3.0.15 は

Ruby on Rails 3.0.x へ対応しており、SQL Azure での動作も問題はありません。3.1.1 は

Ruby on Rails 3.1.x へ対応していますが、SQL Azure で動作させる場合において若干の問題

があります。具体的に説明すると、日付型の書式を取得するために「DBCC useroptions」コマ

ンドを使用しており、このコマンドを SQL Azure がサポートしていないことです。このため

次に示す応急処置のパッチコードを参考に sqlserver_adapter.rb ファイルを修正してくださ

い。

#NougakuDo/lib/ruby/gems/1.9.1/gems/activerecord-sqlserver-adapter-3.1.1

#ディレクトリにある以下の sqlserver_adapter.rb ファイルです。

#lib/active_record/connection_adapters/sqlserver_adapter.rb

434

435

436

437

434

435

436

437

438

439

440

441

-

+

+

+

+

+

def initialize_dateformatter

@database_dateformat = user_options['dateformat']

if @sqlserver_azure

@database_dateformat = 'mdy'

else

@database_dateformat = user_options['dateformat']

end

a, b, c = @database_dateformat.each_char.to_a

[a,b,c].each { |f| f.upcase! if f == 'y' }

パッチコードの「-」は削除を表し、「+」は追加することに注意してください。

この問題を activerecord-sqlserver-adapter の開発チームへ報告済みであり、対処が完了し

たライブラリを NougakuDo の将来バージョンに含める予定です。

データベースの作成

初回実行時は、まだ SQL Azure 内にデータベースが作成されていません。このため、開発用 PC

のアプリケーションディレクトリで以下を実行します。

rake db:create_db62 を実行してデータベースを作成します

62 rake db:create_db コマンドを実行するか、Windows Azure 管理ポータルでデータベースを作成します。また、

SQL Azure のファイアーウォール設定に開発用 PC の IP アドレスを追加してから作業をしてください。


74

データベースが作成できたら、一度、rake db:migrate を実行してください。ただし初回実行

時はエラーとなります。これはマイグレーション管理用テーブル（schema_migrations）にイ

ンデックスが作れないからです。

以下のコマンドを SQL Server Managemnt Studio などで実行してクラスタインデックスを

作成してください。

CREATE CLUSTERED INDEX [idx_schema_migrations_version] ON

[schema_migrations] ([version])

インデックスが作成できたら、あらためて rake db:migrate を実行してデータベースを用意し

ます。

Note：NougakuDo アプリケーションの本番運用について

SQL Azure を使った NougakuDo アプリケーションを本番運用する前に、以下のストアドプ

ロシージャを作成してください。

sp_MSforeach_worker

sp_MSforeachtable

これは activerecord-sqlserver-adapter が、このストアドプロシージャ63を使用しているため

です。

NougakuDoCompanion の配備

ServiceConfiguration.Cloud.cscfg の設定

AdminWeb の管理者 ID とパスワード、Blob ストレージの情報などを設定します。

NougakuDoCompanion を Windows Azure へデプロイ

ソリューションエクスプローラーで NougakuDoCompanion プロジェクトを選択

し、右クリック『発行』を選択して Windows Azure へ発行します64。

63 https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/wiki/Using-Azure の this code にある

リンク先からダウンロードしてください。

64 あるいは、Package を選択してアプリケーションパッケージ（cspkg）ファイルを作成してから、Windows Azure

管理ポータルを使ってアプリケーションパッケージを配置します。

https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/wiki/Using-Azure


75

まとめ

NougakuDoCompanion を利用することで、NougakuDo アプリケーションを Windows

Azure で比較的容易に配備、実行、管理を行えます。

NougakudoSetupTool を利用したアップロードファイルの作成

NougakuDoController による Blob ストレージの監視とダウンロードおよび自動展

開と起動

AdminWeb アプリケーションを利用したログの照会、アプリケーションの起動、停止、

再起動

また、NongakuDoCompanion 自体が、IIS で実行される ASP.NET Web アプリケーション

（AdminWeb）と Rails アプリケーションの同一ノードでの共存のデモとなっているという点

についても着目すべきでしょう。これが可能なのは、パート 1 で説明したように、Windows が

提供する Http.sys を使用しているからです。

このホワイトペーパーで説明したように、Windows Azure は、Windows プロパーの

ASP.NET Web アプリケーションは当然として、Ruby on Rails などのオープンソースのソフ

トウェアも強力にサポートするプラットフォームです。

みなさんのビジネスの発展に、Windows Azure のパワーをぜひとも活用してください。

rubyon windowsazure

Technology