Наслідування конфігурацій

1) Навіщо потрібно успадкування конфігурацій

• Перевикористати загальні значення (логування, ретраї, таймаути).
• Ділити відповідальність: платформа задає базові політики, команди сервісів - тільки відхилення.
• Уникнути дублювання і знизити ризик розсинхронізації.
• Прискорити релізи: зміни за замовчуванням транслюються вниз по дереву.
• Підтримувати мульти-оточення і мульти-тенантність єдиним підходом.

2) Моделі успадкування

2. 1 Ієрархічна (батько → дитина)

База (global) → оточення (prod/stage/dev) → регіон/кластер → сервіс → інстанс.
Проста і прозора, але може призвести до «глибоких ланцюжків» і складних налагоджень.

2. 2 Шарувата (base/overlays)

Базовий шар + набір оверлеїв (feature-x, region-eu, security-hardening).
Добре поєднується з GitOps і Kustomize; оверлеї незалежні і композиційні.

2. 3 Композиційна (модулі/пакети)

Конфігурація збирається з модулів: `logging@v2`, `metrics@v1`, `http@v3`.
Управління версіями модулів, семантична сумісність, явні залежності.

2. 4 Політика поверх значень (Policy-as-Code)

Базові «обмежувачі» та інваріанти (OPA/Rego, Kyverno, Conftest).
Успадковуються не самі значення, а правила їх допустимості.

3) Алгоритми злиття і пріоритети

1. Порядок джерел: зліва направо (base ← env ← region ← service ← instance).

• Скаляр: «останній переміг» (last-write-wins).
• Об'єкт: рекурсивний мердж по ключах.

• `append`/`prepend`
• 'uniqueBy (key)'( множина за ключем)
• 'patch'( пошук елемента по'name'і частковий мердж).
• 3. Зарезервовані ключі (наприклад,'_ merge: replace` / `_merge: deep'на рівні вузла).

• Прапори запуску/ENV-змінні> секрети рантайму> файли на диску> значення за замовчуванням в коді.

Приклад YAML-мерджа

yaml base. yaml http:
port: 8080 timeouts:
read: 2s write: 2s features:
- name: audit enabled: false

prod. yaml http:
timeouts:
read: 1s features:
- name: audit enabled: true
- name: billing enabled: true

Result (under policy: object = deep merge, array = uniqueBy (name) + patch)
http:
port: 8080 timeouts:
read: 1s write: 2s features:
- name: audit enabled: true
- name: billing enabled: true

4) Схеми і валідація

Наявність схеми - обов'язкова умова безпечного успадкування.

JSON Schema/OpenAPI: типи, обов'язкові поля, enum, патерни, обмеження ('minimum','format','patternProperties').
Версіонування схем (semver): major - ламаючі, minor - нові поля, patch - фікси.
Pre-merge і Post-merge перевірки: валідувати і фрагменти, і результат.
Дефолти: задавати на рівні схеми (draft-07 + підтримує'default').

5) Оточення і матриця розгортань

• env: dev, test, stage, prod region: eu-central-1, us-east-1 tier: batch, realtime, internal tenant: A/B/C (white-label, B2B)
• Комбінації формують дерево оверлеїв; уникайте надлишкової глибини (3-4 рівня достатньо).

6) Мульти-тенантність

• Жорсткий поділ: окремі файли/папки на тенанта.
• Параметризація: один шаблон + values per tenant.
• Успадковані політики: ліміти ресурсів/квоти, SLO, ретеншн логів.
• Важливо: межі безпеки (секрети/ключі) не повинні витікати між тенантами.

7) Секрети та безпека

Не успадковуйте секрети в явному вигляді. Успадковуються посилання: `secretRef`, `vaultPath`.
KMS/Vault/SOPS: зберігати зашифровані значення в Git, ключі - поза.
Поділяйте відповідальність: платформа управляє шляхами і політиками, команда сервісу - тим, що дійсно потрібно.
Політики: заборона'plaintext'секретів при CI-перевірках.
Rotation: не «перезаписуйте вниз» - використовуйте alias/абстракції ('db/primary/password @ 2025-Q4').

Приклад з Vault-посиланням

yaml db:
host: postgres. service user: app passwordFrom:
vaultPath: "kv/prod/app-db"
key: "password" # secret is taken at the deploy stage, not stored in files

8) Версіонування та міграції

Версії модулів конфігурації: `logging@2. 3. 1`.
Changelog для схем: міграції за допомогою jsonnet/ytt/кастомних скриптів.
Двонаправні міграції (up/down) для безпечного відкату.
Довгі гілки: уникати дрейфу; регулярно ребейзити оверлеї на базу.

9) Інструменти та практики

9. 1 Kubernetes

Kustomize (overlays): натуральна модель успадкування через'bases '/' resources','patchesStrategicMerge '/' patchesJSON6902'.
Helm (values): ієрархія'values. yaml'+'--set'( але будьте обережні з перевизначеннями в CI).
Kyverno/OPA: політики як «страхувальні сітки».

