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

Установка Blitz через Helm

В этом разделе приведён рекомендуемый порядок установки Blitz IDP в Kubernetes с помощью Helm. Порядок рассчитан на типовую эксплуатацию в namespace blitz.

ОписаниеДистрибутив Helm-чартаи сопутствующие материалы

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

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

Если установка предполагается в режиме config.readOnly=true, достаточно чарта и подготовленных образов.

Для сценария config.readOnly=false вы можете найти ссылку для скачивания стандартных конфигов в разделе подготовки конфигурации.

Шаг 1. Подготовьте namespace

kubectl create namespace blitz || true

Если namespace уже существует, убедитесь, что он используется последовательно во всех дальнейших командах.

Шаг 2. Подготовьте PostgreSQL

Если внешняя PostgreSQL уже установлена, переходите к следующему шагу. Если базы ещё нет, можно развернуть её отдельным Helm-релизом.

Пример:

helm upgrade --install blitz-pg oci://registry-1.docker.io/bitnamicharts/postgresql \
  -n default \
  --set auth.username=blitz \
  --set auth.password=blitzpass \
  --set auth.database=blitz

После этого проверьте строку подключения, которую будете использовать в values.yaml.

Шаг 3. Подготовьте секреты

Если используется Vault, сначала сгенерируйте и загрузите секреты:

tools/secrets/blitz-secrets.sh \
  --db-pass "S3cureDBPass" \
  --admin-pass "S3cureAdminPass" \
  --license "AAAA-BBBB-CCCC-DDDD" \
  --ldap-mfa-confirmation-shared-key "radius-shared-key" \
  --format json > secrets.json

Затем загрузите их в Vault и создайте Secret Kubernetes с secret_id.

Если используется Git как источник конфигурации, также подготовьте секрет с учётными данными:

kubectl -n blitz create secret generic blitz-config-git-creds \
  --from-literal=username=gituser \
  --from-literal=password='StrongGitPassword'

Шаг 4. Подготовьте values-файл

Рекомендуется использовать отдельный файл, например values-prod.yaml.

Минимальный рабочий пример:

domain: "blitz.company.loc"

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

vault:
  enabled: true
  source:
    mount: "kv"
    path: "blitz/helm/test/env"
  connection:
    create: true
    address: "https://vault.company.loc"
    skipTLSVerify: false
  auth:
    create: true
    mount: "approle"
    appRole:
      roleId: "aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa"
      secretRef: "vault-approle-secretid"

ingress:
  enabled: true
  className: "traefik"
  tls:
    enabled: true
    secretName: "blitz-idp-tls"

Шаг 5. Проверьте шаблоны перед установкой

Перед применением полезно выполнить локальную проверку:

helm template blitz ./helm -n blitz -f values-prod.yaml
helm lint ./helm -f values-prod.yaml

Если в выводе есть ошибки валидации или рендеринга, устраните их до установки.

Шаг 6. Установите или обновите релиз

Основная команда:

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

Если часть параметров нужно быстро переопределить в конкретном запуске, можно использовать --set, но для production среды это желательно свести к минимуму.

Пример включения дополнительных модулей:

helm upgrade --install blitz ./helm \
  -n blitz \
  -f values-prod.yaml \
  --set panel.enabled=true \
  --set ldapMfa.enabled=true

Состав ресурсов релиза

В типовой инсталляции чарт создаёт:

  • рабочие 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.confmemcached

ДляЕсли модулейвключён BlitzVault, этидополнительно файлысоздаются поресурсы умолчанию монтируются в каталог:VSO.

/usr/share/identityblitz/blitz-config
Базовый

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

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

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

/usr/share/identityblitz/idp-config
сценарий

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

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

Режим image-only

Режим

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

    Расширенный Git или локального каталога.

    сценарий

    ОсобенностиЕсли режима:требуется полный production контур:

    • нетиспользуйте общегоVault
    • используйте Git как источник конфигурации
    • включите PersistentVolumeClaimNetworkPolicy
    • не запускаетсянастройте init-conf JobPodDisruptionBudget
    • эксплуатациявключите прощемониторинг и безопаснееэкспорт метрик
    • изменениязафиксируйте конфигурацииотдельный вносятсяvalues-файл черезна пересборкукаждое образов

    Режим Git/Local -> PVC

    Режим config.readOnly=false нужен, когда конфигурацию требуется публиковать в общий каталог во время установки.

    Особенности режима:

    • используется общий PersistentVolumeClaim
    • источник динамической конфигурации задаётся через config.source.type
    • создаётся init-conf Job
    • рабочие поды могут ожидают готовности конфигурации через initContainerокружение

    Kubernetes-ресурсыПосле установки

    После деплоя перейдите к следующему разделу книги для проверки статуса релиза, подов, Job, PVC и 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. В чарте есть как более мягкий режим, так и строгий режим с явными правилами.

    Наверх