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

このガイドでは、既存の Spring Cloud アプリケーションを移行して Azure Container Apps で実行する場合に注意する必要がある事項について説明します。

移行前

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

以下の移行前の要件のいずれかを満たすことができない場合は、次の関連する移行ガイドを参照してください。

実行可能な JAR アプリケーションを Azure Kubernetes Service 上のコンテナーに移行する (ガイダンスが計画されています)
実行可能な JAR アプリケーションを Azure Virtual Machines に移行する (ガイダンスが計画されています)

アプリケーションコンポーネントを検査する

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

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

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 プリロード」を参照してください。

いずれかのサービスに OS 固有のコードが含まれているかどうかを判断する

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

サポートされているプラットフォームに切り替える

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

成果物からのデプロイのために、Azure Container Apps には、特定のバージョンの Java (8、11、17、21) と、Spring Boot および Spring Cloud コンポーネントの特定のバージョンが用意されています。互換性を確保するには、まず、現在の環境でサポートされているバージョンの Java にアプリケーションを移行してから、残りの移行手順に進みます。 Linux ディストリビューションの最新の安定したリリースで、結果の構成を完全にテストします。

注

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

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

java -version

サポートされているバージョンの Java、Spring Boot、Spring Cloud については、 Java on Azure Container Apps の概要を参照してください。

Spring Boot のバージョンを特定する

移行する各アプリケーションの依存関係を調べて、Spring Boot のバージョンを確認します。

Maven プロジェクトで、POM ファイルの <parent> 要素で Spring Boot バージョンを見つけます。

<parent>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-parent</artifactId>
    <version>3.3.3</version>
    <relativePath/> <!-- lookup parent from repository -->
</parent>

Gradle プロジェクトで、plugins セクションで Spring Boot のバージョンを見つけます。

plugins {
  id 'org.springframework.boot' version '3.3.3'
  id 'io.spring.dependency-management' version '1.1.6'
  id 'java'
}

3.x より前の Spring Boot バージョンを使用するアプリケーションの場合は、 Spring Boot 3.0 移行ガイドに従って、サポートされているバージョンに更新してください。サポートされているバージョンについては、 Spring Boot と Spring Cloud のバージョンを参照してください。

Spring Cloud のバージョンを特定する

移行する各アプリケーションの依存関係を調べて、使用されている Spring Cloud コンポーネントのバージョンを確認します。

Maven

Maven プロジェクトで、 spring-cloud.version プロパティで Spring Cloud のバージョンを設定します。

  <properties>
    <spring-cloud.version>2023.0.2</spring-cloud.version>
  </properties>

Gradle

Gradle プロジェクトで、Spring Cloud のバージョンを "extra properties" ブロックに設定します。

ext {
  set('springCloudVersion', "2023.0.2")
}

サポートされているバージョンの Spring Cloud を使用するには、すべてのアプリケーションを更新することが必要です。サポートされているバージョンについては、 Spring Cloud のドキュメントを参照してください。

ログ集計ソリューションを特定する

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

アプリケーションパフォーマンス管理 (APM) エージェントを特定する

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

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

データソース、JMS メッセージブローカー、その他のサービスの URL などの外部リソースを特定します。 Spring Cloud アプリケーションでは、通常、このようなリソースの構成は次のいずれかの場所にあります。

src/main/resources フォルダー内の、通常は application.properties または application.yml と呼ばれるファイル内。
前の手順で特定した Spring Cloud Config Server リポジトリ内で。

データベース

Spring Boot アプリケーションの場合、接続文字列は通常、外部データベースに依存する場合に構成ファイルに表示されます。 application.properties ファイルの例を次に示します。

spring.datasource.url=jdbc:mysql://localhost:3306/mysql_db
spring.datasource.username=dbuser
spring.datasource.driver-class-name=com.mysql.jdbc.Driver

application.yaml ファイルの例を次に示します。

spring:
  data:
    mongodb:
      uri: mongodb://mongouser:deepsecret@mongoserver.contoso.com:27017

可能な構成シナリオについては、Spring Data のドキュメントを参照してください。

JMS メッセージブローカー

関連する依存関係のビルドマニフェスト (通常は 、pom.xml または build.gradle ファイル) を調べることで、使用中のブローカーを特定します。

たとえば、ActiveMQ を使用する Spring Boot アプリケーションでは、通常、 pom.xml ファイルにこの依存関係が含まれます。

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-activemq</artifactId>
</dependency>

