次の方法で共有

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

  • [アーティクル]

このガイドでは、既存の WebLogic アプリケーションを移行して Azure Kubernetes Service コンテナー内の WildFly で実行する場合に知っておくべきことについて説明します。

移行前

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

移行前の要件を満たすことができない場合は、関連する移行ガイドを参照してください。

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

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

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

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

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 を参照してください。

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

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

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

データソースの文書化

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

  • データソース名
  • 接続プールの構成
  • 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 ファイルを調べて、その構成を把握してください。

Note

Azure Kubernetes Service リソースがより適切に使用されるよう各 Web アプリを個別にスケーリングできるようにしたい場合は、EAR を個々の Web アプリに分割する必要があります。

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

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

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

Azure Kubernetes Service で WildFly を使用するには、特定のバージョンの Java が必要です。そのため、サポートされているバージョンを使用してアプリケーションが正しく動作することを確認する必要があります。

Note

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

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

java -version

WildFly の実行に使用するバージョンのガイダンスについては、「Requirements」を参照してください。

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

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

AKS クラスターでスケジュールされたジョブを実行するには、必要に応じて Kubernetes CronJob を定義します。 詳細については、「CronJob を使用した自動タスクの実行」を参照してください。

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

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

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

WLST で上記以外の作業が行われている場合は、移行の間に余分な作業が必要になります。

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

アプリケーションで WebLogic 固有の API が使用される場合、それらの依存関係を削除するためにそれをリファクタリングする必要があります。 たとえば、Oracle WebLogic Server 向け Java API リファレンスに記載されているクラスを使用している場合は、アプリケーションで WebLogic 固有の API を使用しています。 参照を削除するには、リファクタリングする必要があります。

アプリケーションで 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 タイマー コードが各 WildFly インスタンスによって個別にトリガーできることを確認する必要があります。 この確認が必要な理由は、Azure Kubernetes Service のデプロイ シナリオでは、各 EJB タイマーがその独自の WildFly インスタンス上でトリガーされるためです。

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

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

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

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

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

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

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

アプリケーションで頻繁に書き込みおよび読み取りされるファイル (一時データ ファイルなど) や、アプリケーションでのみ表示できる静的ファイルには、Azure Storage 共有を永続ボリュームとしてマウントできます。 詳細については、「Azure Kubernetes Service (AKS) で Azure Files を含むボリュームを作成して使用する」を参照してください。

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

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

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

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

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

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

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

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

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

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

移行

Azure Container Registry と Azure Kubernetes Service をプロビジョニングする

次のコマンドを使用して、レジストリの閲覧者ロールを持つサービス プリンシパルを使って、コンテナー レジストリと Azure Kubernetes クラスターを作成します。 クラスターのネットワーク要件に応じて、適切なネットワーク モデルを選択してください。

az group create \
    --resource-group $resourceGroup \
    --location eastus
az acr create \
    --resource-group $resourceGroup \
    --name $acrName \
    --sku Standard
az aks create \
    --resource-group $resourceGroup \
    --name $aksName \
    --attach-acr $acrName \
    --network-plugin azure

WildFly 用の Docker イメージを作成する

Dockerfile を作成するには、次の前提条件が必要です。

  • サポートされている JDK。
  • WildFly のインストール。
  • JVM ランタイム オプション。
  • 環境変数を渡す方法 (該当する場合)。

その後、以下のセクションで説明されている手順を適宜実行できます。 Dockerfile と Web アプリケーションの開始点として WildFly コンテナーのクイック スタート リポジトリを使用できます。

KeyVault FlexVolume を構成する

Azure KeyVault を作成し、必要なすべてのシークレットを設定します。 詳細については、「クイック スタート: Azure CLI を使用して Azure Key Vault との間でシークレットの設定と取得を行う」を参照してください。 次に、KeyVault FlexVolume を構成して、これらのシークレットにポッドがアクセスできるようにします。

WildFly のブートストラップに使用されるスタートアップ スクリプトを更新する必要もあります。 このスクリプトでは、サーバーを起動する前に、WildFly によって使用されるキーストアに証明書をインポートする必要があります。

データ ソースを設定する

