Найкращі практики для обробки великої кількості структурованих файлів конфігурації / властивості

Уявіть систему, яка має велику кількість серверів. Кожен з них має ряд налаштувань:

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

Сучасна практика, яку я маю на увазі, - це проста структура властивості, яка має переважні здібності.

Давайте візьмемо сервери 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+ досвід ІТ. Звучить як складна структура даних, яка може швидко змінюватися / змінюватися з великою кількістю користувачів.

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

Це моя пропозиція.

Ви можете заглянути в дуже дорогі системи безпеки та управління постачальниками, які реалізують цей тип послуг. Розглянь їх. Загалом вони будуть залежати від навколишнього середовища.