1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Migration Toolkitを使用した、従来型 WebSphere Application Server から Open Liberty への移行ハンズオン [MacOS 編]

1
Posted at

1. はじめに

本ドキュメントは、従来型の WebSphere Application Server traditional (tWAS) で動作する Java アプリケーションに対して Migration Toolkit for Application Binaries と呼ばれるツールを使用し、Open Liberty に移行する一連の流れを体験するためのハンズオン手順書です。
このハンズオンでは、アプリケーションの診断、修正、自動化、動作確認、パッケージングまでを一通り実施します。

対象読者

  • アプリケーション・モダナイゼーション(クラウド化、コンテナ化を含む)を検討している技術者・監督者
  • 従来型のWebSphere Application Server を利用中のお客様
  • 旧来の Java EE / Java 8 ベースの業務アプリをモダナイズしたい方

本ハンズオンで実施すること

  1. 移行ツールによる診断
    Migration Toolkit for Application Binaries を用いて WAR ファイルを診断し、移行上の問題点を把握します。IBM はこのツールを、ソースコードにアクセスせずに WAR/EAR を迅速に評価するコマンドラインツールとして提供しています。

  2. 自動修正 + 手動修正
    移行レポートに基づいて、OpenRewrite による自動修正と、必要箇所の手動修正を行います。

  3. Open Liberty 上での実行・検証・パッケージング
    Liberty Maven Plugin を利用して Open Liberty 上でアプリケーションを起動し、最後に配布可能な ZIP パッケージを作成します。

2. 概要

2-1. WAS traditional (tWAS) と Open Liberty の概要

WAS traditional (tWAS)

tWAS は、長年、多くの企業システムを支えてきた Java EE ベースのアプリケーションサーバーです。特に基幹系・業務系システムにおいて、高い信頼性と豊富な実績を持ち、オンプレミス環境を中心に広く利用されてきました。
tWAS は、Java EE のフルスタック実装を前提とした設計になっており、エンタープライズ用途に必要な機能を包括的に提供します。一方で、比較的重厚なアーキテクチャを前提としており、サーバーの起動時間やメモリ使用量は大きくなる傾向があります。
近年では、クラウドやコンテナといった環境の普及により、「小さく起動し、必要に応じて素早くスケールする」アプリケーションが求められるようになっています。しかし、tWAS の設計思想はこれらの環境を前提としていないため、CI/CD パイプラインへの組み込みや、コンテナ化・マイクロサービス化においては、運用・構成面での工夫や追加コストが必要になるケースがあります。
また、多くの既存アプリケーションは Java EE 8 / Java 8 を前提としており、新しい Jakarta EE や最新 Java バージョンへの追従が課題となることも少なくありません。これらの背景から、既存資産を活かしつつ、より現代的な実行環境へ移行したいというニーズが高まっています。

Open Liberty

Open Liberty は、IBM が提供する軽量かつモダンな Java ランタイムであり、クラウドネイティブなアプリケーションの実行を目的として設計されています。オープンソースとして開発されており、Jakarta EE および MicroProfile の仕様に準拠しています。
Open Liberty の大きな特徴は、「必要な機能だけを有効化する」徹底的にモジュール化された設計です。アプリケーションで使用する機能のみを構成ファイルで指定することで、起動時間の短縮やメモリ使用量の削減を実現できます。この特性により、コンテナ環境での利用に非常に適しています。
また、高速起動・軽量であることから、CI/CD パイプラインへの組み込みを前提とした運用にも向いています。従来のアプリケーションサーバーと比較して、開発・テスト・本番の各環境をよりシンプルな構成で統一できる点も利点の一つです。
既存の Java EE アプリケーションについても、多くの場合は Open Liberty 上で動作させることが可能です。一方で、Java EE から Jakarta EE への名前空間変更 (javax.* から jakarta.*) など、アプリケーションの修正が必要となるケースもあります。これに対して IBM は、Migration Toolkit といった、移行支援ツールを提供しており、診断・修正・検証を段階的に進めることができます。
このように Open Liberty は、既存の Java 資産を活かしながら、クラウドネイティブなアーキテクチャへ移行するための現実的な選択肢として位置づけられています。

2-2. WAS traditional (tWAS) から Open Liberty 移行による効果

