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

[アーティクル]
10/03/2024

このガイドでは、既存の Spring Cloud アプリケーションを移行して Azure Container Apps で実行する場合に知っておくべきことについて説明します。

移行前

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

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

Azure Kubernetes Service のコンテナーに実行可能 JAR アプリケーションを移行する (ガイド計画済)
実行可能 JAR アプリケーションを Azure Virtual Machines に移行する (ガイド計画済)

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

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

お使いのサービスがローカルファイルシステムに対して書き込みや読み取りを行うすべてのインスタンスを検索します。短期または一時ファイルの書き込みと読み取りが行われる場所と、存続期間が長いファイルの書き込みと読み取りが行われる場所を特定します。

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

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

現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。静的コンテンツを Azure Blob Storage に移動し、グローバルな高速ダウンロードのために Azure CDN を追加することを検討できます。詳細については、「Azure Storage での静的 Web サイトホスティング」と「クイックスタート:Azure ストレージアカウントと Azure CDN との統合」を参照してください。

動的に公開される静的コンテンツ

アプリケーションが、アップロードされたものかアプリケーション自体によって生成されたものかを問わず、作成後に変更されない静的コンテンツをサポートしている場合は、Azure Blob Storage と Azure CDN を統合できます。また、Azure Functions を使用してアップロードを管理し、必要に応じて CDN の更新をトリガーすることもできます。「Azure Functions を使用した静的コンテンツのアップロードと CDN の事前読み込み」で、ご利用いただけるサンプルの実装を提供しています。

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

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

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

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

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

Note

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

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

java -version

サポートされている Java、Spring Boot、Spring Cloud のバージョンと更新手順については、「Azure Container Apps 上の Java の概要」を参照してください。

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

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

Maven

Maven プロジェクトでは、Spring Boot バージョンは通常、POM ファイルの <parent> 要素にあります。

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

Gradle

Gradle プロジェクトでは、Spring Boot バージョンは通常、org.springframework.boot プラグインのバージョンとして plugins セクションにあります。

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 2.0 移行ガイドまたは Spring Boot 3.0 移行ガイドに従って、サポートされている Spring Boot バージョンに更新してください。サポートされているバージョンについては、Spring Cloud のドキュメントを参照してください。

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

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

Maven

Maven プロジェクトでは、通常、Spring Cloud バージョンは spring-cloud.version プロパティで設定されています。

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

Gradle

Gradle プロジェクトでは、Spring Cloud バージョンは通常、"追加のプロパティ" ブロックで設定されます。

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

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

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

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

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

アプリケーションで使用しているアプリケーションパフォーマンス管理エージェントを特定します。 Azure Containers 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")
      ...
    }

使用中のブローカーを特定したら、対応する設定を見つけます。 Spring Cloud アプリケーションでは、通常、アプリケーションディレクトリ内の application.properties および application.yml ファイル内、または Spring Cloud Config Server リポジトリ内にあります。

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=tryandguess

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

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

ibm:
  mq:
    queueManager: qm1
    channel: dev.ORDERS
    connName: localhost(14)
    user: admin
    password: big$ecr3t

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

外部キャッシュを特定する

使用中の外部キャッシュを特定します。一般的に、Redis が Spring Data 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

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

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

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

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

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

geo レプリケーション/分散を文書化する

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

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

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

移行

制限付き構成を削除する

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

コマンドライン引数、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 レジストリおよび構成サーバーとして実行されるアプリを作成する必要はありません。詳細については、クイックスタート: Azure portal を使用して最初のコンテナーアプリをデプロイするを参照してください。

Spring Cloud Config Server を準備する

Azure Container Apps for Spring コンポーネントで Config Server を構成します。詳細については、「Azure Container Apps の Spring 用 Config Server コンポーネントの設定を構成する」を参照してください。

Note

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

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

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

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

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

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

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

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

Note

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

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

