Tomcat アプリケーションを Azure Container Apps に移行する

このガイドでは、既存の Tomcat アプリケーションを Azure Container Apps に移行するプロセスについて説明します。 移行前の評価、移行自体、移行後の最適化について説明します。

前提条件

• Azure のサブスクリプション。 アカウントがない場合は、無料アカウントを作成してください。
• Azure CLI がインストールされているか、 Azure portal にアクセスします。
• Apache Tomcat の管理、WAR パッケージ、Docker コンテナーに関する知識。
• サポートされている JDK バージョン (8、11、17、または 21)。 詳細については、「Azure Container Apps 上の Java の概要」を参照してください。
• Docker (省略可能 - イメージをローカルでビルドする場合にのみ必要)。

移行前の評価

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

外部リソースをインベントリする

Java Naming and Directory Interface (JNDI) を使用して、データ ソース、JMS メッセージ ブローカーなどの外部リソースを挿入します。 これらのリソースの一部には、移行または再構成が必要な場合があります。

アプリケーション内

META-INF/context.xml ファイルを調べます。 <Resource>要素内<Context>要素を探します。

アプリケーション サーバー上

$CATALINA_BASE/conf/context.xml ファイルと $CATALINA_BASE/conf/server.xmlファイルを調べます。 .xmlファイルについても$CATALINA_BASE/conf/<engine-name>/<host-name>ディレクトリを確認すること。

context.xml ファイルでは、最上位の <Resource> 要素内の<Context>要素を使用して JNDI リソースを記述します。

server.xml ファイルでは、<Resource>要素内の<GlobalNamingResources>要素を使用して JNDI リソースを記述します。

データ ソース

データ・ソースは、 type 属性が javax.sql.DataSource に設定された JNDI リソースです。 データ ソースごとに、次の情報を文書化します。

• データ ソース名は何ですか?
• 接続プールの構成は何ですか?
• JDBC ドライバー JAR ファイルはどこにありますか?

詳細については、Tomcat ドキュメントの JNDI データソースのハウツー を参照してください。

その他のすべての外部リソース

このガイドでは、可能なすべての外部依存関係を文書化することは不可能です。 チームは、移行後にアプリケーションのすべての外部依存関係を満たすことができるかどうかを確認する責任があります。

シークレットと証明書のインベントリ

パスワードとセキュリティで保護された文字列

運用サーバー上のすべてのプロパティと構成ファイルで、シークレット文字列とパスワードを確認します。 必ず $CATALINA _BASE/conf で server.xml とcontext.xmlを確認してください。 META-INF/context.xml、Spring Boot アプリケーション、application.properties、またはapplication.yml ファイルなど、アプリケーション内にパスワードまたは資格情報を含む構成ファイルが見つかる場合もあります。

証明書

パブリック SSL エンドポイント、またはバックエンド データベースやその他のシステムとの通信に使用されるすべての証明書を文書化します。 次のコマンドを実行すると、運用サーバー上のすべての証明書を表示できます。

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

ファイル システムの使用状況を確認する

サービスがローカル ファイル システムに対して読み取りまたは書き込みを行うインスタンスを特定します。 短期または一時的なファイルと、有効期間が長いファイルに注意してください。

Azure Container Appsには、いくつかの種類のストレージが用意されています。 エフェメラル ストレージを使用すると、実行中のコンテナーまたはレプリカ内の一時データの読み取りと書き込みを行うことができます。 Azure Files を使用すると、複数のコンテナーで共有できる永続的なストレージを提供できます。 詳細については、「 Azure Container Appsを参照してください。

アプリケーションが 読み取り専用の静的コンテンツを提供する場合は、それを Azure Blob Storage に移動し、グローバル配布用に Azure CDN を追加することを検討してください。 詳細については、「 Azure Storagec1>Quickstart: Azure storage アカウントを Azure CDN と統合する」を参照してください。

