次の方法で共有

WebLogic Server アプリケーションを Azure App Service 上の JBoss EAP に移行する

  • [アーティクル]

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

移行前

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

これらの移行前の要件を満たせない場合、代わりにアプリケーションを Virtual Machines に移行する手順については、関連する移行ガイド「WebLogic Server アプリケーションを Azure Virtual Machines に移行する」を参照してください。

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

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 たとえば、App Service プランの選択をガイドするのに役立ちます。

使用可能な App Service プラン レベルの一覧には、メモリ、CPU コア、ストレージ、および価格情報が表示されます。 App Service 上の JBoss EAP は、Premium V3 および Isolated V2 App Service プラン レベルでのみ使用できます。

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

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

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

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

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

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

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

ドメインの構成を検査する

WebLogic Server の主な構成単位は、ドメインです。 そのため、config.xml ファイルには、移行のために慎重に検討する必要がある多数の構成が含まれています。 このファイルには、サブディレクトリに格納されている追加の XML ファイルへの参照が記載されています。 Oracle では、通常、[管理コンソール] を使用して WebLogic Server の管理可能なオブジェクトとサービスを構成し、WebLogic Server で config.xml ファイルを保守できるようにすることを推奨しています。 詳細については、「ドメイン構成ファイル」を参照してください。

アプリケーション内

WEB-INF/weblogic.xml ファイルおよび WEB-INF/web.xml ファイルを調べます。

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

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

  • セッション管理にデータベースを使用するようにアプリケーションをリファクターします。
  • Azure Redis サービスへのセッションを外部化するようにアプリケーションをリファクターします。 詳細については、「Azure Cache for Redis」を参照してください。

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

データソースの文書化

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

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

WebLogic の JDBC ドライバーの詳細については、「WebLogic Server での JDBC ドライバの使用方法」を参照してください。

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

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

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

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

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

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

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

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

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

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

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

OSGi バンドルが使用されているかどうか確認する

WebLogic Server に追加されている OSGi バンドルを使用した場合は、同等の JAR ファイルを Web アプリケーションに直接追加する必要があります。

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

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

Oracle Service Bus が使用されているかどうか確認する

アプリケーションが Oracle Service Bus (OSB) を使用している場合は、OSB がどのように構成されているかを把握する必要があります。 詳細については、「Oracle Service Bus のインストールについて」を参照してください。

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

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

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

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

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

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

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

Azure App Service 上の JBoss EAP では、Java 8 と 11 がサポートされています。 したがって、そのサポートされているバージョンを使用してアプリケーションを正常に実行できることを検証する必要があります。 現在のサーバーでサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) を使用している場合、この検証が特に重要です。

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

java -version

スケジュールされたジョブにアプリケーションが依存しているかどうかを判断する

スケジュールされたジョブ (Quartz Scheduler タスクや Unix cron ジョブなど) は、Azure App Service では使用しないでください。 Azure App Service では、スケジュールされたタスクを含むアプリケーションの内部でのデプロイが妨げられることはありません。 ただし、アプリケーションをスケールアウトすると、同じスケジュールされたジョブが、スケジュールされた期間に複数回実行されることがあります。 このような場合、意図しない結果になることがあります。

スケジュールされたジョブを Azure で実行するには、Azure Functions をタイマー トリガーとともに使用することを検討してください。 詳しくは、「Azure Functions のタイマー トリガー」を参照してください。 ジョブ コード自体を関数に移行する必要はありません。 この関数では、アプリケーションで URL を呼び出すだけでジョブをトリガーできます。

Note

悪意のある使用を防ぐために、ジョブの呼び出しエンドポイントで資格情報が求められるようにする必要があります。 この場合、トリガー関数が資格情報を提供する必要があります。

WebLogic Scripting Tool (WLST) を使用しているかどうか確認する

現在、WLST を使用してデプロイを実行している場合は、実行内容を評価する必要があります。 WLST によってデプロイの一部としてアプリケーションの (ランタイム) パラメーターが変更される場合は、これらのパラメーターが次のいずれかのオプションに準拠していることを確認する必要があります。

  • アプリ設定として外部化される。
  • アプリケーションに埋め込まれている。
  • デプロイ中に JBoss CLI を使用する。

WLST により上記の説明よりも多くの作業が行われている場合は、移行中に追加の作業が必要になります。

アプリケーションで WebLogic 固有の API が使用されているかどうかを判断する

アプリケーションで WebLogic 固有の API を使用されている場合は、アプリケーションで使用されないようにリファクタリングする必要があります。 たとえば、Oracle WebLogic Server 向け Java API リファレンスに記載されているクラスを使用している場合は、アプリケーションで WebLogic 固有の API を使用しています。 Red Hat Migration Toolkit for Apps は、これらの依存関係の削除とリファクタリングに役立ちます。

アプリケーションで Entity Beans または EJB 2.x スタイルの CMP Beans が使用されているかどうかを判断する

