Azure Kubernetes Serviceで WebLogic Server アプリケーションを WildFly に移行する
このガイドでは、既存の WebLogic Server アプリケーションを移行して、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 と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。
JMS 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。
独自に作成したカスタム共有 Java EE ライブラリを使用しているかどうか確認する
共有 Java EE ライブラリ機能を使用している場合は、次の 2 つの選択肢があります。
- アプリケーション コードをリファクターして、ライブラリへの依存関係をすべて削除し、代わりにその機能をアプリケーションに直接組み込みます。
- サーバーのクラスパスにそれらのライブラリを追加します。
OSGi バンドルが使用されているかどうか確認する
WebLogic Server に追加されている OSGi バンドルを使用した場合は、同等の JAR ファイルを Web アプリケーションに直接追加する必要があります。
アプリケーションに OS 固有のコードが含まれているかどうかを判断する
アプリケーションにホスト OS に依存するコードが含まれている場合は、それをリファクタリングしてそれらの依存関係を削除する必要があります。 たとえば、ファイル システムのパスで /
または \
を使用している場合、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 ファイルを調べて、その構成を把握してください。
注意
Azure Kubernetes Service リソースがより適切に使用されるよう各 Web アプリを個別にスケーリングできるようにしたい場合は、EAR を個々の Web アプリに分割する必要があります。
実稼働サーバーで実行されているすべての外部プロセスとデーモンを特定する
デーモンの監視など、アプリケーション サーバーの外部で実行されているプロセスがある場合は、それらを削除するか、別の場所に移行する必要があります。
サポートされている Java バージョンが正しく動作することを検証する
Azure Kubernetes Service で WildFly を使用するには、特定のバージョンの Java が必要です。そのため、サポートされているバージョンを使用してアプリケーションが正しく動作することを確認する必要があります。
注意
現在のサーバーがサポートされていない 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 Spring Apps Enterprise プランのアプリに直接デプロイすることもできます。 詳細については、「 Web 静的ファイルをデプロイする」を参照してください。
動的に公開される静的コンテンツ
アプリケーションによってアップロードまたは生成されるが、作成後に変更できない静的コンテンツをアプリケーションで許可する場合は、前述のように Azure Blob Storage と Azure CDN を使用し、Azure Function でアップロードと CDN の更新を処理します。 「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。 静的コンテンツは、Azure Spring Apps Enterprise プランのアプリに直接デプロイすることもできます。 詳細については、「 Web 静的ファイルをデプロイする」を参照してください。
動的または内部のコンテンツ
アプリケーションで頻繁に書き込みおよび読み取りされるファイル (一時データ ファイルなど) や、アプリケーションでのみ表示できる静的ファイルには、Azure Storage 共有を永続ボリュームとしてマウントできます。 詳細については、「Azure Kubernetes Service で 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 について説明します。
PostgreSQL、MySQL、または SQL Server 用の JDBC ドライバーをダウンロードします。
ダウンロードしたアーカイブをアンパックして、ドライバーの .jar ファイルを取得します。
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>
datasource-commands.cli
のような名前のファイルを作成し、次のコードを追加します。<JDBC .jar file path>
を前のステップで使った値に置き換えます。<module file path>
を、前のステップのファイル名とパス (/opt/database/module.xml
など) に置き換えます。PostgreSQL
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
MySQL
batch module add --name=com.mysql --resources=<JDBC .jar file path> --module-xml=<module file path> /subsystem=datasources/jdbc-driver=mysql:add(driver-name=mysql,driver-module-name=com.mysql,driver-class-name=com.mysql.cj.jdbc.Driver) data-source add --name=mysqlDS --jndi-name=java:jboss/datasources/mysqlDS --connection-url=$DATABASE_CONNECTION_URL --driver-name=mysql --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=com.mysql.cj.jdbc.Driver --jta=true --use-java-context=true --exception-sorter-class-name=com.mysql.cj.jdbc.integration.jboss.ExtendedMysqlExceptionSorter reload run batch shutdown
SQL Server
batch module add --name=com.microsoft --resources=<JDBC .jar file path> --module-xml=<module file path> /subsystem=datasources/jdbc-driver=sqlserver:add(driver-name=sqlserver,driver-module-name=com.microsoft,driver-class-name=com.microsoft.sqlserver.jdbc.SQLServerDriver,driver-datasource-class-name=com.microsoft.sqlserver.jdbc.SQLServerDataSource) data-source add --name=sqlDS --jndi-name=java:jboss/datasources/sqlDS --driver-name=sqlserver --connection-url=$DATABASE_CONNECTION_URL --validate-on-match=true --background-validation=false --valid-connection-checker-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLValidConnectionChecker --exception-sorter-class-name=org.jboss.jca.adapters.jdbc.extensions.mssql.MSSQLExceptionSorter reload run batch shutdown
アプリケーションの JTA データソース構成を更新します。
アプリの
src/main/resources/META-INF/persistence.xml
ファイルを開き、<jta-data-source>
要素を見つけます。 その内容を次に示すように置き換えます。PostgreSQL
<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
MySQL
<jta-data-source>java:jboss/datasources/mysqlDS</jta-data-source>
SQL Server
<jta-data-source>java:jboss/datasources/postgresDS</jta-data-source>
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
使用する
DATABASE_CONNECTION_URL
はデータベース サーバーごとに異なり、Azure portal 上の値とは異なるため、これを特定します。 WildFly では、ここで示す URL の形式を使う必要があります。PostgreSQL
jdbc:postgresql://<database server name>:5432/<database name>?ssl=true
MySQL
jdbc:mysql://<database server name>:3306/<database name>?ssl=true\&useLegacyDatetimeCode=false\&serverTimezone=GMT
SQL Server
jdbc:sqlserver://<database server name>:1433;database=<database name>;user=<admin name>;password=<admin password>;encrypt=true;trustServerCertificate=false;hostNameInCertificate=*.database.windows.net;loginTimeout=30;
後の段階でデプロイ YAML を作成するときに、適切な値と共に環境変数
DATABASE_CONNECTION_URL
、DATABASE_SERVER_ADMIN_FULL_NAME
、およびDATABASE_SERVER_ADMIN_PASSWORD
を渡す必要があります。
WildFly でのデータベース接続の構成について詳しくは、PostgreSQL、MySQL、または SQL Server をご覧ください。
JNDI リソースを設定する
WildFly 上で構成する必要がある各 JNDI リソースを設定するには、一般に次の手順を使用します。
- 必要な JAR ファイルをダウンロードし、Docker イメージにコピーします。
- これらの JAR ファイルを参照する WildFly module.xml ファイルを作成します。
- 特定の JNDI リソースに必要な構成を作成します。
- Docker ビルド中に JNDI リソースを登録するために使用する JBoss CLI スクリプトを作成します。
- Dockerfile にすべてのものを追加します。
- デプロイ YAML に適切な環境変数を渡します。
次の例は、Azure Service Bus への JMS 接続用の JNDI リソースを作成するために必要な手順を示しています。
Apache Qpid JMS プロバイダーをダウンロードします
ダウンロードしたアーカイブをアンパックして、.jar ファイルを取得します。
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>
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}
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
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
後の段階でデプロイ 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}."
AKS にデプロイする
Kubernetes YAML ファイルを作成して適用します。 詳細については、「クイック スタート: Azure CLI を使用して Azure Kubernetes Service クラスターをデプロイする」を参照してください。 外部ロード バランサーを (アプリケーションまたはイングレス コントローラー用に) 作成する場合は、前のセクションで LoadBalancerIP
としてプロビジョニングした IP アドレスを必ず指定してください。
外部化したパラメーターを環境変数として含めます。 詳細については、「コンテナーの環境変数の定義」を参照してください。 シークレット (パスワード、API キー、JDBC 接続文字列など) は含めないでください。 これらについては以下のセクションで説明します。
デプロイ YAML を作成するときは、必ずメモリと CPU の設定を含めて、コンテナーのサイズが適切に設定されるようにしてください。
永続ストレージを構成する
アプリケーションで非揮発性ストレージが必要な場合は、永続ボリューム を 1 つ以上構成します。
スケジュールされたジョブを移行する
AKS クラスター上でスケジュールされたジョブを実行するには、必要に応じて Kubernetes CronJob を定義します。 詳細については、「CronJob を使用した自動タスクの実行」を参照してください。
移行後
アプリケーションを Azure Kubernetes Service に移行したので、期待どおりに動作することを確認する必要があります。 これを完了したら、アプリケーションをよりクラウドネイティブにするための次の推奨事項をご覧ください。
推奨事項
イングレス コントローラーまたはアプリケーション ロード バランサーに割り当てられた IP アドレスに DNS 名を追加することを検討してください。 詳細については、「AKS で静的パブリック IP アドレスを使用してイングレス コントローラーを作成する」を参照してください。
アプリケーションに HELM チャートを追加することを検討してください。 Helm チャートを使用すると、より多様な顧客によって使用およびカスタマイズされるように、アプリケーションのデプロイをパラメーター化できます。
DevOps の戦略を設計し、実装します。 信頼性を維持しながら開発速度を向上させるには、Azure Pipelines を使用してデプロイとテストを自動化することを検討してください。 詳細については、AKS へのビルドとデプロイに関するページをご覧ください。
クラスターに対して Azure 監視を有効にします。 詳しくは、「既にデプロイされている AKS クラスターの監視を有効にする」をご覧ください。 これにより、Azure Monitor はコンテナー ログの収集、使用状況の追跡などを行えます。
Prometheus を使用して、アプリケーション固有のメトリックを公開することを検討してください。 Prometheus は、Kubernetes コミュニティで広く採用されているオープンソースのメトリック フレームワークです。 独自の Prometheus サーバーをホストするのではなく、Azure Monitor で Prometheus メトリックのスクレーピングを構成して、アプリケーションからのメトリックの集計と、異常な状態に対する自動応答またはエスカレーションを有効にできます。 詳しくは、「Azure Monitor for containers で Prometheus メトリックのスクレーピングを構成する」をご覧ください。
事業継続とディザスター リカバリー戦略を設計し、実装します。 ミッション クリティカルなアプリケーションの場合は、複数リージョン デプロイのアーキテクチャを検討してください。 詳細については、「AKS での事業継続とディザスター リカバリーに関するベスト プラクティス」を参照してください。
Kubernetes バージョン サポート ポリシーを確認します。 常にサポートされているバージョンが実行されるように、継続的に AKS クラスターを更新するのは開発者の責任です。 詳細については、「AKS クラスターのアップグレード」を参照してください。
クラスター管理とアプリケーション開発を担当するすべてのチーム メンバーに、関連する AKS のベスト プラクティスを確認してもらいます。 詳しくは、「Azure Kubernetes Service (AKS) でのアプリケーションの構築および管理のためのクラスター オペレーターと開発者のベスト プラクティス」をご覧ください。
デプロイ ファイルでローリング アップデートの実行方法が指定されていることを確認します。 詳細については、Kubernetes のドキュメントの「ローリング アップデートのデプロイ」を参照してください。
ピーク時の負荷に対処するように自動スケーリングを設定します。 詳細については、「AKS でのアプリケーションの需要を満たすようにクラスターを自動的にスケーリング」を参照してください。
さらにパフォーマンスを最適化するために、コードのキャッシュ サイズを監視し、Dockerfile に JVM パラメーター
-XX:InitialCodeCacheSize
および-XX:ReservedCodeCacheSize
を追加することを検討します。 詳細については、Oracle のドキュメントの「Codecache チューニング」をご覧ください。