アプリケーションが 動的に発行された静的コンテンツ (作成後に変更されないアップロードまたは生成されたコンテンツ) を処理する場合は、Azure Blob Storage と Azure CDN を統合できます。 Azure 関数を使用してアップロードを管理し、CDN の更新をトリガーすることもできます。 サンプル実装については、「 Azure Functions を使用した静的コンテンツのアップロードと CDN プリロード」を参照してください。

現在、アプリケーションが Tomcat webapps/ ディレクトリから静的コンテンツを提供している場合は、移行の一環として、そのコンテンツを外部ストレージ ソリューションに移動することを計画します。

OS 固有のコードを確認する

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

プラットフォームの互換性を確認する

Dockerfile を手動で作成し、コンテナー化されたアプリケーションを Azure Container Apps にデプロイする場合は、JRE/JDK のバージョンや Tomcat のバージョンなど、デプロイを完全に制御できます。

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

注

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

現在の Java バージョンを確認するには、運用サーバーにサインインし、次のコマンドを実行します。

java -version

セッション永続化メカニズムを特定する

使用中のセッション永続化マネージャーを識別するには、アプリケーションと Tomcat の構成内の context.xml ファイルを調べます。 <Manager>要素を探し、className属性の値をメモします。

Tomcat の組み込みの PersistentManager 実装 ( StandardManager や FileStore など) は、Azure Container Apps などの分散スケーリングされたプラットフォームで使用するように設計されていません。 Container Apps は、複数のインスタンス間で負荷分散を行い、いつでも任意のインスタンスを透過的に再起動する可能性があるため、変更可能な状態をファイル システムに保持することはお勧めしません。

セッションの永続化が必要な場合は、Redis Cache を使用した VMware Tanzu Session Manager などの外部データ ストアに書き込む代替の PersistentManager 実装を使用します。

スケジュールされたジョブを識別する

コンテナー化された Tomcat デプロイでは、Quartz Scheduler タスクや cron ジョブなどのスケジュールされたジョブを使用することはできません。 アプリケーションをスケールアウトすると、スケジュールされた 1 つのジョブがスケジュールされた期間ごとに複数回実行される可能性があり、意図しない結果になる可能性があります。

アプリケーション サーバーの内部または外部で、スケジュールされたジョブのインベントリを作成します。 Container Apps ジョブには、有効期間の短いタスクまたはバッチ スタイルのタスクが適しています。 詳細については、Azure Container Apps におけるジョブをご参照ください。

MemoryRealm が使用されているかどうかを確認する

MemoryRealm には、永続化された XML ファイルが必要です。 Azure Container Apps では、このファイルをコンテナー イメージに追加するか、コンテナーで使用できるようにする共有ストレージにアップロードする必要があります。 詳細については、「 セッション永続化メカニズムの識別 」セクションを参照してください。 それに応じて、 pathName パラメーターを変更する必要があります。

MemoryRealmが現在使用されているかどうかを確認するには、server.xml ファイルと context.xml ファイルを調べます。 <Realm>属性がclassNameに設定されているorg.apache.catalina.realm.MemoryRealm要素を検索します。

構成をパラメーター化する

移行前に、server.xmlファイルや context.xml ファイルで、データ ソースなどのシークレットと外部依存関係を特定した可能性があります。 各項目について、ユーザー名、パスワード、接続文字列、または URL を環境変数に置き換えます。

注

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

たとえば、 context.xml ファイルに次の要素が含まれているとします。

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="jdbc:postgresql://postgresdb.contoso.com/wickedsecret?ssl=true"
    driverClassName="org.postgresql.Driver"
    username="postgres"
    password="{password}"
/>

次の例に示すように、変更できます。

<Resource
    name="jdbc/dbconnection"
    type="javax.sql.DataSource"
    url="${postgresdb.connectionString}"
    driverClassName="org.postgresql.Driver"
    username="${postgresdb.username}"
    password="${postgresdb.password}"
/>

ログ記録と APM の評価

移行するアプリケーションで使用するログ集計ソリューションを特定します。 ログに記録されたイベントを使用できるように、移行中に診断設定を構成する必要があります。 詳細については、「 ログ記録と診断の構成」セクションを 参照してください。