アプリケーションで Entity Beans または EJB 2.x スタイルの CMP Beans が使用されている場合は、アプリケーションで使用されないようにリファクタリングする必要があります。

Java EE アプリケーション クライアント機能が使用されているかどうか確認する

Java EE アプリケーション クライアント機能を使用して (サーバー) アプリケーションに接続するクライアント アプリケーションがある場合は、HTTP API を使用するようにクライアント アプリケーションと (サーバー) アプリケーションの両方をリファクタリングする必要があります。

デプロイ計画が使用されたかどうかを判断する

デプロイ計画を使用してデプロイを実行した場合は、デプロイ計画の実行内容を評価する必要があります。 デプロイ計画が単純なデプロイである場合は、変更を加えなくても Web アプリケーションをデプロイできます。 デプロイ計画がより複雑な場合は、JBoss CLI を使用してアプリケーションをデプロイの一部として適切に構成できるかどうかを判断する必要があります。 JBoss CLI を使用できない場合は、デプロイ計画が不要になったような方法でアプリケーションをリファクタリングする必要があります。

EJB タイマーが使用中かどうかを判断する

アプリケーションで EJB タイマーを使用する場合は、EJB タイマー コードが各 JBoss EAP インスタンスによって個別にトリガーできることを確認する必要があります。 この検証が必要なのは、App Service を水平方向にスケーリングすると、各 EJB タイマーが独自の JBoss EAP インスタンスでトリガーされるためです。

ファイル システムが使用されているかどうかとその使用方法を検証する

アプリケーション サーバーでファイル システムを使用する場合は、再構成や、まれにアーキテクチャの変更が必要になります。 ファイル システムは、WebLogic 共有モジュールまたはアプリケーション コードによって使用される場合があります。 次のシナリオの一部または全部を確認できます。

読み取り専用の静的コンテンツ

現在、アプリケーションで静的コンテンツを提供している場合は、その静的コンテンツのための別の場所が必要になります。 静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。

動的に公開される静的コンテンツ

アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。 お使いいただけるサンプル実装をご用意しました。

動的または内部のコンテンツ

アプリケーションで頻繁に書き込みおよび読み取りされるファイル (一時データ ファイルなど) や、アプリケーションでのみ表示できる静的ファイルの場合、Azure Storage を App Service ファイル システムにマウントすることができます。

JCA コネクタが使用されているかどうかを判断する

アプリケーションで JCA コネクタを使用する場合は、JBoss EAP で JCA コネクタを使用できることを確認する必要があります。 JCA の実装が WebLogic に関連付けられている場合は、JCA コネクタがアプリケーションで使用されないようにリファクタリングする必要があります。 コネクタを使用できる場合は、JAR をサーバーのクラスパスに追加し、必要な構成ファイルを JBoss EAP サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。

アプリケーションでリソース アダプターが使用されるかどうかを判断する

アプリケーションでリソース アダプター (RA) が必要な場合、JBoss EAP と互換性がある必要があります。 JBoss EAP のスタンドアロン インスタンスで RA が正常に機能するかどうかを確認するには、それをサーバーにデプロイし、適切に構成します。 RA が適切に機能する場合、JAR を App Service インスタンスのサーバー クラスパスに追加し、必要な構成ファイルを JBoss EAP サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。

JAAS が使用されているかどうかを判断する

アプリケーションで JAAS が使用されている場合は、JAAS がどのように構成されているかを把握する必要があります。 データベースを使用している場合は、それを JBoss EAP 上の JAAS ドメインに変換できます。 カスタム実装の場合は、それを JBoss EAP で使用できるかどうかを確認する必要があります。

WebLogic クラスタリングが使用されているかどうか確認する

多くの場合、高可用性を実現するために、アプリケーションは複数の WebLogic サーバーにデプロイされています。 Azure App Service はスケーリングが可能ですが、WebLogic Cluster API を使用している場合は、コードをリファクタリングしてその API を使用しないようにする必要があります。

移行

Red Hat Migration Toolkit for Apps

Red Hat Migration Toolkit for Applications は、Visual Studio Code 用の無料の拡張機能です。 この拡張機能は、アプリケーション コードと構成を分析して、独自の API との依存関係の削除など、Jakarta EE アプリケーションを他のアプリ サーバーから JBoss EAP に移行するためのレコメンデーションを提供します。 この拡張機能では、オンプレミスからクラウドに移行する場合のレコメンデーションも提供されます。 詳細については、「Migration Toolkit for Applications の概要」を参照してください。

このガイドの内容は、移行の過程における他のコンポーネントの処理に役立ちます (適切な App Service プラン タイプの選択、セッション状態の外部化、EAP インスタンスの管理に JBoss 管理インターフェイスではなく Azure を使用するなど)。

App Service プランをプロビジョニングする

利用可能なサービス プランの一覧から、仕様が現在の実稼働ハードウェアの仕様を満たしているか超えているプランを選択します。

Note

