アプリケーション構成を保存するための好ましい方法は何ですか？
ほとんどの場合、次のように、開発アプリケーションの構成をプロジェクトのルートディレクトリに保存します。
app
|-- config.json
しかし、この設定はバージョン管理システムに保存されるため、これは最善のアプローチではないようです。ユーザー名、パスワードなどの機密情報が漏洩する可能性があります。
12 Factor App ガイドでは、構成ファイルをすべて削除し、構成設定に環境変数を使用することを推奨しています。
...設定を環境変数に保存します。環境変数は、コードを変更せずにデプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコードリポジトリにチェックインされる可能性はほとんどありません。カスタム構成ファイル、またはJavaシステムプロパティ）などの他の構成メカニズムとは異なり、言語やOSに依存しない標準です。
それは私には本当にいいように聞こえますが、ソース環境にチェックインせずに、環境変数をどこに保存しますか？また、これらの変数をアプリに渡すためにどのツールを使用できますか？何十もの設定オプションが存在する可能性があり、アプリを起動するたびに手動で入力するのはいいことではありません。そのため、これらのファイルはある種のファイルに保存する必要があります。したがって、上記のファイルはソース管理になり、元の場所に戻ります。
構成オプションを処理する一般的に受け入れられている方法はありますか？ローカル制御をソース管理に保存するリスクがありませんか？
おそらくこれに対する良い答えはありません。このデータはいつか災害復旧の目的で必要になるため、安全な場所に保管する必要があるようです。これは、環境変数を設定するプロパティファイルとスクリプトにも同様に適用されます。
- このデータには本番データベースのパスワードなどが含まれるため、ソースコード（SVN/GITなど）を使用するのは非常に悪い考えです。
- 企業の夜間バックアップで十分な場合もありますが、すぐにアクセスできる変更履歴を保持することはほとんどありません。
- データは、使用するソフトウェアとは別にバージョン管理する必要があります。現在のシステムでは、構成を変更すると新しいアプリケーションがビルドされますが、これはまったく間違っています。
現在、この問題の解決策を検討しており、アクセスが制限されたコードリポジトリを利用しています。このリポジトリには、構成データのみが含まれます。他の人が共有する経験がありますか？
問題と考えられる解決策を検討する際に、方法を使用するのに役立ちます Jeff Atwoodによって人気が高くなります ：神が機密の構成情報を保存する方法を作成するとしたら、彼はそれをどのように実行しますか？
まあ、彼は誰が設定情報を必要としているかを知っていて、それをそれらの人々にだけ与えるでしょう、そしてその情報は他の誰からもアクセスされることが決してできなかったでしょう。
最初の部分はすでに処理されているはずです。ソース管理システムがユーザーを認証する必要があります。そして、このアプローチは、 トロイハントのソース管理の10の戒め 、「依存関係はソース管理にある必要がある」の＃10に従って有効性も与えられます。
しかし、もしそれが漏洩した場合、それを安全に保つには？まあ、プレーンテキストで保存する必要はありません。 暗号化を使用します。.NETでは、 設定ファイルの接続文字列データを暗号化するために実行できる手順があります 。選択した特定のテクノロジでこれを行うには、同等の方法を見つける必要があります。
多くの人々はソースコードと一緒に通常のファイルに設定を保存することを批判しますが、私の経験では、これは実際にはかなり良い解決策です：
- どの言語でも簡単に実装できます。多くの場合、複雑な構成ファイルのサポートをすぐに利用できます。例えば。 Javaの場合、ツリーのような構造を表現できるYAMLサポートが得られます。さまざまな環境用の個別の構成ファイルと、環境固有のファイルは継承できます。
- ソフトウェアを実行するには構成が必要です。コードを変更すると、多くの場合、構成設定を追加/変更する必要があるため、構成とコードを一緒にしておくのが自然です。
- ソースを使用して構成を保存すると、誰がどの設定をいつ変更したかを知り、定期的なコードレビューで構成を確認できるなど、ソース管理のすべての利点が得られます。
- あなたがCIAで働いていない限り、セキュリティの議論は私には誇張されているようです。したがって、データベースのパスワードは、アプリが実行されているマシンのファイルに保存されます。まあ、誰かがあなたのアプリでマシンにアクセスできるようになれば、あなたはおそらくすでに多くの問題に直面しています-彼らは例えばアプリを削除し、同じポートの代わりに独自のアプリを起動します。このようなシナリオでは、DBパスワードにアクセスできることはそれほど大きな問題ではない可能性があります。すべての接続が完全に暗号化されておらず、マシンにアクセスできる場合を除いて、ネットワークインターフェイスから興味深いデータの多くを傍受できます。
- Hiera などのツールを使用すると、テキストの構成ファイルを作成できますが、その中にパスワードやその他の機密データを保存することはできません。
そのため、多くの場合、コードとともにソース管理に格納されているテキスト構成が適切な出発点です。
分散システムを使用している場合、またはアプリケーションを再デプロイせずに構成をホットスワップできるようにしたい場合は、構成サーバーを中心にしたソリューションが見つかるかもしれません。 Spring Cloudには このようなメカニズムのサポート があり、バックエンドのサービス構成はgitリポジトリまたは Eureka にすることができます。また、たとえば、 Zookeeper 。これらのアプローチのいずれかを使用すると、ソフトウェアを再構築して再展開する必要なく、多くのサーバーで一貫した構成を管理して構成を更新することが容易になります。もちろん、これにはコストがかかります。これには、構成サーバーと、それをアプリケーションから使用する方法と、デプロイおよび保守する別のシステムが含まれます。
私は私が働いているのと同じ問題と闘っています。現在、すべての構成はファイルベースであり、それらを使用する個々のアプリケーションでソース管理されています。これは複製につながり、開発者は開発だけでなく本番/ QAパスワードにアクセスできます。
そうは言っても、これからは良い解決策を考え出したと思います。設定ファイルを別のgitリポジトリ（config repoというラベル）に移動しています。次に、渡されたプロファイルに基づいて構成リポジトリからファイルを提供するだけのspring-cloud-config（Java）サーバーを設定します。これは、Javaアプリケーションに最適です。PHP/ Java以外のアプリの場合、ファイルを直接プルダウンします（理想的ではありません）。 PHPアプリケーションが独自に設定をダウンロードしてどこかにキャッシュできるようにする何かを書くかもしれませんが、最初の実行では優先度は高くありません。この解決策は設定- 12要素のアプリの推奨事項に明示的に違反しないサービスとして。
私はzookeeperも同じように使用できると思います（kubernetes + zookeeperを使用した設定を見ました）ので、その答えが上記の-1になった理由はよくわかりません。
リンク：
構成全体を1つのファイルに保存する代わりに、複数のファイルに保存します。
- 構成ディレクトリを用意します。
README*以外のすべてのファイルは、構成ファイルとして解釈されます。 - すべてのファイル名はアルファベット順にソートされ、ファイルはその順序でロードされます。これが、このような場合のファイルが1桁か2桁で始まることが多い理由です：
01-logging.json。02-database.jsonなど. - すべてのファイルからのデータは、アプリケーションで利用可能なsame構成構造にロードされます。これは、いくつかのファイルが互いの設定を補完し、予測可能な方法でそれらを上書きする方法です。
- VCSには、見やすい値またはデフォルト値の設定ファイルのみを保存します。デプロイ時にシークレットを含む構成ファイルを追加するか、認証済みのシークレットストレージサービスを使用することをお勧めします。
最寄りのLinuxボックスで、/etc/sudoers.dまたは/etc/nginx/conf.dをご覧ください。同じパターンを示しています。
秘密の管理は別の獣です。あなたは小さい間、あなたはそれらを手動のステップとして管理することができます。 Zookeeperなどを使用できます。 シークレットをVCSにチェックインする暗号化された形式 で、展開手順としてそれらを復号化することもできます。他にもいくつかのオプションがあります。
（また、意見の一部：コメントを許可しないため、JSONは良い構成ファイル形式ではありません。コメントは非常に重要です。TOML、YAML、さらにはINI形式のほうが実用的です。 ）
あなたのオプションはあなたが展開しているOSによってある程度定義されていると思います
はい、値をソース管理に入れます。ただし、「dev」バージョンのみ。ソースコードをコンパイルして動作させたい！余分な秘密の手順を含まない
ビルドとデプロイのプロセスでは、デプロイメント中にこれらの値を環境ごとに交換する必要があります。 （タコはこの種のモデルを持っています）
Apache zookeeperは、分散システムのアプリケーション構成を保存するための素晴らしいオプションを提供します。飼育係で行われた変更は、アプリケーション側に学芸員または飼育係のリスナーを置くことで、キャプチャおよび処理できます。