Windows AzureでJBossをしぶしぶ動かしてみる
諸事情から、JBossをAzure上で動かさないといけない状態が発生。
今回は「JBossなんて、無理してWorkerRole上で動かさなくても、VMRoleでいいじゃん！」っていう手前勝手な理屈が通らない状況のため、しぶしぶWorkerRole上で動かすことに。
ちらっとネットを検索してみたもののJBoss on Azure 関連の情報はあまりないので、何かの足しになればとメモしておきます。
1年くらい前にインストールした際はTomcat Solution Acceleratorを改造したり、いろいろ苦労した記憶があるのですが、今回は、道具として、Windows Azure Starter Kit for Java（WASKJ） を利用してみることにしました。
なにはともあれ、WASKJをダウンロードしてきます。
Azure上でOSS系のツールを動かすための支援ツールは、なんとかAcceleratorとかStarter Kit とか、大そうな名前がついているのですが、何のことはない、ただのクラウドプロジェクトのテンプレートファイルです。もちろん、それでもありがたいのですけど・・・。
で、とりあえず、展開すると
下記のような構造になっています。
下記の図にはありませんが、WorkerRole1の配下にapprootがあるのを確認しておいてください。それが、AzureにUpした時のルートディレクトリになります。
WASKJでは、これらをテンプレートファイルに足したり引いたりすることで、アプリケーションサーバやJavaアプリを簡単に展開することができます。
「事前準備」
で、WASKJを使う前準備ですが、Windows Azure SDK 1.3 やTools for VSとかは当然として、ローカルPCにJavaの環境が必要です。
とはいえ、まあ、JDKくらいですけど。私はJDK6を利用してます。
あと、WASKJではパッケージのビルドにAntを利用するので、ローカル環境上でAntのビルドが効く状態にしておきます。
Antはここから落とします。展開してANT_HOMEを設定するだけです。
「JBossとかJava実行環境の準備」
次に、Java実行環境と、JBossの本体を用意します。
Upするファイルですが、展開してすぐに使える状態のファイルをZipしたものがよいらしいので、Zipファイルを用意します。
JBossに関しては、ここからダウンロードしました。最新は7.0のようですが、私は、諸事情あるので5.1をダウンロードしました。私が利用したものは、JDK6に対応したバージョンのjboss-5.1.0.GA-jdk6.zipというやつです。
で、問題はJava実行環境です。JREを含むJDK環境はインストーラー形式（あるいはそれをZipしたもの）しか提供されていないので、ローカル環境にインストール、展開済みのJavaファイルをZipして利用することにしました。
私は、インストールされていた
C:\Program Files\Java\jdk1.6.0_24\jre
をまんまZipしました。たぶん、C:\Program Files\Java\jre6でもいいと思います。なお、Azureは64bit環境なので、ローカルも64bitであることが前提です。念のため・・・。
で、ダウンロードした、jboss-5.1.0.GA-jdk6.zipと、ローカルのjre環境をZipしたjre.zipを、approot以下にコピーします。私は、わかりやすくするために、jboss、javafilesというディレクトリを作り、さらにその配下に配置しました。
私は下記のようなディレクトリ構造となりました。
ちなみに、WASKJを展開した時のディレクトリ名はWindowsAzureCloudServiceProjectですが、私の環境ではProjectという短い名前にしてあります（この理由は後で説明します・・・）。あと、deployディレクトリは初期段階ではありません。ビルド時に自動生成されたものです。
次に、Utilフォルダ配下にあるstartup.cmdを編集します。
私は下記のようにしました。approot以下の構造により下記内容は変化します。念のため。
@REM unzip JBoss
cscript /B /Nologo util\unzip.vbs jboss\jboss-5.1.0.GA-jdk6.zip .
@REM unzip JRE
cscript /B /Nologo util\unzip.vbs javafiles\jre.zip .
@REM change dir & set env & execute bat
cd jboss-5.1.0.GA\bin
set PATH=%PATH%;..\..\jre\bin
start run.bat -b 0.0.0.0
やってることはJBossを起動させてるだけです。「解凍」して、「ディレクトリ移動」して、「環境変数設定」して・・・。JBossの起動でおなじみ「run.batの実行」です。
環境設定については、JBossは、java.exeにパスが通ってるととりあえず動くようなのでそれだけ。できればJAVA_HOMEなども設定した方がいいみたい（今回は割愛）。
あと、重要な点はJBossの起動は、
run.bat
ではなく、
start run.bat -b 0.0.0.0
で行うこと。
頭のstartですが、これは、非同期でバッチ処理をきどうするためのものです。非同期で起動しないとAzureへの発行時に、永遠Busy状態に陥ります。また、JBoss4.2から、デフォルトで外部アクセスを受け付けなくなっているらしく、外部からのアクセスを受け付けるためには-b 0.0.0.0とオプションをつけて起動します（久しぶりのJBossで少々はまる）。
次に、ServiceDefinition.csdefを編集し、エンドポイントを追加します（赤字部分）。
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="A" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition">
<WorkerRole name="WorkerRole1">
<Startup>
<!-- Sample startup task calling startup.cmd from the role's approot\util folder -->
<Task commandLine="util\startup.cmd" executionContext="elevated" taskType="simple"/>
</Startup>
<Endpoints>
<InputEndpoint name="Http" protocol="tcp" port="80" localPort="8080" />
</Endpoints>
</WorkerRole>
</ServiceDefinition>
こうすることで、ローカルでは8080で動いているJBossに、外部（80）からのアクセスをマップしてくれるそうです。かしこい。
以上で準備完了です。
コマンドプロンプト（管理者の方がいいかな？）で、WASKJ直下のディレクトリに移動します。で、下記コマンドによりビルドを実行します。
ant -buildfile package.xml
すると、いろいろメッセージが出た後、BUILD SUCCESSFULとでればOKです（もちろんBUILDが成功しただけですけど）。同時に、同じ階層にdeployディレクトリが生成されているはずです。
コマンドプロンプトでdeployディレクトリに移動し、DevelopmentFabricを起動させた上で、
csrun
とたたけばOKのはずなのですが・・・。私の場合、問題はここからでした・・・。
どうやら、WorkerRoleは正常に起動し、展開を始めているようなのですが、エラーががでます。
そのエラーは
「パスが長すぎます」
というものです。
この問題は、DevelopmentFabricで時折起こる問題なので、下記のように解決法も確立されているので、
http://blogs.msdn.com/b/jnak/archive/2010/01/14/windows-azure-path-too-long.aspx
軽視してたのですが、なんと、解決策を講じてもなお、エラーが解決されません。
どうやら、そもそもものすごい長いファイル名のクラスファイルがJBossにあるらしく・・・。Tmpディレクトリ名を短くしてもそもそも既定のファイル名長（160とか260文字とか）をオーバーするようです・・・。
クラスファイル名を変えるわけにもいかず、かといって、ディレクトリ名の多くが自動生成される中、いじれる範囲のディレクトリ名などをを極力短くしたところ何とか乗り越えられました。
私がいじった個所は、まず、そもそものディレクトリ名をシンプルにしました。
C:\JBossTest\Project\deploy
例えば、上記のようにしました。Projectの部分はもともとWindowsAzureCloudServiceProjectと、とんでもなく長いディレクトリ名でしたが、短くしました。deployは自動生成のためいじれません。
あとは、生成されるパッケージファイルの名前もWindowsAzurePackage.cspkg"となっていたところを念のためWAP.cspkgと短くしました。これは、package.xmlファイル中のpackagefilenameで定義されているので、そこをいじります。
あと、ServiceDefinition.csdefとServiceConfiguration.cscfgファイル中のnameおよびserviceNameが"WindowsAzureCloudServiceProject"となっているところを"A"などとすることで、途中生成されるファイル名が短くなります。
これで、なんとかエラーを防止することができました。
DevelopmentFabricを起動した状態で、
csrun
を実行します。
しばらくまって（私の環境では1分くらいかかりました）、、
とすると、
きましたJBoss。
が、まだ、終わりではありません。
「Azure環境へUploadする」
ローカルだとこれでいいんですが、Cloud環境に上げる際は、Antのビルドの際、package.xml中の
packagetype="local"
となっているところを、
packagetype="cloud"
として再ビルドしたものをUploadする必要があります。
Azure Management Portal でUpするのに30分（これはうちのネットが遅いだけ）。展開されるのに40分。
とりあえずAzure上でJBossが動きました。
JBossさんは、いろいろ内部的に通信してるみたいなので、全ての機能が正常に動作しているかどうかはチェックが必要かもです。