Наследование конфигураций

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. наблюдаемостью происхождения итоговых значений.

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