ステージング/カナリア デプロイを実行する場合、またはデプロイ スロットを使用する場合は、App Service プランにその追加容量が含まれている必要があります。 Java アプリケーションでは、Premium 以上のプランを使用することをお勧めします。

App Service プランを作成します。

Web アプリを作成してデプロイする

App Service プランでは、JBoss EAP サーバーにデプロイされている WAR ファイルごとに Web アプリを作成する必要があります。

Note

1 つの Web アプリに複数の WAR ファイルをデプロイすることは可能ですが、非常に望ましくない操作です。 1 つの Web アプリに複数の WAR ファイルをデプロイすると、各アプリケーションを独自の使用要件に従ってスケーリングできなくなります。 さらに、後続の配置パイプラインの複雑さも増大します。 1 つの URL で複数のアプリケーションを使用できるようにする必要がある場合は、Azure Application Gateway などのルーティング ソリューションの使用を検討してください。

Maven アプリケーション

アプリケーションが Maven POM ファイルから作成されている場合は、Maven 用の Webapp プラグインを使用して Web アプリを作成し、アプリケーションをデプロイします。 詳細については、「クイック スタート: Azure App Service 上で Java アプリを作成する」の「Maven プラグインの構成」セクションを参照してください。

Maven 以外のアプリケーション

Maven プラグインを使用できない場合は、次のような他のメカニズムを使用して Web アプリをプロビジョニングする必要があります。

Web アプリを作成したら、利用可能なデプロイ メカニズムのいずれかを使用してアプリケーションをデプロイします。 詳細については、「App Service へのファイルのデプロイ」を参照してください。

JVM ランタイムオプションを移行する

アプリケーションで特定のランタイム オプションが必要な場合は、最適なメカニズムを使用してそれらを指定します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「Java ランタイム オプションの設定」セクションを参照してください。

外部化されたパラメーターを移行する

外部パラメーターを使用する必要がある場合は、それらをアプリケーション設定として設定する必要があります。 詳細については、「アプリ設定の構成」を参照してください。

スタートアップ スクリプトを移行する

元のアプリケーションでカスタム スタートアップ スクリプトが使用されている場合は、Bash スクリプトに移行する必要があります。 詳細については、アプリケーション サーバー構成のカスタマイズに関するページを参照してください。

シークレットを取り込む

アプリケーション固有のシークレットを格納するには、アプリケーション設定を使用します。 複数のアプリケーションで 1 もしくは複数の同じシークレットを使用する場合、またはきめ細かなアクセス ポリシーと監査機能が必要な場合は、代わりに Azure Key Vault 参照を使用します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「KeyVault 参照の使用」セクションを参照してください。

Custom Domain と SSL を構成する

アプリケーションをカスタム ドメインに表示する場合は、Web アプリケーションをそれにマップする必要があります。 詳細については、「チュートリアル: 既存のカスタム DNS 名を Azure App Service にマップする」を参照してください。

その後に、そのドメインの TLS/SSL 証明書を App Service Web アプリにバインドする必要があります。 詳細については、「Azure App Service で TLS/SSL バインディングを使用してカスタム DNS 名をセキュリティで保護する」を参照してください。

データソース、ライブラリ、および JNDI リソースを移行する

データ ソースを移行するには、「Azure App Service 用に Java アプリを構成する」の「データ ソースの構成」セクションの手順に従います。

「Azure App Service 用に Java アプリを構成する」の「JBoss EAP」セクションの手順に従って、追加のサーバー レベルのクラスパス依存関係を移行します。

その他の共有サーバー レベルの JDNI リソースを移行します。 詳細については、「Azure App Service 用に Java アプリを構成する」の「JBoss EAP」セクションを参照してください。

JCA コネクタと JAAS モジュールを移行する

モジュールと依存関係のインストールに関する記事の手順に従って、JCA コネクタと JAAS モジュールを移行します。

Note

アプリケーションごとに 1 つの WAR という推奨アーキテクチャに従っている場合は、サーバー レベル クラスパス ライブラリと JNDI リソースをアプリケーションに移行することを検討してください。 これにより、コンポーネントのガバナンスと変更管理が大幅に簡素化されます。 アプリケーションごとに複数の WAR をデプロイする場合は、このガイドの冒頭で説明したコンパニオン ガイドの 1 つを確認する必要があります。

スケジュールされたジョブを移行する

少なくとも、スケジュールされたジョブを Azure VM に移動して、それらがアプリケーションに含まれないようにする必要があります。 または、Azure Functions、SQL Database、Event Hubs などの Azure サービスを使用して、それらをイベント ドリブン Java に最新化することもできます。

再起動とスモーク テスト

最後に、Web アプリを再起動してすべての構成の変更を適用する必要があります。 再起動が完了したら、アプリケーションが正しく実行されていることを確認します。

移行後

アプリケーションを Azure App Service に移行したので、期待どおりに動作することを確認する必要があります。 これを完了したら、アプリケーションをよりクラウドネイティブにするためのレコメンデーションがいくつかあります。

推奨事項