Rubyon windowsazure

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

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

1


データベースの準備１ ................................................................................. 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

2


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/

3


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

4


前の節で 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/）

5


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

6


図 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

7


入とは別に、セキュリティパッチやバージョンアップについて考慮しなければなりません。この
観点からは、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

8


本ホワイトペーパーで推奨するのは、（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

9


本ホワイトペーパーの構成
このホワイトペーパーは大きく 3 つのパートから構成されます。
最初のパートでは簡単に Ruby on Rails の特徴について説明します。次に Ruby on Rails と
Ruby の実行時の仕組みについて説明します。このパートで実行時の問題点と、それに対する解
決策について明らかにします。
次のパートでは、Windows Azure での実行を意識した Ruby on Rails の開発方法について説
明します。ここには簡単なチュートリアルを含みます。このパートの肝は、開発に利用するデー
14
タベースエンジンに SQL Server
（Express Edition）を最初から利用する点です。SQL Server
を利用することで、Azure 上では SQL Azure をほとんどそのまま効率よく利用できるからで
す。
最後のパートでは、開発した Ruby on Rails アプリケーションを Windows Azure にデプロ
イする方法について解説します。

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

10


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

11


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

12


Framework かという点と、開発した成果物がすべて編集可能なテキストファイルか、それとも
バイナリや基本的に編集不可の XML や IDE 17 用ソースファイルかどうかという点となりま
す（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 を使うべきかも知れません。

13


<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 の実装に端的に表れているの
が、既存のライブラリがあればそれを利用する、既にメタデータがあればそれを利用する、とい

14


う点です。これは、バグを入りにくくする（二重管理、三重管理といったものがバグの原因の１
つであることに異論がある方はいないでしょう）、記述量を少なくする、といった良い効果をも
たらします。しかし、その反面、最適化されていない状態で大量の情報を利用することになると
いう負の側面もあります。
まず 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 ア

15


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

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 と表記します。

16


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

現時点の Ruby は、JIT 21 を利用した VM コマンドの機械語への置き換えは行っていません。
このため、やろうと思えば VM 内でプログラムがアクセスする変数の競合の回避や他のスレッ
ドへの反映を処理できます。したがって、Ruby で記述されたプログラムの動作については並行
動作を実行することに特に設計上の問題があるわけではありません。
しかし、C で開発された拡張ライブラリについては、話が異なります。スレッドが並行して動
作すれば、同じメソッドを同時に複数のスレッドがアクセスできてしまいます。このため、スタ
ック上やスレッドローカルに確保していない変数は競合を回避するように考慮しなければなり
ません。しかし、Ruby は以前から C の拡張ライブラリについて、C レベルの関数呼び出し中
はスレッドの切り替えを行わない（行えない）ということを打ち出しています。このため、以前
のバージョン22用に作成された C 拡張ライブラリの互換性を維持するためには、拡張ライブラ
リを呼び出している間は他のスレッドへ制御を移すことはできません。そうでなければ拡張ライ
ブラリの中でさまざまな競合問題が発生してしまいます。

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

21
Just In Time コンパイラ
22
Ruby 1.8 までは Ruby は OS が用意したスレッドを利用せずに独自実装のスレッドを利用していました。

17


拡張ライブラリの呼び出し中はスレッドを切り替えられません。このような制御を行うためには、
現在実行中のスレッドを何らかの方法で他のスレッドと区別する必要があります。
Ruby がこのために利用するのが、GVL（グローバル VM ロック）または GIL（グローバルイ
ンタプリタロック）と呼ばれる、Windows のミューテックスに相当するオブジェクトです。
プロセス内のスレッドは GVL を共有し、GVL がシグナル状態となったスレッドのみが実行権
を握ります。つまり、あるスレッドが GVL を持っている（シグナル状態の）間は、他のスレッ
ドは一切動作できません。これによって、Ruby がプロセス内で同時に動作するスレッドをただ
1 つに制限しています。
ところが、前節で説明したように、Ruby はあるスレッドが IO を実行している間は他のスレ
ッドに制御を移せます。
これは Ruby の IO ライブラリが、スレッドセーフに作られているからです。このため、Ruby
プログラムの部分から Ruby の IO ライブラリ（ファイルやソケット）を呼び出した場合は、
IO 待機前に GVL を解放することが可能です（図 7）。

