spring - 構成フレームワークの提案

Question

スプリングベースのWebアプリケーション（20のJVMで実行するため）の作業を開始しています。Webアプリケーションは、さまざまな環境（Dev、QA、test、Stress、Productionなど）で実行されます。

以下の設計目標を使用して、アプリケーションの構成フレームワークの設計を検討しています...

構成フレームワークの設計目標

1. 継承モデルのサポート：
   構成プロパティが静的である場合、グローバルに定義でき、すべての環境に継承できる必要があります。環境には、継承されたプロパティの値をオーバーライドする機能が必要です。
2. 冗長性の排除：
   構成プロパティを表示、変更、および追加するには、1つの場所を調べるだけで済みます。これにより、プロパティを追加または変更するときにファイルが失われるリスクを減らすことができます。
3. 実行時にプロパティを管理および維持する機能。
   メモリ内の1対多のJVMのプロパティを簡単に変更でき、JVMの再起動時にその変更を保持するオプションが必要です。
4. デバッグする機能。
   機能スイッチなどの現在の状態を判断するには、プロパティをメモリから簡単にダンプできる必要があります（1対多のプロパティ）。
5. さまざまなINT、QA、STRESS環境が同期しておらず、展開および保守が困難である可能性を減らします。
6. 開発の容易さ、および本番環境までの展開プロセスをサポートします。この変更は、開発を効果的に行うためのローカル開発者の能力に悪影響を与えるべきではありません。それどころか、それはそれを容易にするはずです。

Springでこの種の構成フレームワークを実現するための提案/推奨事項はありますか？

Answer 1

そこには多くの要件があり、それらすべてに対する答えはありませんが、アプリケーションが可能な限り多くのランタイム構成パラメーターを外部化することをお勧めします。私はBeanファイルでプロパティ置換を使用するのが好きで、値はファイルシステム上のよく知られた場所からロードされます。本番環境では、管理者またはアプリのみがその場所の読み取り/書き込みを行えるように、その場所をロックダウンする必要があります。

したがって、開発環境では、開発者のニーズに固有のもの（ローカルデータベースのクレデンシャルなど）があります。QAとプロダクションについても同じです。アプリを一度ビルドすると（通常はビルドボックス/継続的インテグレーションサーバーによって実行されます）、デプロイ先の環境の構成が読み込まれるだけです。これにより、すべての詳細がコードベースから分離され、パスワードや暗号化キーなどの機密情報を安全な場所にロックしておくのに便利です。

Springを使用してプロパティの置換を実行することにまだ慣れていない場合は、次を参照してください。

PropertyPlaceholderConfigurer

Answer 2

これをソフトウェア開発作業（Springまたはその他）としてではなく、構成管理作業のように扱うことをお勧めします。

これらの要件のほとんどを達成するために私たちが行うことは、環境全体で一定のままである構成と、潜在的に変化する可能性のある構成を区別することです。たとえば、アプリの配線の多くは一定のままですが、パスワード、WebサービスのURLなどは異なります。（アプリの配線も変更される場合があることに注意してください。たとえば、ローカル開発ボックスではローカル認証を使用しますが、他の環境ではCASを使用します。）

次に、一定の構成がアプリ自体の一部であり（つまり、WARまたはEARにパッケージ化されている）、変化する構成が外部化されていることを確認します。

どこで外部化するのですか？お気に入りのバージョン管理ツールを使用してバージョン管理リポジトリ（構成リポジトリ）を設定し、さまざまな環境用のフォルダーを作成します。環境固有の構成を適切なフォルダーに配置し、適切なフォルダーから適切な構成を取得するように展開スクリプトを設定します。

このスキームはかなりいいです。構成の集中管理が可能になり、ドリフトの制御に役立ち、監査機能、ロールバック、診断サポートなども提供されます。ソースコードを分岐するのと同じように構成を分岐します。

特にSpringに関しては、3.1にはプロファイルと呼ばれるもののサポートが含まれます。これにより、特定の環境に合わせて構成を調整できます。まだ見ていませんが、SpringOne2GXで聞いたことを覚えています。

Answer 3

Jeff Hallの回答に同意しますが、PropertyOverrideConfigurerクラスのドキュメントも読むことをお勧めします。

PropertyPlaceholderConfigurerおよびクラスがニーズに合わない場合は、 PropertyOverrideConfigurerJeffHallの回答の次の2段階の変更/拡張を検討することをお勧めします。

ステップ1.MyConfig4 *（「config4star」と発音）構成ファイルパーサーは、Springに統合されていないことを除いて、指定された要件のほとんどすべてに対応します。「Config4*スタートガイド」の第2章と第3章を読んで、Config4*がプロジェクトに役立つかどうかを判断することをお勧めします。あなたがそれが役に立つかもしれないと決めるなら、そして...

手順2.Springクラスのソースコードのコピーを作成し、プロパティファイルではなくConfig4*ファイルから名前=値PropertyPlaceholderConfigurerペアを取得するように変更します。

この2段階の提案の潜在的な利点は、INT / QA/STRESS環境ごとおよび/または20個のJVMごとに個別のプロパティファイルを維持する必要がないことです。代わりに、Config4 *の「適応可能な構成」機能により、これらすべての環境とJVMのランタイム構成値を単一の構成ファイルに入れることができます。