GlassFish Nucleus のお話

もはや誰も把握できていないであろう GlassFish Nucleus の内部動作に関するツイートのまとめ(作成中)
0
HASUNUMA Kenji @khasunuma_

22/25 Nucleus には main メソッドがいくつもあって、少なくとも asadmin の実体、nadmin の実体、glassfish.jar にはそれぞれ main が存在している。通常の起動では asadmin -> nadmin -> glassfish.jar という流れになる。

2020-02-12 01:32:18
HASUNUMA Kenji @khasunuma_

23/25 Nucleus 本来の CLI は nadmin だが、GlassFish v2 系との互換性維持のため asadmin が用意され、そのまま現在に至っている。Nucleus の起動/停止だけなら startserv / stopserv を使うこともできる。 ただし、Payara Server の場合は必ず asadmin を使うこと。公式な CLI が asadmin なので。

2020-02-12 01:32:18

GlassFish Deployer の話 (ここから長くなる)

HASUNUMA Kenji @khasunuma_

24/25 デプロイ周りは Nucleus の GlassFish Deployer というモジュールが深くかかわっている。GlassFish / Payara Embedded を使うときには、コードから Deployer を呼び出すので、Embedded 版を使ったことがあれば必ず経験しているはず。Embedded も DAS も同じ Deployer を使う。

2020-02-12 01:32:18
HASUNUMA Kenji @khasunuma_

25/25 Embedded を起動するためのコードは、DAS が起動する際にクラスが呼び出されていく流れを端折ったものになっている。DAS はかなり複雑なことをしているが、アプリをデプロイするところだけに焦点を当てると Embedded と大きな差はない。 Nucleus の仕組みはまだまだ続く...

2020-02-12 01:32:19
HASUNUMA Kenji @khasunuma_

この表現もかなり雑で、実際にはJava EE / Jakarta EEの複雑怪奇なクラスローディングとOSGiのアクロバティックなクラスローディングの複合なので、私も正確には把握しきれていない。誤解を恐れずに言うなら「地雷」です。 twitter.com/khasunuma/stat…

2020-02-12 02:28:17
HASUNUMA Kenji @khasunuma_

1/15 前回は Nucleus の GlassFish Deployer について、中途半端なところで止めた覚えがあるので、今回はその続きから。デプロイも意外と複雑なので、たぶん中座すると思います。

2020-02-13 01:33:01
HASUNUMA Kenji @khasunuma_

2/15 最初に Deployer クラスの Javadoc を提示しようと思ったのだが、検索しても出てくるのは自分の過去のブログ記事で古い URL を参照しているところばかりで、肝心の新しい URL が出てこないので、忘れなければ探しておきます。

2020-02-13 01:33:02
HASUNUMA Kenji @khasunuma_

3/15 GlassFish Deployer の役目は、大雑把に言うとアプリケーションをデプロイする、デプロイ済みのアプリケーションをデプロイしなおす、デプロイしたアプリケーションを削除する、etc. と、名前通りのことをする。

2020-02-13 01:33:02
HASUNUMA Kenji @khasunuma_

4/15 管理コンソールの「アプリケーション」や、asadmin の deploy / redeploy / undeploy サブコマンドは Deployer のフロントエンドになっていて、最終的には裏で GlassFish Deployer を呼び出している。

2020-02-13 01:33:02
HASUNUMA Kenji @khasunuma_

5/15 Deployer 自身は、アプリケーションをファイルシステム、バイトストリーム、URLのいずれかで取得して、Deployer が関連付けられているインスタンスにデプロイする。

2020-02-13 01:33:03
HASUNUMA Kenji @khasunuma_

6/15 Deployer の賢いところは2点あって、1つはアプリケーションをファイルシステム、バイトストリーム、URLのいずれでもロードできること。もう1つは、ファイルシステムから取得する場合、アーカイブ (.war .ear など) or ディレクトリを勝手に判断して適切に処理してくれること。

2020-02-13 01:33:03
HASUNUMA Kenji @khasunuma_

7/15 .war などのアーカイブをデプロイする場合: 1. アーカイブを読み込む 2. 読み込んだアーカイブをファイルシステムに展開する 3. ファイルシステムに展開したアプリケーションをコンテナに認識させる 4. コンテナがアプリケーションのエントリ・ポイントを実行する

2020-02-13 01:33:03
HASUNUMA Kenji @khasunuma_

8/15 アプリケーションをディレクトリに展開した状態でデプロイする場合には、前項の 1 と 2 を飛ばし、3 から処理する。コンテナには Deployer に渡されたディレクトリ・パス (アプリケーションが展開された形で入っているはず) を直接認識させる。

2020-02-13 01:33:04
HASUNUMA Kenji @khasunuma_

9/15 アプリケーションの展開先は、デフォルトでは DAS 上の所定のディレクトリになるが、ディレクトリ形式のデプロイではインスタンスの「ローカル」ファイルシステム上の任意の場所にすることができる。逆に言うと、「リモート」のディレクトリは原則として直接デプロイすることができない。

2020-02-13 01:33:04
HASUNUMA Kenji @khasunuma_

10/15 ディレクトリ形式のデプロイは、Eclipse の GlassFish Tools や Payara Tools が採用しているやり方で、これらのプラグインはサーバーのインストール・ディレクトリの外側である Eclipse ワークスペースを直接アプリケーションの展開先として認識させる。

2020-02-13 01:33:04
HASUNUMA Kenji @khasunuma_

11/15 補足) 「リモート」のディレクトリであっても、NFS 共有などでローカルのファイルシステムにマウントすれば、ディレクトリ形式のデプロイは可能である。Windows の場合はネットワーク・ドライブに割り当てればOK。ただし、これは危険な裏技なので、知識だけに留めて実際には使わないこと。

2020-02-13 01:33:04
HASUNUMA Kenji @khasunuma_

12/15 自動デプロイは、アーカイブ形式のデプロイの応用。サーバーが autodeploy ディレクトリをポーリングで監視して、新しく .war などが置かれたらそれを Deployer に渡している。自動デプロイ自体は Deployer の機能ではないので、Embedded には備わっていない。

2020-02-13 01:33:05
HASUNUMA Kenji @khasunuma_

13/15 少なくとも GlassFish 系 (GlassFish、Payara Server、Interstage AS) のデプロイは、アーカイブをインスタンス上に展開するか、インスタンスのローカル・ファイルシステム上のディレクトリを直接認識させるかのどちらかで行っている。

2020-02-13 01:33:05
HASUNUMA Kenji @khasunuma_

14/15 NetBeans はディレクトリ形式ではなくアーカイブ形式でデプロイするようになっていたはず (確か自動デプロイを使っていたと思うが、違うかもしれない)。IntelliJ もアーカイブ形式を採用しているが、奴は Deployer とその周辺を直接叩いて Shoal クラスタにデプロイできたりもする。

2020-02-13 01:33:05
HASUNUMA Kenji @khasunuma_

15/15 Nucleus のアプリケーション・デプロイのうち、今回取り上げたのはアプリケーションをどこから取ってくるかのお話。その先のことはまた別の機会に。

2020-02-13 01:33:06