次の方法で共有

JBoss EAP アプリケーションを JBoss EAP on Azure App Service に移行する

  • [アーティクル]

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

移行前

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

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

現在の実稼働サーバーのハードウェア (メモリ、CPU、ディスク) と、平均およびピーク時の要求数とリソース使用率を文書化します。 この情報は、選択した移行パスに関係なく必要になります。 たとえば、ノード プール内の VM のサイズ、コンテナーによって使用されるメモリの量、コンテナーが必要とする CPU 共有の数などの選択に役立ちます。

AKS でノード プールのサイズを変更できます。 方法については、「Azure Kubernetes Service (AKS) でノード プールのサイズを変更する」を参照してください。

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

すべてのシークレットとパスワードについて、実稼働サーバー上のすべてのプロパティと構成ファイルを確認します。 必ず、WAR 内の jboss-web.xml を確認してください。 また、パスワードや資格情報を含む構成ファイルがアプリケーション内に見つかる場合もあります。

これらのシークレットを Azure Key Vault に格納することを検討してください。 詳細については、「Azure Key Vault の基本的な概念」をご覧ください。

Key Vault 参照を使用して App Service インスタンスで Key Vault シークレットを使用できます。 Key Vault 参照を使用すると、アプリケーションでシークレットを使用しながら、保存時にセキュリティ保護して暗号化された状態を維持できます。 詳細については、「App Service と Azure Functions の Key Vault 参照を使用する」を参照してください。

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

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

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

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

JBoss EAP on Azure VMs には、サポートされているバージョンの Java が必要です。 使用する JDK のバージョンに関するガイダンスについては、Red Hat ドキュメントの サポートされている構成に関するページ をご覧ください。

Note

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

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

java -version

外部リソースをインベントリする

データ ソース、JMS メッセージ ブローカー、およびその他の外部リソースは、JNDI (Java Naming and Directory Interface) を介して挿入されます。 こうしたリソースの一部では、移行または再構成が必要な場合があります。

アプリケーション内

WEB-INF/jboss-web.xml または WEB-INF/web.xml あるいはその両方のファイルを調べます。 <Context> 要素内の <Resource> 要素を探します。

データソース

データソースは、 type 属性が javax.sql.DataSourceに設定されている JNDI リソースです。 データソースごとに、次の情報を文書にまとめます。

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

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

その他のすべての外部リソース

このガイドでは、考えられるすべての外部依存関係を記載することはできません。 アプリケーションの外部依存関係がすべて満たされるよう確認するのは、担当チームの責任です。

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

アプリケーションがセッション レプリケーションに依存している場合は、アプリケーションを変更してこの依存関係を削除する必要があります。 App Service ではインスタンス同士が直接通信することは許可されません。

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

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

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

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。 詳細については、「Azure Storage での静的 Web サイト ホスティング」と 「クイック スタート:Azure ストレージ アカウントと Azure CDN との統合」を参照してください。

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

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

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

アプリケーションで頻繁に書き込みおよび読み取りされるファイル (一時データ ファイルなど) や、アプリケーションでのみ表示できる静的ファイルの場合、App Service プランに関連付けられたローカル ファイル ストレージを使用できます。 詳細については、「Azure App Service におけるオペレーティング システムの機能」および「Azure App Service ファイル システムについて」を参照してください。

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

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

アプリケーション コードの内部または外部で、実稼働サーバーで実行されているスケジュールされたタスクのインベントリを作成します。

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

アプリケーションからオンプレミスのサービスのいずれかにアクセスする必要がある場合、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 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。

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

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

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

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

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

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

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

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

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

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

Note

App Service リソースの使用を改善するために各 Web アプリを個別に拡張できるようにする場合は、個々の Web アプリに EAR を分割する必要があります。

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

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

インプレース テストの実行

コンテナー イメージを作成する前に、アプリケーションを App Service で使用する予定の JDK および JBoss EAP バージョンに移行します。 アプリケーションを十分にテストして、互換性とパフォーマンスを確認します。

JBoss EAP on App Service の機能に関する注意事項

