タイガー!タイガー!じれったいぞー!(SE編)

AS400, Java, JavaEE, JSF等の開発、習慣など。日々の気づきをまとめたブログ(備忘録)

Payara Serverアップグレードを試す

Java EE Advent Calendar 2016の16日目です。

昨日の記事は @khasunumaさんの「JavaFX から Payara Micro API を呼び出す際の注意点」でした。
明日は@backpaper0@githubさんです。



今回のゴール

  • 既存のアプリが起動しているJavaEE環境(CentOS7.2)のアップグレードを行う。
    • JDK 8.45 => JDK 8.112
    • Payara 4.1.1.154 => Payara 4.1.1.164

目的

去年の11月より、業務系サーバーに Payara を選定し、ようやくPayara管理者2年生を迎えました。
実際、運用中のPayara Severは、利用ユーザーも少なく、オンプレミス環境1台で働いてくれています。

Payaraは、3か月ごとに新しいフルリリース(バグフィックスと新機能)を提供してくれていますが、リリースしたものが安定稼働していると、なかなかアップグレードをしなくなってしまいます。

そこで、現在動いているシステムのPayaraとJavaのアップグレードをテスト機で試しておこうと思ったのが、この記事を書くきっかけとなりました。
正直、JavaEEの原理・原則を正しく理解できていないので、作業はコピペ中心です(汗)。。。

作業手順

※注:下記Linuxコマンドは、一時的な検証機での操作のため、root権限で行っています。

(1) JDKアップグレード

JDKダウンロード

現在運用のJDKは、8.45であるため、こちらも最新版にしておこうと思います。
Oracleのdownloadsサイトより、CentOS7用のlinux-x64.rpmをダウンロードします。

JDKインストール

作業前Version確認

まずは、現状確認から。1.8.0_45で間違いないようです。

# java -version
java version "1.8.0_45"
Java(TM) SE Runtime Environment (build 1.8.0_45-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode)

# javac -version
javac 1.8.0_45
ファイル配備

とりあえず、/tmpへ配置しました。

# ls /tmp
jdk-8u112-linux-x64.rpm
インストール

rpmコマンドでインストール開始です!

# rpm -Uvh jdk-8u112-linux-x64.rpm
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:jdk1.8.0_112-2000:1.8.0_112-fcs  ################################# [100%]
Unpacking JAR files...
        tools.jar...
        plugin.jar...
        javaws.jar...
        deploy.jar...
        rt.jar...
        jsse.jar...
        charsets.jar...
        localedata.jar...

無事、インストールが終わったようです。

Java実行環境切替

J実行環境切替は、不要でした。
すでに、インストールしたばかりの「jdk1.8.0_112」が選択されているようです。

# alternatives --display java
java -ステータスは自動です。
リンクは現在 /usr/java/jdk1.8.0_112/jre/bin/java を指しています。 <<<<<<<<<<<<<<<<
/usr/java/jdk1.8.0_45/jre/bin/java - 優先項目 18045
 スレーブ ControlPanel: /usr/java/jdk1.8.0_45/jre/bin/ControlPanel
 スレーブ javaws: /usr/java/jdk1.8.0_45/jre/bin/javaws
:
:
/usr/java/jdk1.8.0_112/jre/bin/java - 優先項目 180112
 スレーブ ControlPanel: /usr/java/jdk1.8.0_112/jre/bin/ControlPanel
 スレーブ javaws: /usr/java/jdk1.8.0_112/jre/bin/javaws
:
:
現在の「最適」バージョンは /usr/java/jdk1.8.0_112/jre/bin/java です。
作業後Version確認

Version確認でも、1.8.0_112となっています。

# java -version
java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b15)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b15, mixed mode)

# javac -version
javac 1.8.0_112
切替が必要な場合

もし、新しいVersionのJDKが適用されていなければ、「alternatives –config java」でjavaを指定できます。また、業務アプリが正常に動かないなど、やむを得ず戻す必要になった場合には、このコマンドで前のVersionに戻すことが可能です。

# alternatives --config java

2 プログラムがあり 'java' を提供します。

  選択       コマンド
-----------------------------------------------
   1           /usr/java/jdk1.8.0_45/jre/bin/java
*+ 2           /usr/java/jdk1.8.0_112/jre/bin/java

Enter を押して現在の選択 [+] を保持するか、選択番号を入力します: 

④Payara起動確認

PayaraのWeb管理コンソールにアクセスし、「JVM Report」を確認すると、「jdk1.8.0_112」で起動していました。
オッケー、オッケー!!

java.home = /usr/java/jdk1.8.0_112/jre
java.runtime.name = Java(TM) SE Runtime Environment
java.runtime.version = 1.8.0_112-b15

(2) Payaraアップグレード

まず、今回わかったこと。
Payaraのリリース番号って、西暦下2ケタ+その年の回数ってことなんですね! はじめて利用したとき、154個目のリリースだと思ってしまいました。。。なので、現時点の最新版は164。
2016年4番目のリリースにアップグレードをしましょう。

参考にしたサイトは、こちらになります。