アプリケーション・モダナイゼーションによる運用コストの最適化
Liberty への移行により、軽量かつ構成柔軟性の高い実行基盤を採用できるため、従来環境と比較してミドルウェア運用の複雑性を低減できます。
これにより、構成管理、保守作業、障害対応、継続的デリバリーに伴う運用負荷を軽減し、トータルの運用コスト最適化が期待できます。

クラウド・コンテナ活用によるシステム基盤の柔軟性向上
Open Liberty はコンテナ技術およびクラウド環境との親和性が高く、スケーラブルかつ可搬性の高いシステム構成を実現できます。
これにより、需要変動への柔軟な対応、環境間差異の抑制、迅速なデプロイ、およびハイブリッド/マルチクラウド展開への適応力向上が見込まれます。

軽量ランタイムを活用したセキュリティおよびパフォーマンスの向上
必要機能のみを選択して利用可能な Open Liberty の特性により、起動性能、リソース効率、保守性の向上が期待できます。
加えて、不要な機能を排除したシンプルな構成により攻撃対象領域を抑制し、継続的なセキュリティアップデート適用を通じて、より安全かつ安定したアプリケーション運用が可能となります。

2-3. ハンズオンの全体像

本ハンズオンは、以下の 3 ステップで構成されます。

  1. 診断
    自分でビルドした modresorts-2.0.0.war を Migration Toolkit for Application Binaries にかけて、問題点を抽出します。IBM はこのツールを WAR/EAR 評価用のコマンドラインツールとして提供しています。

  2. 修正
    OpenRewrite を用いた自動修正と、移行レポートに基づく手動修正を行います。

  3. 検証
    Open Liberty 上でアプリを実行し、期待する URL にアクセスして動作を確認した後、ZIP へパッケージングします。

2-4. ハンズオンの全体像図

下記にハンズオンの全体像を示す2つの図を添付します。

1つ目は、ハンズオンの全体像を3ステップの流れベースで図に示したものです。

photo_architecture.png

2つ目は、ハンズオンの全体像を操作の流れベースで図に示したのものです。

スクリーンショット 2026-04-15 13.32.11.png

2-5. ハンズオンのゴール

  • tWAS アプリケーションの WARファイル を診断し、修正点を把握できる
  • OpenRewrite による自動修正を適用できる
  • 手動修正が必要な箇所をレポートから読み解ける
  • Open Liberty 上でアプリケーションを起動し、期待 URL で応答を確認できる
  • 最終成果物として ZIP パッケージを生成できる

3. 必要な環境と事前準備

3-1. 必要な環境

インターネット接続

以下の作業でインターネット接続が必要です。

  • GitHub から sample-app-mod を取得する
  • Homebrew で JDK と Maven をインストールする
  • IBM から Migration Toolkit for Application Binaries をダウンロードする

WebSphere Application Server v9の既存環境

本ハンズオンではWebSphere Application Server traditional 9 を使用し、was_public を取り出す必要があります。

既存のtWAS環境がない場合は、Windows もしくは Linux などの対応 OS 環境を別途利用し、was_public.jar の取得用に tWAS環境を構築する必要があります。

OS

本ハンズオンの作業端末は macOS を想定します。

Homebrew

Homebrew がインストールされていることを確認してください。

brew --version

出力例:

Homebrew 4.x.x

表示されない場合は、Homebrew 公式サイトの手順に従ってインストールしてください。
https://brew.sh/ja/

Visual Studio Code

IDE として Visual Studio Code を使用します。最新バージョンを推奨します。

本資料執筆時の検証環境(例)

  • チップ – Apple M1 Pro
  • メモリ – 16GB
  • OS – macOS Sequoia 15.7.1
  • Homebrew – 4.6.13
  • Git – 2.50.1
  • JDK (Java Development Kit) - IBM Semeru Runtime Open Edition 21.0.7.0-m2
  • Apache Maven – Apache Maven 3.9.10

3-2. 事前準備

3-2-1. 作業用ディレクトリの作成

Desktopに java_project フォルダを作成します。

mkdir ~/Desktop/java_project
cd ~/Desktop/java_project

続いて、補助用ディレクトリを作成します。