JBoss EAP on App Service を使用しているときは、次の注意事項を考慮してください。

  • JBoss EAP 管理コンソール: JBoss Web コンソールは App Service で公開されていません。 代わりに、Azure portal がアプリケーションの管理 API を提供しています。Azure CLI、Azure Maven プラグイン、または他の Azure 開発者ツールを使用してデプロイする必要があります。 JBoss リソースの追加構成は、アプリケーションの起動時に JBoss CLI を使用して実現できます。

  • トランザクション: Transactions API がサポートされており、トランザクションの自動復旧がサポートされています。 詳細については、Red Hat のドキュメントの「JBoss EAP でトランザクションを管理する」を参照してください。

  • マネージド ドメイン モード: マルチサーバー実稼働環境では、JBoss EAP のマネージド ドメイン モードに集中型管理機能があります。 ただし JBoss EAP on App Service では、App Service プラットフォームがサーバー インスタンスの構成と管理の責任を負います。 App Service によって、JBoss EAP のマネージド ドメイン モードが不要になります。 ドメイン モードは、仮想マシン ベースのマルチサーバー デプロイの場合に適した選択肢です。 詳細については、Red Hat のドキュメントの「マネージド ドメインについて」を参照してください。

  • サーバー間クラスタリング: 2023 年 9 月 28 日の時点で、JBoss EAP のクラスター化された展開が一般公開されています。 このサポートによって、App Service にデプロイする前に次の機能を削除する必要がなくなりました。

    • ステートフル セッション Bean。
    • 分散トランザクション。
    • インスタンス間の通信または高可用性を必要とする同様の機能。

    詳細については、「Azure アプリ Service 用の Java アプリを構成する」の「リリースのお知らせおよび Clustering」セクションを参照してください。

移行

Red Hat Migration Toolkit for Apps

Red Hat Migration Toolkit for Applications は、Visual Studio Code 用の無料の拡張機能です。 この拡張機能により、アプリケーション コードと構成を分析して、オンプレミスからクラウドに移行するための推奨事項を提供します。 詳細については、「Migration Toolkit for Applications の概要」を参照してください。

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

JBoss EAP ランタイム用に Azure App Service をプロビジョニングする

次のコマンドを使用して、リソース グループと Azure App Service プランを作成します。 App Service プランが作成されると、JBoss EAP ランタイムを使用して Linux Web アプリ プランが作成されます。 JBoss EAP サイトは、PremiumV3 および IsolatedV2 App Service プランのサービス レベルでのみ作成できます。

指定した環境変数に適切な値が設定されていることを確認してください。

Note

PremiumV3 と IsolatedV2 はどちらも予約インスタンスの価格に適合しているため、コストを削減できます。 App Service プランのサービス レベルと予約インスタンスの価格の詳細については、「App Service の価格」を参照してください。

az group create --resource-group $resourceGroup --location eastus
az acr create --resource-group $resourceGroup --name $acrName --sku Standard
az appservice plan create \
    --resource-group $resourceGroup \
    --name $jbossAppService \
    --is-linux \
    --sku P1V2
az webapp create \
    --resource-group $resourceGroup \
    --name $jbossWebApp \
    --plan $jbossAppServicePlan \
    --runtime "JBOSSEAP|7-java8"
    #  Or use "JBOSSEAP|7-java11" if you're using Java 11

アプリケーションのビルド

次の Maven コマンドを使用してアプリケーションをビルドします。

mvn clean install -DskipTests

アプリケーションを展開する

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

JBoss EAP アプリケーションのデプロイを自動化するには、Web アプリ用の Azure Pipelines タスクまたは Azure WebApp へのデプロイ用の GitHub のアクションを使用できます。

データ ソースを設定する

JBoss EAP を使用してデータ ソースを登録する場合の 3 つの主要なステップは、JDBC ドライバーのアップロード、モジュールとしての JDBC ドライバーの追加、モジュールの登録です。 詳細については、JBoss EAP のドキュメントの「Datasource Management」を参照してください。 App Service はステートレスのホスティング サービスであるため、データ ソース モジュールを追加および登録するための構成コマンドは、スクリプト化して、コンテナーの起動時に適用する必要があります。