最初は、Web管理コンソール画面でアップグレードメニューなどあるのかなと思っていたのですが、基本的な移行方法として下記の2つが選択肢になるようです。

  1. 既存の構成をバックアップして新しいインストールに復元する
  2. 完全に分離したドメインとノードのディレクトリを維持し、新しいバージョンを既存のディレクトリに向ける

今回は、1.の方法でアップグレードの検証を行います。

①起動中Payaraの停止(payara154)

まずは、動いているPayaraサービスを止めます。
このPayaraサービスは、後述の⑦payara.service で定義済みです。

# systemctl stop payara  (/opt/payara/payara-4.1.154/payara41/bin/asadmin stop-domain)

ドメインのバックアップ(payara154)

現行のドメインドメイン名:domain1)をバックアップします。
バックアップ先は、「/opt/payara/backups」としました。
終了すると、バックアップ先に「domain1/domain1_2016_12_13_v00001.zip」というファイルが出来上がっていました(当作業は、2016/12/13に実施)。

# /opt/payara/payara-4.1.154/payara41/bin/asadmin backup-domain --backupDir /opt/payara/backups domain1
Backed up domain1 at Tue Dec 13 19:39:59 JST 2016.
Command backup-domain executed successfully.

# ls /opt/payara/backups/domain1
domain1_2016_12_13_v00001.zip

③環境構築(payara164)

次に、新環境構築です。

ファイル配備

Payaraのダウンロードページより、現時点で最新の「payara-4.1.1.164.zip」をダウンロードし、「/opt/payara/payara-4.1.164」へ配備しました。

# mkdir /opt/payara/payara-4.1.164

//ダウンロードしたファイルを配備する。

# ls /opt/payara/payara-4.1.164
payara-4.1.1.164.zip

続けて解凍処理を行います。

# unzip payara-4.1.1.164.zip
# ls /opt/payara/payara-4.1.164
payara-4.1.1.164.zip  payara41

ドメインのリストア(payara154→payara164)

②で作成されたバックアップファイルを新環境へリストアします。
バックアップディレクトリとドメイン名を指定して、無事、リストアが成功しました!!

# bin/asadmin restore-domain --backupdir /opt/payara/backups domain1
Restored the domain (domain1) to /opt/payara/payara-4.1.164/payara41/glassfish/domains/domain1
Command restore-domain executed successfully.

ドメイン所有者変更(payara164)

rootで操作してきたため、新Versionのpayara内、リストアされたドメインすべてが所有者rootになっているため、これをすでに作成済みユーザーの「payara」へ変更します。
このpayaraユーザーがpayaraサービスの実行ユーザーとなっているため、この変更は必須となります。

# chown -R payara:payara /opt/payara/payara-4.1.164

⑥起動確認(payara164)

さあ、起動してみましょう!!(テスト機 IP Address: 192.168.100.100)

# /opt/payara/payara-4.1.164/payara41/bin/asadmin start-domain
Waiting for domain1 to start ................................
Successfully started the domain : domain1
domain  Location: /opt/payara/payara-4.1.164/payara41/glassfish/domains/domain1
Log File: /var/log/payara/server.log
Admin Port: 4848
Command start-domain executed successfully.
  • https://192.168.100.100:4848

20161213193717

無事に起動できました!
当たり前なのかもしれませんが、前の設定もすべて引き継がれており、設定変更は不要でした。

※ログファイルの保管場所が同一ドメイン内である場合は、修正が必要でしょうか。

payara164停止→payara154起動テスト

念のため、payara154が動作するかもテスト。まったく問題ありません。

# /opt/payara/payara-4.1.164/payara41/bin/asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.

# /opt/payara/payara-4.1.154/payara41/bin/asadmin start-domain
Waiting for domain1 to start ...................................
Successfully started the domain : domain1
domain  Location: /opt/payara/payara-4.1.154/payara41/glassfish/domains/domain1
Log File: /var/log/payara/server.log
Admin Port: 4848
Command start-domain executed successfully.

# /opt/payara/payara-4.1.154/payara41/bin/asadmin stop-domain
Waiting for the domain to stop .
Command stop-domain executed successfully.

なお、154と164を複数起動してみると、同じ設定のpayaraなので、ポートが被って後者が起動できませんでした。

# /opt/payara/payara-4.1.154/payara41/bin/asadmin start-domain
There is a process already using the admin port 4848 -- it probably is another instance of a GlassFish server.
Command start-domain failed.

⑦payaraサービスの編集

単一コマンドで起動/停止を確認できたので、payaraサービスの設定も変更しておきます。
「payara-4.1.154」の箇所を「payara-4.1.164」へ変更。

/lib/systemd/system/payara.service

[Unit]
Description=Payara Server
After=network.target remote-fs.target

