Обновление и откат

Helm делает обновление Blitz IDP достаточно прямолинейным, но в продакшен среде важно заранее понимать, что именно меняется в релизе, когда возможна повторная публикация конфигурации и как безопасно откатиться к предыдущей версии.

Базовый порядок обновления

Перед установкойобновлением Blitz необходимо выбрать, как именно будет поставляться конфигурация приложения. В чарте поддерживаются две рабочие схемы, и от этого выбора зависят состав ресурсов в кластере, способ обновления и порядок сопровождения.рекомендуется:

Схемы

Схема

сохранить 1.изменённый Конфигурацияvalues.yaml

внутри

проверить образов

шаблоны через helm template
• проверить chart через helm lint
• зафиксировать текущую ревизию релиза

ВКоманды этойдля схеме используется режим:проверки:

config:helm readOnly:history trueblitz -n blitz
helm template blitz ./helm -n blitz -f values-prod.yaml
helm lint ./helm -f values-prod.yaml

ФайловаяКоманда конфигурация должна быть встроена в Docker-образы модулей Blitz, а чарт отвечает только за запуск подов и подключение необходимых Kubernetes-ресурсов.обновления:

helm upgrade blitz ./helm -n blitz -f values-prod.yaml

Проверки перед обновлением

Преимущества:Перед helm upgrade убедитесь:

• самаявсе простаяподы эксплуатация
текущего
• меньшерелиза зависимостейв во время установки
• не нуженсостоянии PersistentVolumeClaimReady
• ненет нужен init-confнезавершённых Job
• меньшепонятен рисков,ожидаемый связанныхсостав с начальной публикацией файлов

Ограничения:

• изменения конфигурации обычно требуют обновления образовизменений
• сложнеебаза отделитьданных жизненный цикл приложения от жизненного цикла конфигурации

Эта схема подходит, если:

• конфигурация редко меняетсядоступна
• есть контролируемый процесс сборки образов
• важнее предсказуемостьVault и простотаingress-контроллер запуска

Схема 2. Динамическая конфигурация из Git или локального источника

В этой схеме используется режим:

config:
  readOnly: false

В этом случае конфигурация публикуетсянаходятся в общийрабочем каталог через PersistentVolumeClaim, а источником служит:

• Git-репозиторий
• локальный каталог на узле

Пример настройки для Git:

config:
  readOnly: false
  source:
    type: git
    git:
      repo: https://git.company.loc/blitz/blitz-config.git
      ref: main
      depth: 1
      auth:
        existingSecret: blitz-config-git-creds
        usernameKey: username
        passwordKey: password

Преимущества:

• конфигурация отделена от образов
• удобнее сопровождать дерево конфигурации как отдельный артефакт
• можно использовать единый Git-репозиторий как источник правды

Ограничения:

• появляется зависимость от PersistentVolumeClaim
• установка становится сложнее
• нужно контролировать начальную загрузку конфигурации
• обновления требуют более аккуратной проверки

Эта схема подходит, если:

• конфигурация Blitz живёт в отдельном репозитории
• есть требования к сопровождению конфигов вне процесса сборки образов
• нужно публиковать динамические каталоги в runtime

Роль init-conf

При config.readOnly=false чарт может запускать Job, который публикует конфигурацию в общее хранилище.

init-conf делает следующее:

• копирует исходные файлы во временную staging-зону
• не изменяет исходный Git-репозиторий или локальный каталог
• переносит blitz.conf в root/blitz.conf
• публикует только разрешённые каталоги верхнего уровня
• при наличии публикует конфигурацию panel
• при доступности секрета инициализирует credentials

Чарт публикует в PersistentVolumeClaim только следующие верхнеуровневые пути:

• apps
• assets
• captchas
• custom_messages
• dynamic
• flows
• methods
• root
• saml
• token_exchange
• miscсостоянии

Если в дереве конфигурации присутствует panel, он обрабатывается отдельно:

• panel/app.conf публикуется в {{ .Values.dataPath }}/blitz-panel/app.conf
• panel/icons/* публикуются в {{ .Values.dataPath }}/blitz-panel/static/*

Признак готовности конфигурации для рабочих pod

Когда для релиза ожидается первичная публикация конфигурации, чарт может добавить в рабочие модули initContainer, который ожидает готовности общей конфигурации.

Это нужно, чтобы:

• idp
• console
• recovery
• reg
• panel

не стартовали раньше времени и не столкнулись с пустым каталогом конфигурации.

Практический выбор схемы

Выбирайте config.readOnly=true, если

• хотите самый простой запуск
• готовы обновлять конфигурацию через Docker-образы
• не хотите использовать общийиспользуется PersistentVolumeClaim
,
• неотдельно планируетепроверьте выноситьсостояние конфигитома.
  в

  Особенности отдельныйобновления Git-процесс

Выбирайтепри config.readOnly=false, если

• конфигурация Blitz уже ведётся в Git
• нужен общий runtime-каталог с конфигами
• есть требования к публикации flows, assets, custom_messages и других директорий без пересборки образов
• команда эксплуатации готова сопровождать PersistentVolumeClaim, Job и порядок обновлений

Важные последствия выбора

Для

В обновлений

Прирежиме динамической схемеконфигурации отдельноотдельное контролируйтезначение имеет параметр:

config:
  source:
    git:
      reseedOnUpgrade: false

ЕслиИли включитьаналогичный параметр для local-источника.

reseedOnUpgradereseedOnUpgrade=false,

чарт

Это более осторожный режим. Обновление Helm не будет автоматически повторно публиковать конфигурацию прив обновлении релиза. Это полезно не всегда и должно использоваться осознанно.PersistentVolumeClaim.

Для

Подходит, безопасности

Даже в режиме readOnly=false статическая и динамическая конфигурация остаются разделёнными. Это сделано специально, чтобы:если:

• ненужно смешиватьразделить runtime-секретыобновление чарта и публикуемыеобновление файлыконфигурации
• уменьшитьвы рискхотите неконтролируемыхизбежать неожиданных изменений
• сохранитьфайлов предсказуемыйв жизненный цикл конфигурацииruntime

Для эксплуатацииreseedOnUpgrade=true

РежимЭтот режим полезен, если вместе с PersistentVolumeClaimрелизом требуетнужно болеезаново внимательногоопубликовать сопровождения:конфигурацию. Но использовать его нужно осознанно, потому что он меняет фактическое содержимое общего хранилища во время upgrade.

Подходит, если:

• проверятьконфигурация меняется вместе с релизом
• порядок поставки строго контролируется
• команда понимает последствия повторной инициализации

Проверки после обновления

Сразу после helm upgrade проверьте:

• статус Helm-релиза
• состояние всех подов
• наличие ошибок в логах
• состояние Ingress
• результат Job, если он должен был запускаться
• контролировать доступность хранилища
внешнего
• понимать, когда конфигурация была опубликована повторноURL

Полезные команды:

helm status blitz -n blitz
kubectl get pods,svc,ingress,pvc -n blitz
kubectl get jobs -n blitz

Выполнение отката

Сначала узнайте доступные ревизии:

helm history blitz -n blitz

Затем выполните откат:

helm rollback blitz 3 -n blitz

Здесь 3 — номер ревизии, к которой нужно вернуться.

После rollback обязательно проверьте:

• состояние подов
• readiness и health endpoint
• корректность опубликованной конфигурации
• доступность секретов и Ingress

Риски при обновлении

Смена режима конфигурации

Переход между:

• config.readOnly=true
• config.readOnly=false

нужно планировать отдельно. Это влияет на:

• наличие PersistentVolumeClaim
• способ поставки конфигурации
• порядок эксплуатации
• процедуру восстановления

Рекомендуем заранее выбрать фиксированный режим конфигурации и не изменять его.

Изменение состава модулей

Включение или выключение panel, ldapMfa, standby-режима console и других опций меняет состав ресурсов в кластере. После такого обновления нужно дополнительно проверить маршрутизацию, секреты и готовность новых подов.

Изменение секретов и Vault

Если одновременно обновляются:

• путь в Vault
• AppRole
• параметры TLS до Vault

то риск регрессии высокий, такие изменения лучше проверить поэтапно.

Практические рекомендации

• обновляйте Helm-релиз только из версионированных values-файлов
• не совмещайте крупные изменения конфигурации и инфраструктуры без необходимости
• сначала проверяйте шаблоны, затем обновляйте релиз
• держите rollback-процедуру короткой и воспроизводимой