JBoss EAP を使用して Azure Red Hat OpenShift クラスターに Java アプリケーションを手動でデプロイする

この記事では、Red Hat JBoss Enterprise Application Platform (EAP) アプリケーションを Azure Red Hat OpenShift クラスターにデプロイする方法について説明します。 このサンプルは、SQL データベースを基盤とする Java アプリケーションです。 このアプリは、 JBoss EAP Helm チャート を使用してデプロイされます。

このガイドでは、以下の方法について説明します。

サンプル アプリケーションは、HTTP セッションに情報を格納するステートフル アプリケーションです。 これは、JBoss EAP クラスタリング機能を利用し、Jakarta EE と MicroProfile の以下のテクノロジを使用します。

• Jakarta Server Faces
• Jakarta Enterprise Beans
• Jakarta Persistence
• MicroProfile Health

この記事は、Azure Red Hat OpenShift クラスターで JBoss EAP アプリを実行するためのステップバイステップの手動ガイダンスです。 Azure Red Hat OpenShift クラスターへの取り組みを加速させるより自動化されたソリューションについては、「クイック スタート: Azure portal を使用して Azure Red Hat OpenShift に JBoss EAP をデプロイする」を参照してください。

JBoss EAP on Azure ソリューションを開発しているエンジニアリング チームとフィードバックを提供したり、移行シナリオに密接に取り組んだりすることに関心がある場合は、JBoss EAP 移行に関するこの短いアンケートに記入し、連絡先情報を含めてください。 プログラム マネージャー、アーキテクト、エンジニアのチームは、すぐに連絡を取り、緊密なコラボレーションを開始します。

前提条件

1. インストールされているさまざまな製品 (Ubuntu、macOS、または Windows Subsystem for Linux など) でサポートされている Unix のようなオペレーティング システムを搭載したローカル コンピューターを準備します。

2. Java Standard Edition (SE) 実装をインストールします。 この記事のローカル開発手順は、OpenJDK の Microsoft ビルドの Java Development Kit (JDK) 17 でテストされました。

3. Maven 3.8.6 以上をインストールします。

4. Azure CLI 2.40 以降をインストールします。

5. このデモ アプリケーション (todo-list) のコードを、お使いのローカル システムにクローンします。 デモ アプリケーションは GitHub にあります。

6. Azure Red Hat OpenShift 4 クラスターの作成に関するページの手順に従います。

   "Red Hat プル シークレットを取得する" 手順は省略可能のラベルが付いていますが、この記事には必須です。 プル シークレットを使用すると、Azure Red Hat OpenShift クラスターで、JBoss EAP アプリケーション イメージを見つけることができます。

   クラスターでメモリを集中的に使用するアプリケーションを実行する予定の場合は、--worker-vm-size パラメーターを使用して、ワーカー ノードにとって適切な仮想マシン サイズを指定します。 詳細については、以下を参照してください:

   • クラスターを作成するための Azure CLI
   • メモリ最適化でサポートされる仮想マシンのサイズ

7. Azure Red Hat OpenShift 4 クラスターへの接続に関するページの手順に従って、クラスターに接続します。

   • 「OpenShift CLI をインストールする」の手順に従います
   • ユーザー kubeadmin として、OpenShift CLI を使用して Azure Red Hat OpenShift クラスターに接続します

8. 次のコマンドを実行して、このデモ アプリケーションのための OpenShift プロジェクトを作成します。

   oc new-project eap-demo
   

9. 次のコマンドを実行して、既定のサービス アカウントに view ロールを追加します。 このロールが必要なのは、アプリケーションで他のポッドを検出し、それらを備えたクラスターをセットアップできるようにするためです。

   oc policy add-role-to-user view system:serviceaccount:$(oc project -q):default -n $(oc project -q)
   

アプリケーションを準備する

次のコマンドを使用して、サンプル アプリケーションを複製します。

git clone https://github.com/Azure-Samples/jboss-on-aro-jakartaee

Todo-list デモ アプリケーションをクローンしたので、ローカル リポジトリは main ブランチ上にあります。 デモ アプリケーションは、Azure SQL でレコードを作成、読み取り、更新、削除する単純な Java アプリです。 ローカル マシンにインストールされている JBoss EAP サーバーに、このアプリケーションをそのままでデプロイできます。 必要なのは、必要なデータベース ドライバーとデータ ソースを使用してサーバーを構成することだけです。 ローカル環境からアクセスできるデータベース サーバーも必要です。

