View Source

{scrollbar}

本記事は、Geronimo 2.0 以降を対象としています。

この記事では Geronimo の一つの導入インスタンスから、複数サーバーのインスタンスを実行する方法を述べます。サーバーのインスタンスができるだけ、ベースとなる Geronimo アーティファクトおよびファイル・システムのスペースを共有します。下記はデフォルトでの Geronimo ディレクトリーおよび <geronimo_home> 下のサブ・ディレクトリーです。

bin
lib
schema
var
repository
deploy (hot deployment)

<geronimo_home> は Geronimo を導入したディレクトリーです。 bin, lib そして schema ディレクトリーは読み取り専用ですので、インスタンス間で共有できます。導入したばかりの Geronimo インスタンスが通常占有するディスク・スペースは var と repository で均等にそれぞれ約 50 MB に分割されています。その他は無視できるくらいの容量です。 var のほとんどを占める 40 MB は ActiveMQ ジャーナル・ファイルです。これによって特に、各サーバー・インスタンスに対して一つずつ、第二リポジトリーとして使用できる、という考えができます。

単純な read/write パーティションのケイパビリティーに加えて、ディレクトリーへのアクセス許可というセキュリティの観点もあります。各サーバー・インスタンスは、自分自身の、たとえば var ディレクトリーだけに read/write 権限があります。

構成サブスティテューション・プロパティ

リポジトリーを共有しているかどうかにかかわらず、複数サーバーを実行させるためのフィーチャーは、構成サブスティテューション・プロパティ・ファシリティである config.xml を以下の形式で記述します。

${prop1 + prop2 + prop3}

その他、この記述方法で、下記により設定される値を使用し、jexl に関しての評価を行います。

プロパティ・ファイル。デフォルトで var/config/config-substitutions.properties このファイル名はコマンドライン・プロパティによって変更できます。
-Dorg.apache.geronimo.config.substitutions.file=var/config/some-other-file.properties
システム環境プロパティ
コマンドライン・プロパティ
上記の順序で、お互いにオーバーライドします。コマンドライン・プロパティは他のすべてをオーバーライドします。システム環境プロパティおよびコマンドライン・プロパティは接頭辞がデフォルトで、"org.apache.geronimo.config.substitution." (末尾の "." にご注意ください。) とつきます。コマンドライン・プロパティで接頭辞を変更することもできます。
-Dorg.apache.geronimo.config.substitution.prefix=myPrefix.

複数のサーバー・インスタンス

サーバー・インスタンスを Geronimo に作成するのは容易です。

サーバー起動前に、org.apache.geronimo.server.name システム・プロパティをインスタンス名に変更します。
- シンタックス -Dorg.apache.geronimo.server.name=foo を使用し、あなたのインスタンス foo を命名します。
- 以下の2つの方法があります。
  1. GERONIMO_OPTS 環境変数に追加する、もしくは
  2. サーバーの java コマンドライン・インボケーションに渡す
