あれとアレは混ぜるな危険

日々精進をしているふり

わんくま同盟 東京勉強会#46 フォローアップ その2

こんばんは、はるたまです。そろそろ部屋掃除しないとマズイよね。

わんくま同盟 東京勉強会#46 フォローアップ その2」ということで、いきなりですがJettyをWindows AzureのWorker Roleで動かしましょう。

セッションで紹介していた「Windows Azure Jetty Solution Accelerator」ですが、一次懇親会後の立ち話で


MSDN Code Galleryで公開しちゃってもいいんですかね?
砂金さん(マイクロソフト
いいんじゃないっすか。
荒井さん(マイクロソフト
あー、いいんじゃない。

ということで、MSDN Code Galleryのここから入手できます。

Windows Azure Jetty Solution Accelerator - Home

さて、今日はこれを使ってJettyを動かします。結構長編になります。

前準備

今回の主役、Windows Azure Jetty Solution Acceleratorはここからダウンロードできます。本体以外にjetty.xmlなるものがありますが、これも一緒にダウンロードして下さい。後で使います。

Windows Azure Jetty Solution Accelerator - Release: JettySolutionAccelerator

Jetty Solution Acceleratorと言うからには、JettyとJava(JRE)が必要になりますので事前に入手しておく必要があります。
Jettyはここからダウンロードできます。最新のものでもいいんですが、Stableなものを使うことをおすすめします。zipをダウンロードして、どこかに解凍しておいてください。
Eclipse Jetty - Downloads
JREについては、ローカルのマシンにインストールしておいてください。
http://www.java.com/ja/download/
あと、ローカルのマシンにWindows Azure SDKがインストールされている必要があります。Windows Azure Tools for Microsoft Visual Studioなんかをインストールしていれば勝手に入っていたり、Visual Studioの2008と2010で違ってきたりするので、まあそこら辺は適宜お願いします。
Windows Azure Software Development Kit (February 2010)
ちなみに、Visual Studioは特に使いません。Windows Azure SDKがあればいいです。

Jettyの設定変更

ところで、このままの状態でJettyをWindows Azureで動作させようとすると、Development Fablicでは動作しますが、Windows AzureのHosting環境では動作しません。主な原因は、Windows Azureではループバックアドレスにアクセスできないという制限に由来します。


This Topic Is No Longer Available


Jetty標準の構成では、コネクタにNon-Blocking I/Oを使用したものが構成されていますが、ループバックアドレスにアクセスできないと、Non-Blocking I/O自体が使用できないため、Jettyが起動できません。これを回避するために、Blocking I/Oを使用したコネクタでJettyを構成する必要があります。
それと、標準の構成ではローカルディスクにログを出力するよう構成されていますが、これもWindows Azureの制限でディスクへの書き込みが制限されている上に、Azureのローカルディスクにログを出力しても取得する方法がないので、これをdisableにする必要があります。
この2点の構成変更が反映された設定ファイルが、Jetty Solution Acceleratorと一緒にダウンロードしたjetty.xmlになります。このファイルで、ローカルに解凍されているJettyの中にある「etc\jetty.xml」を上書きすれば、これらの構成が反映されます。

使い方

JettySolutionAccelerator.zipを解凍すると

  • Buildme.cmd
  • Runme.cmd
  • Packme.cmd

というのが入っています。使うのはこの3つのコマンドだけです。VisualStudioは特に使いません。
さて、これらのコマンドを実行していくわけですが、普通のコマンドプロンプトでは使えません。「Windows Azure SDK Command Prompt」を使用しないときちんと実行できないので注意してください。

Buildme.cmd

さて、Buildme.cmdをWindows Azure SDK Command Promptから実行します。すると
f:id:haru-tama:20100508200436p:image:w300
「Jettyのバイナリってどこ?」と聞かれますので、Jettyのzipが解答された場所を指定してください。しばらくJettyのファイルがコピーされたあとで
f:id:haru-tama:20100508200435p:image:w300
JREってどこ?」と、また聞かれますので、JREがインストールされたフォルダを指定してください。特にインストールフォルダが指定されていない場合「C:\Program Files\Java\jre6」にインストールされています。これでしばらくすると、こんな画面になります。
f:id:haru-tama:20100508200433p:image:w300
これで準備完了です。あっけないですね。ここで何が行われたかというと。

  • JettyとJREを所定の場所にコピー
  • コピーされたファイルをWindows AzureのDevelopment Fablicから実行出来るように配置

ということをやっています。

Runme.cmd

Runme.cmdを実行すると、今作成したJettyの環境がDevelopment Fablic上で実行されます。権限昇格を確認する画面が2回起動しますので、両方とも「はい」で答えてください。
Development Fablicが起動したあとコマンドプロンプトが開きますが閉じないでください。真っ黒い画面で何もしてなさそうですが、Jettyが実行されているコマンドプロンプトの画面ですので、閉じてしまうとJettyも終わってしまいます。Development Fablicを見るとこんな感じですね。
f:id:haru-tama:20100508203206p:image:w300
デフォルトでは8080番ポートでエンドポイントが作成されていますので、ブラウザから「http://localhost:8080」と叩けば、Jettyのサンプル画面が表示されます。
f:id:haru-tama:20100508203204p:image:h300
で、Jettyのログはどこに出ているのかという話ですが、Jettyが標準出力に出しているログに関しては、Windows Azureのログとして出力するよう構成しています。何らかのツールを使ってDevelopment Storageを覗いてみると、本来は標準出力に出ているログが出力されていることを確認できます。
f:id:haru-tama:20100508203200p:image:w300

Packme.cmd

Packme.cmdを実行すると、Windows Azureの本番環境にアップロードするパッケージが「Jetty.cspkg」という名前で作成されます。構成ファイルである「Jetty.cscfg」も同じ場所にありますが、これは「Jetty\ServiceConfiguration.cscfg」をリネームしてコピーしたものです。
ということで、Windows Azureにアップロードする際には「Jetty.cspkg」と「Jetty.cscfg」をアップロードすれば大丈夫です。