図 7 GVL と解除

現在、GVL 解除のための API については公開と周知が始まっています。このため、今後は拡
張ライブラリのマルチスレッド対応が進むことが考えられます。そのように準備が進めば、自然
の流れとしてスレッドの並行実行機能も実装されることになると考えられます。

18


ちなみに 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 アプリケーシ

19


ョンの場合は、クライアントからのリクエストを 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 キーを同時に押すことを意味します。

20


であれば 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

21


アントからのリクエスト待ちの間に他の既に受信済みのリクエストを処理できるように、GVL
の解除を行うライブラリが必要だということです。そうでなければ、リクエスト待ちになった時
点で既に受信したリクエストの処理が停止してしまうからです。Ennou を利用することで、こ
の問題は解決します。

22


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 を構成するホスト名のことです。

23


開発用 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）を利用して改行コードをキャリッジ
リターン＋ラインフィード（rn）28に変換してください。
 IDE について

27
http://www.microsoft.com/express
28
キャリッジリターン（CR)、ラインフィード（LF）

24


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 ディレクトリと表記します。

25


とし、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 のコマンド名。

26


 オフラインインストール可能（インターネット接続不可環境への配慮）
NougakuDo は単一の msi ファイルの中に最低限実行に必要なものをすべて同梱し、オフ
ラインまたはイントラネットで閉じている PC に対してインストールから実行までを可能
とします。
 バイナリ配布
コンパイルが必要なソフトウェアについてはあらかじめ最新の Visual C++ を利用してビ
ルド後に配布します。これにより開発 PC に追加のツールインストールを不要とします。

NougakuDo のインストール
NougakuDo は、筆者のドメインの http://www.artonx.org/data/nougakudo/ から配布して
います（図 8）。

図 8 NougakuDo のホームページ

NougakuDo のインストールは、上述のページから NougakuDo.msi をダウンロード（または
直接実行）してください（図 9）。

27


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

なお、NougakuDo.msi には署名を行っていないため、直接実行時には SmartScreen フィル
ターの警告（図 10）、ダウンロード後のインストール時には不明な発行元の警告が表示されま
す（図 11）。上記のサイトから直接ダウンロードした場合など、出元が明らかな場合は「実行」
をクリックしてインストールしてください。

28


図 10 SmartScreen フィルターの警告

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

インストール作業は、ライセンス表示（図 12）などのステップを踏みます。ただし、設定項目
は無いため、「Next」を数回クリックするだけで完了します。

図 12 NougakuDo のライセンス表示

29


NougakuDo インストーラはシステムに対して以下を実行します。
 現在のユーザの APPDATA ディレクトリへ nougakudo ディレクトリを作成し、パッケ
ージ内のディレクトリツリーとファイルを展開します。
APPDATA ディレクトリは、標準構成の Windows 7 であれば、C:Usersユーザ名
AppDataRoaming です。
 スタートメニューに NougakuDo フォルダを作成します。
NougakuDo フォルダには次の 3 つのショートカットが作成されます（図 13）。

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

 irb
Ruby の対話型実行環境です。
 NougakuDo
メニューから起動するアプリケーションとしての NougakuDo は、Ennou を利用し
て Rails アプリケーションの起動を制御するローンチャーです。NougakuDo を利用
すると、Rails アプリケーション起動用のバッチファイルも生成できます。
 Prompt
