アプリケーション構成を保存する好ましい方法は何ですか？

ほとんどの場合、次のように、プロジェクトのルートディレクトリに開発アプリケーションの構成を保存します。

app
|-- config.json

しかし、この設定はバージョン管理システムに保存され、ユーザー名、パスワード、その他の機密情報が漏洩する可能性があるため、これは最善のアプローチではないようです。

12ファクターアプリガイドでは、構成ファイルをすべて削除し、構成セットアップに環境変数を使用することをお勧めします。

...環境変数に設定を保存します。Env変数は、コードを変更せずにデプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコードリポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルやJavaシステムプロパティなどの他の構成メカニズムとは異なり、これらは言語およびOSに依存しない標準です。

それは本当にいいように思えますが、ソース変数にチェックインせずに、前述の環境変数をどこに保存しますか？そして、これらの変数をアプリに渡すためにどのツールを使用できますか？多数の設定オプションが存在する可能性があり、アプリを起動するたびに手動で入力するのは好ましくありません。したがって、それらはどこかの種類のファイルに保存する必要があります。したがって、このファイルはソース管理になり、元の場所に戻ります。

構成オプションを処理する一般的に受け入れられている方法はありますか。ソース管理にローカル構成を保存するリスクはありませんか？

おそらくこれに対する良い答えはありません。いつか災害復旧の目的で必要になるため、このデータを安全な場所に保存する必要があるようです。これは、環境変数を設定するプロパティファイルとスクリプトに等しく適用されます。

• （SVN / GITなどで）ソースコードを使用することは、このデータに本番データベースのパスワードなどが含まれるため、本当に悪い考えです。
• 企業の夜間バックアップで十分な場合もありますが、すぐにアクセスできる変更履歴を保持することはほとんどありません。
• データは、消費ソフトウェアとは別にバージョン管理する必要があります。現在のシステムでは、構成を変更すると新しいアプリケーションがビルドされますが、これは明らかに間違っています。

現在、この問題の解決策を検討しており、アクセスが制限されたコードリポジトリに傾倒しています。このリポジトリには、構成データのみが含まれます。他の人と共有する経験はありますか？

問題と考えられる解決策を調べる際に、Jeff Atwoodが普及させた方法を使用すると役立ちます。

まあ、彼はだれが構成情報を必要とするかを知っており、それらの人々にそれを与えるだけであり、その情報は他の誰によっても決してアクセスされることができないでしょう。

最初の部分はすでに処理されている必要があります。ソース管理システムはユーザーを認証する必要があります。また、このアプローチには、トロイハントの「ソース管理の10の戒め」の＃10に従って有効性が与えられています。

しかし、それが漏洩した場合にそれを安全に保つ方法は？まあ、そこにプレーンテキストで保存する必要はありません！暗号化を使用します。.NETには、構成ファイルの接続文字列データを暗号化するために実行できる手順があります。選択した特定のテクノロジーでこれを行うには、同等の方法を見つける必要があります。

多くの人々はあなたのソースコードと一緒に通常のファイルに設定を保存することを批判していますが、私の経験では、これは実際にはかなり良い解決策です：

• どの言語でも簡単に実装できます。多くの場合、複雑な設定ファイルをすぐに使用できます。たとえば、Spring Bootを使用したJavaの場合、ツリーのような構造を表現できるYAMLサポートが得られます。また、さまざまな環境用の個別の構成ファイルと、環境固有のファイルが継承できるベースライン構成を簡単に作成できます。
• ソフトウェアを実行するには構成が必要であり、コードを変更するには構成設定を追加/変更する必要があることが多いため、構成とコードを一緒に保持するのが自然です。
• ソースを使用して構成を保存すると、通常のコードレビュー中に誰がどの設定をいつ変更したか、いつ構成を確認できるかなど、ソース管理のすべての利点が得られます。
• あなたがCIAで働いていない限り、セキュリティの議論は私には誇張されているようです。したがって、データベースのパスワードは、アプリを実行するマシン上のファイルに保存されます。誰かがあなたのアプリでマシンにアクセスできるようになったら、おそらくあなたはすでに多くの問題に直面しているでしょう-例えば、彼らはあなたのアプリを削除し、同じポートの代わりに自分のアプリを起動できます。このようなシナリオでは、DBパスワードにアクセスできることはそれほど大きな問題ではないかもしれません。すべての接続が完全に暗号化され、マシンにアクセスできない限り、ネットワークインターフェイスからの興味深いデータの多くをとにかく盗聴できます。
• Hieraなどのツールを使用して、テキスト形式の構成ファイルを作成できますが、パスワードやその他の機密データを内部に保存することはできません。

