アプリケーション構成はどこに置くべきですか？

私は最近、「環境に依存するプロパティをどこに保存すべきか」という議論を読んでいます。

従来の方法は、環境ごとに複数のプロパティファイルを作成し、環境変数（DEV、PROD ...）に基づいて、アプリケーションの起動時にそれらを読み込む場所を選択することです（Springプロファイルなど）。

一方、コンテナを使用してアプリケーションを展開している場合、この種の構成は環境自体から（アプリケーションが読み取る環境変数を使用して）取得する必要があるため、イメージは環境間で変化しません。

各アプローチの長所と短所は何ですか？コンテナシナリオに「最適な」アプローチはありますか？

プロパティファイルと環境変数が相互に排他的であると言ったのは誰ですか？

「アプリの設定をどこに保存しますか？」には区別があります。そして、「私のアプリはどこで設定をソースしますか？」

最も起こりそうな結果は、誰もがおそらくあるはずですただ彼らは、設定ファイルでやっていることをやり続けるストレージ・メカニズム（長期的、環境が存在する限りとしての永続的な状態だと思います）。

ただし、その構成ファイルをアプリケーションコンテキストにドロップして実行させるのではなく、アプリケーションの起動時に環境内でこれらの変数が既に使用可能になっていることを期待できるはずです。

つまり、2つの展開ワークフローが必要です-

1. X変更管理プロセスを経て、ZツールでYレビューを行うことにより、環境にアプリケーションをデプロイします。
2. A変更管理プロセスを経て、CツールでBレビューを行い、同じプロセスで異なる結果を出すことにより、環境構成を環境に展開します。

consulなどのツールで環境変数をキーと値のペアとして管理する例を使用するには、gitに構成ファイルを保存し、git2consulなどのツールを使用して、更新時に構成を環境に取り込みます。

構成ファイルとして構成が利用できることを期待しているアプリがある場合、consul-templateのようなものを使用してデプロイプロセスを構築することにより、アプリで構成ファイルの複数のコピーを出荷することを回避できます。 consul値をファイルに戻します。

 その方法は、実行中のアプリケーションごとに3つのピース（またはアーティファクト）があることです。

1. 開発中のアプリケーション。これは環境に関係なく同じです。例に合わせて、それはjar / warとしてのSpringアプリケーションになります。
2. アプリケーションを実行するコンテナ。これは環境に関係なく同じです。Spring Bootを使用している場合、Tomcatは必要なく、Javaランタイムのみが必要です。そのため、openjdk Dockerコンテナーを使用します。
3. アプリケーションに必要な構成。これは、環境によって異なる唯一のものです。Springアプリでは、おそらくプロパティファイルを使用します。

構成ファイルは、別個のソース管理に存在します。これは以前はGitでしたが、現在はhttp://www.configapp.comで作成した ConfigというSaaSを使用しています。Configのコア機能は、環境固有の構成を簡単に処理できることです。新しいサーバーでアプリケーションを実行するには、Dockerコンテナー、アプリケーションアーティファクト、およびその環境の構成ファイルをプルします。コンテナでは、コンテナの実行の一部として、アプリケーションと設定ファイルが保存されているディレクトリをマウントします。私たちのアプリケーションは同じです。コンテナ/イメージは同じです。構成ファイルのみが異なります。

構成ファイルと環境変数について。長い間、構成ファイルを使用していました。PaaS /クラウドを使用する場合、環境変数を使用しました。多くの設定がある場合は追加の作業であったため、環境変数を使用して正しい設定ファイルを決定することになりました。プロパティを環境変数に変換するアプリケーションが1つありますが、それは一般的ではありません。一元化された構成サーバーを認可された会社がある場合は、それを使用します。そうでない場合は、構成ファイルの単純さが気に入っています。

要約すると、app.jar、app.properties、openjdk Dockerをプルします。次に、app.jarとapp.propertiesの場所をマウントしてopenjdk Dockerを実行します。環境固有の唯一のものはapp.propertiesです。プロパティキー、環境、クラスター/リージョンインスタンスの数に関係なく、app.propertiesを簡単に管理するために、Configを使用します。