mkdir twas_files
mkdir liberty_file

3-2-2. GitHub から移行元アプリケーションを取得

gitがインストールされていない場合は、まず以下のコマンドでインストールしてください。

brew install git

IBM のサンプルアプリケーション sample-app-mod をクローンします。

git clone https://github.com/IBM/sample-app-mod.git

java_project 配下に sample-app-mod ディレクトリが作成されていることを確認してください。

3-2-3. JDK 21 (IBM Semeru) のインストール

本ハンズオンでは移行先 Java として 21 を使用します。
IBM Semeru Runtimes の公式サイト (インストール手順を確認可能):
https://www.ibm.com/support/pages/semeru-runtimes-installation

今回は、移行先の Java バージョンが 21 であるため、IBM Semeru Runtimes 21 をインストールします。

brew install --cask semeru-jdk-open@21
java --version

出力例:

openjdk version "21.x.x" ...
IBM Semeru Runtime Open Edition ...

3-2-4. Apache Maven のインストール

今回の Java で開発された Web アプリケーションを開発・実行するためには、Apache Maven をインストールすることで便利になります。

Apache Maven とは、Java プロジェクトのビルド、依存関係管理・テストなどを自動化するためのビルドツールです。したがって、Apache Maven をインストールすることで、Liberty における開発・実行で、手動作業を省力化し、再現性と効率を大幅に向上させることができます。

また、Liberty では,アプリケーションを実行するサーバーをあらかじめ導入しておく必要はありません。Maven のプロジェクト構成ファイル (pom.xml) を組み込むと、Maven のビルド時に環境を自動構築することや、パッケージ作成時にアプリと Liberty ランタイム、構成ファイルをまとめて導入することができる単一の ZIP を作成することができます。

ターミナル の任意のディレクトリで、下記コマンドを実行して、Apache Maven をインストールしてください。

brew install maven
mvn --version

出力例:

Apache Maven <version 名>

3-2-5. Migration Toolkit for Application Binaries のダウンロード

IBM 公式サイトから Migration Toolkit for Application Binaries をダウンロードします。

Migration Toolkit for Application Binaries は、古いバージョンのアプリケーションサーバー (例えば、WAS traditional や JBoss、Tomcat など) から新しいバージョンのアプリケーションサーバーに移行する際のツールです。

この移行ツールにはスキャン機能が含まれており、アプリケーションのバイナリを迅速に評価し、例えば、WebSphere Application Server traditional から Liberty への迅速なデプロイを可能にします。

このコマンドラインツールを使用することで、管理者はソースコードにアクセスすることなく、数分でアプリケーションを評価できます。

なお、スキャンは本番環境ではなく、常にテスト環境で実行することを推奨します。

Migration Toolkit for Application Binaries の公式サイト:
https://www.ibm.com/support/pages/migration-toolkit-application-binaries

※ Migration Toolkit for Application Binaries を IBM の公式サイトでダウンロードするためには、IBMid の取得が必要です。

Migration Toolkit for Application Binaries をインストールするため、上記に添付したリンク先の「Installation Instructions」に記されている手順を実施してください。

まず、Download package で Migration Toolkit for Application Binaries のダウンロードボタンを押下してください。

3.png

ライセンス情報を確認し、同意する場合は I agree を押下してください。

4.png

Downloads フォルダに保存されたことを確認してください。

6.png

Downloads フォルダに保存された binaryAppScannerInstaller.jar ファイルをドラッグ&ドロップなどの方法を用いて、java_project フォルダ内に移動してください。

java_project ディレクトリで下記コマンドを実行して、 jar ファイルを解凍してください。

java -jar binaryAppScannerInstaller.jar

実行後、インストラクションにしたがってください。
まず、ライセンス条項を表示して閲覧するために Enter を押下して、確認してください。

9.png

追加のライセンス情報を表示するために Enter を押下して、確認してください。

7.png

ライセンス情報を確認し、同意する場合は 1 を入力後、Enter を押下してください。

10.png

デフォルトのターゲット・ディレクトリーのままでよいので、そのまま Enter を押下してください。
java_project フォルダ内に wamt フォルダが生成されていれば完了です。

3-2-6. was_public を 各自取得する