Ruby on Rails を利用した開発作業を行うためのコマンドラインプロンプトです。こ
れはユーザー／システムの環境変数を汚染するのではなく、環境変数を設定したコマ
ンドプロンプトを提供するというポリシーに基づきます。
 レジストリの HKEY_CLASS_ROOT 下に、ビット版 ActiveScriptRuby を登録します。
64
ActiveScriptRuby は、COM 経由で Ruby を操作するための COM サーバーです。
NougakuDo（パッケージ）は、NougakuDo（ローンチャ）の実装に ActiveScriptRuby を
利用します。
なお、ActiveScriptRuby の HKEY_CLASS_ROOT 登録は、NougakuDo を利用した開発
に利用するだけなので、完成した Rails アプリケーションを Azure へデプロイする時に
は実行されません。

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

30


してみましょう。
なお、本ホワイトペーパーの目的から、ここでは完全な Ruby on Rails 開発について説明する
わけではないことに注意してください。Ruby on Rails を使った Web アプリケーションの開
発（特に、Ruby on Rails 3.1）については、『Rails によるアジャイル Web アプリケーショ
ン開発（第 4 版）37』などの著作を参照してください。

コマンドプロンプトの実行
最初に、スタートメニューの NougakuDo フォルダから prompt を起動します。
すると、コマンドプロンプトが順番に 2 回開きます。このうち最初に開くコマンドプロンプト
は 2 番目に開くコマンドプロンプトの環境を設定するだけなのですぐに閉じます。
開発作業は、主として、ここで 2 番目に開いた（そしてそのまま残る）コマンドプロンプトに
対して行います。
インストールが正しく行われていれば、コマンドプロンプトのカレントディレクトリは、
APPDATA（通常、C:Usersユーザ名AppDataRomaing）です。

アプリケーションの新規作成
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
株式会社オーム社より刊行予定です。

31


ジェクトファイルを、カレントディレクトリ下に作成します。この場合、引数で 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/

32


ァイルを編集できるようにするために、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 用のテンプレートに変更
データベース設定ファイル（configdatabase.yml）の雛形を SQL Server 用に変更しま
す。
 データベース作成コマンドを登録
利用するデータベースが sqlite3 などの場合、rake db:create コマンドを利用して、デー
タベース設定ファイルで指定したデータベースの作成が可能です。しかし、 SQL Server 用
の activerecord-sqlserver-adapter は、この機能を持ちません。tds_setup を実行する
と、libtaskscreatedb.rake という名称のデータベース作成ファイルが作成されます。
 ファイルの改行コードを CRLF39 に変更
メモ帳を利用して編集作業ができるように、Rails が生成したファイルの改行コードを
CRLF に変更します。

以下のようにカレントディレクトリを hello へ移動してから、データベース設定ファイルをメ
モ帳で開いてみましょう。
cd hello

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

33


notepad configdatabase.yml

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

development:
adapter: sqlserver
database: developmentdb
username: sa
password: hidden
dataserver: localhostSQLEXPRESS
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

34


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）。

35


図 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]

36


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 で
異なるデータベースを指定するか、または、libtaskscreatedb.rake を編集して既に存在す
るデータベースは作成処理をスキップするように修正してください。

サーバーの起動
ここまでで、以下の作業が完了しました。
 Rails プロジェクト（ここでは hello）の作成
 hello が利用するデータベースの作成

それでは、Rails が Web アプリケーションとして実行されるかどうかを確認してみましょう。
最初にスタートメニューの NougakuDo から NougakuDo を選択します。
NougakuDo は管理者権限で実行されるため、現在ログインしているユーザが管理者
（Administrator）でなければ、ユーザアカウント制御のダイアログが表示されます。必要に応
じて管理者のパスワードを入力し（Windows 7 の場合、通常は管理者のパスワード入力は必要
ありませんが、Windows Server でユーザとしてログインしている場合には必要です）OK（も
しくは、はい）を選択してください。NougakuDo（ローンチャー）が起動します（図 15）。

37


図 15 NougakuDo（ローンチャー）