そのため、多くの場合、ソース管理にコードと一緒に保存されたテキスト設定が良い出発点です。

分散システムを使用している場合、またはアプリケーションを再デプロイせずに構成をホットスワップできるようにしたい場合は、構成サーバーに基づいたソリューションの方が適している場合があります。Spring Cloudはこのようなメカニズムをサポートしており、バックエンドサービスの構成はgitリポジトリまたはEurekaにできます。Zookeeperなどを使用して、独自のロールを実行することもできます。これらのアプローチはいずれも、ソフトウェアを再構築および再展開することなく、多くのサーバーで一貫した構成を管理して構成を更新することを容易にします。これには当然コストがかかります。設定サーバーと、それをアプリケーションから使用する方法と、デプロイおよび保守するためのさらに別のシステムを学習することです。

私が働いているのと同じ問題に取り組んでいます。現在、すべての構成はファイルベースであり、それらを使用する個々のアプリケーションでソース管理されています。これにより、重複が発生し、開発者は開発だけでなく本番/ QAパスワードにアクセスできます。

そうは言っても、私たちは今後良い解決策を考え出したと思います。構成ファイルを別のgitリポジトリ（構成リポジトリというラベル）に移動しています。次に、渡されたプロファイルに基づいて構成リポジトリからファイルを提供するspring-cloud-config（java）サーバーをセットアップします。これは、クライアントを使用して起動時にダウンロードできるJavaアプリケーションに最適です。PHP / non-javaアプリの場合、ファイルを直接プルダウンします。（理想的ではない）。将来的には、PHPアプリケーションが独自に設定をダウンロードし、どこかにキャッシュできるようにするものを書くかもしれませんが、最初の実行の優先度は高くありません。このソリューションは、12要素アプリの推奨事項に明示的に違反していないconfig-as-a-serviceと考えています。

zookeeperは同じこと（kubernetes + zookeeperでセットアップを見た）に使用できると思うので、その答えが上記の-1になった理由はよくわかりません。

リンク：

https://spring.io/guides/gs/centralized-configuration/

https://cloud.spring.io/spring-cloud-config/

構成全体を1つのファイルに保存する代わりに、複数のファイルに保存します。

• 構成ディレクトリがあります。多分を除いて、そこにあるすべてのファイルは設定ファイルとして解釈されますREADME*。
• すべてのファイル名はアルファベット順にソートされ、ファイルはその順序でロードされます。そのため、このような場合にファイルが1桁または2桁で始まることがよくあります01-logging.json。02-database.jsonなど
• すべてのファイルのデータは、アプリケーションで使用可能な同じ構成構造にロードされます。これは、いくつかのファイルがお互いの設定を補完し、予測可能な方法でそれらを上書きする方法です。
• VCSに、安全に見える値またはデフォルト値を持つ設定ファイルのみを保存します。展開中にシークレットを含む構成ファイルを追加するか、認証済みのシークレットストレージサービスを使用することをお勧めします。

最寄りのLinuxボックスで、/etc/sudoers.dまたはをご覧ください/etc/nginx/conf.d。同じパターンを示しています。

秘密管理は別の獣です。小さいうちに手動で管理できます。Zookeeperなどを使用できます。暗号化された形式でVCS にシークレットをチェックインし、展開ステップとして解読することもできます。他にも多くのオプションがあります。

（また、意見の断片：JSONはコメントを許可しないため、良い構成ファイル形式ではありません。コメントは重要です。TOML、YAML、さらにはINI形式でさえ実用的です。）

オプションは、展開先のOSによってある程度定義されていると思います

はい、値をソース管理に入れます。ただし、「dev」バージョンのみ。ソースコードをコンパイルして動作させたい！余分な秘密の手順を含めない

ビルドおよびデプロイプロセスは、デプロイメント中に環境ごとにこれらの値を交換する必要があります。（タコにはこの種のモデルがあります）

Apache zookeeperは、分散システムのアプリケーション構成を保存するための素晴らしいオプションを提供します。zookeeperで行われた変更は、アプリケーションの最後にキュレーターまたはzookeeperリスナーを配置することでキャプチャおよび処理できます。