Розподілене управління даними: як це правильно зробити?

💡 Усі статті, обговорення, новини про DevOps — в одному місці. Приєднуйтесь до DevOps спільноти!

Виникло складне запитання. Я поки не дуже розумію навіть в яку сторону рухатись. Спробую сформулювати.

Є деяка складна структура даних: вкладені словники. Причому повна структура наперед не відома і постійно змінюється. Тобто, повну структуру можна уявити як деяке дерево. (уявіть собі довільний yaml чи json файл)

Зміни в структурі самого дерева (тобто додає гілки) робить одна команда. Але значення в вузлах цього дерева треба змінювати стороннім командам. Тобто треба якось надати доступ для змін зі сторонньою аутентифікацією. і можливість обрати для кожної групи користувачів — що саме можливо міняти (які саме змінні або цілі гілки дерева), а що — ні. Важливо, щоб можна було змінити, але не видалити. І кожна команда могла бачити тільки те, що їй дозволено міняти, а не всю структуру.

Бажано, після кожної зміни робити якийсь log чи diff щоб зміни можливо було відслідкувати (хто, що). також бажано після кожної зміни викликати якусь дію — наприклад, скрипт (відправити листа, запустити пайплайн, тощо)

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

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

такое чувство что ты описал файловую систему ос

Теоретично може підійти HashiCorp Vault. Колись пробували як сторедж для різних проектних даних. DevOps-и задавали загальну структуру, а розробники і менеджери — працювали в тих рамках з потрібними даними, і навіть могли створювати «підпроекти».
Там можна задавати дерево і значення через JSON, та розділяти права доступу різними способами. Також підтримується версіонування.
Деталей вже не пам’ятаю, але нагадувало щось схоже.

Не претендую на єдине правильне рішення, але для задач з ієрархічними даними (дерево / вкладені JSON/YAML) у нас добре зайшов підхід з правами у вигляді «шляхів доступу».

Типу:

Project/INTERNAL=V,A,M
Project/INTERNAL/Task/17=V
Catalog/Volvo/FH17/Electrical/Part123=V

Де:

  • шлях описує гілку дерева
  • V, A, M — це права (View / Approve / Manage)
  • права на батьківський вузол автоматично поширюються на дочірні

Такі ACL можна:

  • або зберігати у вашій БД
  • або прокидати в токен як custom claim (Entra ID / Auth0 / Okta)

Тоді бекенд просто перевіряє: «Чи має користувач право A на Project/INTERNAL?» без складної логіки й зайвих запитів.

Питання більше не в правах доступу, скільки в тому чи є готовий продукт менеджети це, бо писати свій велосипед ресурсів не дуже є...

Народ пише, що проблема, по суті, ідентична створенню інтернет-маркетплейса (Розетка):
* Організатори маркетплейса створюють дерево можливих продуктів в продажу.
* Кожен продавець розставляє свої товари по нодах дерева.

Ну, цілий маркетплейс мені не потрібен ;)

Я міркував в сторону LDAP — але все воно заточене під авторизацію (через нього), нормальних веб-інтерфейсів для редагування структури немає, як і імпорту в yaml.

Поки виглядає так, що простіше зберігати yaml в git і перевіряти PR перед merge ... але «з того боку» не всі здатні працювати з yaml...

Підписатись на коментарі