- このサーバーの var およびデプロイ・ディレクトリーは、それによって、<geronimo_home>/foo の下に位置します。
- org.apache.geronimo.server.name 名は <geronimo_home> からの（降順で）相対するパス名になります。たとえば、servers/bar は、サーバーの var ディレクトリーを、 <geronimo_home>/servers/bar の下に配置します。
- org.apache.geronimo.server.dir システム・プロパティも使用できますが、 org.apache.geronimo.server.name をオーバーライドします。
- org.apache.geronimo.server.dir として絶対パスを指定してください。 <geronimo_home> との相対的な関係は必要ありません。たとえば、 /ag20/servers/bar サーバーの var ディレクトリーを /ag20/servers/bar 下に配置します。そのようにしない場合は、2つのシステム・プロパティは同一に振舞います。
mkdir foo
var/* を foo/var/ にコピーします。
foo/var/config/config-substitutions.properties を編集し、 PortOffset のコメントを外し、1,2,10,11,12,20,21,22,...のような値に変更し、新規インスタンスのポートが、すでに定義済か始動済の既存のサーバー・インスタンスと衝突しないようにします。(それに代わる方法として、コマンドラインからプロパティ -Dorg.apache.geronimo.config.substitution.PortOffset=3 を指定しサーバーを開始します。）
サーバーを始動します。

新規サーバー・インスタンスへアプリケーションをデプロイするには、 NamingPort+PortOffset を指定し、PortOffset=1 のように使用します。

deploy -port 1100 list-modules

複数のリポジトリー

まず、シングル・サーバー・インスタンスの場合で、セカンド・レジストリーの追加を考えてみましょう。 Geronimo はリポジトリーに残したまま、アプリケーションのデプロイ用にセカンド・リポジトリーを追加します。セカンド・リポジトリーの追加はとても簡単です。

リポジトリー・モジュール用にプラン（repo2.xml）を作成します。 xmlsolidrepo2.xml <?xml version="1.0" encoding="UTF-8"?> <module xmlns="http://geronimo.apache.org/xml/ns/deployment-1.2"> <environment> <moduleId> <groupId>org.example.configs</groupId> <artifactId>myrepo</artifactId> <version>2.0.1</version> <type>car</type> </moduleId> <dependencies> <dependency> <groupId>org.apache.geronimo.configs</groupId> <artifactId>j2ee-system</artifactId> <version>2.0.1</version> <type>car</type> </dependency> </dependencies> <hidden-classes/> <non-overridable-classes/> </environment>  <gbean name="Repo2" class="org.apache.geronimo.system.repository.Maven2Repository"> <attribute name="root">repo2s/</attribute> <attribute name="resolveToServer">true</attribute> <reference name="ServerInfo"> <name>ServerInfo</name> </reference> </gbean>  <gbean name="Local2" class="org.apache.geronimo.system.configuration.RepositoryConfigurationStore"> <reference name="Repository"> <name>Repo2</name> </reference> </gbean> </module>
リポジトリーのルート・ディレクトリーを mkdir <geronimo_home>/repo2s#* コマンドにより作成します。上記の例では、ディレクトリーは、 Maven2Repository GBean, repo2s/ の root 属性で指定されます。ベース･ディレクトリー<geronimo_home> と相対関係にあります。
- resolveToServer 属性はリポジトリーの場所を特定します。
  - true の場合はこのパスが baseServer と相対関係にあり、複数サーバー・インスタンスを扱うには便利です。
  - false の場合はこのパスがベース・ディレクトリー <geronimo_home> と相対関係にあります。
リポジトリー・モジュールをデプロイします。deploy deploy repo2.xml を通し、repo2.xml をデプロイすることにより実施します。
deploy コマンドはスクリプト <geronimo_home>/bin/deploy.{bat,sh}であり、オペレーティング・システムあわせてどちらか(bat,sh)を使用します。 <geronimo_home>/bin ディレクトリーからか、もしくはパスにそのディレクトリーを通しておいて、deploy とタイプするだけです。

新規リポジトリーの使用

新規のリポジトリーを使用するのは少し癖があります。現在のところコマンドラインからのみのサポートとなります。重要な点は deploy コマンドの --targets オプションを使用することであり、新規リポジトリーにご自身のモジュールをデプロイするためにターゲットします。まず、デプロイヤー list-targets コマンドを使用し、リポジトリーを参照します。ターゲット名は長くて扱いにくくなっています。

deploy list-targets

利用可能なターゲット：
org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2
org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car?ServiceModule=org.apache.geronimo.configs/j2ee-system/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local

環境変数の使用にはコマンドラインを推奨します。たとえば、 set SEPO2=
org.example.configs/myrepo/2.0-SNAPSHOT/car?ServiceModule=org.example.configs/myrepo/2.0-SNAPSHOT/car,j2eeType=ConfigurationStore,name=Local2.

新規のリポジトリーをデプロイするには deploy deploy --targets %REPO2% sample.war コマンドを使用します。

deploy list-modules はまた、各 repo に対して長いターゲット名を付与します。それに続くのが、 repo にデプロイされた各モジュールの、通常の短い名前です。
deploy list-modules %REPO2% によってターゲットの repo に対してのいつもの短いアウトプットが与えられます。

repo からのアンデプロイのシンタックスは deploy undeploy "%REPO2%|geronimo/jsp-examples/1.1.1/war" となります。

文字 | がリポジトリー名とモジュール名を区分します。引用句 " はパラメーター全体にわたって使用され、コマンド・シェルが解釈できるように特別な文字を制御（エスケープ）します。

もし --targets がデプロイ･コマンドで指定されなかった場合、モジュールは全リポジトリーに対してデプロイされます。これは明らかに望ましくありません。モジュールを特定のあるリポジトリーに配置したいのであれば、必ず --targets オプションを使用してください!

それぞれが自身のリポジトリーを所有する複数サーバー・インスタンス

複数サーバー・インスタンスの場合には、各サーバーに対して、別のパスが、 Maven2Repository root 属性として付与されます。 config.xml とともに、各サーバー・インスタンスに対してオーバーライドされます。もっとよいやり方は GBean への resolveToServer 属性の追加です。それによって、 root 属性が repository に設定され、各サーバー・インスタンスにとってユニークになり、各インスタンスにとって変更がまったく必要ありません。各サーバー・インスタンスは <geronimo_home>/<instance_name>/repository に配置されるリポジトリーを持ちます。

複数リポジトリーへのコンソール・サポート、およびホット・デプロイおよびプラグインのサポートはありません。

ここでちょっとご紹介しておきたいのは、どのリポジトリーに、新規のリポジトリーがデプロイされるか、ということです。明らかに、セカンド・リポジトリー(たとえば上記 repo2.xml ) はファースト・リポジトリーにデプロイされます。このように、ファースト・リポジトリーを読み取り専用とすることは、動的に追加されるリポジトリーとしては動作しません。おそらく、セカンド・リポジトリーが追加され、これらサーバー・ユニークなリポジトリーを含むことになります。セカンド・リポジトリーは共有され読み取り専用でなくてはなりませんので、ユースケースにはぴったりとフィットしません。