Лучшие практики для обработки большого количества структурированных файлов конфигурации / свойств

Представьте себе систему с большим количеством серверов. Каждый из них имеет ряд настроек:

• Некоторые специфичные для сервера
• Некоторые специфические для региона
• Некоторые общие для всех них
• Может быть, вы можете иметь несколько пользовательских групп, как эта группа серверов только для чтения
• и т.п.

Текущая практика, которую я имею в виду, - это простая структура свойств с преобладающими способностями.

Для примера рассмотрим серверы Google. У каждого из них есть список настроек для загрузки.

Например, лондонский сервер может иметь:

rootsettings.properties, europesettings.properties, londonsettings.properties, searchengine.propertiesИ т.д.

Где каждый файл содержит набор свойств и последовательность загрузки позволяет вам переопределять свойства, тем дальше вы идете.

Например: rootsettings.propertiesможет иметь accessible=falseпо умолчанию, но переопределяется searchengine.propertiesсaccessible=true

Проблема, которую я имею с этой структурой, состоит в том, что очень легко выйти из-под контроля. Он вообще не структурирован, то есть вы можете определить любое свойство на любом уровне, и многие элементы могут устареть.

Кроме того, изменение среднего уровня становится невозможным по мере роста сети, поскольку теперь вы затрагиваете очень большое количество серверов.

И последнее, но не менее важное: для каждого отдельного экземпляра может потребоваться 1 специальное свойство. Это означает, что ваше дерево в любом случае заканчивается конфигурацией для каждого сервера, что делает его не очень оптимальным решением.

Буду очень признателен, если у вас есть предложения / идеи по улучшению архитектуры управления конфигурациями.

Я думаю, что вам нужно сначала задать себе несколько вопросов и уточнить некоторые моменты, затем вы сможете лучше решить, как решить вашу проблему.

Первый: кто должен контролировать серверы?

• Это один администратор, который будет управлять сотнями серверов? Тогда вам нужно максимально централизовать конфигурацию.

• Или каждый сервер потенциально находится под контролем отдельного администратора, который не хочет, чтобы его настройки отменялись или управлялись централизованной конфигурацией? Тогда вам следует сосредоточиться на децентрализованной конфигурации. Если у каждого администратора есть несколько серверов для управления максимально, это все еще можно сделать вручную.

Второе: вам действительно нужны тонны опций конфигурации, или вы можете сократить число до нескольких? Вместо того, чтобы все и все настраивать «на всякий случай», лучше ограничьте себя теми параметрами, которые, как вы знаете, действительно нужны вашей системе. Это может быть сделано, например,

• сделать ваше программное обеспечение немного умнее (например, что программа может определить автоматически, запрашивая окружение)?

• строго придерживаться «соглашения о конфигурации» - например, путем установления определенных соглашений об именах или получения некоторых параметров по умолчанию из других параметров

Третье: вы действительно хотите иерархический уровень конфигурации, жестко запрограммированный в программном обеспечении? Представьте, что вы заранее не знаете, сколько будет серверов, если древовидная иерархия действительно является для них лучшей структурой или сколько уровней должно иметь дерево. Самое простое решение, о котором я могу подумать, - это вообще не предоставлять никакой централизованной конфигурации, только один файл конфигурации на сервер, и позволить ответственным администраторам сервера самим решать, как они решают проблему управления конфигурациями нескольких серверов.

Например, администраторы могут написать сценарии генератора, которые распространяют центральный файл конфигурации на группу разных серверов и вносят незначительные изменения в каждую копию. Таким образом, вам не нужно заранее делать какие-либо предположения о «топологии распространения серверов», ее можно в любой момент настроить в соответствии с требованиями реального мира. Недостаток в том, что вам нужны администраторы, обладающие некоторыми знаниями о том, как писать скрипты на таких языках, как Perl, Python, Bash или Powershell.

Мне лично никогда не нравилось наследование конфигурационных файлов. Вы упомянули наличие последовательности загрузки, но не знаете, как она определена или получена. Может быть, это поможет сделать последовательность очевидной, отразив ее в структуре каталогов, в которую вы помещаете файлы, или включив ее в имена файлов.

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

