JBoss EAP アプリケーションを Azure Red Hat OpenShift に移行する

  • [アーティクル]

このガイドでは、既存の JBoss EAP アプリケーションを Azure Red Hat OpenShift で実行するよう移行する場合に知っておくべきことについて説明します。

移行前

移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。

ターゲットが移行作業に適したターゲットであることを確認する

JBoss EAP アプリケーションを Azure に正常に移行する最初の手順は、最も適切な移行ターゲットを選択することです。 JBoss EAP は Azure 仮想マシン (VM) または Azure Red Hat OpenShift で適切に動作します。

VM ターゲットは、オンプレミスのデプロイに最も近いため、最も簡単な選択です。 仮想マシンの管理とデプロイのエクスペリエンスは、オンプレミスにあるものと類似します。 VM を選択すると、最新化を延期できます。

Red Hat OpenShift には、アプリケーションの開発、最新化、デプロイ、実行、管理における障壁を軽減する、テスト済みかつ信頼済みのサービスがまとめられています。 Azure Red Hat OpenShift は Kubernetes に基づいています。 Azure Red Hat OpenShift は、パブリック クラウド、オンプレミス、ハイブリッド クラウド、エッジ アーキテクチャ全体で一貫したエクスペリエンスを提供します。

変更を最小限に抑えることが移行作業の最も重要な要素である場合は、VM ベースの移行を検討してください。 この場合は、「JBoss EAP アプリケーションを Azure VM 上の JBoss EAP に移行する」を参照してください。 ランタイム コストを削減するために、Red Hat OpenShift 内で実行するようにアプリケーションを変換できる場合は、Azure Red Hat OpenShift ベースの移行を検討してください。 この場合は、「JBoss EAP アプリケーションを Azure Red Hat OpenShift 上の JBoss EAP に移行する」に進んでください。 JBoss EAP と JBoss EAP for OpenShift の違いについては、「比較: JBoss EAP と JBoss EAP for OpenShift」を参照してください。

事前構築済みの Azure Marketplace オファーが適切な出発点であるかどうか判断する

まず、Azure Red Hat OpenShift を適切なデプロイ先として決定します。 次に、事前構築済みの Azure Marketplace オファーが適切な出発点となるかどうかを決定します。 事前構築済みの Azure Marketplace オファーについては、次の点を考慮してください。

  • Red Hat と Microsoft は、Azure Red Hat OpenShift 上で JBoss EAP を迅速にプロビジョニングできるように、このオファーを作成しました。
  • 大まかに言えば、オファーによって次の手順が自動化されます。
    • Azure Red Hat OpenShift に EAP Operator をインストールする。
    • eap-s2i-build テンプレートを使用してアプリケーション イメージをビルドする。 Source-to-image (S2I) の詳細については、「OpenShift での OpenJDK 11 Source-to-Image の使用」を参照してください。
    • EAP Operator を使用して Java アプリケーションをデプロイします。 詳細については、Red Hat の EAP Operator のリファレンス ドキュメントを参照してください。

事前構築済みの Azure Marketplace オファーを使用しない場合は、EAP Operator を直接使用する方法を学習する必要があります。 演算子の習得については、この記事の範囲外です。 EAP Kubernetes Operator の完全なドキュメントは、Red Hat で入手できます。

このセクションの残りの部分では、事前構築済みの Azure Marketplace オファーを使用するか、演算子を直接使用するかを決定するための考慮事項について説明します。

JBoss EAP バージョンに互換性があるかどうか確認する

既存の JBoss EAP バージョンは、Operator がサポートするバージョンのいずれかである必要があります。 詳細については、Red Hat ドキュメントの「バージョンの互換性とサポート」を参照してください。

サーバー容量をインベントリする

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 サーバー容量の詳細なインベントリを作成することで、以下のような利点があります。

  • ノード プール内の VM のサイズを選択しやすくなります。
  • コンテナーで使用されるメモリの量を理解できます。
  • コンテナーに必要な CPU の共有数を把握できます。

Azure Red Hat OpenShift では、ノード プールのサイズを変更できます。 詳細については、Red Hat のドキュメントの「クラスターのサイズ変更 - Microsoft Azure」を参照してください。

すべてのシークレットをインベントリする

Azure Key Vault などの "サービスとしての構成" テクノロジが登場する前に、"シークレット" の明確に定義された概念はありませんでした。 代わりに、現在 "シークレット" を呼ばれるものとして効果的に機能する、さまざまな種類の構成設定のセットがありました。 JBoss EAP などのアプリ サーバーでは、これらのシークレットは多くの異なる構成ファイルと構成ストアにあります。 すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 アプリケーションの custom-config.xml や jboss-web.xml などの構成ファイルを必ず確認してください。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。 詳細については、「Azure Key Vault の基本的な概念」をご覧ください。

シークレットの強固なインベントリを作成したら、シークレットについて EAP Operator のドキュメントを参照してください。 詳細については、Red Hat のドキュメントの「シークレットの作成」を参照してください。

すべての証明書をインベントリする

パブリック SSL エンドポイントで使用されるすべての証明書を文書化します。 次のコマンドを実行して、運用サーバー上のすべての証明書を表示できます。

keytool -list -v -keystore <path to keystore>

証明書の強固なインベントリを作成したら、Azure Red Hat OpenShift でそれらを構成できます。 詳細については、Red Hat のドキュメントの「OpenShift Container Platform での TLS 構成」(replace) を参照してください。

サポートされている Java バージョンが正しく動作することを検証する

Azure Red Hat OpenShift への JBoss EAP の移行パスのすべてにおいて、パスごとに異なる特定の Java バージョンが必要です。 そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。

