Перейти к основному контенту

Выбор схемы развертывания

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

Две схемы, которые поддерживает чарт

Схема 1. Конфигурация внутри образов

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

config:
  readOnly: true

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

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

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

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

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

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

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

Схема 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

Если включить reseedOnUpgrade, чарт будет повторно публиковать конфигурацию при обновлении релиза. Это полезно не всегда и должно использоваться осознанно.

Для безопасности

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

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

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

Режим с PersistentVolumeClaim требует более внимательного сопровождения:

  • проверять состояние Job
  • контролировать доступность хранилища
  • понимать, когда конфигурация была опубликована повторно
Наверх