ただし、OpenShift をターゲットにしている場合は、JBoss EAP サーバーの機能をトリミングすることをお勧めします。 たとえば、プロビジョニングされたサーバーのセキュリティの露出を減らし、全体的なフットプリントを減らすことができます。 また、OpenShift 環境での実行により適したアプリケーションとするため、いくつかの MicroProfile 仕様を含めることもできます。 JBoss EAP を使用する場合、このタスクを実行する 1 つの方法は、アプリケーションとサーバーを Bootable JAR と呼ばれる単一のデプロイメント ユニットにパッケージ化することです。 デモ アプリケーションに必要な変更を追加して、これを行いましょう。

デモ アプリケーションのローカル リポジトリに移動し、ブランチを bootable-jar に変更します。

## cd jboss-on-aro-jakartaee
git checkout bootable-jar

このブランチで変更した内容を簡単に確認してみましょう。

• wildfly-jar-maven プラグインを追加して、サーバーとアプリケーションを 1 つの実行可能な JAR ファイルにプロビジョニングしました。 OpenShift のデプロイ単位は、アプリケーションがあるサーバーです。
• Maven プラグインに対して、一連の Galleon レイヤーを指定しました。 この構成により、サーバーの機能を削って必要な機能だけにすることができます。 Galleon に関する完全なドキュメントについては、WildFly のドキュメントを参照してください。
• このアプリケーションは Ajax リクエストで Jakarta Faces を使用しているため、HTTP セッションに情報が格納されます。 このような情報を、ポッドが削除された場合に失いたくはありません。 この情報をクライアントに保存すれば、要求ごとに送り返すことができます。 ただし、クライアントには一定の情報を配布しないという決定を下す場合もあります。 このデモでは、すべてのポッド レプリカにわたってセッションをレプリケートすることを選択しました。 これを行うために、<distributable /> を web.xml に追加しました。 これにより、サーバーのクラスタリング機能とともに、HTTP セッションがすべてのポッドに配布可能になります。
• 2 つの MicroProfile 正常性チェックを追加しました。これらのチェックにより、アプリケーションがいつライブになっていて要求の受信準備ができているかを識別できます。

ローカルでアプリケーションを実行する

アプリケーションを OpenShift にデプロイする前に、ローカルで実行して動作を確認します。 次の手順では、Azure SQL Server が実行されていて、ローカル環境から使用できることを前提としています。

データベースを作成するには、「クイック スタート: Azure SQL Database の単一データベースを作成する」の手順に従いますが、次の置換を使用します。

• [リソース グループ] には、前に作成したリソース グループを使用します。
• [データベース名] には todos_db を使用します。
• [サーバー管理者ログイン] には azureuser を使用します。
• [パスワード] には Passw0rd! を使用します。
• [ファイアウォール規則] セクションで、[Azure サービスおよびリソースにこのサーバーへのアクセスを許可する] を [はい] に切り替えます。

その他の設定はすべて、リンクされた記事から安全に使用できます。

[追加設定] ページで、データベースにサンプル データを事前に設定するオプションを選択する必要はありませんが、そうしても害はありません。

データベースを作成したら、概要ページからサーバー名の値を取得します。 [サーバー名] フィールドの値の上にマウス ポインターを置き、値の横に表示されるコピー アイコンを選択します。 後で使用するために、この値を保存します。(この値に MSSQLSERVER_HOST という名前の変数を設定します)。

以下の手順に従って、ローカルでアプリケーションをビルドして実行します。

1. 起動可能な JAR をビルドします。 MS SQL Server データベースで eap-datasources-galleon-pack を使用しているため、この特定の環境変数で使用するデータベース ドライバーのバージョンを指定する必要があります。 eap-datasources-galleon-pack および MS SQL Server の詳細については、Red Hat の「」ドキュメントを参照してください

   export MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11
   mvn clean package
   