Note

現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。

現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。

java -version

JNDI リソースをインベントリする

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、Red Hat のドキュメントの「データソース管理」を参照してください。 ActiveMQ Artemis メッセージ ブローカーなど、その他の JNDI 関連リソースには、移行または再構成が必要になる場合があります。 ActiveMQ Artemis 構成の詳細については、Red Hat のドキュメントの「メッセージングの構成」を参照してください。

セッション レプリケーションが使用されているかどうか確認する

Infinispan の有無にかかわらず、アプリケーションがセッション レプリケーションに依存している場合は、次の 3 つの選択肢があります。

  • Infinispan は Azure 仮想マシンで適切に動作しますが、高可用性機能を提供するプロファイルを使用している場合は、JGroups 構成に注意してください。 システムがマネージド ドメインとスタンドアロン サーバーのどちらとして動作しているかを確認します。
    • マネージド ドメインの場合は、ha または full-ha プロファイルで JGroups を処理します。
    • スタンドアロン サーバーの場合は、standalone-ha.xml または standalone-full-ha.xml 構成ファイルで JGroups を処理します。
    • Microsoft Azure では、UDP マルチキャストに基づく JGroups 検出プロトコルがサポートされていません。 詳細については、Red Hat のドキュメントの「Microsoft Azure での JBoss EAP 高可用性の使用」を参照してください。
  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。 詳細については、「Azure Cache for Redis」を参照してください。

これらすべてのオプションにおいて、JBoss EAP が HTTP セッション状態レプリケーションを行う方法を習得することをお勧めします。 詳細については、Red Hat のドキュメントの「HTTP セッションのレプリケーションについて」を参照してください。

データソースの文書化

アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。

  • データソース名
  • 接続プールの構成
  • JDBC ドライバーの JAR ファイルの場所

JBoss EAP の JDBC ドライバーの詳細については、Red Hat のドキュメントの「データソース管理」を参照してください。

JBoss EAP がカスタマイズされているかどうかを確認する

次のうち、どのカスタマイズが行われたかを確認し、作業内容を把握します。

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、host、eap_env、standalone、domain などがあります。
  • JVM に渡される特定のパラメーターはありますか?
  • サーバーのクラスパスに追加された JAR はありますか?

これらのカスタマイズは、Azure Red Hat OpenShift で実行されているコンテナー イメージに反映させる必要があります。 詳細については、Red Hat のドキュメントの「Java アプリケーション用の JBoss EAP for OpenShift イメージの構成」を参照してください。

オンプレミスへの接続が必要かどうかを判断する

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、Azure の接続サービスの 1 つをプロビジョニングする必要があります。 詳しくは、「オンプレミス ネットワークの Azure への接続」をご覧ください。 または、オンプレミスのリソースで公開されている一般公開の API を使用するように、アプリケーションをリファクタリングする必要があります。

Java Message Service (JMS) キューまたはトピックが使用中かどうか確認する

アプリケーションで JMS キューまたはトピックを使用している場合は、外部でホストされている JMS サーバーにそれらを移行してもかまいません。 Azure Service Bus と Advanced Message Queuing Protocol は、JMS を使用している場合の優れた移行方法となります。 詳細については、「Azure Service Bus Standard と AMQP 1.0 で Java Message Service 1.1 を使用する」を参照してください。

JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。

詳細については、Red Hat のドキュメントの「メッセージングの構成」を参照してください。

独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認する

共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。

  • アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。
  • サーバーのクラスパスにそれらのライブラリを追加します。

これらのライブラリは、「JBoss EAP がカスタマイズされているかどうかを確認する」セクションで説明されているのと同じ手法で処理できます。

アプリケーションに OS 固有のコードが含まれているかどうかを判断する

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、アプリケーションが Windows 上で実行されている場合、ファイル システム パス内の / または \ の使用を File.Separator または Paths.get に置き換える必要がある場合があります。

Azure Red Hat OpenShift は、すべてのコントロールプレーンとワーカーノードのオペレーティングシステムとして Red Hat Enterprise Linux CoreOS (RHCOS) を使用して OpenShift 4 で実行されます。 OS 固有のコードは、RHCOS と互換性がある必要があります。

アプリケーションが複数の WAR で構成されているかどうか確認する

アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。

アプリケーションが EAR としてパッケージ化されているかどうか確認する

アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ずその構成を把握してください。

実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する

デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。

負荷分散の要件の考慮

負荷分散を考慮する最良の方法は、App Gateway 統合を使用することです。 詳細については、「Azure Application Gateway とは」を参照してください。

移行

このセクションの手順では、分析によって事前構築済みの Azure Marketplace オファーを使用することを決定していることを前提としています。

オファーをプロビジョニングする

Azure portal でオファーを開くには、「Azure Red Hat OpenShift 上の JBoss EAP」を参照してください。 [作成] を選択し、オファーの指示に従います。

アプリケーションの移行

このオファーは、JBoss EAP for OpenShift イメージで Java アプリケーションをビルドして実行するための Source-to-Image (S2I) プロセスをサポートしています。 Red Hat には、後で自分でデプロイする場合に手動で行う方法を示すサンプルが用意されています。 詳細については、Red Hat のドキュメントの「第 2 章 JBoss EAP for OpenShift イメージでの Java アプリケーションのビルドと実行」を参照してください。

移行後

「移行前」ステップで定義した移行の目標に到達したら、エンド ツー エンドの受け入れテストを実施して、すべてが予期したとおりに機能することを確認します。 移行後の機能強化の可能性については、以下の記事を参照してください。