このガイドでは、Azure Container Appsで実行する既存の Spring Cloud アプリケーションを移行する場合に注意する必要がある事項について説明します。
移行前
移行を確実に成功させるには、開始する前に、次のセクションで説明する評価とインベントリの手順を完了します。
以下の移行前の要件のいずれかを満たすことができない場合は、次の関連する移行ガイドを参照してください。
- 実行可能な JAR アプリケーションを Azure Kubernetes Service 上のコンテナーに移行する (ガイダンスが計画されています)
- 実行可能な JAR アプリケーションをAzure Virtual Machinesに移行する (ガイダンスが計画されています)
アプリケーション コンポーネントを検査する
ファイル システムが使用されているかどうかとその使用方法を判断する
お使いのサービスがローカル ファイル システムに対して書き込みや読み取りを行うすべてのインスタンスを検索します。 短期または一時ファイルの書き込みと読み取りが行われる場所と、存続期間が長いファイルの書き込みと読み取りが行われる場所を特定します。
Azure Container Appsには、いくつかの種類のストレージが用意されています。 エフェメラル ストレージでは、一時データの読み取りと書き込みを行い、実行中のコンテナーまたはレプリカで使用できます。 Azure File は永続的なストレージを提供し、複数のコンテナー間で共有できます。 詳細については、「
読み取り専用の静的コンテンツ
現在、アプリケーションで静的コンテンツを提供している場合は、そのための別の場所が必要になります。 静的コンテンツをAzure Blob Storageに移動し、超高速ダウンロード用のAzure CDNをグローバルに追加することを検討することをお勧めします。 詳細については、「
動的に公開される静的コンテンツ
アプリケーション自体によってアップロードまたは生成された静的コンテンツ (作成後も変更されない) がアプリケーションでサポートされている場合は、Azure Blob StorageとAzure CDNを統合できます。 Azure関数を使用してアップロードを管理し、必要に応じて 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 ディストリビューションの安定した最新リリースを使用します。
注
現在のサーバーがサポートされていない JDK (Oracle JDK や IBM OpenJ9 など) で実行されている場合、この検証が特に重要です。
現在のJava バージョンを取得するには、実稼働サーバーにサインインし、次のコマンドを実行します。
java -version
サポートされているバージョンの Java、Spring Boot、Spring Cloud、および 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 アプリケーションでは、通常、アプリケーション ディレクトリまたは Spring Cloud Config Server リポジトリ内の 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 コンポーネントのドキュメントを参照してください。
外部キャッシュを特定する
使用中の外部キャッシュを特定します。 一般的に、Redis が Spring Data Redis 経由で使用されています。 構成情報については、 Spring Data Redis のドキュメントを参照してください。
それぞれの構成 (
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 アプリケーションでは、通常、個々のサービスまたは Spring Cloud Config Server リポジトリ内の application.properties または application.yml ファイルでこのような文字列を見つけることができます。
証明書をインベントリする
パブリック 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 の量。
地理的レプリケーション・配信の文書化
Spring Cloud アプリケーションが現在複数のリージョンまたはデータセンターに分散しているかどうかを判断します。 移行するアプリケーションの稼働時間要件/SLA を文書化します。
サービス レジストリを使用しないクライアントを特定する
Spring Cloud サービス レジストリを使用せずに、移行する任意のサービスを呼び出すクライアント アプリケーションを特定します。 移行後は、このような呼び出しはできなくなります。 移行前に Spring Cloud OpenFeign を使用するようにこのようなクライアントを更新します。
移行
制限付き構成を削除する
Azure Container Apps環境には、管理対象の Eureka Server、Spring Cloud Config Server、および Admin が用意されています。アプリケーションがJava コンポーネントにバインドされると、Azure Container Appsは関連するプロパティをシステム環境変数として挿入します。 Spring Boot Externalized Configuration の設計に従って、コードで定義されている、または成果物にパッケージ化されたアプリケーション プロパティは、システム環境変数によって上書きされます。
コマンド ライン引数、Java システム プロパティ、またはコンテナーの環境変数を使用して次のいずれかのプロパティを設定する場合は、競合や予期しない動作を回避するために削除する必要があります。
SPRING_CLOUD_CONFIG_COMPONENT_URISPRING_CLOUD_CONFIG_URISPRING_CONFIG_IMPORTeureka.client.fetch-registryeureka.client.service-url.defaultZoneeureka.instance.prefer-ip-addresseureka.client.register-with-eurekaSPRING_BOOT_ADMIN_CLIENT_INSTANCE_PREFER-IPSPRING_BOOT_ADMIN_CLIENT_URL
Azure Container Appsマネージド環境とアプリを作成する
既存のマネージド環境で Azure サブスクリプションにAzure Container Apps アプリをプロビジョニングするか、移行するすべてのサービスに対して新しいアプリを作成します。 Spring Cloud レジストリおよび構成サーバーとして実行されるアプリを作成する必要はありません。 詳細については、「Quickstart: Azure ポータルを使用して最初のコンテナー アプリをデプロイするを参照してください。
Spring Cloud Config Server を準備する
Spring コンポーネントのAzure Container Appsで構成サーバーを構成します。 詳細については、Azure Container Apps の「
注
現在の Spring Cloud Config リポジトリがローカル ファイル システムまたはオンプレミスにある場合は、まず、構成ファイルを移行するか、クラウド ベースのリポジトリ (GitHub、Azure Repos、BitBucket など) にレプリケートする必要があります。
コンソール ログを確認して診断設定を構成する
すべての出力がファイルではなくコンソールにルーティングされるように、ログ記録を構成します。
アプリケーションを Azure Container Apps にデプロイした後、Container Apps 環境内でログ オプションを構成して、ログの 1 つ以上の宛先を定義できます。 これらの宛先には、Azure Monitor Log Analytics、Azure イベント ハブ、その他のサードパーティの監視ソリューションを含めることができます。 ログ データを無効にして、実行時にのみログを表示することもできます。 詳細な構成手順については、「log storage and monitoring options in Azure Container Apps」を参照してください。
永続ストレージを構成する
アプリケーションのいずれかの部分でローカル ファイル システムに対する読み取りまたは書き込みが行われる場合は、永続ストレージを構成してローカル ファイル システムを置き換える必要があります。 アプリ設定を通じてコンテナーにマウントするパスを指定することで、アプリで使用されているパスと一致させることができます。 詳細については、「
Spring Cloud Vault シークレットを Azure KeyVault に移行する
Azure KeyVault Spring Boot Starter を使用して、Spring を介してアプリケーションにシークレットを直接挿入できます。 詳細については、「
注
移行において、一部のシークレットの名前変更が必要になる場合があります。 必要に応じて、アプリケーション コードを更新してください。
すべての証明書を KeyVault に移行する
Azure Containers Apps では、アプリ間のセキュリティで保護された通信がサポートされています。 安全な通信を確立するプロセスをアプリケーションで管理する必要はありません。 プライベート証明書をAzure Container Appsにアップロードすることも、Azure Container Appsによって提供される無料のマネージド証明書を使用することもできます。 Azure Key Vaultを使用して証明書を管理することをお勧めします。 詳細については、「Azure Container Apps の
アプリケーション パフォーマンス管理 (APM) 統合を構成する
コンテナー内で、APM 関連の変数を既に構成している場合は、ターゲット APM プラットフォームへの接続を確立できることを確認するだけです。 APM 構成がコンテナーの環境変数を参照する場合は、Azure Container Appsに応じてランタイム環境変数を設定する必要があります。 connection stringなどの機密情報は安全に処理する必要があります。 シークレットとして指定することも、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 レジストリと連動するようにアプリケーションを有効にすることを検討してください。 このコンポーネントにより、デプロイされた他の Spring アプリケーションやクライアントから、アプリケーションを動的に検出できます。 詳細については、「Azure Container Apps の Eureka Server for Spring コンポーネントの
Configure 設定」を参照してください。 次に、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 コンポーネントの構成設定」を参照してください。 次に、以下の手順で構成を移行します。 アプリケーションの 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 ファイルを作成します。 このファイルを使用して、Azure Container Apps環境内のすべてのアプリケーション間で共有される設定とリソースを定義できます。 通常、このような設定には、データ ソース、ログ設定、Spring Boot アクチュエータの構成などが含まれます。
これらの変更を Git リポジトリにコミットし、プッシュします。
application.properties または application.yml ファイルをアプリケーションから削除します。
アクチュエータ エンドポイントを公開する Spring Boot Web アプリケーションの管理インターフェイスを有効にするには、Admin for Spring マネージド コンポーネントの追加を検討してください。 詳細については、「
Azure Container Apps を参照してください。一貫性のある自動デプロイのためにデプロイ パイプラインを追加することを検討します。 手順は、Azure Pipelines および GitHub Actions で使用できます。
コンテナー アプリのリビジョン、リビジョン ラベル、およびイングレス トラフィックの重みを使用してブルーグリーン デプロイを有効にすることを検討してください。これにより、コードの変更を一部またはすべてのエンド ユーザーに公開する前に、運用環境でテストできます。 詳細については、「Blue-Green Deployment in Azure Container Apps」を参照してください。
サポートされているAzure データベースにアプリケーションを接続するためのサービス バインドを追加することを検討してください。 これらのサービス バインドにより、資格情報などの接続情報を Spring Cloud アプリケーションに提供する必要がなくなります。
Java開発スタックを有効にして、アプリケーションの JVM コア メトリックを収集することを検討してください。 詳細については、
Java Azure Container Apps を参照してください。アラート ルールとアクション グループAzure Monitor追加して、異常な条件をすばやく検出して対処することを検討してください。 詳細については、「
Azure Container Apps を参照してください。ゾーンの冗長性を有効にして、リージョン内のゾーン間でアプリAzure Container Appsレプリケートすることを検討してください。 トラフィックは負荷分散され、ゾーンの停止が発生した場合、レプリカに自動的にルーティングされます。 冗長な設定の詳細については、「reliability in Azure Container Apps」を参照してください。
Application Gateway でWeb Application Firewallを使用して、一般的な悪用や脆弱性からAzure Container Appsを保護することを検討してください。 詳細については、「Application Gateway でのWeb Application Firewallを使用した Protect Azure Container Apps」を参照>。
アプリケーションで 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 (クライアント側のload balancer) Spring Cloud Hystrix Spring Cloud Circuit Breaker と Resilience4J Spring Cloud Netflix Turbine Micrometer と Prometheus