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

Подготовка конфигурации и кастомных образов

Данный раздел описывает основные шаги, если вы планируете использовать собственное содержимое: конфигурацию, темы, сообщения, Java-классы flow, дополнительные JAR и т.д.

Дерево конфигурации Blitz IDP для Helm чарта

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

blitz.conf
assets/
captchas/
custom_messages/
dynamic/
flows/
misc/
panel/
saml/
token_exchange/

Во время публикации чарт переносит blitz.conf в root/blitz.conf, а остальные каталоги размещает в общем хранилище.

Для первого развёртывания вы можете скачать готовый стандартный набор конфигов по данной ссылке.

Это удобный стартовый вариант для режима Git/Local -> PVC: архив можно использовать как основу для собственного конфигурационного репозитория и затем постепенно адаптировать под свои нужды.

Какие каталоги допустимы

Чарт публикует только заранее определённые пути верхнего уровня:

  • apps
  • assets
  • captchas
  • custom_messages
  • dynamic
  • flows
  • methods
  • root
  • saml
  • token_exchange
  • misc

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

Назначение основных каталогов

assets

Мемы и другие статические HTML-ресурсы.

captchas

Hесурсы, связанные с используемыми капчами.

custom_messages

Здесь можно разместить дополнительные или переопределённые наборы сообщений. Этот каталог удобен для локализации и настройки пользовательских текстов.

dynamic

Здесь размещаются JAR процедуры.

flows

Здесь располагаются Java-классы login flow и связанные с ними расширения.

misc

Прочие дополнительные ресурсы, например словари паролей.

panel

Если используется модуль Blitz Panel, учитывайте отдельную публикацию:

  • panel/app.conf
  • panel/icons/*

Сценарии без пересборки образов

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

  • assets
  • custom_messages
  • части dynamic
  • flow-расширений, которые поставляются из внешнего конфигурационного репозитория

Когда нужны кастомные образы

Собственные образы нужны, если:

  • файловая конфигурация должна быть встроена прямо в контейнер
  • организация использует режим config.readOnly=true
  • требуется единый immutable-артефакт для релиза
  • нужно поставлять собственные файлы вместе с образом и не зависеть от публикации в PersistentVolumeClaim

Сборка кастомного образа

В репозитории уже есть Dockerfile и каталог dockerfiles/files, куда можно положить необходимые материалы.

Пример сборки образа одного модуля:

MODULE=idp TAG=5.31.0 SUFFIX=custom
docker build . \
  --build-arg MODULE=${MODULE} \
  --build-arg TAG=${TAG} \
  -t "blitz-${MODULE}-${SUFFIX}:${TAG}"

Сборка нескольких модулей

TAG=5.31.0 SUFFIX=custom
for MODULE in idp console recovery registration; do
  docker build . \
    --build-arg MODULE=${MODULE} \
    --build-arg TAG=${TAG} \
    -t "blitz-${MODULE}-${SUFFIX}:${TAG}"
done

Содержимое dockerfiles/files

Типовой набор:

  • assets
  • captchas
  • custom_messages
  • dynamic
  • flows
  • misc

Если вы собираете образ под конкретный модуль, заранее проверьте, какие каталоги реально должны попасть в этот модуль, чтобы не раздувать образ без необходимости.

Рекомендации

Используйте кастомные образы, если:

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

Используйте внешний конфигурационный репозиторий и PVC, если:

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