データ ソースにアクセスするように WildFly を構成するには、JDBC ドライバー JAR を Docker イメージに追加してから、適切な JBoss CLI コマンドを実行する必要があります。 これらのコマンドでは、Docker イメージをビルドするときにデータ ソースを設定する必要があります。

次の手順では、PostgreSQL、MySQL、SQL Server について説明します。

  1. PostgreSQL、MySQL、または SQL Server 用の JDBC ドライバーをダウンロードします。

    ダウンロードしたアーカイブをアンパックして、ドライバーの .jar ファイルを取得します。

  2. module.xml のような名前のファイルを作成し、次のマークアップを追加します。 <module name>プレースホルダー (山かっこを含む) を、org.postgres (PostgreSQL の場合)、com.mysql (MySQL の場合)、または com.microsoft (SQL Server の場合) に置き換えます。 <JDBC .jar file path> を、前のステップの .jar ファイルの名前に置き換えます。ご自分の Docker イメージ内のファイルを配置する場所への完全なパス (/opt/database など) を含めます。

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="<module name>">
    <resources>
       <resource-root path="<JDBC .jar file path>" />
    </resources>
    <dependencies>
        <module name="javax.api"/>
        <module name="javax.transaction.api"/>
    </dependencies>
</module>

  3. datasource-commands.cli のような名前のファイルを作成し、次のコードを追加します。 <JDBC .jar file path> を前のステップで使った値に置き換えます。 <module file path> を、前のステップのファイル名とパス (/opt/database/module.xml など) に置き換えます。

    Note

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

    batch
module add --name=org.postgres --resources=<JDBC .jar file path> --module-xml=<module file path>
/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=$DATABASE_CONNECTION_URL --user-name=$DATABASE_SERVER_ADMIN_FULL_NAME --password=$DATABASE_SERVER_ADMIN_PASSWORD --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
reload
run batch
shutdown

  4. アプリケーションの JTA データソース構成を更新します。

    アプリの src/main/resources/META-INF/persistence.xml ファイルを開き、<jta-data-source> 要素を見つけます。 その内容を次に示すように置き換えます。

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

  5. Docker イメージをビルドするときにデータ ソースが作成されるように、以下を Dockerfile に追加します

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/database/datasource-commands.cli && \
sleep 30

  6. 使用する DATABASE_CONNECTION_URL はデータベース サーバーごとに異なり、Azure portal 上の値とは異なるため、これを特定します。 WildFly では、ここで示す URL の形式を使う必要があります。

    jdbc:postgresql://<database server name>:5432/<database name>?ssl=true

  7. 後の段階でデプロイ YAML を作成するときに、適切な値と共に環境変数 DATABASE_CONNECTION_URL、DATABASE_SERVER_ADMIN_FULL_NAME、および DATABASE_SERVER_ADMIN_PASSWORD を渡す必要があります。

Note

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

WildFly でのデータベース接続の構成について詳しくは、PostgreSQL、MySQL、または SQL Server をご覧ください。

JNDI リソースを設定する

WildFly 上で構成する必要がある各 JNDI リソースを設定するには、一般に次の手順を使用します。

  1. 必要な JAR ファイルをダウンロードし、Docker イメージにコピーします。
  2. これらの JAR ファイルを参照する WildFly module.xml ファイルを作成します。
  3. 特定の JNDI リソースに必要な構成を作成します。
  4. Docker ビルド中に JNDI リソースを登録するために使用する JBoss CLI スクリプトを作成します。
  5. Dockerfile にすべてのものを追加します。
  6. デプロイ YAML に適切な環境変数を渡します。

次の例は、Azure Service Bus への JMS 接続用の JNDI リソースを作成するために必要な手順を示しています。

  1. Apache Qpid JMS プロバイダーをダウンロードします

    ダウンロードしたアーカイブをアンパックして、.jar ファイルを取得します。

  2. module.xml のような名前のファイルを作成し、次のマークアップを /opt/servicebus に追加します。 JAR ファイルのバージョン番号が、前のステップの JAR ファイルの名前と一致していることを確認します。

    <?xml version="1.0" ?>
