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

  • [アーティクル]

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

移行前

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

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

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

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

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

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

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

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

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

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

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

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

注意

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

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

java -version

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

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

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

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

アプリケーションがセッション レプリケーションに依存している場合は、アプリケーションを変更してこの依存関係を削除する必要があります。

アプリケーション内

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

データソースの文書化

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

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

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

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

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

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

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

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

スケジュールされたジョブ (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 と AMQP 1.0 で Java Message Service (JMS) を使用する」を参照してください。

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

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

アプリケーションで JBoss-EAP 固有の API が使用される場合、それらの依存関係を削除するためにそれをリファクタリングする必要があります。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

注意

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

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

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

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

コンテナー イメージを作成する前に、アプリケーションを 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 コンテナーのクイック スタート リポジトリを使用できます。

  1. KeyVault FlexVolume を構成する
  2. データ ソースを設定する
  3. JNDI リソースを設定する
  4. 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 など) に置き換えます。

    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

  4. アプリケーションの 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>

  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 の形式を使う必要があります。

    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;

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

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}."

AKS にデプロイする

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

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

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

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

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

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

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

移行後

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

Recommendations