多数の構造化構成/プロパティファイルを処理するためのベストプラクティス

多数のサーバーがあるシステムを想像してください。それぞれに多くの設定があります：

• サーバーに固有のもの
• 地域固有のいくつか
• それらすべてに共通するもの
• このグループのサーバーは読み取り専用であるように、カスタムグループを作成できます
• 等

私が念頭に置いている現在のプラクティスは、オーバーライド機能を持つ単純なプロパティ構造です。

例の目的でGoogleサーバーを使用してみましょう。それぞれにロードする設定のリストがあります。

たとえば、ロンドンのサーバーには次のものがあります。

rootsettings.properties、europesettings.properties、londonsettings.properties、searchengine.properties、など

各ファイルに一連のプロパティが含まれており、読み込みシーケンスを使用するとプロパティをオーバーライドできます。

たとえば、次のようにrootsettings.properties持っていることがありaccessible=false、デフォルトとして、しかしでオーバーライドされるsearchengine.propertiesとaccessible=true

私がこの構造で抱えている問題は、制御不能になるのが非常に簡単なことです。構造化されていないため、任意のレベルで任意のプロパティを定義でき、多くのアイテムが廃止される可能性があります。

さらに、ネットワークの成長に伴い、非常に多くのサーバーに影響を与えるため、中間レベルの変更は不可能になります。

最後に重要なことですが、個々のインスタンスにはそれぞれ1つの特別なプロパティが必要になる場合があります。つまり、ツリーは最終的に各サーバーの構成になり、最適なソリューションではなくなります。

より良い構成管理アーキテクチャの提案/アイデアがあれば、私は大歓迎です。

最初にいくつか質問をして、いくつかのポイントを明確にする必要があると思うので、問題を解決する方法をより適切に決定できます。

最初：サーバーを制御できるのは誰ですか？

• 数百台のサーバーを制御するのは単一の管理者ですか？次に、構成をできるだけ集中化する必要があります。

• または、各サーバーが個々の管理者の制御下にある可能性はありますか？次に、分散構成に焦点を当てる必要があります。各管理者が最大で管理する少数のサーバーを持っている場合、これは手動で管理できます。

第二に、本当にたくさんの設定オプションが必要ですか、それとも数を少なくすることができますか？「万が一に備えて」すべてを構成可能にするのではなく、システムが本当に必要とすることがわかっているオプションに自分自身を制限します。これは、たとえば次のようにして実行できます。

• ソフトウェアを少し賢くする（たとえば、環境に問い合わせることでプログラムが自動的に決定できるもの）。

• 「設定より規約」に厳密に従う-たとえば、特定の命名規則を確立するか、他のオプションからデフォルトとしていくつかのオプションを導出する

第三に、ソフトウェアにハードコーディングされた構成の階層レベルが本当に必要ですか？ツリーのような階層が実際にそれらに最適な構造である場合、またはツリーに必要なレベルの数がいくつあるかを事前に知らないことを想像してください。私が考えることができる最も簡単な解決策は、集中化された構成をまったく提供せず、サーバーごとに1つの構成ファイルのみを提供し、責任あるサーバー管理者が複数のサーバーの構成を管理する問題を解決する方法を自分で決定できるようにすることです。

たとえば、管理者は、中央の構成ファイルを異なるサーバーのグループに配布し、各コピーに若干の変更を加えるジェネレータースクリプトを作成できます。そうすれば、事前に「サーバー分散トポロジ」について仮定する必要はありません。トポロジはいつでも現実の要件に合わせて調整できます。欠点は、Perl、Python、Bash、Powershellなどの言語でスクリプトを記述する方法についてある程度の知識を持つ管理者が必要なことです。

私は個人的に設定ファイルの継承が好きではありませんでした。ロードシーケンスがあることに言及しますが、それがどのように定義または派生されているかはわかりません。ファイルを配置したディレクトリ構造にミラーリングするか、ファイル名に含めることで、シーケンスを明確にするのに役立つかもしれません。