yaml overlays/prod/kustomization. yaml resources:
-../../base patchesStrategicMerge:
- patch-resources. yaml commonLabels:
env: prod

9. 2 Terraform

Модулі +'variables. tf'як контракт.
'locals'для обчислюваних значень,'override'файлів немає - використовуйте шари каталогів і робочі простори ('workspaces').
Порядок джерел: значення за замовчуванням <tfvars-файли <'-var '/' -var-file'.

hcl module "svc" {
source = "./modules/svc"
replicas = var. env == "prod"? 4: 2 logging = local. logging_base
}

9. 3 Ansible

Чітка ієрархія змінних (за зростанням пріоритету): role defaults < inventory group_vars < host_vars < extra vars.
Для спадкування - структура'group _ vars/{ env }/{ region} .yml'.

9. 4 Jsonnet / ytt

Багата композиція, функції і «ключ-наміри» ('overlay. replace`, `overlay. merge`).

10) Контракти та межі відповідальності

Платформа (platform team): визначає схему, політики, базові значення, логіку мерджа.
Продуктові команди: тільки оверлеї в межах контракту.
SRE/Безпека: аудит, валідації, сигнатури, enforcement.

11) CI/CD и GitOps

1. Lint (формат, заборона невідомих ключів).

2. Validate (JSON Schema/OpenAPI).

3. Dry-run/Render (helm template/kustomize build).

4. Policy check (OPA/Kyverno/Conftest).

5. Diff проти цільового кластера (kubectl diff/ArgoCD diff).

6. Progressive delivery: канарні оверлеї з обмеженим трафіком.

7. Підпис артефактів (Cosign, SLSA-атестації).

12) Спостережуваність і налагодження

Трасування походження (provenance): хто і коли вніс поле, з якого шару прийшло остаточне значення.
Візуалізація мерджа: звіт «переможців» ключів.
Runtime-експорт активної конфігурації (endpoint '/config'з маскуванням секретів).
Алерти на дрейф: розбіжності між задекларованим і фактичним.

13) Анти-патерни

«Магія» без явних правил пріоритету.
Глибокі ланцюжки (> 4-5 шарів): підвищують когнітивне навантаження.
Секрети в успадкованих файлах.
Приховані перевизначення через'--set'в CI.
Відсутність схеми і тестів рендеринга.

14) Чек-лист впровадження

• Визначте модель (ієрархія/шари/композиція).
• Зафіксуйте порядок мерджа і стратегії за типами.
• Опублікуйте схему і версіонування.
• Розділіть секрети (тільки посилання/рефи).
• Додайте policy-checks і підписи артефактів.
• Увімкніть dry-run, диффи та візуалізацію походження.
• Забезпечте експорт активної конфігурації в рантаймі.
• Налаштуйте прогресивні релізи для конфіг-змін.

15) FAQ

Q: Як зрозуміти, що шар занадто глибокий?
A: Якщо для зміни параметра потрібно відкрити> 3 файлів і «прокрутити»> 2 рівня абстракції - перегляньте структуру.

Q: Що робити з конфліктуючими масивами?
A: Введіть явні стратегії: 'replace','append','uniqueBy (key)','patchBy (name)'- і зафіксуйте їх у документації.

Q: Чи можна успадковувати секрети?
A: Ні, ні. Успадковуються тільки посилання (URI/рефи) на секрет-сховища і політики доступу.

Q: Як тестувати спадкування?
A: Знімайте «зрізи» для ключових комбінацій оверлеїв і перевіряйте golden-файлами; ганяйте рендеринг в CI на кожен PR.

Додаток A: Міні-спека мерджа

`scalars`: last-write-wins

`objects`: deep-merge за ключами

• за замовчуванням «replace»

• `append`
• `uniqueBy(key)`
• 'patchBy (key)'з рекурсивним мерджем елементів

• `_merge: replace|deep`
• `_strategy. array: replace|append|uniqueBy(name)|patchBy(name)`

Додаток B: Приклади

B.1 Helm values (prod поверх base)

yaml values. base. yaml replicas: 2 resources:
requests:
cpu: "100m"
memory: "128Mi"
logging:
level: info

values. prod. yaml replicas: 4 logging:
level: warn

helm template svc chart/ -f values. base. yaml -f values. prod. yaml

Пріоритет останнього файлу -'values. prod. yaml`.

B.2 Kustomize overlays

yaml base/deployment. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 2

overlays/prod/patch. yaml apiVersion: apps/v1 kind: Deployment metadata:
name: app spec:
replicas: 4

B.3 Ansible vars

group_vars/prod. yml # values of prod host_vars/prod-eu-1. yml # clarifications for extra vars host in CLI have highest priority

Підсумки

1. чіткою моделлю і пріоритетами,

2. валідуючими схемами і самостійними оверлеями,

3. відмовою від успадкування секретів,

4. GitOps-пайплайном з dry-run, policy-checks і диффами,

5. спостережуваністю походження підсумкових значень.

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