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

[アーティクル]
09/20/2024

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

移行前

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

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

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

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

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

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

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

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

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

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

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

Note

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

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

java -version

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

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

すべての JNDI リソースをインベントリします。 JMS メッセージブローカーなどでは、移行または再構成が必要になる場合があります。

アプリケーション内

ファイル WEB-INF/ibm-web-bnd.xml または WEB-INF/web.xml、またはその両方を調べます。

データソースの文書化

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

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

詳細については、WebSphere のドキュメントの「データベース接続の構成」を参照してください。

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

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

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

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。静的コンテンツを 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 を含むボリュームを作成して使用する」を参照してください。

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

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

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

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

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

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

アプリケーションで WebSphere 固有の API が使用される場合、それらの依存関係を削除するためにそれをリファクタリングする必要があります。たとえば、IBM WebSphere アプリケーションサーバー、Release 9.0 API の仕様に記載されているクラスを使用している場合は、アプリケーションで WebSphere 固有の API を使用しています。

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

アプリケーションで Entity Beans または EJB 2.x スタイルの CMP Beans が使用されている場合は、アプリケーションをリファクタリングしてこれらの依存関係を削除する必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Note

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

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

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

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

コンテナーイメージを作成する前に、アプリケーションを 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 を構成する
データソースを設定する
JNDI リソースを設定する
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}."

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

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

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

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

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

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

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

移行後

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

推奨事項

イングレスコントローラーまたはアプリケーションロードバランサーに割り当てられた IP アドレスに DNS 名を追加することを検討してください。詳細については、「Azure Kubernetes Service のイングレスコントローラーで TLS を使用する」を参照してください。
アプリケーションに HELM チャートを追加することを検討してください。 Helm チャートを使用すると、より多様な顧客によって使用およびカスタマイズされるように、アプリケーションのデプロイをパラメーター化できます。
DevOps の戦略を設計し、実装します。信頼性を維持しながら開発速度を向上させるには、Azure Pipelines を使用してデプロイとテストを自動化することを検討してください。詳細については、「Azure Pipelines を使用して Azure Kubernetes Service にビルドしてデプロイする」を参照してください。
クラスターに対して Azure 監視を有効にします。詳細については、「Kubernetes クラスターの監視を有効にする」をご覧ください。これにより、Azure Monitor はコンテナーログの収集、使用状況の追跡などを行えます。
Prometheus を使用して、アプリケーション固有のメトリックを公開することを検討してください。 Prometheus は、Kubernetes コミュニティで広く採用されているオープンソースのメトリックフレームワークです。独自の Prometheus サーバーをホストするのではなく、Azure Monitor で Prometheus メトリックのスクレーピングを構成して、アプリケーションからのメトリックの集計と、異常な状態に対する自動応答またはエスカレーションを有効にできます。詳細については、「Prometheus と Grafana を有効にする」を参照してください。
事業継続とディザスターリカバリー戦略を設計し、実装します。ミッションクリティカルなアプリケーションの場合は、複数リージョンデプロイのアーキテクチャを検討してください。詳細については、「Azure Kubernetes Service (AKS) の高可用性とディザスターリカバリーの概要」を参照してください。
Kubernetes バージョンサポートポリシーを確認します。常にサポートされているバージョンが実行されるように、継続的に AKS クラスターを更新するのは開発者の責任です。詳細については、「Azure Kubernetes Service (AKS) クラスターのアップグレードオプション」を参照してください。
クラスター管理とアプリケーション開発を担当するすべてのチームメンバーに、関連する AKS のベストプラクティスを確認してもらいます。詳細については、「Azure Kubernetes Service (AKS) でのアプリケーションの構築および管理のためのクラスターオペレーターと開発者のベストプラクティス」を参照してください。
デプロイファイルでローリングアップデートの実行方法が指定されていることを確認します。詳細については、Kubernetes のドキュメントの「ローリングアップデートのデプロイ」を参照してください。
ピーク時の負荷に対処するように自動スケーリングを設定します。詳細については、「Azure Kubernetes Service (AKS) でクラスターを使用する」を参照してください。
さらにパフォーマンスを最適化するために、コードのキャッシュサイズを監視し、Dockerfile に JVM パラメーター -XX:InitialCodeCacheSize および -XX:ReservedCodeCacheSize を追加することを検討します。詳細については、Oracle のドキュメントの「Codecache チューニング」をご覧ください。

次の方法で共有