序文
最新のサービスのクラウド ネイティブ理論の 12 の要素に基づいて、コンテナー化されたデプロイメントを使用する場合、異なる環境で異なるシーンをパッケージ化するのではなく、同じイメージが異なる環境のデプロイメント要件を満たせるようにする必要があります。このドキュメントでは主に、環境グループ化でのスタートアップ項目の構成を通じて、同じイメージを異なる環境にデプロイできるように、さまざまな環境構成に対応する Spring フレームワークに基づくコンパイルおよびパッケージ化ソリューションを紹介します。
既存の解決策と問題点
私たちがこれまでに見た最も一般的な構成ファイル管理ソリューションは、複数環境の切り替えを実現するための Maven のプロファイル構成に基づいています。その欠点は、pom.xml でプロファイルを構成することです。コンパイルおよびパッケージ化するたびに、コンパイル命令を渡す必要があります。 - P は、現在の環境構成を識別します。これによって生じる問題は、パッケージ化したイメージに環境属性があり、1 つのイメージを複数環境に展開するための要件を満たしていないことです。
もう 1 つの構成ソリューションは、Spring プロファイルに基づいて構成ファイルを管理することです。これら 2 つのソリューションについて、次にいくつかの分析と比較を実行します。
2 つのプロファイル構成の違いと長所と短所の比較
a. 2 つのプロファイル ソリューションの比較
pom.xml
pom.xml
application.properties
application.propertiesapplication.properties
一般に、Maven プロファイルはビルド プロセス中の構成により適しており、ビルド環境や条件に応じて異なるプロファイルをアクティブ化できます。一方、Spring のプロファイル構成はアプリケーションの実行構成により適しており、異なるプロファイルをロードできます。さまざまなプロファイルの設定に従ってください。どちらを選択するかは、ニーズと好みによって異なります。application.properties
b. クラウドネイティブおよびコンテナ化された展開シナリオの分析
クラウド ネイティブおよびコンテナ化されたデプロイメント シナリオでは、Spring のプロファイル構成方法を使用することを好みます。application.properties
クラウド ネイティブおよびコンテナ化された展開シナリオでプロファイル構成を使用する利点は次のとおりです。application.properties
- 環境の独立性:アクティブ化されたプロファイルに従って異なる構成をロードできるため、アプリケーションは異なる環境で実行しても一貫した動作を実現します。アプリケーションは異なる環境 (開発、テスト、運用など) で実行する必要がある場合があるため、これはクラウドネイティブおよびコンテナ化された展開にとって重要です。
application.properties - 構成の集中化:プロファイル構成方法を使用すると、複数のプロファイルに基づく構成を 1 つのファイルで定義できるため、構成管理がより集中化され便利になります。これは、複数の Maven プロファイルを分散して管理する必要がなく、さまざまなプロファイルに従って適切な構成をロードできるため、クラウド ネイティブおよびコンテナ化されたデプロイメント シナリオに非常に役立ちます。
application.properties - コンテナーへの利便性: コンテナー化されたデプロイメント シナリオでは、通常、アプリケーションの構成とデプロイメントを管理するためにコンテナー オーケストレーション ツール (Kubernetes など) が使用されます。プロファイル構成メソッドを使用すると、構成ファイル内の環境変数または属性を通じてアクティブ化されたプロファイルを指定でき、それによってコンテナー オーケストレーション ツールとの統合が実現します。
application.properties
要約すると、Spring の application.properties を使用したプロファイル構成方法は、環境の独立性、集中構成、およびコンテナーへの使いやすさという利点があるため、クラウド ネイティブおよびコンテナー化されたデプロイメント シナリオにより適しています。
プロパティに基づくマルチ環境構成スキームの実践
次のスキームは springboot を例にしています。もちろん、springMVC スキームも適用できますが、追加の構成が必要です。新しいプロジェクトは基本的に springboot に基づいて構築されているため、springMVC の実線スキームはここでは拡張されません。必要に応じて、 , Provide mvc 構成スキームを追加します。
a. 設定ファイルツリー
図１に示すように、
- プロパティ フォルダー: プロパティ フォルダーの下に、dev、online、test、uat などのさまざまな環境に基づいて個別のフォルダーがあり、各フォルダーには現在の環境の構成情報が保存されます。
- spring フォルダー: 共通の JSF 構成 (jsf.xml) や、xml 構成を通じて挿入する必要があるその他のビジネス シナリオなどの XML 構成情報を保存します。もちろん、springboot 公式 Web サイトの提案に基づいて、誰もがアノテーション コードを使用して Bean インジェクションを実装し、xml メソッドを最小限に抑えるよう努めるべきです。
- application.properties ファイル: このファイルは、コア構成 spring.profiles.active=** を通じて現在のプロファイル環境を識別します。もちろん、他のグローバル クラス構成もここに配置できます。図に示すように、spring.profiles.active の値を変更するには、このファイルを別のデプロイメント グループに基づいて上書きする必要があるため、application.properties ファイルを Xingyun デプロイメントのグループ構成で構成する必要があることに注意してください。下に。もちろん、ランタイム起動命令を通じてさまざまなプロファイルを選択することもできます。
- 重要.propertiesファイル: このファイルは JD Xingyun デプロイメント プロトコルです。秘密キーなどの高セキュリティ ファイルは暗号化された方法でこのファイルに保存され、Xingyun デプロイメント グループのリモート構成にデプロイされます。
クラウド展開における具体的な構成は次のとおりです。
b. プロパティファイルのロード
通常の状況では、properties/**/*.properties の下にある構成ファイルは、スタートアップ項目に自動的にロードされません。したがって、動的ロードには追加のメソッドを使用する必要があります。具体的な方法は、Spring フレームワークの下で PropertySourcesPlaceholderConfigurer のクラス属性を使用し、環境変数と組み合わせて構成ファイルをバッチで動的にロードすることです。(追記: springMVC フレームワークの場合は、xml 設定 context:property-placeholder 属性を通じて実装することもできます。 )
具体的なコードは次のとおりです。
/**
* 配置文件环境配置
*
* @Author zhaoyongping
* @date 2023/7/10 15:13
* @ClassName EnvPropertiesConfig
* @Descripiton 配置文件环境配置
**/
@Configuration
public class EnvPropertiesConfig {
/**
* 加载属性配置
*
* @param environment 环境属性
* @return PropertySourcesPlaceholderConfigurer
* @author zhaoyongping
* @date 2023/7/10 15:13
* @description 加载属性配置
*/
@Bean
public static PropertySourcesPlaceholderConfigurer propertySourcesPlaceholderConfig(Environment environment) throws IOException {
PropertySourcesPlaceholderConfigurer config = new PropertySourcesPlaceholderConfigurer();
String[] activeProfiles = environment.getActiveProfiles();
if (activeProfiles.length > 0) {
String resourceUrl = "classpath:properties/"
+ environment.getActiveProfiles()[0] + "/*.properties";
config.setLocations(
new PathMatchingResourcePatternResolver().getResources(resourceUrl));
} else {
//兜底策略
config.setLocations(
new PathMatchingResourcePatternResolver()
.getResources("classpath:properties/dev/*.properties"));
}
return config;
}
}
要約する
上記の手順を通じて、コンパイルおよびパッケージ化されたイメージを環境変数にバインドする必要はなく、実行の開始時に異なるグループに基づいて application.properties ファイルを動的に構成するだけで、異なる環境に適応できることがわかります。実行時に構成ファイルを変更できるこのメカニズムは、クラウド ネイティブ時代のコンテナ化された展開ソリューションにより適しており、サービスの移植性にも役立ちます。もちろん、上記はあくまで筆者の個人的な実践経験であり、それが現実的な解決策として最適であるというわけではありません。
Spring Boot 3.2.0 が正式リリース、 Didi 史上最も深刻なサービス障害、原因は基盤ソフトウェアか、それとも「コスト削減と笑いの増大」か? プログラマーらがETC残高を改ざんし年間260万元以上を横領 Google従業員が離職後偉人を批判 Flutterプロジェクトに深く関与しHTML関連の標準策定に関与 Microsoft Copilot Web AIが正式にスタート12 月 1 日、2023 年に中国版 PHP 8.3 GA Firefox をサポート Rust Web フレームワーク Rocket が高速化して v0.5 をリリース: 非同期、SSE、WebSocket などをサポート Loongson 3A6000 デスクトップ プロセッサが正式リリース、国産の光! Broadcom が VMware の買収成功を発表著者: JD Logistics 趙永平
出典：JD Cloud Developer Community Ziyuanqishuo Tech 転載の際は出典を明記してください