今回使用するsample-app-mod の main ブランチは、WebSphere Application Server 固有 API に依存しています。そのため、最初の mvn clean package を成功させるには、was_public.jar と対応する POM を ローカル Maven リポジトリへ登録する必要があります。

WebSphere Application Server traditional 9 の対応 OS 一覧に macOS は含まれません。したがって、以下のいずれかで対応してください。

  • 方法 A(推奨): 既に組織内にある Windows / Linux 上の tWAS 9 導入済み環境から was_public.jarwas_public-9.0.0.pom を取得し、Mac にコピーする
  • 方法 B: Windows / Linux の別マシンや仮想環境に IBM サイトから tWAS 9 を導入し、その導入済み環境からファイルを取得して Mac にコピーする

3-2-6-1. was_public.jarwas_public-9.0.0.pom を取り出す

was_public.jar とwas_public-9.0.0.pomWebSphere Application Server 導入ディレクトリの dev フォルダに配置されています。

典型例として /opt/WebSphere/AppServer/dev を確認してください。

典型例:

/opt/WebSphere/AppServer/dev/was_public.jar
/opt/WebSphere/AppServer/dev/was_public-9.0.0.pom

Maven に登録する際は JAR をバージョンに合わせて was_public-9.0.0.jar のようにリネームしてください

例: 対応 OS 側でファイルを退避

cp /opt/WebSphere/AppServer/dev/was_public.jar /tmp/was_public-9.0.0.jar
cp /opt/WebSphere/AppServer/dev/was_public-9.0.0.pom /tmp/

Mac へコピー

was_public-9.0.0.jarwas_public-9.0.0.pomは、java_project/twas_files 下へ移動してください。

例:

scp /tmp/was_public-9.0.0.jar <your-mac>:~/Desktop/java_project/twas_files/
scp /tmp/was_public-9.0.0.pom <your-mac>:~/Desktop/java_project/twas_files/

3-2-6-2. Mac 側のローカル Maven リポジトリへ登録

sample-app-mod README にあるとおり、mvn install:install-file を使って local Maven repository (~/.m2/repository) に登録します。

cd ~/Desktop/java_project/sample-app-mod
mvn install:install-file \
  -Dfile=../twas_files/was_public-9.0.0.jar \
  -DpomFile=../twas_files/was_public-9.0.0.pom

これで、sample-app-mod のビルド時に WebSphere 固有 API 依存が解決されます。

3-2-7. ビルドによる war ファイルの生成

上記手順によってビルドが問題なく実行可能かどうか確認します。

mvn clean package

生成確認:

ls target/modresorts-2.0.0.war

以降のハンズオンでは、まず最初にこちらの war ファイルを分析していきます。

4. ハンズオン

4-1. Migration Toolkit for Application Binaries で修正点確認

移行元アプリケーションの war ファイル (modresorts-2.0.0.war) を移行ツール (Migration Toolkit for Application Binaries) にかけます。
下記コマンドを実行して、アプリケーション・マイグレーション・レポートを取得してください (コマンドを実行すると、レポートが自動で Web ブラウザに表示されます)。

cd ~/Desktop/java_project/wamt
java -jar binaryAppScanner.jar ../sample-app-mod/target/modresorts-2.0.0.war \
  --all \
  --sourceAppServer=was90 \
  --targetJava=java21

レポートがブラウザに表示されたら、以下を確認します。

  • 「深刻な」(Critical) 問題の件数
  • 自動修正可能な項目(歯車アイコン)
  • 手動修正が必要な項目

ここからは、レポートで出てきた深刻なエラー6つを修正していきます。

11.png

ラベルにある深刻なボタンを押下し、自動修正できるものと手動修正しなければならないものを確認してください。
自動修正できるものには歯車のアイコンが表示されます。

12.png

4-2. OpenRewrite で自動修正

OpenRewrite は、Maven / Gradle から利用できる自動リファクタリングツールです。

移行レポートには、必要な自動修正構成が表示されます。

手順 1: 移行レポートから OpenRewrite の設定を取得