[Service]
Type=forking
### payara-4.1.154 => payara-4.1.164
PIDFile=/opt/payara/payara-4.1.164/payara41/glassfish/domains/domain1/config/pid
ExecStart=/opt/payara/payara-4.1.164/payara41/bin/asadmin start-domain domain1
ExecReload=/opt/payara/payara-4.1.164/payara41/bin/asadmin restart-domain domain1
ExecStop=/opt/payara/payara-4.1.164/glassfish41/bin/asadmin stop-domain domain1
TimeoutStartSec=300
TimeoutStopSec=30
User=payara

[Install]
WantedBy=multi-user.target

systemdへ設定反映

# systemctl daemon-reload

⑧サービスでの起動・停止

payaraサービスで上げ下げしてみます。こちらも問題なしでした。

# systemctl start payara

# systemctl status payara
● payara.service - Payara Server
   Loaded: loaded (/usr/lib/systemd/system/payara.service; enabled; vendor preset: disabled)
   Active: active (running) since 火 2016-12-13 19:53:21 JST; 5s ago
  Process: 29867 ExecStop=/opt/payara/payara-4.1.164/glassfish41/bin/asadmin stop-domain domain1 (code=exited, status=203/EXEC)
  Process: 29894 ExecStart=/opt/payara/payara-4.1.164/payara41/bin/asadmin start-domain domain1 (code=exited, status=0/SUCCESS)
 Main PID: 29908 (java)
   CGroup: /system.slice/payara.service
           mq29908 /usr/java/jdk1.8.0_112/bin/java -cp /opt/payara/payara-4.1.164/payara41/glassfish/modules/glassfish.jar -XX:+UnlockDiagn...

12月 13 19:52:48 localhost.localdomain systemd[1]: Starting Payara Server...
12月 13 19:53:20 localhost.localdomain asadmin[29894]: Waiting for domain1 to start ...............................
12月 13 19:53:20 localhost.localdomain asadmin[29894]: Successfully started the domain : domain1
12月 13 19:53:20 localhost.localdomain asadmin[29894]: domain  Location: /opt/payara/payara-4.1.164/payara41/glassfish/domains/domain1
12月 13 19:53:20 localhost.localdomain asadmin[29894]: Log File: /var/log/payara/server.log
12月 13 19:53:20 localhost.localdomain asadmin[29894]: Admin Port: 4848
12月 13 19:53:20 localhost.localdomain asadmin[29894]: Command start-domain executed successfully.
12月 13 19:53:21 localhost.localdomain systemd[1]: Started Payara Server.

# systemctl stop payara

⑨業務アプリの動作確認

基本的なJavaEEアプリ「JSF(PrimeFaces)+CDI/EJB+JPA」で作られたWeb業務システムの動作検証を行いました。全テストは実現できておりませんが、問題なく動作できていることを確認できました。

完全テストを終えたのち、本番環境の方もJDK/Payaraのアップグレードを実施しようと思います。

これにて、今回の検証は終了となります。

まとめ

今回のpayaraのアップグレードで、主なモジュールも下記の通り、Versionアップされました。

modules 4.1.154 4.1.161 4.1.162 4.1.163 4.1.164
Eclipselink 2.6.1 2.6.2 2.6.3
Grizzly 2.3.23 2.3.24 2.3.25 2.3.28
Hazelcast 3.5.2 3.6.2 3.6.4 3.7.1
Jackson 2.5.1 2.8.1
Jersey 2.22 2.22.1 2.22.2
Mail 1.5.4 1.5.6
Mojarra 2.2.12 2.2.13
Tyrus 1.11 1.13
Weld 2.2.16.Final 2.3.2.Final 2.3.5.Final 2.4.0.Final

Payara164で起動すると、EclipseLinkのVersionも上がったことで、今まで起動時に毎回発生していた下記のヌルポも発生しなくなりました。

java.lang.NullPointerException
    at org.eclipse.persistence.platform.server.ServerPlatformUtils.createServerPlatform(ServerPlatformUtils.java:99)
    at org.eclipse.persistence.sessions.factories.SessionManager.init(SessionManager.java:77)
    at org.eclipse.persistence.sessions.factories.SessionManager.<clinit>(SessionManager.java:71)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.addSessionToGlobalSessionManager(EntityManagerSetupImpl.java:907)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.initSession(EntityManagerSetupImpl.java:2671)
    at org.eclipse.persistence.internal.jpa.EntityManagerSetupImpl.deploy(EntityManagerSetupImpl.java:675)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.getAbstractSession(EntityManagerFactoryDelegate.java:205)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryDelegate.createEntityManagerImpl(EntityManagerFactoryDelegate.java:305)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManagerImpl(EntityManagerFactoryImpl.java:337)
    at org.eclipse.persistence.internal.jpa.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:318)
    at com.sun.enterprise.container.common.impl.EntityManagerWrapper._getDelegate(EntityManagerWrapper.java:197)
    at com.sun.enterprise.container.common.impl.EntityManagerWrapper.find(EntityManagerWrapper.java:341)
:

今回はじめて、JavaEEのサーバーのアップグレードに挑戦したわけですが、やはり最新版で動いているという安心感があります。
もちろん、ケースバイケースかと思いますが、今後も、可能なものについては積極的に新しいVersionへ上げていきたいと思っています。