Note：直接 rackup や rails server コマンドを実行する場合の注意
NougakuDo を利用しなくても、rackup -s Ennou や rails server Ennou で ennou をサー
バーとして起動することは可能です。
しかし、この場合、管理者権限でログインしていないとアクセス違反となります（リスト）。こ
れは Http.sys にアクセスするために管理者権限が必要だからです。
C:UsersdevlAppDataRoaminghello>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)
（略）

38


NougakuDo を使った起動および、NougakuDo を利用して作成した起動バッチファイルには
管理者権限への昇格処理が含まれているため、開発者としてログインしていてもサーバーを起動
できます。

『参照』ボタンをクリックして APPDATA ディレクトリの helloconfig.ru を選択してくださ
い。
config.ru は、Rails が利用する Web サーバーとアプリケーションのインターフェイスを制御
する Rack というコンポーネントの構成ファイルです。このファイルは既定でプロジェクトデ
ィレクトリの直下に作成されます。
正しく config.ru を読み込むと、NougakuDo の表示は図 16 のように変わります。図 16 で
は、ユーザ名として筆者（arton）のものが示されています。

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

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

選択項目説明

Directory と表示されサブディレクトリモードと仮想ホストモードの指定40。
たドロップダウンリスモードについては後述します。「Host」を選択すると右側に仮想ホ

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

39


トスト名を入力するためのインプットボックスが表示されます。ディレ
クトリ（既定値）を選択した場合、アプリケーション名がそのままデ
ィレクトリ名として利用されます。

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 つ開きます。このコマンドプロンプトはす
べてのプロセスが共通でログを出力するのに利用します。また、アプリケーションを終了するに
41
は、このコマンドプロンプトに対して Ctrl-C を入力します。
Rails の起動が完了するには数 10 秒が必要です。この間、コマンドプロンプトには何も出力さ
れません。
起動が完了すると、Ennou のメッセージが表示されます（図 17）。

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

40


図 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
が設定されないため、環境が表示できなくなります。

41


図 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 をリクエス

42


トします。
ところが、最初のリクエストを 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 でサブディレクトリモードを選択した場合、起動時や保存時に
configenvironment.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

43


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

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 アクションに制御が渡るように、
configroutes.rb を編集します。
ただ、そのままメモ帳で開くと、rails generate コマンドが追加した行の改行コードが CRLF
ではないため表示が崩れ、保存すると異常な改行状態となってしまいます。
これを避けるため、editable コマンドを実行します。
コマンドプロンプトへ

editable .

と入力してください。これにより、メモ帳で正しく編集できるようになります。
editable は、引数で指定したディレクトリ下のソースファイルやパラメータファイルの改行を
CRLF に揃える NougakuDo が提供するコマンドです。Rails によって新たなファイルが追加
されるつど実行しても問題ないように考慮されているので、必要に応じて実行してください。ち
なみに最初に実行した tds_setup コマンドも内部では editable を利用しています43。

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

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

# root :to => 'welcome#index'
という行を

root :to => 'home#index'

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

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

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

44


ようにします。
修正が完了したら、上書き保存してメモ帳を終了します。
ここまでの作業でアプリケーション専用のインデックスページとインデックスページへの
routes.rb の設定ができたので、Rails が既定で用意した index.html は不要となりました。
最初に

del publicindex.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 の既定のテキストです。この内容を変えるには、表
示されている通りに、appviewshomeindex.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

45


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 appviewshomeindex.html.erb

メモ帳が起動したら、以下のように内容を変更して上書き保存してください。この時、『名前を
付けて保存』を選択し、『ファイルの種類』「すべてのファイル」『文字コード』「UTF-8」
を、を
に設定してください（図 19）。

<h1>ようこそ！</h1>
<%= link_to "一言どうぞ", greetings_path %>

46

Rubyon windowsazure

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Rubyon windowsazure

Ähnlich wie Rubyon windowsazure (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (8)

Rubyon windowsazure