次の方法で共有

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

  • [アーティクル]

このガイドでは、Azure Red Hat OpenShift で実行するために既存の JBoss EAP アプリケーションを移行する場合に注意する必要がある事項について説明します。

移行前

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

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

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 ベースの移行を検討してください。 この場合は、「 Azure VM 上の JBoss EAP に JBoss EAP アプリケーションを送信するを参照してください。 Red Hat OpenShift 内で実行するようにアプリケーションを変換してランタイム コストを削減できる場合は、Azure Red Hat OpenShift ベースの移行を検討してください。 この場合は、引き続き Azure Red Hat OpenShift 上の JBoss EAP に JBoss EAP アプリケーションをします。 JBoss EAP と JBoss EAP for OpenShift の違いについては、「 Comparison: 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 オペレーターをインストールします。
    • eap-s2i-build テンプレートを使用してアプリケーション イメージをビルドします。 Source-to-image (S2I) の詳細については、「 OpenShift の OpenJDK 11 ソースからイメージへの使用を参照してください。
    • EAP オペレーターを使用して Java アプリケーションをデプロイします。 詳細については、EAP オペレーターのリファレンス ドキュメント ( Red Hat を参照してください。

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

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

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

既存の JBoss EAP バージョンは、オペレーターがサポートするバージョンのいずれかである必要があります。 詳細については、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 オペレーターのドキュメントを参照してください。 詳細については、Red Hat ドキュメントの「 シークレットの作成 を参照してください。

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

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

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

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

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

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

Note

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

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

java -version

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

すべての JNDI リソースをインベントリします。 たとえば、データベースなどのデータソースには、関連付けられている JNDI 名が存在することがあります。これによって、JPA が特定のデータベースに EntityManager のインスタンスを正しくバインドできます。 JNDI リソースとデータベースの詳細については、Red Hat ドキュメントの「 Datasource Management を参照してください。 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 ドキュメントの「 Datasource Management を参照してください。

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

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

  • スタートアップ スクリプトは変更されていますか? このようなスクリプトには、 host、 eap_env、 standalone、および ドメインが含まれます。
  • 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 と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。

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

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

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

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

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

JBoss EAP がカスタマイズされているかどうかを Determine で説明したのと同じ手法を使用して、これらのライブラリ 処理できます。

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

アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで / または \ を使用している場合、 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 でオファーを開くには、「 JBoss EAP on Azure Red Hat OpenShiftを参照してください。 Createを選択し、オファーの指示に従います。

アプリケーションの移行

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

移行後

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