rootsettings.properties
rootsettings.eurosettings.properties
rootsettings.eurosettings.londonsettings.properties

これは、リージョンに整合しない構成値の集合がある時点まである程度機能します。そのため、選択する組織軸に配慮する必要があります。

私がもっと気に入っているのは、構成値の集合を独自のファイルに分離し、（リーフ）構成ファイルが1つを指していることです。

例：

bigcity.searchsettings.properties
regional.searchsettings.properties

内部にはlondonsettings.properties次のような値があります。

searchsettings:bigcity.searchsettings.properties

これにより、より多くの自由度または追加の自由度が可能になります。

私は同じ問題を抱えており、ソリューションをオープンソース化しました。ソースコードはhttps://github.com/Bikeman868/Urchinにあります

多数のサーバー、各サーバーに複数のアプリケーション、および複数の環境がある大規模システムに使用します。構成を管理するためのDartで書かれたUIが含まれています。

地面から降りるのに助けが必要な場合は直接私に連絡することができます。

私が実装したソリューションはルールベースです。通常、すべての構成に適用される1つのルールから始めて、「この環境内のすべてのマシンがこのUNCパスにログファイルを作成する」などのルールを追加できます。ルールは、環境、アプリケーション、マシン、またはアプリケーションのインスタンスに固有のものにすることができます。この特定のサーバーで実行されているこのアプリケーションのこの特定のインスタンスのみのように、ルールをより具体的にすることもできます。

ルールは、最も具体的なものから最も具体的なものの順に適用され、後のルールは前のルールで指定された値を上書きできます。これは、たとえば、特定のアプリケーションに適用するルールを作成し、特定のマシンまたはアプリケーションの特定のインスタンスなどの異なる値でそれをオーバーライドできることを意味します。

サーバーにはREST + JSONインターフェースがあり、ほとんどの開発システムで動作します。また、.Netアプリケーション用の便利なクライアントライブラリもあります。

これらの種類の設定は、管理するのが悪夢です。ソフトウェアコンポーネントがすべてのケースを処理できるようにして、できる限りそれらを削減することをお勧めします。

すなわち、地域に対してAPIサーバーを設定する代わりに、API呼び出しで地域を渡し、すべての地域を単一のサーバー設定で処理できるようにします。

ただし、現在の状態にあることを考えると、構成設定を生成するためのシステムを設定することはお勧めしません。すでに複雑な問題に複雑さを追加するだけです。

代わりに、サーバーの種類ごとに展開ツールに設定を保存してください。（タコの展開設定、teamcityファイルの書き換えなど）これにより、ソフトウェアをアップグレードするときに前回行ったのと同じ構成設定を確実に展開し、変更をきめ細かく制御できます。

メタ構成ファイルに変更を加えた後、さまざまな地域/サーバー/カスタムグループで生成される構成ファイルをテストする必要がある状況になりたくない

調査なし。すべて個人的な意見、30年以上のIT経験。複雑なデータ構造のように聞こえますが、多数のユーザーがいるとすぐに変更/修正できます。

データベースリポジトリ（SQLなど）を考慮して、データを構造化し、ユーザーごとに個別の構成ファイルを生成するカスタム抽出プロセスを使用します。データベースのクエリを使用して、変更が実装される前に変更の影響を判断できます。重複するオカレンスなどを見つけます。個々のフラットファイルは問題の一部です。さらに、変更ログと回復/再構築のサポートを取得できます。データベース制御を使用すると、構成の継承の問題を解消できる場合があります。このタイプのソリューションには、追加のデータベース構造が必要になります。正しい複合キー構造は非常に重要です。

それが私の提案です。

このタイプのサービスを実装する非常に高価なベンダーシステムのセキュリティおよび制御システムを検討する場合があります。それらを考慮してください。一般に、それらは環境に依存します。