アプリケーションで使用するアプリケーション パフォーマンス管理 (APM) エージェントを特定します。 Azure Container Apps では、組み込みの APM サポートは提供されていません。 コンテナー イメージを準備するか、APM ツールをコードに直接統合します。 アプリケーションのパフォーマンスを測定するが、まだ APM を統合していない場合は、自動インストルメンテーション Java エージェントで Azure Application Insights を使用することを検討してください。 詳細については、「 Java アプリケーションの Azure Monitor OpenTelemetry を有効にする」を参照してください。

ドキュメント展開アーキテクチャ

Tomcat アプリケーションの次の情報を文書化します。

• 実行中のインスタンスの数。
• 各インスタンスに割り当てられた CPU の数。
• 各インスタンスに割り当てられた RAM の量。

また、アプリケーション インスタンスを複数のリージョンまたはデータ センターに分散するかどうかを決定します。 移行するアプリケーションのアップタイム要件と SLA を文書化します。

移行

Container Apps 環境を作成する

Azure サブスクリプションに Container Apps 環境を作成します。 詳細については、「Quickstart: Azure ポータルを使用して最初のコンテナー アプリをデプロイするを参照してください。

ログ記録と診断を構成する

ログ記録を構成して、すべての出力をファイルではなくコンソールにルーティングします。

アプリケーションを Azure Container Apps にデプロイした後、Container Apps 環境内でログ オプションを構成して、1 つ以上のログ宛先を定義できます。 これらの宛先には、Azure Monitor Log Analytics、Azure Event Hubs、または Microsoft 以外の監視ソリューションを含めることができます。 また、ログ データ ストレージを無効にして、実行時にのみログを表示することもできます。 構成手順については、 Azure Container Apps のログ ストレージと監視オプションに関するページを参照してください。

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

アプリケーションの一部がローカル ファイル システムに対して読み取りまたは書き込みを行う場合は、永続的ストレージを構成して置き換えます。 たとえば、Tomcat アプリケーションがログを書き込んだり 、/opt/tomcat/data にアップロードしたりする場合は、Azure Files 共有を作成し、同じパスにマウントします。

az containerapp update \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --set-env-vars "UPLOAD_DIR=/opt/tomcat/data"

アプリ設定を使用してコンテナーにマウントするパスを指定し、アプリケーションが使用するパスに合わせます。 詳細については、「 Azure Container Appsを参照してください。

証明書を Azure Key Vault に移行する

Azure Container Apps では、アプリ間のセキュリティで保護された通信がサポートされています。 安全な通信を確立するプロセスをアプリケーションで管理する必要はありません。 プライベート証明書を Azure Container Apps にアップロードすることも、無料のマネージド証明書を使用することもできます。 Azure Key Vault を使用して証明書を管理することをお勧めします。

Key Vault に証明書を格納し、コンテナー アプリから証明書を参照するには:

1. 証明書を Azure Key Vault にインポートします。 詳細については、「 Azure Key Vault に証明書をインポートする」を参照してください。
2. コンテナー アプリでマネージド ID を有効にし、 コンテナーに対する Key Vault シークレット ユーザー ロールを付与します。
3. カスタム ドメインに Key Vault 証明書を使用するようにコンテナー アプリを構成します。

詳細については、Azure Container Apps の証明書 を参照してください。

デプロイの成果物を準備する

Tomcat on Containers クイック スタート GitHub リポジトリを複製します。 このリポジトリには、多くの推奨される最適化を含む Dockerfile と Tomcat 構成ファイルが含まれています。 次の手順では、コンテナー イメージをビルドして Container Apps にデプロイする前に、これらのファイルに対して行う必要がある変更の概要を示します。

注

一部の Tomcat デプロイでは、1 つの Tomcat サーバーで複数のアプリケーションが実行されます。 このセットアップがデプロイと一致する場合は、個別のコンテナー アプリで各アプリケーションを実行します。 この方法を使用すると、複雑さと結合を最小限に抑えながら、各アプリケーションのリソース使用率を最適化できます。