アプリケーション・マイグレーション・レポートにある自動修正構成を確認します。4-1 で生成したアプリケーション・マイグレーション・レポートを下にスクロールして、自動修正構成を sample-app-mod にある pom.xml ファイルに、既存のコードを消さずに、コピー&ペースト (追加) してください。
※  <plugins></plugins> の間の適切な箇所にコピー&ペーストしてください (ここで示す適切な箇所とは、<plugins> の直後を指します)。

14.png

手順 2: OpenRewrite 実行

OpenRewrite を使用して自動修正を行います。

cd ~/Desktop/java_project/sample-app-mod
mvn rewrite:run

手順 3: ビルド

mvn clean package

手順 4: 修正後 WAR を再スキャン

再度レポートを生成します。

cd ~/Desktop/java_project/wamt
java -jar binaryAppScanner.jar ../sample-app-mod/target/modresorts-2.0.0.war \
  --all \
  --sourceAppServer=was90 \
  --targetJava=java21

「深刻な」の件数が減っていることを確認してください。

15.png

4-3. レポートを参照して手動修正

自動修正後も、手動で修正が必要な項目が残ります。レポートの 「規則のヘルプの表示」「結果の表示」 を使って、詳細を確認してください。

16.png

ここから先の手順では、残る2つの問題について、手動での修正を実施していきます。

1つ目: DMBeanUtils.java の修正

対象ファイル: sample-app-mod/src/main/java/com/acme/modres/mbean/DMBeanUtils.java

レポートでは、MBeanOperationInfo コンストラクターに関する変更が指摘されます。

17.png

getOps() メソッド内の生成部分を try / catch で囲みます。

DMBeanUtils.java の修正後のソースコードは下記の通りです。
全体をコピー&ペーストして元のソースコードを置き換えてください。

package com.acme.modres.mbean;

import java.util.logging.Level;
import java.util.logging.Logger;

import javax.management.MBeanOperationInfo;

public final class DMBeanUtils {
  private static final Logger logger = Logger.getLogger(DMBeanUtils.class.getName());

  public static MBeanOperationInfo[] getOps(OpMetadataList opList) {
    MBeanOperationInfo[] ops = null;
    if (opList == null || opList.getOpMetadatList() == null) {
      logger.log(Level.WARNING, "No operation is configured");
      return ops;
    }

    int numOps = opList.getOpMetadatList().size();
    if (numOps > 0) {
      ops = new MBeanOperationInfo[numOps];
      int i = 0;
      for (OpMetadata opMetadata : opList.getOpMetadatList()) {
        String name = opMetadata.getName();
        String desc = opMetadata.getDescription();
        String type = opMetadata.getType();
        int impact = opMetadata.getImpact();

        MBeanOperationInfo opInfo = null;
        try {
          opInfo = new MBeanOperationInfo(name, desc, /* signature */ null, type, impact, /* descriptor */ null);
        }
        catch (IllegalArgumentException iae) {
          iae.printStackTrace();
        }

        ops[i++] = opInfo;
      }
    }

    return ops;
  }
}

修正後、以下を実行します。

cd ~/Desktop/java_project/sample-app-mod
mvn clean package

続いて再スキャン:

cd ~/Desktop/java_project/wamt
java -jar binaryAppScanner.jar ../sample-app-mod/target/modresorts-2.0.0.war \
  --all \
  --sourceAppServer=was90 \
  --targetJava=java21

レポートを見て、「深刻な」の数が減っていることを確認してください。

00.png

2つ目: UpperServlet.java の修正

対象ファイル: sample-app-mod/src/main/java/com/acme/modres/UpperServlet.java

レポートでは、WAS 固有の ResponseUtils に依存する処理が問題として出ます。

Liberty では同等メソッドが使えないため、HTML エスケープ処理を自前実装して回避します。

01.png

UpperServlet.java の修正後のソースコードは下記の通りです。
以下のソースコードをコピーして、元のソースコード全体を置き換えてください。

package com.acme.modres;

import java.io.IOException;
import java.io.PrintWriter;
import java.io.Serial;

import javax.servlet.ServletException;
import javax.servlet.annotation.WebServlet;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import com.ibm.websphere.servlet.response.ResponseUtils;

@WebServlet("/resorts/upper")
public class UpperServlet extends HttpServlet {

  @Serial
  private static final long serialVersionUID = 1L;