商用ブローカーを使用する Spring Boot アプリケーションには、通常、ブローカーの JMS ドライバーライブラリへの依存関係が直接含まれます。 build.gradle ファイルの例を次に示します。

    dependencies {
      ...
      compile("com.ibm.mq:com.ibm.mq.allclient:9.4.0.5")
      ...
    }

使用中のブローカーを特定したら、対応する設定を見つけます。通常、アプリケーションディレクトリ内の application.properties ファイルと application.yml ファイルで見つかります。

注

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

application.properties ファイルの ActiveMQ の例を次に示します。

spring.activemq.brokerurl=broker:(tcp://localhost:61616,network:static:tcp://remotehost:61616)?persistent=false&useJmx=true
spring.activemq.user=admin
spring.activemq.password=<password>

ActiveMQ 構成の詳細については、 Spring Boot メッセージングのドキュメントを参照してください。

application.yaml ファイルの IBM MQ の例を次に示します。

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: <password>

IBM MQ 構成の詳細については、 IBM MQ Spring コンポーネントのドキュメントを参照してください。

外部キャッシュを識別する

使用中の外部キャッシュを特定します。多くの場合、Spring Data Redis 経由で Redis を使用します。構成情報については、 Spring Data Redis のドキュメントを参照してください。

(Java または XML で) それぞれの構成を検索して、Spring Session 経由でセッションデータをキャッシュするかどうかを決定します。

ID プロバイダー

すべての ID プロバイダーと、認証と承認を必要とするすべての Spring Cloud アプリケーションを特定します。 ID プロバイダーを構成する方法についての詳細は、次のリソースを参照してください。

OAuth2 の構成については、 Spring Cloud Security のクイックスタートを参照してください。
Auth0 Spring Security の構成については、 Auth0 Spring Security のドキュメントを参照してください。
PingFederate Spring Security の構成については、 Auth0 PingFederate の手順を参照してください。

VMware Tanzu Application Service (TAS) (以前の Pivotal Cloud Foundry) によって構成されたリソース

TAS で管理されるアプリケーションの場合、多くの場合、TAS サービスバインドを使用して、前に説明したリソースを含む外部リソースを構成します。このようなリソースの構成を調べるには、 TAS (Cloud Foundry) CLI を使用して、アプリケーションの VCAP_SERVICES 変数を表示します。

# Log into TAS, if needed (enter credentials when prompted)
cf login -a <API endpoint>

# Set the organization and space containing the application, if not already selected during login.
cf target org <organization name>
cf target space <space name>

# Display variables for the application
cf env <Application Name>

VCAP_SERVICES変数で、アプリケーションにバインドされている外部サービスの構成設定を調べます。詳細については、 TAS (Cloud Foundry) のドキュメントを参照してください。

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

このガイドでは、可能なすべての外部依存関係を文書化することはできません。移行後、アプリケーションのすべての外部依存関係を満たすことができることを確認する必要があります。

構成のソースとシークレットをインベントリする

パスワードとセキュリティで保護された文字列をインベントリする

運用環境のデプロイ内のすべてのプロパティ、構成ファイル、環境変数で、シークレット文字列とパスワードを確認します。 Spring Cloud アプリケーションでは、通常、これらの文字列は application.properties または application.yml ファイル内の個々のサービスまたは Spring Cloud Config Server リポジトリにあります。

インベントリ証明書

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

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

Spring Cloud Vault が使用されているかどうかを判断する

Spring Cloud Vault を使用してシークレットを格納およびアクセスする場合は、バッキングシークレットストア (HashiCorp Vault や CredHub など) を特定します。次に、アプリケーションコードで使用されるすべてのシークレットを特定します。

構成サーバーソースを見つける

アプリケーションで Spring Cloud Config Server を使用している場合は、構成が格納されている場所を特定します。通常、この設定は bootstrap.yml または bootstrap.properties ファイル、または application.yml または application.properties ファイルにあります。設定は次の例のようになります。

spring.cloud.config.server.git.uri: file://${user.home}/spring-cloud-config-repo

Git は Spring Cloud Config Server のバッキングデータストアとして最も一般的に使用されますが、前に示したように、アプリケーションは他の可能なバックエンドのいずれかを使用する可能性があります。リレーショナルデータベース (JDBC)、SVN、ローカルファイルシステムなどの他のバックエンドについては、Spring Cloud Config Server のドキュメントを参照してください。

デプロイアーキテクチャを検査する

各サービスのハードウェア要件を文書化する

個々の Spring Cloud サービスについて (構成サーバー、レジストリ、ゲートウェイを除く)、次の情報を文書化します。

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

ジオレプリケーションと分散のドキュメント化

Spring Cloud アプリケーションが現在複数のリージョンまたはデータセンターに分散しているかどうかを判断します。移行するアプリケーションのアップタイム要件と SLA を文書化します。

サービスレジストリを使用しないクライアントを特定する

Spring Cloud サービスレジストリを使用せずに、移行する任意のサービスを呼び出すクライアントアプリケーションを特定します。移行後、このような呼び出しはできなくなります。移行前に Spring Cloud OpenFeign を使用するようにこれらのクライアントを更新します。

移行

制限付き構成を削除する

Azure Container Apps 環境には、管理対象の Eureka Server、Spring Cloud Config Server、および管理者が用意されています。アプリケーションを Java コンポーネントにバインドすると、Azure Container Apps は関連するプロパティをシステム環境変数として挿入します。 Spring Boot Externalized Configuration の設計に従って、システム環境変数によって、コードで定義されているアプリケーションプロパティまたは成果物にパッケージ化されたアプリケーションプロパティが上書きされます。

コマンドライン引数、Java システムプロパティ、またはコンテナーの環境変数を使用して次のいずれかのプロパティを設定した場合は、競合や予期しない動作を回避するために削除します。

SPRING_CLOUD_CONFIG_COMPONENT_URI
SPRING_CLOUD_CONFIG_URI
SPRING_CONFIG_IMPORT
eureka.client.fetch-registry
eureka.client.service-url.defaultZone
eureka.instance.prefer-ip-address
eureka.client.register-with-eureka
SPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IP
SPRING_BOOT_ADMIN_CLIENT_URL

Azure Container Appsマネージド環境とアプリを作成する

既存のマネージド環境で Azure サブスクリプションにAzure Container Apps アプリをプロビジョニングするか、移行するすべてのサービスに対して新しいアプリを作成します。 Spring Cloud レジストリおよび構成サーバーとして実行されるアプリを作成する必要はありません。詳細については、「Quickstart: Azure ポータルを使用して最初のコンテナーアプリをデプロイするを参照してください。

Spring Cloud Config Server を準備する

Azure Container Apps の Spring コンポーネントにおいて、Config サーバーを構成します。詳細については、Azure Container Apps の Config Server を利用した Spring コンポーネントの構成設定を参照してください。

注

現在の Spring Cloud Config リポジトリがローカルファイルシステムまたはオンプレミスにある場合は、まず、GitHub、Azure Repos、BitBucket などのクラウドベースのリポジトリに構成ファイルを移行またはレプリケートする必要があります。

コンソールログを確認して診断設定を構成する

ログ記録を構成して、すべての出力がファイルではなくコンソールに送信されるようにします。

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

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

アプリケーションのいずれかの部分でローカルファイルシステムに対する読み取りまたは書き込みが行われる場合は、永続ストレージを構成してローカルファイルシステムを置き換える必要があります。アプリ設定を通じてコンテナーにマウントするパスを指定することで、アプリで使用されているパスと一致させることができます。詳細については、「 Azure Container Appsを参照してください。

Spring Cloud Vault シークレットを Azure Key Vault に移行する

Azure Key Vault Spring Boot Starter を使用して、Spring を介してアプリケーションにシークレットを直接挿入できます。詳細については、「Azure Key Vaultを参照してください。

注

移行において、一部のシークレットの名前変更が必要になる場合があります。必要に応じて、アプリケーションコードを更新してください。

すべての証明書を Key Vault に移行する

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

アプリケーションパフォーマンス管理 (APM) 統合を構成する

コンテナー内で APM 関連の変数を既に構成している場合は、ターゲット APM プラットフォームに接続できることを確認します。 APM 構成がコンテナーの環境変数を参照する場合は、それに応じて Azure Container Apps でランタイム環境変数を設定します。接続文字列などの機密情報を安全に処理します。シークレットとして指定することも、Azure Key Vaultに格納されているシークレットを参照することもできます。

サービスごとのシークレットと外部化された設定を構成する

各コンテナーに、環境変数として構成設定を挿入できます。変数に何らかの変化が生じると、既存アプリの新しいリビジョンが作成されます。シークレットはキーと値のペアであり、すべてのリビジョンで有効です。

ID プロバイダーを移行して有効にする

いずれかの Spring Cloud アプリケーションで認証または承認が必要な場合は、次のガイドラインに従って、ID プロバイダーにアクセスするように構成されていることを確認してください。

ID プロバイダーが Microsoft Entra ID の場合は、変更を加えないでください。
ID プロバイダーがon-premises Active Directory フォレストである場合は、Microsoft Entra IDを使用してハイブリッド ID ソリューションを実装することを検討してください。ガイダンスについては、ハイブリッド ID のドキュメントを参照してください。
ID プロバイダーが PingFederate などの別のオンプレミスソリューションである場合は、 Microsoft Entra Connect のインストールに関するトピックを参照して、Microsoft Entra IDとのフェデレーションを構成します。または、Spring Security を使用して、OAuth2/OpenID Connect または SAML 経由で ID プロバイダーを使用することを検討してください。

クライアントアプリケーションを更新する

移行されたアプリケーションに対して発行されたAzure Container Apps エンドポイントを使用するように、すべてのクライアントアプリケーションの構成を更新します。

移行後

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

クラウドネイティブパターンに合わせて最適化する

次の推奨事項は、Spring Cloud コンポーネントと Azure Container Apps マネージド Java コンポーネントを採用して、アプリケーションをよりクラウドネイティブにするのに役立ちます。

サービスの検出と負荷分散

アプリケーションが Spring Cloud Registry コンポーネントを操作できるようにして、デプロイされた他の Spring アプリケーションとクライアントが動的に検出できるようにします。詳細については、「Azure Container Apps の Eureka Server for Spring コンポーネントの Configure 設定」を参照してください。

次に、Spring Client Load Balancerを使用するようにアプリケーションクライアントを変更します。 Spring Client Load Balancer を使用すると、クライアントはアプリケーションの実行中のすべてのインスタンスのアドレスを取得し、別のインスタンスが破損または応答しなくなった場合に動作するインスタンスを見つけます。詳細については、Spring ブログの「Spring Tips: Spring Cloud Load Balancer」を参照してください。

API ゲートウェイ

Spring Cloud Gateway インスタンスを追加することを検討してください。 Spring Cloud Gateway は、Azure Container Apps環境にデプロイされているすべてのアプリケーションに対して単一のエンドポイントを提供します。 Spring Cloud Gateway を既にデプロイしている場合は、新しくデプロイされたアプリケーションにトラフィックをルーティングするようにルーティング規則を構成していることを確認します。

一元化された構成

Spring Cloud Config Server を追加し、すべての Spring Cloud アプリケーションの構成を、バージョン管理も含め、一元的に管理することを検討してください。まず、構成を格納する Git リポジトリを作成し、それを使用するようにアプリインスタンスを構成します。詳細については、Azure Container Apps の Config Server を利用した Spring コンポーネントの構成設定を参照してください。

次の手順を使用して、構成を移行します。

アプリケーションの src/main/resources ディレクトリ内に、次の内容 のbootstrap.yml ファイルを作成します。
```
spring:
  application:
    name: <your-application-name>
```
構成 Git リポジトリで、 <アプリケーション名>.yml ファイルを作成します。 your-application-name は前の手順と同じです。 設定を src/main/resources のapplication.yml ファイルから、作成した新しいファイルに移動します。設定が以前 に .properties ファイルに含まれている場合は、最初に YAML に変換します。この変換を実現するためのオンラインツールまたは IntelliJ プラグインを見つけることができます。
作成したディレクトリに application.yml ファイルを作成します。このファイルを使用して、データソース、ログ設定、Spring Boot Actuator の構成など、Azure Container Apps 環境内のすべてのアプリケーション間で共有される設定とリソースを定義します。
これらの変更を Git リポジトリにコミットし、プッシュします。
application.properties または application.yml ファイルをアプリケーションから削除します。

行政

アクチュエータエンドポイントを公開する Spring Boot Web アプリケーションの管理インターフェイスを有効にするには、Admin for Spring マネージドコンポーネントの追加を検討してください。詳細については、「Azure Container Appsを参照してください。

運用の準備を改善する

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

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 を保護する方法を参照してください。

従来の Spring Cloud Netflix コンポーネントを置き換える

アプリケーションで Spring Cloud Netflix のレガシコンポーネントを使用している場合は、次の表に示すように、それらを現在の代替候補に置き換えることを検討してください。

レガシーコンポーネント	現在の代替手段
Spring Cloud Eureka	Spring Cloud Service Registry
Spring Cloud Netflix Zuul	Spring Cloud ゲートウェイ
Spring Cloud Netflix Archaius	Spring Cloud Config Server（スプリング・クラウド・コンフィグ・サーバー）
Spring Cloud Netflix リボン	Spring Cloud Load Balancer（クライアント側ロードバランサー）
Spring Cloud Hystrix	Spring Cloud Circuit Breaker と Resilience4J
Spring Cloud Netflix Turbine	Micrometer と Prometheus

フィードバック

このページはお役に立ちましたか?

Last updated on 2026-03-27