<module xmlns="urn:jboss:module:1.1" name="org.jboss.genericjms.provider">
 <resources>
  <resource-root path="proton-j-0.31.0.jar"/>
  <resource-root path="qpid-jms-client-0.40.0.jar"/>
  <resource-root path="slf4j-log4j12-1.7.25.jar"/>
  <resource-root path="slf4j-api-1.7.25.jar"/>
  <resource-root path="log4j-1.2.17.jar"/>
  <resource-root path="netty-buffer-4.1.32.Final.jar" />
  <resource-root path="netty-codec-4.1.32.Final.jar" />
  <resource-root path="netty-codec-http-4.1.32.Final.jar" />
  <resource-root path="netty-common-4.1.32.Final.jar" />
  <resource-root path="netty-handler-4.1.32.Final.jar" />
  <resource-root path="netty-resolver-4.1.32.Final.jar" />
  <resource-root path="netty-transport-4.1.32.Final.jar" />
  <resource-root path="netty-transport-native-epoll-4.1.32.Final-linux-x86_64.jar" />
  <resource-root path="netty-transport-native-kqueue-4.1.32.Final-osx-x86_64.jar" />
  <resource-root path="netty-transport-native-unix-common-4.1.32.Final.jar" />
  <resource-root path="qpid-jms-discovery-0.40.0.jar" />
 </resources>
 <dependencies>
  <module name="javax.api"/>
  <module name="javax.jms.api"/>
 </dependencies>
</module>

  3. jndi.properties ファイルを /opt/servicebus に作成します。

    connectionfactory.${MDB_CONNECTION_FACTORY}=amqps://${DEFAULT_SBNAMESPACE}.servicebus.windows.net?amqp.idleTimeout=120000&jms.username=${SB_SAS_POLICY}&jms.password=${SB_SAS_KEY}
queue.${MDB_QUEUE}=${SB_QUEUE}
topic.${MDB_TOPIC}=${SB_TOPIC}

  4. servicebus-commands.cli のような名前のファイルを作成し、次のコードを追加します。

    batch
/subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)
/system-property=property.mymdb.queue:add(value=myqueue)
/system-property=property.connection.factory:add(value=java:global/remoteJMS/SBF)
/subsystem=ee:list-add(name=global-modules, value={"name" => "org.jboss.genericjms.provider", "slot" =>"main"}
/subsystem=naming/binding="java:global/remoteJMS":add(binding-type=external-context,module=org.jboss.genericjms.provider,class=javax.naming.InitialContext,environment=[java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory,org.jboss.as.naming.lookup.by.string=true,java.naming.provider.url=/opt/servicebus/jndi.properties])
/subsystem=resource-adapters/resource-adapter=generic-ra:add(module=org.jboss.genericjms,transaction-support=XATransaction)
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:add(class-name=org.jboss.resource.adapter.jms.JmsManagedConnectionFactory, jndi-name=java:/jms/${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=ConnectionFactory:add(value=${MDB_CONNECTION_FACTORY})
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd/config-properties=JndiParameters:add(value="java.naming.factory.initial=org.apache.qpid.jms.jndi.JmsInitialContextFactory;java.naming.provider.url=/opt/servicebus/jndi.properties")
/subsystem=resource-adapters/resource-adapter=generic-ra/connection-definitions=sbf-cd:write-attribute(name=security-application,value=true)
/subsystem=ejb3:write-attribute(name=default-resource-adapter-name, value=generic-ra)
run-batch
reload
shutdown

  5. Docker イメージをビルドするときに JNDI ソースが作成されるように、以下を Dockerfile に追加します

    RUN /bin/bash -c '<WILDFLY_INSTALL_PATH>/bin/standalone.sh --start-mode admin-only &' && \
sleep 30 && \
<WILDFLY_INSTALL_PATH>/bin/jboss-cli.sh -c --file=/opt/servicebus/servicebus-commands.cli && \
sleep 30

  6. 後の段階でデプロイ YAML を作成するときに、適切な値と共に環境変数 MDB_CONNECTION_FACTORY、DEFAULT_SBNAMESPACE、SB_SAS_POLICY、SB_SAS_KEY、MDB_QUEUE、SB_QUEUE、MDB_TOPIC、および SB_TOPIC を渡す必要があります。

WildFly の構成を確認する

「WildFly 管理者ガイド」を確認して、前のガイダンスで説明されていないその他の移行前手順をカバーします。

Docker イメージをビルドし、Azure Container Registry にプッシュする

Dockerfile を作成したら、Docker イメージをビルドし、自身の Azure コンテナー レジストリに発行する必要があります。

WildFly コンテナーのクイック スタート GitHub リポジトリを使用した場合、イメージをビルドして自身の Azure コンテナー レジストリにプッシュするプロセスは、次の 3 つのコマンドを呼び出すことと同等です。

これらの例では、MY_ACR 環境変数は自身の Azure コンテナー レジストリの名前を保持し、MY_APP_NAME 変数は、Azure コンテナー レジストリで使用する Web アプリケーションの名前を保持します。

WAR ファイルをビルドします。

mvn package

自身の Azure コンテナー レジストリにログインします。

az acr login --name ${MY_ACR}

イメージをビルドしてプッシュします。

az acr build --image ${MY_ACR}.azurecr.io/${MY_APP_NAME} --file src/main/docker/Dockerfile .

また、次のコマンドに示すように、Docker CLI を使用して最初にイメージをビルドしてローカルでテストすることもできます。 この方法を使用すると、ACR への初期デプロイの前に、イメージのテストと調整を簡単に行えます。 ただし、Docker CLI をインストールし、Docker デーモンが実行されていることを確認する必要があります。

イメージをビルドします。

docker build -t ${MY_ACR}.azurecr.io/${MY_APP_NAME}

イメージをローカルで実行します。

docker run -it -p 8080:8080 ${MY_ACR}.azurecr.io/${MY_APP_NAME}

http://localhost:8080 でアプリケーショにアクセスできるようになりました。

自身の Azure コンテナー レジストリにログインします。

az acr login --name ${MY_ACR}

自身の Azure コンテナー レジストリにイメージをプッシュします。

docker push ${MY_ACR}.azurecr.io/${MY_APP_NAME}

Azure 内でコンテナー イメージをビルドして保存する方法の詳細については、「Azure Container Registry を使用してコンテナー イメージをビルドして保存する」を参照してください。

パブリック IP アドレスをプロビジョニングする

内部ネットワークまたは仮想ネットワークの外部からアプリケーションにアクセスできるようにする場合は、パブリック静的 IP アドレスが必要になります。 この IP アドレスは、次の例に示すように、クラスターのノード リソース グループ内にプロビジョニングする必要があります。

export nodeResourceGroup=$(az aks show \
    --resource-group $resourceGroup \
    --name $aksName \
    --query 'nodeResourceGroup' \
    --output tsv)
export publicIp=$(az network public-ip create \
    --resource-group $nodeResourceGroup \
    --name applicationIp \
    --sku Standard \
    --allocation-method Static \
    --query 'publicIp.ipAddress' \
    --output tsv)
echo "Your public IP address is ${publicIp}."

Azure Kubernetes Service (AKS) へのデプロイ

Kubernetes YAML ファイルを作成して適用します。 詳細については、「 Quickstart: Azure CLI を使用して Azure Kubernetes Service (AKS) クラスターをデプロイする」を参照してください。 外部ロード バランサーを (アプリケーションまたはイングレス コントローラー用に) 作成する場合は、前のセクションで LoadBalancerIP としてプロビジョニングした IP アドレスを必ず指定してください。

外部化したパラメーターを環境変数として含めます。 詳細については、「コンテナーの環境変数の定義」を参照してください。 シークレット (パスワード、API キー、JDBC 接続文字列など) は含めないでください。 これらについては以下のセクションで説明します。

デプロイ YAML を作成するときは、必ずメモリと CPU の設定を含めて、コンテナーのサイズが適切に設定されるようにしてください。

永続ストレージを構成する

アプリケーションで非揮発性ストレージが必要な場合は、永続ボリューム を 1 つ以上構成します。

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

AKS クラスターでスケジュールされたジョブを実行するには、必要に応じて Kubernetes CronJob を定義します。 詳細については、「CronJob を使用した自動タスクの実行」を参照してください。

移行後

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

推奨事項