わんくま同盟 東京勉強会#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から実行します。すると
「Jettyのバイナリってどこ？」と聞かれますので、Jettyのzipが解答された場所を指定してください。しばらくJettyのファイルがコピーされたあとで
「JREってどこ？」と、また聞かれますので、JREがインストールされたフォルダを指定してください。特にインストールフォルダが指定されていない場合「C:\Program Files\Java\jre6」にインストールされています。これでしばらくすると、こんな画面になります。
これで準備完了です。あっけないですね。ここで何が行われたかというと。
- JettyとJREを所定の場所にコピー
- コピーされたファイルをWindows AzureのDevelopment Fablicから実行出来るように配置
ということをやっています。
Runme.cmd
Runme.cmdを実行すると、今作成したJettyの環境がDevelopment Fablic上で実行されます。権限昇格を確認する画面が2回起動しますので、両方とも「はい」で答えてください。
Development Fablicが起動したあとコマンドプロンプトが開きますが閉じないでください。真っ黒い画面で何もしてなさそうですが、Jettyが実行されているコマンドプロンプトの画面ですので、閉じてしまうとJettyも終わってしまいます。Development Fablicを見るとこんな感じですね。
デフォルトでは8080番ポートでエンドポイントが作成されていますので、ブラウザから「http://localhost:8080」と叩けば、Jettyのサンプル画面が表示されます。
で、Jettyのログはどこに出ているのかという話ですが、Jettyが標準出力に出しているログに関しては、Windows Azureのログとして出力するよう構成しています。何らかのツールを使ってDevelopment Storageを覗いてみると、本来は標準出力に出ているログが出力されていることを確認できます。
Packme.cmd
Packme.cmdを実行すると、Windows Azureの本番環境にアップロードするパッケージが「Jetty.cspkg」という名前で作成されます。構成ファイルである「Jetty.cscfg」も同じ場所にありますが、これは「Jetty\ServiceConfiguration.cscfg」をリネームしてコピーしたものです。
ということで、Windows Azureにアップロードする際には「Jetty.cspkg」と「Jetty.cscfg」をアップロードすれば大丈夫です。
