Где, обычно, меняется Helm

Место и контекст изменения Helm-чартов в DevOps-практике

В классическом GitOps-подходе и CI/CD-пайплайнах, Helm-чарты обычно меняются не в среде выполнения (например, непосредственно в кластере Kubernetes), а в системе контроля версий (VCS), такой как Git. Это ключевой принцип инфраструктуры как кода (IaC) и декларативного управления конфигурацией.

Основные места и способы изменений

1. Git-репозиторий — основной источник истины (Single Source of Truth)

• Все изменения начинаются здесь. Репозиторий обычно структурирован одним из следующих способов:

    *   **Монорепозиторий (Monorepo)**: В одном репозитории лежат и код приложения, и Helm-чарты, и другая инфраструктурная конфигурация.
    *   **Отдельный репозиторий для чартов**: Специализированный репозиторий, содержащий только Helm-чарты (часто для библиотечных или зависимых чартов).
    *   **GitOps-репозиторий (или репозиторий конфигураций)**: Репозиторий, содержащий исключительно манифесты и чарты для развертывания. CI-пайплайн собирает артефакты (образы), а CD-инструмент (например, ArgoCD, Flux) синхронизирует состояние кластера с этим репо.

    Пример структуры репозитория приложения:

```bash
my-app-repo/
├── src/                    # Исходный код приложения
├── helm/                   # Директория с Helm-чартом
│   ├── Chart.yaml          # Метаданные чарта
│   ├── values.yaml         # Значения по умолчанию
│   ├── values-prod.yaml    # Переопределения для Production
│   ├── templates/          # Шаблоны Kubernetes-манифестов
│   │   ├── deployment.yaml
│   │   └── service.yaml
│   └── charts/             # Зависимости (subcharts)
└── .github/workflows/      # CI/CD пайплайны (GitHub Actions)
```

2. CI/CD пайплайн — этап упаковки и тестирования

• Изменения из Git автоматически попадают в пайплайн. Здесь происходит:

    *   **Валидация**: Проверка синтаксиса чарта (`helm lint`).
    *   **Тестирование шаблонов**: Рендеринг манифестов для разных окружений (`helm template --values values-prod.yaml .`) и их статический анализ (например, с помощью `kubeval` или `kubeconform`).
    *   **Упаковка**: Создание версионного `.tgz` архива чарта (`helm package .`).
    *   **Публикация**: Загрузка упакованного чарта в **Helm-репозиторий**.

    Пример этапа в GitLab CI:

```yaml
package-chart:
  stage: package
  image: alpine/helm:latest
  script:
    - helm lint ./helm
    - helm dependency update ./helm
    - helm package ./helm --version $CI_COMMIT_TAG --app-version $CI_COMMIT_SHA
    - curl --data-binary "@my-app-${CI_COMMIT_TAG}.tgz" ${HELM_REPO_URL}/api/charts
```

3. Helm-репозиторий — хранилище версионных артефактов

• Это не место для прямого редактирования, а конечная точка для опубликованных, протестированных чартов. Репозиторием может выступать:

    *   **ChartMuseum**: Специализированное решение.
    *   **Harbor**: Container registry с поддержкой Helm.
    *   **OCI-реестр**: Современный стандарт, позволяющий хранить чарты как OCI-артефакты в реестрах вроде Docker Hub, AWS ECR, Google GAR.
    *   **Простой HTTP/S-сервер** с индексным файлом.

4. CD/GitOps-инструмент — место объявления желаемого состояния

• Инструменты вроде ArgoCD или Flux непрерывно следят за источниками (Git, Helm-репозиторий) и приводят состояние кластера к желаемому. Здесь изменения вносятся косвенно:

    *   В Git-репозитории (для ArgoCD Application) меняется ссылка на версию чарта или значения (`values.yaml`).
    *   В самом кластере в Custom Resource (например, `HelmRelease` в Flux) обновляются параметры.

    Пример манифеста ArgoCD Application, указывающего на Helm-чарт:

```yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app-prod
spec:
  source:
    repoURL: 'https://my-helm-repo.local'
    chart: my-app
    targetRevision: 1.2.3 # Версия чарта меняется здесь
    helm:
      valueFiles:
        - values-prod.yaml
  destination:
    server: 'https://kubernetes.default.svc'
    namespace: production
```

Исключения и административные сценарии

Прямое изменение в кластере через helm upgrade или helm install с ключом --set считается императивной операцией и допустимо только для:

• Экспериментов и отладки в dev-средах.
• Экстренного "горячего" фикса, когда нет времени на полный CI/CD цикл (с последующим обязательным закреплением изменений в Git).
• Администрирования кластера системными чартами (например, nginx-ingress, cert-manager), которые могут управляться отдельно от жизненного цикла приложений.

Золотое правило: Любое прямое изменение, сделанное в кластере, должно быть немедленно "затолкано" (push) обратно в Git-репозиторий для сохранения согласованности и избежания дрифта конфигурации. Современные GitOps-инструменты даже могут детектировать такой дрифт и либо перезаписывать его, либо сигнализировать об этом.

Таким образом, основной и правильный поток изменений: Разработчик/DevOps -> Git (PR/MR) -> CI/CD (тест, сборка) -> Helm-репозиторий -> GitOps-инструмент -> Kubernetes-кластер. Это обеспечивает воспроизводимость, аудит, откат изменений и коллаборацию.