JNDI リソースを追加する

次の例に示すように、server.xmlを編集して、移行前の手順で準備したリソース (データ ソースなど) を追加します。

注

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

<!-- Global JNDI resources
      Documentation at /docs/jndi-resources-howto.html
-->
<GlobalNamingResources>
    <!-- Editable user database that can also be used by
         UserDatabaseRealm to authenticate users
    -->
    <Resource name="UserDatabase" auth="Container"
              type="org.apache.catalina.UserDatabase"
              description="User database that can be updated and saved"
              factory="org.apache.catalina.users.MemoryUserDatabaseFactory"
              pathname="conf/tomcat-users.xml"
               />

    <!-- Migrated datasources here: -->
    <Resource
        name="jdbc/dbconnection"
        type="javax.sql.DataSource"
        url="${postgresdb.connectionString}"
        driverClassName="org.postgresql.Driver"
        username="${postgresdb.username}"
        password="${postgresdb.password}"
    />
    <!-- End of migrated datasources -->
</GlobalNamingResources>

その他のデータ ソースの手順については、Tomcat ドキュメントの JNDI データソースのハウツー の次のセクションを参照してください。

• MySQL
• PostgreSQL
• SQL Server

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

Container Apps で使用するためにイメージをビルドして Azure Container Registry (ACR) にアップロードする最も簡単な方法は、 az acr build コマンドを使用することです。 このコマンドでは、Docker をコンピューターにインストールする必要はありません。 たとえば、 tomcat-container-quickstart リポジトリの Dockerfile があり、現在のディレクトリにアプリケーション パッケージ petclinic.war がある場合は、次のコマンドを使用して ACR でコンテナー イメージをビルドできます。

az acr build \
    --registry $acrName \
    --image "${acrName}.azurecr.io/petclinic:{{.Run.ID}}" \
    --build-arg APP_FILE=petclinic.war \
    --build-arg SERVER_XML=prod.server.xml .

WAR ファイルに --build-arg APP_FILE... という名前が付けられている場合は、 パラメーターを省略できます。 サーバー XML ファイルにserver.xmlという名前が付けられている場合は、--build-arg SERVER_XML...パラメーターを省略できます。 両方のファイルは、Dockerfile と同じディレクトリに存在する必要があります。

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

# Build the image locally.
docker build . --build-arg APP_FILE=petclinic.war -t "${acrName}.azurecr.io/petclinic:1"

# Run the image locally.
docker run -d -p 8080:8080 "${acrName}.azurecr.io/petclinic:1"

# You can now access your application with a browser at http://localhost:8080.

# Sign in to ACR.
az acr login --name $acrName

# Push the image to ACR.
docker push "${acrName}.azurecr.io/petclinic:1"

注

Linux では、ユーザーが docker グループにいない場合は、sudo コマンドの前に docker を付ける必要がある場合があります。

詳細については、「 Azure Container Registry を使用したコンテナー イメージのビルドと格納」を参照してください。

Azure Container Appsにデプロイする

次のコマンドは、デプロイの例を示しています。

az containerapp create \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --environment <ENVIRONMENT_NAME> \
    --image <IMAGE_NAME> \
    --target-port 8080 \
    --ingress 'external' \
    --registry-server <REGISTRY_SERVER> \
    --min-replicas 1

詳細なクイック スタートについては、「 クイック スタート: 最初のコンテナー アプリをデプロイする」を参照してください。

シークレットと環境変数を構成する

各アプリケーションに環境変数として構成設定を挿入します。 これらの変数を手動エントリまたはシークレットへの参照として設定します。 詳細については、「 Azure Container Apps での環境変数の管理」および「Azure Container Appsでのシークレットの管理」を参照してください。

ID と認証を設定する

Tomcat アプリケーションで認証または承認が必要な場合は、ID プロバイダーにアクセスするように構成が設定されていることを確認します。

