web-dev-qa-db-ja.com

Java Webアプリケーション構成パターン

複数の環境にわたるJava Webアプリケーションの構成プロファイルの変更を簡素化するために使用できるパターンまたはベストプラクティスがあります。例：JDBC URL、SOAPエンドポイント、など.

私の質問を明確にするのに役立つ背景として、私はいくつかの大きなJava Webアプリケーションを使用して、特定のリリースサイクル中に6つの異なる環境を移動します;開発、統合、QA、パフォーマンス、そして最終的に複数の運用サーバーに展開されます。各環境では、構成を変更する必要があります。現時点では、各展開のほとんどの構成変更は手動で行われるため、時間がかかり、エラーが発生しやすくなります。
このプロセスから手動による介入を取り除く方法はありますか？

javaweb-applicationsconfigurationdesign-patterns
60
Dónal Boyle

最近は.NETで作業する傾向があるので、私のJavaはかなり錆びています。これは少し調整するだけでどの言語でも機能するはずです。

.NET構成システムの拡張機能を使用して、よりグローバルな構成と組み合わせて環境やアプリケーション固有の設定を使用できるようにしています。構成システムは、各マシンに対してグローバル設定を使用して、それをdev、beta、またはproduction（デフォルト）として識別します。順番に読み込まれる一連のファイル、および最後のファイルの設定は、以前に読み込まれたファイルで定義された設定を上書きします。ファイルは次の順序でロードされます。

  1. 全体設定
  2. アプリケーション固有の設定
  3. アプリケーション固有の環境のオーバーライド

すべてのファイルはソース管理下にあり、環境はアプリケーションが実行されているマシンで定義されているため、マシン構成が「ベータ」として識別しない限り、「ベータ」構成にアクセスしないため、本番アプリケーションを開発データベースに誤って指定することを恐れることなく、すべての構成ファイルを昇格できます。

15
Jeremy S

Jakarta Commons Configuration API（ http://commons.Apache.org/configuration/ ）でこの質問に答えた人がいないことに驚いています。ファイル（またはXML、JNDI、JDBCなどの他の構成ソース）の階層を持つことができます。それがJeremy Seghiが話していたことであり、デフォルトとローカルのオーバーライドの両方を有効にする良い方法を提供します。

最良の部分は、テスト済みの実用的なソリューションであるため、自分で何かを作る必要がないということです。

31
John Munsch

ここでは、私が使用した、または遭遇したいくつかの可能なプラクティスを示します。通常、これらを組み合わせることが実際に必要です。

ビルド時にconffilesの変数値を置き換える

これは、Apache Antでこれを行う方法の例です。 Antプロパティ（${var.name}）は、ビルド構成ファイルで制御できます。

<filterset id="variables.to.replace">
    <filter token="APPNAME" value="${app.name}"/>
    <filter token="WEBAPP-PATH" value="${webapp.path}"/>
    <filter token="ENCRYPT-ALGORITHM" value="${encrypt.algorithm}"/>
    <filter token="ERROR-MAILTO" value="${error.mailTo}"/>
    <!--...-->
</filterset>

<!-- Then, when building & copying the conf, replace the variables: -->
<copy todir="${properties.target.dir}">
    <!-- env specific conf files -->
    <fileset dir="${basedir}/env/${run.env}/webapp/WEB-INF/classes" />
    <filterset refid="variables.to.replace"/>
</copy>

良い点は、ビルド時にさまざまな構成を細かく制御できることです。悪い点は、この方法を多数の異なる構成で広範囲に使用すると、システムが非常に複雑になり、保守が困難になる傾向があることです。また、conffileもビルドする必要があるため、開発サイクルが遅くなります。

webapp起動時のwar内のconfからの変数の置換

これは、可能な構成が1つしかない場合でも、Spring Frameworkを使用するときに私が通常行うことであり、懸念の分離の利点を得ています。 Springを使用すると、webappの起動時に、Springコンテキスト内でconf値をPlaceholderPropertyConfigurerに置き換えることができます。この場合、とにかく正しい構成を選択する必要があります。これは、たとえばビルド時に構成できます。

ビルド時の置き換えと比較して、必要に応じて、非圧縮のWebアプリケーションの値を一時的に操作する方が簡単です。もちろん、何かを変更した場合はwebappを再起動する必要があり、手動による変更はwebappの再デプロイ後は保持されません。 SpringもSpringコンテキストに制限されているため、 これは、たとえばweb.xmlでは機能しません （しかし、web.xmlでの変数の使用は、制限があるため、とにかく回避する必要があります）。

