DevOps FM: “От values-файлов к управлению вариантами конфигураций в ConfigHub: как…”

От values-файлов к управлению вариантами конфигураций в ConfigHub: как перестать рендерить вслепую

В этот понедельник поговорим о переходе от классического Helm-подхода с values.yaml к модели Configuration as Data, которая реализует себя в ConfigHub. Если вы всё ещё храните values.yaml для разных сред, при аварийных запросах запускаете helm template и парсите YAML – рекомендуем сменить подход. В ConfigHub реализуется модель «конфигурация как данные»: вместо того чтобы каждый раз генерировать YAML из шаблонов по запросу, вы создаёте готовый манифест один раз.

Как внедрить подход?
⏺Развертывание базового окружения (Infra Space)

1. Добавляем репозиторий Helm:


helm repo update

2. Разворачиваем базовое окружение для инфраструктуры:

cub space create infra

3. Устанавливаем Helm-чарт через ConfigHub:


cub helm install --space infra \
  --use-placeholder=false \
  --namespace monitoring \
  prometheus prometheus-community/kube-prometheus-stack \
  --version 79.6.1

• ConfigHub использует движок Helm для однократного рендеринга чарта.
• Результат сохраняется как материализованный, версионируемый и индексируемый артефакт (Config Unit).

⏺Создание пространств для окружений (Spaces)
1. Создаем пространства для каждого целевого окружения:

cub space create dev
cub space create prod

2. В качестве альтернативы – создаем пространства через UI ConfigHub, используем кнопку [Add] на странице списка Spaces.
3. Каждое пространство будет содержать копии базовых конфигураций для конкретного окружения.

⏺Клонирование и создание Вариантов (Variants)
Variant – это копия Config Unit, которая создается через операцию Clone.

1. Создаем Dev Variant из базового окружения:
2. Выбираем чарты в infra space.
3. Выбираем dev space как цель.
4. Нажимаем [Clone Units].
5. Создаем Prod Variant из Dev Variant аналогично.

⬆️Так, мы получаем цепочку конфигураций:
[infra's Helm charts] → [dev's Helm charts] → [prod's Helm charts]

Аналогичную концепцию можем использовать в Kustomize. Мы начинаем с базовых ресурсов, а затем добавляем к ним «Dev Overlays».

⏺Мгновенный доступ к конфигурациям
1. После клонирования не требуется повторный рендеринг.
2. Получаем точные манифесты для окружений:

Dev


cub unit get --space dev prometheus --data-only

Prod


cub unit get --space prod prometheus --data-only

Получаем готовый YAML, а не шаблон или переменную.

⏺Решение сценариев «Fire Drill»
1. Так как конфигурации сохранены как данные, можно выполнять поиск и анализ без повторного рендеринга:

Поиск уязвимых образов


cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*registry.compromised.com.*'"

Поиск образов


cub unit list --space "*" \
  --resource-type monitoring.coreos.com/v1/Prometheus \
  --where-data "spec.image ~ '.*quay.io.*'"

👀Подводные камни и что делать:
• Нативные зависимости и postinstall хуки. При рендере учитывайте, что некоторые чарты рассчитывают поведение во время выполнения. Обязательный этап – прогон тестов в staging.
• Избежание версионных конфликтов Helm чартов, за счет фиксирования версий чарта; используйте lock-файлы чарта или helmfile для управления групповыми релизами.

Делимся полезными ресурсами:
⚙️Интеграция ConfigHub-workflow с CI/CD (build → render → store → apply), примеры для GitHub Actions/GitLab CI и рекомендации по кэшированию здесь.
❕How-to по Variants и GitOps (ArgoCD/Flux) – синхронизация «данных-конфигураций» с Git и кластерами (Kustomize в ArgoCD), подробнее тут.

#confighub #kubernetes #helm #devops