• ID プロバイダーが Microsoft Entra ID の場合は、変更を加えないでください。
• ID プロバイダーがon-premises Active Directory フォレストである場合は、Microsoft Entra IDを使用してハイブリッド ID ソリューションを実装することを検討してください。 詳細については、ハイブリッド ID のドキュメントを参照してください。
• ID プロバイダーが PingFederate などの別のオンプレミス ソリューションである場合は、「 Microsoft Entra Connect のカスタム インストール 」を参照して、Microsoft Entra ID とのフェデレーションを構成します。

アプリケーションで認証に Tomcat 領域 ( MemoryRealm や JDBCRealmなど) を使用する場合は、外部 ID プロバイダーに移行するか、コンテナー イメージ内の領域を構成することを計画します。

アプリケーションを公開する

既定では、Azure Container Apps にデプロイされたアプリケーションには、環境外からアクセスできません。 外部アクセスを有効にするには、イングレスを構成します。

az containerapp ingress enable \
    --resource-group <RESOURCE_GROUP> \
    --name <APP_NAME> \
    --type external \
    --target-port 8080 \
    --transport auto

独自の仮想ネットワークを使用してマネージド環境にアプリをデプロイする場合は、アプリのアクセシビリティ レベルを決定して、仮想ネットワークからのパブリックイングレスまたはイングレスのみを許可します。 詳細については、「Azure Container Apps 環境でのNetworkingを参照してください。

移行後

移行が完了したら、アプリケーションが期待どおりに動作することを確認します。 次のセクションでは、アプリケーションをよりクラウドネイティブで運用上の堅牢なものにするための推奨事項について説明します。

運用の準備を改善する

次の推奨事項は、移行されたアプリケーションの信頼性、可観測性、デプロイプラクティスを強化するのに役立ちます。

• CI/CD パイプライン: 自動で一貫性のあるデプロイ用のデプロイ パイプラインを追加します。 手順は、 Azure Pipelines と GitHub Actions で使用できます。
• 青緑色のデプロイ: コンテナー アプリのリビジョン、リビジョン ラベル、イングレス トラフィックの重みを使用して、運用環境でコードの変更をテストしてから、エンド ユーザーが使用できるようにします。 詳細については、「Blue-Green Deployment in Azure Container Apps」を参照してください。
• サービス バインド: サポートされている Azure データベースにアプリケーションを接続するためのサービス バインドを追加します。 サービス バインドにより、Spring Boot アプリケーションに接続情報 (資格情報を含む) を提供する必要がなくなります。
• JVM メトリック: Java 開発スタックで JVM コア メトリックを収集できるようにします。 詳細については、Azure Container Apps 内の Java アプリ用 Java メトリックを参照してください。
• アラート: Azure Monitor アラート ルールとアクション グループを追加して、異常な状態をすばやく検出して対処します。 詳細については、「 Azure Container Appsを参照してください。
• ゾーンの冗長性: ゾーンの冗長性を有効にして、可用性ゾーン間でアプリをレプリケートします。 トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。 詳細については、「 Azure Container Apps の信頼性」を参照してください。
• Web アプリケーション ファイアウォール: Application Gateway 上の Web アプリケーション ファイアウォールを使用して、コンテナー アプリを一般的な悪用や脆弱性から保護します。 詳細については、Application Gateway 上の Web Application Firewall で Azure Container Apps を保護する方法 を参照してください。

Tomcat 固有の推奨事項

• パフォーマンスを向上させるには、 logging.properties ファイル内の項目を評価します。 ログ出力の一部を削除または削減することを検討してください。

• コード キャッシュ サイズを監視し、パフォーマンスをさらに最適化するために、dockerfile の-XX:InitialCodeCacheSize変数に-XX:ReservedCodeCacheSizeパラメーターとJAVA_OPTSパラメーターを追加することを検討してください。 詳細については、Oracle ドキュメントの 「Codecache チューニング 」を参照してください。

関連するコンテンツ

• Java on Azure Container Apps の概要
• クイックスタート: Azure portal を使用して最初のコンテナー アプリをデプロイする
• Spring Boot アプリケーションを Azure Container Apps に移行する
• Spring Cloud アプリケーションを Azure Container Apps に移行する