事前定義されたファイルからローカル設定を読み取る

このアプローチは、おそらくセットアップするのが最も簡単なアプローチです。構成ファイルのパスを作成するだけです。 $HOME/mywebapp/conf.propertiesを起動して、起動時に何らかの方法でWebアプリケーションを読み取ります。

ここでの良い点は、webappをビルド/デプロイするときにconfを気にする必要がないことです。とにかく、あなたはいくつかの賢明なconfのデフォルトを持っているべきです、そしてそれはローカルのconfによって上書きされることができます。

データベースにconfがある

これは、confパラメータをオーバーライドするための最も柔軟なソリューションですが、場合によっては複雑になることもあります。 name列とvalue列のあるテーブルにconfを含めると、ほとんどの場合に機能します。

もちろん、データベーステーブルでJDBC接続のURLを構成することはできませんが、これは、db接続がセットアップされた後のwebappの操作に影響を与える単純なテキスト/数値のconfに対する優れたソリューションです。パフォーマンスの低下を避けるために、頻繁にアクセスされる場合は、何らかの方法でconfをキャッシュしてください。

追加プラクティス

Kgiannakakisが指摘したように、アプリの構成診断ページを設定することも役立ちます。

11
Eemeli Kantola

これは、Webアプリケーションサーバーが提供するオプションに大きく依存します。異なるJDBC URLを持つJBoss用の複数の環境があり、JNDI名はすべてのサーバーで同じままで、ローカルインスタンスの構成が変更されるだけなので、ビルドからビルドまで問題はありません。

簡単に言えば、ベストプラクティスは、構成を外部化し、各サーバーの正しい設定で適切なファイルを適切な場所に保持し、Webアプリにその構成を読み取らせることです。外部化と読み取りの正確な性質は、特定の構成とアプリケーションサーバーに依存します。

編集：これらの構成は、戦争の一部として（私たちの場合は耳に）存在しないため、上書きされません。

6
Yishai

最初に、頻繁に変更されるすべての構成設定を1か所にまとめます。構成を完了するために、JNDIのセットアップ、データベース値の編集、およびプロパティファイルの変更を同時に行う必要がある場合は、非常に困難です。編集が最も簡単で、すべてが適切に設定されていることを確認しやすいメディアを優先します。プロパティファイルが最善のソリューションだと思います。あなたは簡単にそれらを編集することができ、すべてが大丈夫であることを確認するためにそれらをざっと見るだけです。プロパティファイルを選択する場合は、それらの標準の場所を慎重に選択し、パスに環境変数を割り当てます。

また、すべてが適切に設定されていることを確認する簡単なテストがある場合にも役立ちます。たとえば、構成パラメーターを表示し、データベースやリモートサーバーへの接続の試行など、いくつかの基本的なテストを実行するテストページを作成できます。

2
kgiannakakis

選択した言語でコンポーネント構成パターンを使用できます

POSAの本に記載されている（第4巻にあると思います）

（Java commons-configuration コンポーネントを使用できます）で）。

1
Jorge DeFlon Developer

Seam またはGrails（Railsから借用）で使用したい良い例が使用されています。プロファイルはデフォルトで3つあります。prod、dev、testですが、必要に応じてさらに定義できます。

SeamではビルドはAntファイルによって行われます。内容が異なる可能性のある各ファイルは、プロファイルごとに定義されます。データソース、SQLスクリプト、またはプロパティファイル。

import-dev.sql
import-prod.sql
import-test.sql

Antファイルが選択されたプロファイルで実行されると、適切なファイルが取得され、プロファイル名はそのファイル名から切り捨てられます。

以下は、ターゲットに配置できるコードスニペットです

<copy tofile="${war.dir}/WEB-INF/classes/import.sql" 
      file="${basedir}/resources/import-${profile}.sql"/>

JDBC url、ドライバー名はプロパティファイルに外部化できます（もちろんプロファイル名をサフィックスとして使用します）。

<filterset id="persistence">
     <filter token="transactionManagerLookupClass" value="${transactionManagerLookupClass}"/>