データ ソースを設定するには、次の手順に従います。

  1. データベースの JDBC ドライバーを入手します。

  2. JDBC ドライバー用の XML モジュール定義ファイルを作成します。 PostgreSQL のモジュール定義の例を次に示します。 値 resource-root path は、使用する JDBC ドライバーへのパスに必ず置き換えてください。

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.postgres">
    <resources>
    <!-- ***** IMPORTANT: REPLACE THIS PLACEHOLDER *******-->
    <resource-root path="/home/site/deployments/tools/postgresql-42.2.12.jar" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. JBoss CLI コマンドを jboss-cli-commands.cli という名前のファイルに置きます。 JBoss コマンドを使用して、モジュールを追加し、データ ソースとして登録する必要があります。 次の例では、PostgreSQL 用の JBoss CLI コマンドを示します。

    Note

    Microsoft では、使用可能な最も安全な認証フローを使用することをお勧めします。 この手順で説明する認証フロー (データベース、キャッシュ、メッセージング、AI サービスなど) には、アプリケーションに対する非常に高い信頼が必要であり、他のフローには存在しないリスクが伴います。 このフローは、パスワードレス接続やキーレス接続のマネージド ID など、より安全なオプションが有効でない場合にのみ使用します。 ローカル コンピューターの操作では、パスワードレス接続またはキーレス接続にユーザー ID を使用します。

    module add --name=org.postgres --resources=/home/site/deployments/tools/postgresql-42.2.12.jar --module-xml=/home/site/deployments/tools/postgres-module.xml

/subsystem=datasources/jdbc-driver=postgres:add(driver-name="postgres",driver-module-name="org.postgres",driver-class-name=org.postgresql.Driver,driver-xa-datasource-class-name=org.postgresql.xa.PGXADataSource)

data-source add --name=postgresDS --driver-name=postgres --jndi-name=java:jboss/datasources/postgresDS --connection-url=${POSTGRES_CONNECTION_URL,env.POSTGRES_CONNECTION_URL:jdbc:postgresql://db:5432/postgres} --user-name=${POSTGRES_SERVER_ADMIN_FULL_NAME,env.POSTGRES_SERVER_ADMIN_FULL_NAME:postgres} --password=${POSTGRES_SERVER_ADMIN_PASSWORD,env.POSTGRES_SERVER_ADMIN_PASSWORD:example} --use-ccm=true --max-pool-size=5 --blocking-timeout-wait-millis=5000 --enabled=true --driver-class=org.postgresql.Driver --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLExceptionSorter --jta=true --use-java-context=true --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.postgres.PostgreSQLValidConnectionChecker

  4. JBoss CLI コマンドを呼び出す startup_script.sh という名前のスタートアップ スクリプトを作成します。 下の例は、jboss-cli-commands.cli ファイルを呼び出す方法を示しています。 後で、インスタンスの起動時にこのスクリプトを実行するように App Service を構成します。

    $JBOSS_HOME/bin/jboss-cli.sh --connect --file=/home/site/deployments/tools/jboss-cli-commands.cli

  5. 任意の FTP クライアントを使用して、JDBC ドライバー、jboss-cli-commands.cli、startup_script.sh、およびモジュール定義を /site/deployments/tools/ にアップロードします。

  6. コンテナーの起動時に startup_script.sh を実行するようにサイトを構成します。 Azure portal で、[構成] > [一般設定] > [スタートアップ コマンド] に移動します。 スタートアップ コマンド フィールドを /home/site/deployments/tools/startup_script.sh に設定し、[保存] を選択します。

  7. Web アプリを再起動すると、構成スクリプトが実行されます。

  8. アプリケーションの JTA データソース構成を更新します。 ご自分のアプリの src/main/resources/META-INF/persistence.xml ファイルを開き、<jta-data-source> 要素を探します。 その内容を次に示すように置き換えます。

    <jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>

アプリケーションのビルド

次の Maven コマンドを使用してアプリケーションをビルドします。

mvn clean install -DskipTests

アプリケーションを展開する

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

JBoss EAP アプリケーションのデプロイを自動化するには、Web アプリ用の Azure Pipelines タスクまたは Azure WebApp へのデプロイ用の GitHub のアクションを使用できます。

移行後

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

推奨事項