Это будет несколько работать до того момента, когда у вас будет совокупность значений конфигурации, которые не соответствуют региону. Таким образом, вы должны учитывать организационную ось, которую вы выбираете.

Что мне больше нравится, так это выделение агрегатов значений конфигурации в их собственные файлы и наличие (конечного) файла конфигурации, указывающего на один.

Пример:

bigcity.searchsettings.properties
regional.searchsettings.properties

Внутри londonsettings.propertiesвы можете иметь значение как:

searchsettings:bigcity.searchsettings.properties

Это допускает больше степеней свободы или дополнительную.

У меня была та же проблема и открытое исходное решение. Вы можете найти исходный код здесь https://github.com/Bikeman868/Urchin

Я использую его для большой системы с большим количеством серверов, несколькими приложениями на каждом сервере и несколькими средами. Он включает в себя пользовательский интерфейс, написанный на Dart для управления конфигурацией.

Вы можете связаться со мной напрямую, если вам нужна помощь, чтобы подняться с земли.

Решение, которое я реализовал, основано на правилах. Обычно вы начинаете с одного правила, которое применяется ко всем конфигурациям, затем добавляете, что вы можете добавить правила, такие как «все машины в этой среде создают файлы журналов по этому пути UNC». Правила могут быть специфическими для среды, приложения, машины или экземпляра приложения. Правила также могут быть более конкретными, как только в этом конкретном экземпляре этого приложения, работающего на этом конкретном сервере.

Правила применяются в порядке от наименее специфического к наиболее конкретному, и более поздние правила могут переопределять значения, указанные в более ранних правилах. Это означает, например, что вы можете создать правило, которое применяется к конкретному приложению, а затем переопределить его другим значением для определенного компьютера или конкретного экземпляра приложения и т. Д.

Сервер имеет интерфейс REST + JSON, поэтому работает с большинством систем разработки, а также имеет удобную клиентскую библиотеку для приложений .Net.

Подобные настройки - это кошмар для управления. Лучше всего попытаться уменьшить их настолько, насколько это возможно, используя ваши программные компоненты для обработки всех случаев.

т. е. вместо того, чтобы настроить сервер API для региона, передайте регион вызовом API и позвольте настройке одного сервера обрабатывать все регионы.

Однако, если вы находитесь в том состоянии, в котором находитесь. Я бы не советовал настраивать систему для генерации параметров конфигурации. Это только добавляет сложности к и без того сложной проблеме.

Вместо этого сохраните настройки в инструменте развертывания для каждого типа сервера. (параметры развертывания осьминога, перезапись файлов teamcity и т. д.) Это позволяет вам быть уверенным, что вы развертываете те же параметры конфигурации, которые вы использовали в прошлый раз при обновлении программного обеспечения, и дает вам точный контроль над изменениями.

Вы не хотите оказаться в ситуации, когда вы вносите изменения в файлы мета-конфигурации, а затем должны проверить, какой файл конфигурации создается в ваших различных регионах / серверах / пользовательских группах

Нет исследований; все личное мнение, 30+ IT опыт. Похоже на сложную структуру данных, которая может быстро меняться / изменяться, с большим количеством пользователей.

Рассмотрим хранилище базы данных (например, .SQL) для структурирования данных с пользовательскими процессами извлечения, которые создают индивидуальные файлы конфигурации для каждого пользователя. Вы можете использовать запрос к базе данных, чтобы определить влияние изменения до его реализации; найти повторяющиеся вхождения и т. д. Отдельные плоские файлы являются частью проблемы. Кроме того, вы можете получить журналы изменений и поддержку восстановления / восстановления. С помощью управления базой данных вы можете устранить проблему наследования конфигурации. Решение такого типа потребует дополнительной структуры базы данных. Правильная составная структура ключей очень важна.

Это мое предложение.

Вы могли бы взглянуть на некоторые очень дорогие системы безопасности и контроля поставщиков, которые реализуют этот тип услуг. Считай их. В целом они будут зависеть от окружающей среды.