2. 以下のコマンドを使用して、起動可能な JAR を起動します。

   Azure SQL データベースで、このサーバーが実行されているホストからのネットワーク トラフィックが許可されていることを確認する必要があります。 「クイック スタート: Azure SQL Database の単一データベースを作成する」の手順を実行するときに [現在のクライアント IP アドレスを追加する] を選択したため、サーバーが実行されているホストが、Azure portal へのブラウザーの接続元と同じホストである場合は、ネットワーク トラフィックを許可する必要があります。 サーバーが実行されているホストが他のホストである場合は、「Azure portal を使用してサーバー レベルの IP ファイアウォール規則を管理する」を参照する必要があります。

   アプリケーションを起動するときは、データソースを構成するために必要な環境変数を渡す必要があります。

   export MSSQLSERVER_USER=azureuser
   export MSSQLSERVER_PASSWORD='Passw0rd!'
   export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds
   export MSSQLSERVER_DATABASE=todos_db
   export MSSQLSERVER_HOST=<server name saved aside earlier>
   export MSSQLSERVER_PORT=1433
   mvn wildfly-jar:run
   

   このデモで使用される基になるランタイムの詳細については、データソースを統合するための Galleon Feature Pack のドキュメントに記載された、使用可能な環境変数の完全な一覧を参照してください。 Feature Pack の概念の詳細については、WildFly のドキュメントを参照してください。

   次の例のようなテキストのエラーが表示された場合:

   Cannot open server '<your prefix>mysqlserver' requested by the login. Client with IP address 'XXX.XXX.XXX.XXX' is not allowed to access the server.
   

   このメッセージは、ネットワーク トラフィックが許可されていることを確認する手順が機能しなかったことを示します。 エラー メッセージの IP アドレスがファイアウォール規則に含まれていることを確認します。

   次の例のようなテキストのメッセージが表示された場合:

   Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: There is already an object named 'TODOS' in the database.
   

   このメッセージは、サンプル データが既にデータベースに存在することを示します。 このメッセージは無視してかまいません。

3. (省略可能) クラスタリング機能を検証する場合は、起動可能な JAR に jboss.node.name 引数を渡して同じアプリケーションのインスタンスをより多く起動し、jboss.socket.binding.port-offset を使用してポート番号を移動することでポート番号の競合を回避することもできます。 たとえば、OpenShift で新しいポッドを表す 2 番目のインスタンスを起動するには、新しいターミナル ウィンドウで次のコマンドを実行します。

   export MSSQLSERVER_USER=azureuser
   export MSSQLSERVER_PASSWORD='Passw0rd!'
   export MSSQLSERVER_JNDI=java:/comp/env/jdbc/mssqlds
   export MSSQLSERVER_DATABASE=todos_db
   export MSSQLSERVER_HOST=<server name saved aside earlier>
   export MSSQLSERVER_PORT=1433
   mvn wildfly-jar:run -Dwildfly.bootable.arguments="-Djboss.node.name=node2 -Djboss.socket.binding.port-offset=1000"
   

   クラスターが動作している場合は、サーバー コンソール ログに次のようなトレースが表示されます。

   INFO  [org.infinispan.CLUSTER] (thread-6,ejb,node) ISPN000094: Received new cluster view for channel ejb
   

   Note

   既定では、起動可能な JAR により、JGroups サブシステムは UDP プロトコルを使用して、他のクラスター メンバーを検出するメッセージを 230.0.0.4 マルチキャスト アドレスに送信するように構成されます。 ローカル マシンのクラスタリング機能を適切に検証するには、お使いのオペレーティング システムでマルチキャスト データグラムの送受信が可能で、それらをイーサネット インターフェイス経由で 230.0.0.4 IP にルーティングする必要があります。 サーバー ログにクラスター関連の警告が示される場合は、ネットワーク構成を調査し、そのアドレスのマルチキャストがサポートされていることを確認してください。

4. ブラウザーで http://localhost:8080/ を開き、アプリケーションのホームページにアクセスします。 より多くのインスタンスを作成した場合は、たとえば http://localhost:9080/ のようにポート番号を移動させ、それらにアクセスすることができます。 アプリケーションは、次の画像のようになります。

   

5. アプリケーションの liveness probe と readiness probe を確認します。 OpenShift はこれらのエンドポイントを使用して、ポッドがいつライブになり、ユーザー リクエストを受信する準備ができているかを確認します。

   liveness の状態を確認するには、次のコマンドを実行します。

   curl http://localhost:9990/health/live
   

   次のように出力されます。

   {"status":"UP","checks":[{"name":"SuccessfulCheck","status":"UP"}]}
   

   準備状況を確認するには、次のコマンドを実行します。

   curl http://localhost:9990/health/ready
   

   次のように出力されます。

    {"status":"UP","checks":[{"name":"deployments-status","status":"UP","data":{"todo-list.war":"OK"}},{"name":"server-state","status":"UP","data":{"value":"running"}},{"name":"boot-errors","status":"UP"},{"name":"DBConnectionHealthCheck","status":"UP"}]}
   

6. Ctrl + C キーを押してアプリケーションを停止します。

OpenShift にデプロイする

アプリケーションをデプロイするには、Azure Red Hat OpenShift で既に利用可能な JBoss EAP Helm Charts を使用します。 また、必要な構成を指定する必要があります。たとえば、データベース ユーザー、データベース パスワード、使用するドライバーのバージョン、データ ソースによって使用される接続情報などです。 次の手順では、OpenShift クラスターから実行中かつアクセス可能な Azure SQL データベース サーバーがあり、mssqlserver-secret という名前の OpenShift Secret オブジェクトにデータベース ユーザー名、パスワード、ホスト名、ポート、およびデータベース名が格納されていることを前提としています。