  @Override
  protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {
    response.setContentType("text/html");

    String originalStr = request.getParameter("input");
    if (originalStr == null) {
      originalStr = "";
    }

    String newStr = originalStr.toUpperCase();
    newStr = escapeHtml(newStr);

    PrintWriter out = response.getWriter();
    out.print("<br/><b>upper case input " + newStr + "</b>");
  }

  private String escapeHtml(String str) {
    StringBuffer escapeStr = new StringBuffer();
    
    for (int i = 0; i < str.length(); i++) {
      char c = str.charAt(i);
      if (c == '<') {
          escapeStr.append("&lt;");
      } else if (c == '>') {
          escapeStr.append("&gt;");
      } else if (c == '+') {
          escapeStr.append("&#43;");
      } else if (c == '&') {
          escapeStr.append("&amp;");
      } else if (c == '"') {
          escapeStr.append("&quot;");
      } else if (c == '\'') {
          escapeStr.append("&#39;");
      } else if (c == '(') {
          escapeStr.append("&#40;");
      } else if (c == ')') {
          escapeStr.append("&#41;");
      } else if (c =='%') {
          escapeStr.append("&#37;");
      } else if (c == ';') {
          escapeStr.append("&#59;");
      } else {
          escapeStr.append(c);
      }
    }
    return escapeStr.toString();
  }
}

修正後に再ビルド:

cd ~/Desktop/java_project/sample-app-mod
mvn clean package

再スキャン:

cd ~/Desktop/java_project/wamt
java -jar binaryAppScanner.jar ../sample-app-mod/target/modresorts-2.0.0.war \
  --all \
  --sourceAppServer=was90 \
  --targetJava=java21

レポートを見て、「深刻な」が 0 になっていることを確認してください。

02.png

4-4. アプリ実行・動作確認

ここでは、修正した WAR ファイルを Open Liberty 上で実際に動かすための設定を行います。

移行・修正したアプリケーションを Open Liberty 用の実行環境に載せて、動作確認できる状態にすることを目的としています。

手順1: server.xmlの配置

ここでは、 server.xml を配置し、Open Liberty 上でアプリケーションを起動します。

server.xml は、Liberty で有効化する機能、待受ポート、デプロイするアプリケーションを定義するための構成ファイルです。

sample-app-modsrc/main/liberty/config/ に、以下の server.xml を追加してください。

<?xml version="1.0" encoding="UTF-8"?>
<server description="binaryAppScanner で生成された構成">
    <featureManager>
        <feature>appSecurity-2.0</feature>
        <feature>cdi-1.2</feature>
        <feature>ejbLite-3.2</feature>
        <feature>jdbc-4.1</feature>
        <feature>jndi-1.0</feature>
        <feature>jsp-2.3</feature>
        <feature>localConnector-1.0</feature>
        <feature>servlet-3.1</feature>
    </featureManager>

    <applicationManager autoExpand="true"/>

    <httpEndpoint host="${httpEndpoint_host}" httpPort="${httpEndpoint_port}" httpsPort="${httpEndpoint_secure_port}" id="defaultHttpEndpoint"/>

    <webApplication contextRoot="/resorts" id="modresorts-2_0_0_war.ear" location="modresorts-2.0.0.war"/>

    <transaction propogatedOrBMTTranLifetimeTimeout="300"/>

    <!-- <keyStore id="NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774" location="${NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774_location}" password="${NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774_password}"/> -->

    <!-- <keyStore id="CellDefaultTrustStore_was905Cell01_KeyStore_2" location="${CellDefaultTrustStore_was905Cell01_KeyStore_2_location}" password="${CellDefaultTrustStore_was905Cell01_KeyStore_2_password}"/> -->

    <!-- <ssl id="NodeDefaultSSLSettings_was905Cell01_SSLConfig_1736241206774" keyStoreRef="NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774" sslProtocol="${NodeDefaultSSLSettings_was905Cell01_SSLConfig_1736241206774_sslProtocol}" trustStoreRef="CellDefaultTrustStore_was905Cell01_KeyStore_2"/> -->

    <!-- <sslDefault sslRef="NodeDefaultSSLSettings_was905Cell01_SSLConfig_1736241206774"/> -->

    <variable name="CellDefaultTrustStore_was905Cell01_KeyStore_2_location" defaultValue="modresorts-2_0_0_war_ear_was905Cell01_CellDefaultTrustStore_trust.p12"/>
    <variable name="httpEndpoint_host" defaultValue="*"/>
    <variable name="httpEndpoint_port" defaultValue="9080"/>
    <variable name="httpEndpoint_secure_port" defaultValue="9443"/>
    <variable name="NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774_location" defaultValue="modresorts-2_0_0_war_ear_was905Node01_NodeDefaultKeyStore_key.p12"/>
    <variable name="NodeDefaultSSLSettings_was905Cell01_SSLConfig_1736241206774_sslProtocol" defaultValue="TLSv1.3,TLSv1.2"/>

    <variable name="CellDefaultTrustStore_was905Cell01_KeyStore_2_password" defaultValue=""/>
    <variable name="NodeDefaultKeyStore_was905Cell01_KeyStore_1736241206774_password" defaultValue=""/>
