現在、私のチームは約 4 ~ 5 台の異なるサーバーと約 2 ~ 3 台の異なる DB サーバーを扱っており、環境変数を使用して、使用するサーバーと使用するサーバー構成を決定しています。
チームが拡大し続けているため、これを行うためのより良い方法はありますか? コンパイラのフラグ/引数を検討しましたが、堅牢ではないようです。
現在、私のチームは約 4 ~ 5 台の異なるサーバーと約 2 ~ 3 台の異なる DB サーバーを扱っており、環境変数を使用して、使用するサーバーと使用するサーバー構成を決定しています。
チームが拡大し続けているため、これを行うためのより良い方法はありますか? コンパイラのフラグ/引数を検討しましたが、堅牢ではないようです。
私の見解では、Java では、基本的に 3 つの方法でこの Cookie をクラックできます。
あなたはすでに環境変数を発見しており、それはあなたが求めている効果を得るためのほとんど「UNIXの方法」です。実行中の環境に合わせて実行中のアプリケーションをカスタマイズする共通のバイナリとは異なる構成。
システム プロパティは、実際には環境変数の Java の「道徳的同等物」です。それらは、アプリケーションのコマンドラインで -D パラメータを介して入力されます...
java -Dlogback.configurationFile=/opt/dm/logback.xml -cp app.jar org.rekdev.App
Java での明示的なプロパティ ファイル処理http://docs.oracle.com/javase/tutorial/essential/environment/properties.htmlは、-D と組み合わせてよく見かける 3 番目のバリアントで、デフォルトの動作のようなものを取得します。コマンドラインから実行します。これが上記の logback.xml 構成で基本的に行われていることです。JAR ファイルには、「logback.configurationFile」と呼ばれるシステム プロパティが存在しない限り使用される logback.xml が含まれています。 .
マルチサーバー環境でこれをすべて同期して正しく動作させる方法を見つけようとするときは、chef http://wiki.opscode.com/display/chef/Homeを使用して展開を行い、それぞれを配置することを検討してください。シェフの管理下にある特定の環境のカスタマイズ。シェフの「レシピ」をバージョン管理に入れ、出来上がり、構成管理を完全に行います。
それを出荷!
2つのシナリオを見ることができます
/yourapp/etc/
) 。アプリに名前が付けられているとしましょうfoo
解決策 1
これには、サポートされている任意のサーバー (アプリ パッケージにプロパティ ファイルがあるすべてのサーバー) にアプリをそのまま配置できるという利点があります。あなたのプロパティは、、、、、と名付けfoo.dev.properties
られます。foo.test.properties
foo.prod.properties
foo.damien.properties
foo.bob.properties
もう 1 つの利点は、作業しているすべての開発者が独自の dev ファイルを持っていることです。これを svn/git/whatever に安全にプッシュでき、他の開発者が自分の構成を破棄しないようにすることができます。
実行時に、アプリケーションは-D
パラメーターをチェックしたり、ホスト名を動的に取得したりして、正しいプロパティ ファイルをロードすることができます。
解決策 2
パッケージが不要なプロパティ ファイルによって汚染されないという利点があります。
特定の環境向けにビルドするには、多くの Ant タスク/Maven ターゲットを構成する必要があります。ソース ディレクトリには環境のプロパティ ファイルもありますが、アプリに同梱されるのは 1 つだけです。これには値のプレースホルダーのみがあり、適切な ant タスク/maven ターゲットfoo.properties
を使用して値が推測されます。foo.ENV.properties
実際の仕事でも、前の仕事でも、ソリューション 1 を使用しましたが、柔軟性が得られると思います。ただし、一部のパラメーター (データベース ユーザー/パスワードなど) は、Unix サーバーの環境変数から直接取得されました (そのため、サーバー管理者だけが資格情報を知っていました)。
あなたとあなたのチームにとってより柔軟性があると感じる場所にたどり着くために、ソリューションを安全に組み合わせることができます。