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

Описание

Перед Helm-чарта

установкой

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

необходимых

Две длясхемы, работыкоторые Blitzподдерживает Identityчарт

Provider.

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

В зависимостиэтой от конфигурации и включённых модулей чарт может создавать:

• Deployment и StatefulSet для модулей Blitz
• Service для внутреннего и внешнего доступа
• Ingress для публикации HTTP-маршрутов
• Secret и ConfigMap для статической конфигурации
• PersistentVolumeClaim для общей динамической конфигурации
• Job начальной загрузки конфигурации
• PodDisruptionBudget
• NetworkPolicy
• ServiceMonitor и PodMonitor
• ресурсы Vault Secrets Operator, если включена интеграция с Vault

Версия чарта требует Kubernetes не ниже 1.26.

Основные модули Blitz

Чарт поддерживает следующие модули:

• idp — основной модуль аутентификации и выдачи identity-сервисов
• console — административная консоль Blitz
• reg — модуль регистрации
• recovery — модуль восстановления доступа
• panel — дополнительный пользовательский веб-модуль
• ldapMfa — сервис LDAP MFA

По умолчанию в чарте включены idp, console, reg, recovery. Модули panel и ldapMfa включаются отдельно через конфигурацию чарта.

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

В чартесхеме используется двухуровневая модель конфигурации:

• статическая конфигурация
• динамическая конфигурация

Статическая конфигурация

Статическая конфигурация рендерится Helm и попадает в Secret, ConfigMap или, при использовании Vault, в VaultStaticSecret.

Типовые статические файлы:

• boot.conf
• overlay.conf
• play.conf
• logback.xml
• blitz-keystore.bks
• console.conf

Для модулей Blitz эти файлы по умолчанию монтируются в каталог:режим:

/usr/share/identityblitz/blitz-configconfig:
  

readOnly:

Динамическая конфигурация

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

По умолчанию она размещается по пути:

/usr/share/identityblitz/idp-configtrue

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

Два режима поставки конфигурации

Режим image-only

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

Особенности режима:Преимущества:

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

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

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

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

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

РежимСхема Git/Local2. ->Динамическая PVCконфигурация из 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

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

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

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

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

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

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

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

Kubernetes-ресурсы

Ingress

Ingress публикует HTTP-эндпоинты Blitz наружу. Чарт поддерживает настройку класса ingress-контроллера, аннотаций и TLS-секрета.

PersistentVolumeClaim

PersistentVolumeClaim нужен только в сценарии с динамической конфигурацией. Он хранит конфигурацию и вспомогательные ресурсы, доступные модулям Blitz IDP.

Vault и VSO

Если используется vault.enabled=true, чарт может забирать секреты из HashiCorp Vault через Vault Secrets Operator. В этом случае вместо прямого создания некоторых Secret в кластере используются ресурсы:

• VaultConnection
• VaultAuth
• VaultStaticSecret

PodDisruptionBudget

PodDisruptionBudget защищает модули от добровольных прерываний, например при kubectl drain или плановом обслуживании узлов.

NetworkPolicy

NetworkPolicy ограничивает сетевой доступ к подам Blitz. В чарте есть как более мягкий режим, так и строгий режим с явными правилами.