デモ アプリケーションのローカル リポジトリに移動し、現在のブランチを bootable-jar-openshift に変更します。

git checkout bootable-jar-openshift

このブランチで変更した内容を簡単に確認してみましょう。

• クラウドでサーバーを実行するための特定の構成で起動可能な JAR を準備する、bootable-jar-openshift という名前の新しい Maven プロファイルを追加しました。 これにより、たとえば、JGroups サブシステムでネットワーク要求を使用し、KUBE_PING プロトコルによって他のポッドを検出できます。
• jboss-on-aro-jakartaee/deployment ディレクトリに、構成ファイルのセットを追加しました。 このディレクトリには、アプリケーションをデプロイするための構成ファイルがあります。

OpenShift にアプリケーションをデプロイする

次の手順では、OpenShift Web コンソールを使用して Helm Chart でアプリケーションをデプロイする方法について説明します。 'シークレット' と呼ばれる機能を使用して、Helm Chart に機密値をハード コーディングしないでください。 シークレットは単に名前=値のペアのコレクションであり、値は必要なときに事前に既知の場所で指定されます。 ここでは、Helm Chart では 2 つのシークレットが使用され、それぞれ次の名前と値のペアが含まれます。

• mssqlserver-secret

  • db-host は MSSQLSERVER_HOST の値を示します。
  • db-name は MSSQLSERVER_DATABASE の値を示します。
  • db-password は MSSQLSERVER_PASSWORD の値を示します。
  • db-port は MSSQLSERVER_PORT の値を示します。
  • db-user は MSSQLSERVER_USER の値を示します。

• todo-list-secret

  • app-cluster-password は、クラスター ノードをより安全に形成できるように、ユーザーが指定した任意のパスワードを示します。
  • app-driver-version は MSSQLSERVER_DRIVER_VERSION の値を示します。
  • app-ds-jndi は MSSQLSERVER_JNDI の値を示します。

1. mssqlserver-secret を作成します。

   oc create secret generic mssqlserver-secret \
       --from-literal db-host=${MSSQLSERVER_HOST} \
       --from-literal db-name=${MSSQLSERVER_DATABASE} \
       --from-literal db-password=${MSSQLSERVER_PASSWORD} \
       --from-literal db-port=${MSSQLSERVER_PORT} \
       --from-literal db-user=${MSSQLSERVER_USER}
   

2. todo-list-secret を作成します。

   export MSSQLSERVER_DRIVER_VERSION=7.4.1.jre11
   oc create secret generic todo-list-secret \
       --from-literal app-cluster-password=mut2UTG6gDwNDcVW \
       --from-literal app-driver-version=${MSSQLSERVER_DRIVER_VERSION} \
       --from-literal app-ds-jndi=${MSSQLSERVER_JNDI}
   

3. OpenShift コンソールを開き、開発者ビューに移動します。 このコマンドを実行すると、OpenShift クラスターのコンソール URL を検出できます。 前の手順で取得した kubeadmin ユーザー ID とパスワードを使用してログインします。

   az aro show \
       --name $CLUSTER \
       --resource-group $RESOURCEGROUP \
       --query "consoleProfile.url" \
       --output tsv
   

   ナビゲーション ウィンドウの上部にあるドロップダウン メニューで、<[/> Developer] パースペクティブを選択します。

   

4. <[/> Developer] パースペクティブで、[プロジェクト] ドロップダウン メニューから [eap-demo] プロジェクトを選択します。

   

5. [+追加] を選択します。 [Developer Catalog] セクションで、[Helm Chart] を選択します。 Azure Red Hat OpenShift クラスターで利用可能な Helm チャート カタログにアクセスします。 [Filter by keyword] ボックスに、「eap」と入力します。 次に示すように、いくつかのオプションが表示されます。

   

   このアプリケーションでは MicroProfile 機能を使用しているため、EAP XP の Helm チャートを選択します。 Xp は拡張パックを表します。 JBoss Enterprise Application Platform 拡張パックを使用すると、開発者は、Eclipse MicroProfile アプリケーション プログラミング インターフェイス (API) を使用して、マイクロサービス ベースのアプリケーションをビルドおよびデプロイできます。

6. JBoss EAP XP 4 Helm チャートを選択し、[Helm チャートのインストール] を選択します。

この時点で、アプリケーションをビルドしてデプロイするために Helm を構成する必要があります。