<copy tofile="${war.dir}/WEB-INF/classes/META-INF/persistence.xml" 
     file="${basedir}/resources/META-INF/persistence-${profile}.xml">
     <filterset refid="persistence"/>
</copy>

または、コマンドラインからant build呼び出しに渡すことができるプロパティの値。これはSeamで行われていることの短い例です。

別のオプションは Maven を使用することです。 mavenの方法では、プロパティと profiles によって行われますが、個別のモジュールを使用して構成を分割し、主要な機能を持つ他のモジュールを作成することもできます。 Mavenのプロパティとプロファイルの一般的な使用例は、複数のデータベース、デプロイメントサーバーなどの実行構成です。異なるベンダーの構成を作成する場合はさらに困難ですが、Mavenの場合は問題ありません:)

Mavenプロファイルを使用する良い例は、この投稿フォーム Carlos Sanchez blog です。

まとめると、Ant/Seam an Mavenパラメータ（プロファイル）を調べることを強くお勧めします。これらのソリューションには、もう1つの利点があります。antまたはmavenスクリプトをCIサーバーで実行でき（ Hudson など）、すべてのプロファイルを同時に実行/テストできます。

1
cetnar

これに取り組むにはいくつかの可能な方法があります：

  • 同様にプロパティファイルを使用しますが、環境値（たとえばlocalhostホスト名）間のマップを定義して使用するプロパティファイルを選択するために使用される「メタプロパティ」ファイルを、ロードするプロパティファイル名に追加します。

  • プロパティをデータベースに配置し、アプリケーションサーバーのプロパティテーブルへのデータベース接続を、Webアプリによって取得されるリソースとして定義します。

  • プロパティファイルを.warまたは.earに配置せず、ターゲットホストごとのプロパティファイルを含むproperties-deployhost.jarアーカイブを作成します。適切な.jarファイルをクラスパスに追加して、デプロイされたWebアプリにバインドします（たとえば、Webアプリごとのアプリケーションサーバー構成の共有ライブラリを介して）。

ターゲットシステムの名前が変更されたときに構成ソースを更新し、新しい展開ファイルを構築する代わりに、これらの最初の手順のみで展開時に手動で追加の手順を実行する必要はありません。

私はこれらの多くのバリエーションとあなたのアプローチが可能であると確信しています、最良の選択はあなたの状況に依存します。

0
rsp

私たちの仕事はかなりうまくいきます。

起動時に、プログラムはハードコードされたパスにある構成ファイルを読み取ります。それがそうだとしましょう：

/config/fun_prog/config.xml

各プログラムには異なるハードコーディングされたパスがあり（FunProgramはfun_progにあり、Super Serverはsup_servにあります）、したがって、プログラムがお互いの上を歩くことを心配する必要はありません。

XMLファイルは、作成した小さな構成ライブラリによって読み取られます。 XMLファイルには、DB接続情報、通常はメールサーバーの構成データ、通知の送信先の電子メールアドレス、テストモードで動作するかどうか、外部サービスのURLなどが含まれています。

したがって、変更を加える必要がある場合は、構成ファイルをコピーし、必要なものを編集して、プログラムを再起動します。標準のサーバー設定があるので、これらのファイルをコピーするだけで（そして必要なhttpd.confをいじるだけで）、任意のサーバーに任意のプログラムを配備できます。

派手ではありませんが、非常にうまく機能します。理解、新しい設定オプションの追加、バックアップ、編集は非常に簡単です。すべてのプラットフォームで機能します（UNIXは明らかです。Windowsは/で始まるパスをc：\に変換するため、編集することなく機能します）。

ワークステーションは基本的にサーバーと同じソフトウェアを実行しますが、その構成ファイルにいくつかの変更が加えられています。

0
MBCook

次のURLをご覧ください。 http://issues.Apache.org/jira/browse/CONFIGURATION-394

私たちが探している構成フレームワークは、Apache Commons Configurationの上にあるものであり、並行処理の問題、JMXの問題、およびほとんどのストア（例：.propertiesファイル、.xmlファイル、またはPreferencesAPI）をサポートする必要があります。

「管理コンソール」でweblogicチームが提供しているのは、登録されたリスナーに通知されるように、構成をトランザクション（アトミック）で更新できるようにすることです。

Apacheの人たちは、このプロジェクトはCommons Configurationの範囲外であると主張しています。

簡単な設定フレームワークを添付しましたので、ご覧ください。

0
javabegin