Azure Containers 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 プロバイダーがオンプレミスの 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 レジストリと連動するようにアプリケーションを有効にすることを検討してください。このコンポーネントにより、デプロイされた他の Spring アプリケーションやクライアントから、アプリケーションを動的に検出できます。詳細については、「Azure Container Apps の Spring 用 Eureka Server コンポーネントの設定を構成する」を参照してください。次に、Spring Client Load Balancer を使用するようにアプリケーションクライアントを変更します。 Spring Client Load Balancer により、クライアントでは、アプリケーションのすべての実行中インスタンスのアドレスを取得し、インスタンスの破損または応答不可状態が発生した場合に、機能する別のインスタンスを検出することができます。詳細については、Spring ブログの「Spring Tips: Spring Cloud Load Balancer」を参照してください。
アプリケーションをパブリックにする代わりに、Spring Cloud Gateway インスタンスの追加を検討してください。 Spring Cloud Gateway は、Azure Container Apps 環境にデプロイされたすべてのアプリケーションの単一エンドポイントとなります。 Spring Cloud Gateway が既にデプロイされている場合は、新しくデプロイされたアプリケーションにトラフィックをルーティングするようにルーティングルールが構成されていることを確認してください。
Spring Cloud Config Server を追加し、すべての Spring Cloud アプリケーションの構成を、バージョン管理も含め、一元的に管理することを検討してください。まず、構成を格納するための Git リポジトリを作成し、それを使用するようにアプリインスタンスを構成します。詳細については、「Azure Container Apps の Spring 用 Config Server コンポーネントの設定を構成する」を参照してください。次に、以下の手順で構成を移行します。
1. アプリケーションの src/main/resources ディレクトリ内に、次の内容を含む bootstrap.yml ファイルを作成します。
```
  spring:
    application:
      name: <your-application-name>
```
2. 構成 Git リポジトリで、<your-application-name>.yml ファイルを作成します。ここで、your-application-name は、前の手順と同じです。 src/main/resources 内の application.yml ファイルから、作成した新しいファイルに、設定を移動します。設定が以前に .properties ファイルに含まれていた場合は、まず YAML に変換します。この変換を実行するには、オンラインツールまたは IntelliJ プラグインを検索します。
3. 上記のディレクトリに application.yml ファイルを作成します。このファイルを使用して、Azure Container Apps 環境内のすべてのアプリケーション間で共有される設定とリソースを定義できます。通常、このような設定には、データソース、ログ設定、Spring Boot アクチュエータの構成などが含まれます。
4. これらの変更を Git リポジトリにコミットし、プッシュします。
5. application.properties または application.yml ファイルをアプリケーションから削除します。
アクチュエータエンドポイントを公開する Spring Boot Web アプリケーションの管理インターフェイスを有効にするには、Admin for Spring マネージドコンポーネントの追加を検討してください。詳細については、「Azure Container Apps で Spring Boot Admin コンポーネントを構成する」を参照してください。
一貫性のある自動デプロイのためにデプロイパイプラインを追加することを検討します。 Azure Pipelines と GitHub Actions の手順を参照できます。
コンテナーアプリのリビジョン、リビジョンラベル、およびイングレストラフィックの重みを使用してブルーグリーンデプロイを有効にすることを検討してください。これにより、コードの変更を一部またはすべてのエンドユーザーに公開する前に、運用環境でテストできます。詳細については、「Azure Container Apps でのブルーグリーンデプロイ」を参照してください。
サポートされている Azure データベースにアプリケーションを接続するために、サービスバインドを追加することを検討します。これらのサービスバインドにより、資格情報などの接続情報を Spring Cloud アプリケーションに提供する必要がなくなります。
Java 開発スタックを有効にして、アプリケーションの JVM コアメトリックを収集することを検討してください。詳細については、「Azure Container Apps の Java アプリ用 Java メトリック」を参照してください。
異常な状態を迅速に検出して対処するために、Azure Monitor のアラートルールおよびアクショングループを追加することを検討します。詳細については、「Azure Container Apps でアラートを設定する」を参照してください。
Azure Container Apps のゾーン冗長性を有効にして、リージョン内のゾーン間でアプリをレプリケートすることを検討してください。トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。冗長設定の詳細については、「Azure Container Apps の信頼性」を参照してください。
Application Gateway の Web Application Firewall を使用して、Azure Container Apps を一般的な悪用や脆弱性から保護することを検討してください。詳細については、「Application Gateway で Web Application Firewall を使用して Azure Container Apps を保護する」を参照してください。

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

従来	現行
Spring Cloud Eureka	Spring Cloud Service Registry
Spring Cloud Netflix Zuul	Spring Cloud Gateway
Spring Cloud Netflix Archaius	Spring Cloud Config Server
Spring Cloud Netflix Ribbon	Spring Cloud Load Balancer (クライアント側のロードバランサー)
Spring Cloud Hystrix	Spring Cloud Circuit Breaker と Resilience4J
Spring Cloud Netflix Turbine	Micrometer と Prometheus

次の方法で共有

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

移行前

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

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

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

動的に公開される静的コンテンツ

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

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

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

Maven

Gradle

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

Maven

Gradle

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

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

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

データベース

JMS メッセージ ブローカー

外部キャッシュを特定する

ID プロバイダー

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

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

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

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

証明書をインベントリする

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

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

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

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

geo レプリケーション/分散を文書化する

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

移行

制限付き構成を削除する

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

Spring Cloud Config Server を準備する

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

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

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

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

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

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

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

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

移行後

フィードバック

その他のリソース

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

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

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

JMS メッセージブローカー

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

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

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

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

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

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