WildFly アプリケーションを Azure Kubernetes Service 上の WildFly に移行する
このガイドでは、既存の WildFly アプリケーションを移行して Azure Kubernetes Service コンテナーの WildFly 上で実行する場合に知っておくべきことについて説明します。
Note
この記事では、一般的なアドバイスのみが記載されています。 Microsoft も Red Hat も WildFly のサポートを提供しませんが、WildFly コミュニティはサポートを提供できます。 Red Hat と Microsoft が共同でサポートするオファーの詳細については、「Azure での Red Hat JBoss EAP」を参照してください。
移行前
移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。
サーバー容量をインベントリする
現在の実稼働サーバーのハードウェア (メモリ、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 が必要です。そのため、サポートされているバージョンを使用してアプリケーションが正しく動作することを確認する必要があります。
Note
現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。
現在の Java バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。
java -version
WildFly の実行に使用するバージョンのガイダンスについては、「Requirements」を参照してください。
JNDI リソースをインベントリする
すべての JNDI リソースをインベントリします。 JMS メッセージ ブローカーなどでは、移行または再構成が必要になる場合があります。
セッション レプリケーションが使用されているかどうか確認する
アプリケーションがセッション レプリケーションに依存している場合は、アプリケーションを変更してこの依存関係を削除する必要があります。
アプリケーション内
ファイル WEB-INF/jboss-web.xml または WEB-INF/web.xml、あるいはその両方を調べます。
データソースの文書化
アプリケーションでデータベースを使用する場合は、次の情報を把握する必要があります。
- データソース名
- 接続プールの構成
- JDBC ドライバーの JAR ファイルの場所
詳細については、WildFly のドキュメントの「DataSource Configuration」を参照してください。
ファイル システムが使用されているかどうかとその使用方法を判断する
アプリケーション サーバーでファイル システムを使用する場合は、再構成や、まれにアーキテクチャの変更が必要になります。 ファイル システムは、WildFly モジュールまたはアプリケーション コードによって使用される場合があります。 次のセクションに記載された一部または全部のシナリオを確認できます。
読み取り専用の静的コンテンツ
現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツを 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 永続ストアが構成されている場合は、それらの構成を把握して、移行後に適用する必要があります。
アプリケーションで 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 の実装が WildFly に関連付けられている場合は、その依存関係を削除するようにアプリケーションをリファクタリングする必要があります。 コネクタを使用できる場合は、JAR をサーバーのクラスパスに追加し、必要な構成ファイルを WildFly サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。
JAAS が使用されているかどうかを判断する
アプリケーションで JAAS が使用されている場合は、JAAS がどのように構成されているかを把握する必要があります。 データベースを使用している場合は、それを WildFly 上の JAAS ドメインに変換できます。 カスタム実装の場合は、それを WildFly で使用できるかどうかを確認する必要があります。
アプリケーションでリソース アダプターが使用されるかどうかを判断する
アプリケーションでリソース アダプター (RA) が必要な場合、アプリケーションは WildFly と互換性がある必要があります。 WildFly のスタンドアロン インスタンスで RA が正常に機能するかどうかを確認するには、それをサーバーにデプロイし、適切に構成します。 RA が適切に機能する場合、JAR を Docker イメージのサーバー クラスパスに追加し、必要な構成ファイルを WildFly サーバー ディレクトリ内の適切な場所に配置して使用できるようにする必要があります。
アプリケーションが複数の WAR で構成されているかどうか確認する
アプリケーションが複数の WAR で構成されている場合は、これらの各 WAR を個別のアプリケーションとして扱い、それぞれについてこのガイドに従う必要があります。
アプリケーションが EAR としてパッケージ化されているかどうか確認する
アプリケーションが EAR ファイルとしてパッケージ化されている場合は、必ず application.xml ファイルを調べて、構成を把握してください。
Note
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 コンテナーのクイック スタート リポジトリを使用できます。
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 チューニング」をご覧ください。