</server>

手順 2: pom.xml に Liberty Maven Plugin を追加

次に、pom.xml に Liberty Maven Plugin を追加することで、Maven から Open Liberty の起動・開発実行・パッケージングを行えるようにします。

下記に記載したOpen Liberty の plugin を sample-app-mod 下にある pom.xml ファイルに、既存のコードを消さずに、コピー&ペースト (追加) してください。

※   <plugins></plugins> の間に適切にコピー&ペーストしてください (ここで示す適切な箇所とは、 <plugins> の直後、または、</plugin> の直後を指します。

<plugin>
    <groupId>io.openliberty.tools</groupId>
    <artifactId>liberty-maven-plugin</artifactId>
    <version>3.11.5</version>
    <configuration>
        <runtimeArtifact>
            <groupId>io.openliberty</groupId>
            <artifactId>openliberty-kernel</artifactId>
            <version>25.0.0.12</version>
            <type>zip</type>
        </runtimeArtifact>
    </configuration>
</plugin>

手順 3: ビルド

cd ~/Desktop/java_project/sample-app-mod
mvn clean package

手順 4: サーバー起動

mvn liberty:dev

手順 5: 動作確認

任意の Web ブラウザで、下記リンク先にアクセスして、アプリーケーションが正常に動くことを確認してください。

アプリケーションが正常に動作しているかどうかを確認する手順は下記の通りです。

Web アプリケーションのホーム画面です。

20.png

Where to? で Paris, France を選択すると、天気情報が表示されることを確認できます。

21.png

日程を選択して、Reserve ボタンを押下すると予約確認ができます。

22.png

最後に、control + c でサーバーを止めます。

4-5. パッケージング

修正済みアプリケーションを ZIP としてパッケージングし、他環境へ配布可能な形にします。

mvn liberty:package

実行後、target 配下に modresorts-2.0.0.zip が生成されます。

この ZIP は、Java 実行環境がある別環境へ配布して利用できます。

4-6. 検証と動作確認

ここでは、生成した ZIP を模擬的に同一端末上で展開し、起動確認を行います。

modresorts-2.0.0.zip を解凍します。

cd target
unzip modresorts-2.0.0.zip

ターミナルで wlp ディレクトリへ移動します。

cd wlp

サーバーを起動します。

./bin/server start

ブラウザで以下へアクセスし、動作確認を行います。

問題なく画面が表示されれば、ZIP パッケージとしての実行確認は完了です。

5. まとめと次のステップ

本ハンズオンでは、WebSphere Application Server traditional 向けアプリケーションを Open Liberty へ移行する流れを、診断 → 自動修正 → 手動修正 → 実行 → パッケージングの順に体験しました。
sample-app-mod は IBM が移行教材として提供しており、WAS 固有 API 依存を解消しながら Liberty + 新しい Java へ進むイメージを掴むのに適しています。

次のステップ

  • 本番環境への適用に向けた負荷試験やセキュリティ設定などの追加検証
  • CI / CD パイプラインへの統合
  • OpenShift や Kubernetes などへのデプロイによるコンテナ化

さいごに

本ハンズオンに対する皆さんからの感想やご質問、発生したトラブルなどを気軽にコメントいただけますと幸いです。
適宜こちらのハンズオンをアップデートしていきます。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?