1. リリースの名前を eap-todo-list-demo に変更します。

2. Form View または YAML View のいずれかを使用して Helm Chart を構成できます。 [Configure via] というラベルのセクションで、[YAML View] を選択します。

3. Helm Chart を構成するために、既存の内容の代わりに deployment/application/todo-list-helm-chart.yaml で入手できる Helm Chart ファイルの内容をコピーして貼り付けることで、YAML の内容を変更します。

   

   このコンテンツは、前に設定したシークレットを参照します。

4. 最後に、[Install] を選択してアプリケーションのデプロイを開始します。 このアクションにより、Helm リリース (eap-todo-list-demo という名前) とそれに関連付けられているリソースのグラフィカル表現を含む [トポロジ] ビューが開きます。

   

   Helm リリース (略記で HR) には eap-todo-list-demo という名前が付いています。 それには、デプロイ リリース (略記で D) が含まれていて、こちらの名前も eap-todo-list-demo です。

   [D] ボックスの左下にある円円で囲まれた 2 つの矢印が付いたアイコンを選択すると、[ログ] ペインが表示されます。 ここでは、ビルドの進行状況を確認できます。 トポロジ ビューに戻るには、左側のナビゲーション ウィンドウで [Topology] を選択します。

5. ビルドが完了すると、左下のアイコンに緑色のチェックが表示されます

6. デプロイが完了すると、円の輪郭は濃い青色になります。 濃い青色の上にマウスを置くと、「3 Running」のようなメッセージが表示されます。 そのメッセージが表示されたら、デプロイに関連付けられているルートから (右上のアイコンを使用して) URL をアプリケーションに移動できます。

   

7. アプリケーションが次の画像のようにブラウザーで開かれて、使用する準備が整います。

   

8. アプリケーションには、情報を提供するポッドの名前が表示されます。 クラスタリング機能を検証するため、いくつかの Todo を追加できます。 次に、アプリケーションに表示される [サーバー ホスト名] フィールドに示された名前のポッドを、oc delete pod <pod-name> を使用して削除します。 ポッドを削除した後、同じアプリケーション ウィンドウに新しい Todo を作成します。 新しい Todo が Ajax リクエストによって追加され、[サーバーのホスト名] フィールドに別の名前が表示されるようになったことがわかります。 バックグラウンドでは、OpenShift ロード バランサーが新しいリクエストをディスパッチし、使用可能なポッドに配信しました。 Jakarta Faces ビューは、要求を処理しているポッドに格納されている HTTP セッションのコピーから復元されます。 実際、[セッション ID] フィールドは変更されなかったことがわかります。 セッションがポッド間でレプリケートされていない場合、Jakarta Faces ViewExpiredException が表示され、アプリケーションは期待どおりに動作しません。

リソースをクリーンアップする

アプリケーションを削除する

アプリケーションを削除するだけの場合は、OpenShift コンソールを開き、開発者ビューで [Helm] メニュー オプションに移動することができます。 このメニューには、クラスターにインストールされているすべての Helm チャート リリースが表示されます。

eap-todo-list-demo Helm Chart を見つけて、行の最後でツリーの縦方向のドットを選択し、アクションのコンテキスト メニュー エントリを開きます。

[Uninstall Helm Release] を選択してアプリケーションを削除します。 アプリケーション構成を提供するために使用されるシークレット オブジェクトは、グラフの一部ではないことに注意してください。 不要になった場合は、それを個別に削除する必要があります。

アプリケーション構成を保持しているシークレットを削除する場合は、次のコマンドを実行します。

$ oc delete secrets/todo-list-secret
# secret "todo-list-secret" deleted

OpenShift プロジェクトを削除する

このデモ用に作成されたすべての構成の削除は、eap-demo プロジェクトを削除することでも行えます。 そのためには、次のコマンドを実行します。

$ oc delete project eap-demo
# project.project.openshift.io "eap-demo" deleted

Azure Red Hat OpenShift クラスターを削除する

「チュートリアル: Azure Red Hat OpenShift 4 クラスターを削除する」の手順に従って、Azure Red Hat OpenShift クラスターを削除します。

リソース グループを削除します

前の手順で作成したすべてのリソースを削除する場合は、Azure Red Hat OpenShift クラスター用に作成したリソース グループを削除します。

次のステップ

このガイドで使用された以下の参考資料から、より多くのことを学習できます。

• Red Hat JBoss Enterprise Application Platform
• Azure Red Hat OpenShift
• JBoss EAP の Helm Chart
• JBoss EAP の起動可能な JAR

Azure で JBoss EAP を実行するためのオプションを引き続き調べる。