Java EE Advent Calendar 2016の16日目です。
昨日の記事は @khasunumaさんの「JavaFX から Payara Micro API を呼び出す際の注意点」でした。
明日は@backpaper0@githubさんです。
今回のゴール
- 既存のアプリが起動しているJavaEE環境(CentOS7.2)のアップグレードを行う。
目的
去年の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ダウンロード先
- 取得したファイル
②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 -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.の方法でアップグレードの検証を行います。
①起動中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
無事に起動できました!
当たり前なのかもしれませんが、前の設定もすべて引き継がれており、設定変更は不要でした。
※ログファイルの保管場所が同一ドメイン内である場合は、修正が必要でしょうか。
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 | ||
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へ上げていきたいと思っています。