Руководство администратора
Настройка DevOps
Определение наименования проекта DevOps
Перед началом настройки необходимо определить имя для проекта DevOps. Данное имя будет использоваться в дальнейших инструкциях, поэтому его необходимо запомнить.
Правила формирования имени проекта DevOps:
- название должно состоять только из символов английского алфавита, должно быть в нижнем регистре, не содержать каких-либо специальных символов (включая "-", "_") и пробелов. Допустимо использование цифр, если они не являются первыми символами названия;
- в качестве названия необходимо указать либо название продукта (не модуля), либо название банка, для конфигурации которых создаётся проект.
Запрещено использование следующих наименований для проекта: dev, usr, release, rc.
Создание эталонной базы данных проекта
Перед созданием проекта необходимо подготовить эталонную базу данных проекта. Для этого необходимо определить список существующих схем БД, которые будут использоваться в проекте.
Список модулей и их БД:
- QBPD - Дизайнер бизнес-процессов и бизнес-правил (Business Process Designer): qbpmdesigner
- QC - Управление бизнес-процессами (Cockpit): qbpmcockpit
- QHT - Пользовательские задания (Human Task): dqhumantask
- QBPET - Средства исполнения бизнес-процессов (Q.BPM Player): qbpetqbpmplayer
- QAL - Список заявок (Application List): qbpmapplist
Формирование списка образов для установки на стенд
Инструмент установки приложений поддерживает два варианта установки Docker-образов на стенд:
- установка образа по ссылке (на базовый образ);
- установка образа из соответствующей проекту ветки реестра образов.
Наиболее правильный способ настройки для производственного стенда предусматривает следующее:
- все смежные модули (системное окружение и другие смежные модули, не разрабатываемые командой) необходимо устанавливать из готового образа;
- модули, разрабатываемые командой, необходимо устанавливать из отдельной ветки реестра образов.
Для того чтобы поддержать данный вариант установки, необходимо выполнить следующее:
- в
config.yml
ветки проекта в devops_configs (opens in a new tab) добавить/изменить следующий параметр:module_list_from_file: "combo";
- добавить файл
module-list.yml
в ту же папку, где размещён файлconfig.yml
, с содержанием используемых модулей.
Образы в проектной ветке реестра образов создаются автоматически при первоначальной настройке DevOps в соответствующем модуле.
Категорически не рекомендуется размещение образов смежных модулей в ветке своего DevOps-проекта. Необходимо указывать именно ссылку на существующий образ.
На ВМ devops по пути папки проекта необходимо разместить sh файл для получения образов из реестра.
Создание Namespace
Для каждого пользователя, которому требуется персональный стенд, необходимо создать задачу на создание/пересоздание персонального стенда.
Для создания неймспейса требуется предоставить следующую информацию:
- devopsProject – ветка проекта в репозитории
devops_configs;
- stage - этап в ветке проекта в репозитории
devops_configs;
. По умолчанию – dev; - registryStage - этап в реестре Docker-образов. Для обычных стендов обычно равен dev, а для персональных – логину пользователя, для которого создаётся стенд;
- namespace - наименование создаваемого Namespace в Q.RunneR;
- team – наименование производственной команды, ответственной за Namespace;
- devops - EMail сотрудника, ответственного за Namespace.
Создание ветки в репозитории devops_configs
Запросить права на работу в репозитории GIT devops_configs
и авторизоваться.
Перейти в интерфейс создания новой ветки в репозитории GIT devops_configs
. В открывшемся интерфейсе в поле Branch name
ввести название новой ветки, соответствующее наименованию проекта DevOps, для которого производится настройка (см. п. 1). Если ветка создаётся для проекта, основанного на микросервисной, либо гибридной архитектуре, в поле Create from
необходимо ввести значение template_micro_pg
.
Нажать кнопку Create branch.
Создание репозитория и сборки микросервиса на базе Q.BPM Player
Для создания прикладных микросервисов на базе Q.BPM Player должен быть использован базовый образ Q.BPM Player. Алгоритм создания репозитория и сборки для прикладного микросервиса следующий:
-
Для каждого разворачиваемого микросервиса на базе Q.BPM Player (далее модуль) в GitLab должен быть создан собственный отдельный репозиторий;
Структура репозитория микросервиса должна быть следующая: Каталог модуля
- Проект (main)
- Ресурсы (resource)
- Схемы (schemas)
- Схема – файл .json
- Процесс – файл .bpmn
- Схемы (schemas)
- Ресурсы (resource)
- Docker
- Dockerfile-database.txt
- Dockerfile-service.txt
- properties.properties
- pom.xml
- Проект (main)
-
В репозитории модуля должен быть расположен каталог проекта «main», где нет java кода, каталог «Docker» и файл pom.xml;
-
В каталоге «main» должен быть расположен каталог «resource», где должны содержаться только ресурсы (процесс + схема (объект)). Для хранения схем в каталоге «resource» должен быть выделен каталог «schemas». Хранение схем (объектов) в отдельном каталоге необходимо для обеспечения однозначной идентификации бизнес-объекта, необходимого для запуска модуля. Таким образом, библиотека динамических атрибутов однозначно определяет схему, необходимую для запуска модуля. В частных случаях сервис может стартовать без схем;
-
В каталоге «Docker» должны быть расположены
Dockerfile-database.txt
иDockerfile-service.txt
- инструкции для сборки docker-образа Q.BPM Player. В файлахDockerfile-database.txt
иDockerfile-service.txt
должно быть указано расположение хранилища, где хранится образ Q.BPM Player определенной версии, указано расположениефайл.jar
ипараметры запуска
; -
Далее настройка Jenkins файла полностью идентична настройка MSA и процесс выпуска построен точно так же.
Обновление базового образа Q.BPM Player
Для обновления базового образа плеера необходимо:
- Перейти в репозиторий плеера в каталог docker
- В файлах
Dockerfile-database.txt
иDockerfile-service.txt
указать актуальную версию образа изregistry-new.diasoft.ru/release
- Зафиксировать изменения. Начнется сборка модуля на обновленном образе
- Если в docker указана версия release, достаточно перезапустить сборку
- Обновить модуль на стенде
Версии образа в Dockerfile-database.txt
и Dockerfile-service.txt
обязательно должны совпадать
Установка прикладного сервиса на базе образа Q.BPM Player
В девопс репозитории необходимо добавить конфигурационный файл разворачиваемого (создаваемого) МС в формате namesService.property.
В конфигурационном файле описаны стандартные параметры относящиеся к DigitalQ платформе, например: AUTH_SERVER_URL
, AUTH_PROVIDER
, AUTH_SERVER_CONTEXT
, DATASOURCE_URL
, KAFKA_URL
и т.д.)
Параметры Q.BPM Player:
QBPM_PROCESS_INPUT_TOPICS
- через точку с запятой топики для подпискиQBPM_PROCESS_OUTPUT_TOPICS
- через точку с запятой топики, в которые разрешена отправка (Пример: QBPM_PROCESS_OUTPUT_TOPICS = dsTaskCreateEvent;dsTaskCancelEvent;dsTaskActionEvent)QBPM_MODE
- режим работы плеера dev/prod/runQBPM_DLQ_TOPICS
- создание топиков с постфиксом dlq - по умолчанию false (true - создание включено; false - создание выключено)QBPM_LIMIT_DEFINITION_VERSIONS_ENABLED
- автоудаление бизнес-процессов - по умолчанию false (true - автоудаление включено; false - автоудаление выключено)QBPM_LIMIT_DEFINITION_VERSIONS_COUNT
- количество сохраненных процессов (по умолчанию 10)
При автоудалении в Дизайнере бизнес-процессов диаграмма меняет статус на архивный. Из Мониторинга процессов удаляются связанные процессы. Если у процесса есть активные экземпляры - данный процесс не удаляется. Удаление происходит после публикации новой версии.
Режим работы плеера dev/prod/run
Реализовано разделение диаграмм по областям/неимспейсам/профилям на два режима работы (в каждом из режимов у диаграмм параметр tenantId будет соответствующий):
- DEV - все версии диаграмм помечаются специальной меткой. Активизируется job, который "чистит" активные процессы - завершает (будут иметь статус "Внешне завершенный") все активные экземпляры процессов, если они исполняются
более 12ч . Также спустя один день исполнения экземпляра процесса по нему очищается история - удаляются записи в сервисе qbpetqbpmplayer таблицы:act_hi_*
- PROD - режим по умолчанию, платформа работает, как и раньше. Публикуются диаграммы, хранится полная история и т.п.
- RUN - все версии диаграмм помечаются специальной меткой. Активизируется job, который "чистит" активные процессы - завершает (будут иметь статус "Внешне завершенный") все активные экземпляры процессов, если они исполняются
более 5 минут . Очищается история - удаляются записи в сервисе qbpetqbpmplayer таблицы:act_hi_*
При этом контроллеры в Swagger также разделены по профилям и не пересекаются.
Режим, настройка конфигурации QBPM_MODE, устанавливается вручную через конфиги Kubernetes. Эта доработка дает несколько плюсов и решает ряд проблем:
- Проведение показов и важных презентаций в режиме PROD. Избавляет от демонстрации множества версий, на которых происходила отладка (мусор).
- В режиме DEV можно удалять версии, как и сколько угодно. Режим PROD для использования финальной, рабочей, стабильной версии диаграммы (без возможности всякого удаления версий диаграмм).
- Уменьшение потребления памяти сервисом.
Дополнительные возможности - реализация функционала тестового запуска экземпляра диаграммы. Кнопка Play открывает модальное окно, в котором указываются входные и выходные параметры, после чего можно запустить на исполнение экземпляр диаграммы в режиме RUN. Данный режим позволяет отлаживать небольшие "кусочки" большой диаграммы, которые разбиваются на подмножество диаграмм. Таким образом позволяя найти и устранить все дефекты при проектировании. При таком тестовом запуске все активные экземпляры диаграмм будут завершены, если исполняются act_hi_*
.
Для того чтобы произвести тестовый запуск экземпляра процесса, необходимо в модальном окне у входных параметров заполнить столбец "Тестовое значение".
Хранение истории выполнения процессов
Для экономии памяти в БД можно настроить очистку истории выполненных процессов. Количество дней хранения истории выполнения процессов записывается в act_re_procdef.history_ttl_
Задать значение history_ttl_ - History Time To Live можно несколькими способами:
- Можно полностью выключить хранение истории. В Дизайнере бизнес-процессов в свойствах процесса включить параметр Не хранить историю выполнения процесса. Настраивается отдельно на каждом процессе.
- Задать количество дней хранения истории. В Дизайнере бизнес-процессов в свойствах процесса задать значение для параметра Время жизни истории. Настраивается отдельно на каждом процессе.
- Задать в Q.BPM Player режим работы через параметр
QBPM_MODE
- Добавить в Мониторинг бизнес-процессов (qbpmcockpit) параметр
QBPM_HISTORY_TIME_TO_LIVE
и указать ему значение в днях. (ПримерQBPM_HISTORY_TIME_TO_LIVE: P1D
)
Если в Q.BPM Player не выставлен режим работы (QBPM_MODE=run/dev/prod), в таком случае значение для act_re_procdef.history_ttl_ будет проставляться из qbpmcockpit в параметре QBPM_HISTORY_TIME_TO_LIVE
Таблицы истории выполнения процессов не будут очищены, пока процесс активный.
Возможности логирования и уровни
logging:
config: classpath:log4j2.xml
level:
root: ${LOGGING_ROOT_LEVEL:INFO} // логирование абсолютно всего
ru.diasoft.micro: ${LOGGING_DIASOFT_LEVEL:${LOGGING_ROOT_LEVEL:INFO}} // логирование классов Диасофта
org.hibernate.type: ${LOGGING_HIBERNATE_LEVEL:INFO} #To log values set TRACE // логирование запросов в БД
org.apache.kafka.clients: ${LOGGING_KAFKA_LEVEL:INFO} // логирование кафка-клиента
org.springframework.kafka.listener: ${LOGGING_KAFKA_LEVEL:INFO} // логирование лиснеров
org.camunda.bpm.engine: ${LOGGING_CAMUNDA_LEVEL:INFO} // логирование всех действий камунды
org.springframework.transaction: ${LOGGING_TRANSACTION_LEVEL:INFO} // логирование транзакций
Логирование всегда должно быть включено. По умолчанию логирование устанавливает в уровень ERROR
, допускается использование всех модулей. Для режима PROD
- рекомендуется выставлять уровень ERROR
и только на необходимый модуль. Для режима DEV
или RUN
- рекомендуется выставлять уровень ALL
, модуль "root".
Доступные режимы логирования:
INFO
- только информативные сообщения и то, что логируется в коде с уровнем INFO;ERROR
- выводится информация по всем ошибкам;WARN
- информация о различных предупреждениях;ALL
- максимальный уровень, который выводит абсолютно все;DEBUG
- режим отладки
В режиме DEBUG сервис потребляет большое количество ресурсов
Q.BPM Руководство по установке и запуску сервисов
Настройка проектного стенда и конфигурации для него в репозитории
devops_configs (opens in a new tab)
Настраивать можно по аналогии с веткой [omniplatform] (https://gitflex.diasoft.ru/devops/devops_configs/-/tree/omniplatform/devops/stages/dev (opens in a new tab))
Необходимо создать свою ветку: название ветки = название неймспейса
Настройка конфигурации сервисов
Примеры общих настроек неймспейса (БД PostgreSQL):
- config.yml - config.yml (opens in a new tab)
- Настройки БД всего стенда - dbservers.properties (opens in a new tab)
- Настройки шлюза - mdpgateway.properties (opens in a new tab)
- Настройки rulelist для работы шлюза в новом формате (opens in a new tab) - rulelist.yaml (opens in a new tab)
Примеры необходимых настроек для модулей:
- Q.BPM UI (Рутовое приложение)
- Настройки QBPM UI (стандартная авторизация через mdpauth)
Пример содержимого конфигурационного файла- Настройки QBPM UI (Keycloak авторизация)
Пример содержимого конфигурационного файла - QBPD - Дизайнер бизнес-процессов и бизнес-правил (Business Process Designer)
qbpmdesigner.properties
- QC - Управление бизнес-процессами (Cockpit)
qbpmcockpit.properties
- QHT - Пользовательские задания (Human Task)
dqhumantask.properties
- QHT - Пользовательские задания UI (Human Task UI)
humantaskui.properties
- QBPET - Средства исполнения бизнес-процессов (Q.BPM Player)
qbpetqbpmplayer.properties
Для работы сервисов Q.BPM потребуется установка актуальных версий платформенных сервисов
- mdpsettings
- mdpgateway
- mdpauth
- mdpemployee
- mdpdepartments
- mdpusers
- mdproles
- mdprefs
- mdpsenders
Копирование образов
Последние релизные версии образа:
- registry-new.diasoft.ru/release/qbpmui:24050501
- registry-new.diasoft.ru/release/qbpmdesigner:24042206
- registry-new.diasoft.ru/release/qbpmcockpit:24042501
- registry-new.diasoft.ru/release/dqhumantask:24042708
- registry-new.diasoft.ru/release/humantaskui:24042711
- registry-new.diasoft.ru/release/qbpetqbpmplayer:24042703
Back-end сервисы (без постфикса UI) также требуют установки database образа
Актуальные версии платформенных сервисов необходимо запрашивать у команды "Инструменты и платформа Back-end разработки"
Настройка лицензии
После 10.03.2023 в сервисах Q.BPM включена проверка на лицензирование.
Для оформления лицензии необходимо направить запрос на «CTL - входящие обращения ctl@diasoft.ru»
Модули, которые должны быть указаны в лицензии:
- QBPD - Управление бизнес процессами (qbpmdesigner)
- QC - Мониторинг бизнес-процессов (qbpmcockpit)
- QHT - Пользовательские задачи (dqhumantask)
- QBPET - Средства исполнения бизнес-процессов (qbpetqbpmplayer)
Настройка в неймспейсе через Kubernetes
- Открыть Kubernetes, раздел Config Maps
- Найти конфигурацию с наименованием share-config-volume
- Открыть на редактирование
- Найти в разделе data параметр license.xml:
- Если данный параметр отсутствует - добавить параметр с названием license.xml
- В значение параметра добавить все содержимое полученного файла license.xml
- Сохранить конфигурацию share-config-volume по кнопке Update
- В system-config либо в конфигурацию сервиса добавить параметр LPATH: /share/config/
- Проверить значение параметра LPATH в сервисах Q.BPM. При необходимости изменить значение на корректное, либо отключить (удалить) параметр
- После настройки параметра перезапустить сервисы Q.BPM
Файл лицензии также необходимо подложить в devops_configs вашего проекта в каталог share_templates/config_templates
И убедиться, что в devops_configs в каталоге properties настроен для сервисов параметр LPATH
Настройка аутентификации в Kafka через SSL (Secure Sockets Layer)
Описание параметров
KAFKA_SECURITY_PROTOCOL
- протокол, по которому сервис подключается к брокеру, по умолчанию ”PLAINTEXT для включения SSL необходимо задать значение ”SSL”.KAFKA_TRUSTSTORE_LOCATION
- путь до хранилища доверенных сертификатов, по умолчанию пустой, значение должно начинаться с указания протокола ”file:// после этого указывается полный путь до файла.KAFKA_TRUSTSTORE_PASSWORD
- пароль от хранилища доверенных сертификатов, по умолчанию пустой.KAFKA_KEYSTORE_LOCATION
- путь до хранилища приватных ключей, по умолчанию пустой, правила заполнения аналогично KAFKA_TRUSTSTORE_LOCATION.KAFKA_KEYSTORE_PASSWORD
- пароль от хранилища приватных ключей, по умолчанию пустой.KAFKA_KEY_PASSWORD
- пароль от приватного ключа, по умолчанию пустой.
Параметры необходимо добавить в файл с настройками сервиса на стенде и в файл, который загружается на стенд при установке/обновлении сервиса (application.properties или application.yaml)
Настройка сервисов для работы с Keycloak-авторизацией
Для использования ВPM-сервисов на стенде с Keycloak необходимо:
-
Установить актуальные версии сервисов
- qbpmdesigner
- qbpetqbpmplayer
- dqhumantask
- qbpmcockpit
- qunnotification
- mdpemployee
- mdpdepartments
- mdpusers
- mdproles
- mdprefs
-
Если необходим справочник сотрудников и подразделений с qwork - в платформенных сервисах mdpemployee и mdpdepartments в dbsecret настроить подключение к БД qwork
-
В Kubernetes в сервисных конфигурационных файлах добавить параметры
QOAUTH_MODE
RESOURCE_SERVER_ID
AUTH_SERVER_PUBLIC_KEY
-
Убрать параметр
AUTH_PROVIDER=digitalq
-
В системной конфиг-мапе добавить параметр
KUBERNETES_LEGACY_MOD=true
-
В BPM-сервисах включить параметр
SECURITY_ENABLED=true
-
Параметры для добавления технического пользователя в Q.BPM Player
KEYCLOAK_AUTH_URL
KEYCLOAK_CLIENT_ID
KEYCLOAK_CLIENT_SECRET
KEYCLOAK_SCOPE
KEYCLOAK_GRANT_TYPE
TECH_AUTH_SERVICE_NAME
// имя сервиса авторизацииTECH_USERNAME
// логин технического пользователяTECH_PASSWORD
// пароль технического пользователя
- После выполнения настроек перезапустить сервисы Пример настроенного стенда (opens in a new tab)
Завершающий этап
После выполненных настроек необходимо запустить сборку пересоздания стенда (RecreateNamespace), которая была создана для вашего неймспейса. Должен подняться стенд.
Запуск сервисов
Рекомендуемые значения ресурсов для запуска сервиса:
Проверить настройки в Deployment сервиса в разделе resources/limits. Рекомендуемые лимиты для сервисов Q.BPM:
resources:
limits:
cpu: '2'
memory: 2Gi
Параметры пула выделения памяти:
JAVA_XMS: 1g
JAVA_XMX: 2g
JAVA_XMS
- начальный пул выделения памятиJAVA_XMX
- максимальный пул выделения памяти
Сколько выделено памяти, будет видно при запуске сервиса. Если не настроить параметры JAVA_XMS и JAVA_XMX, по умолчанию их значения следующие:
JAVA_XMS: 64m
JAVA_XMX: 512m
Нельзя выставлять параметры JAVA_XMS и JAVA_XMX выше лимитов в деплойменте сервиса. В таком случае сервис не запустится.
Сервис перезапускается с ошибкой Killed в логах:
- Решение: Поднять лимиты в деплойменте сервиса
Сервис перезапускается с ошибкой Java heap space в логах:
- Решение: Проверить настройки JAVA_XMS и JAVA_XMX согласно описанию выше
Статус ImagePullBackOff у пода:
Failed to pull image "registry-new.diasoft.ru/dvt/development/dev/qbpmdesigner:24010101": rpc error: code = NotFound desc = failed to pull and unpack image "registry-new.diasoft.ru/dvt/development/dev/qbpmdesigner:24010101": failed to resolve reference "registry-new.diasoft.ru/dvt/development/dev/qbpmdesigner:24010101": registry-new.diasoft.ru/dvt/development/dev/qbpmdesigner:24010101: not found
Решение: Прописать актуальный образ из реестра образов
JPA_DIALECT
Failed to initialize JPA EntityManagerFactory: Unable to load class [jsonb-node]
Решение: Неправильно задано значение параметра JPA_DIALECT
Лицензия:
Error creating bean with name 'LStart': Invocation of init method failed; nested exception is java.lang.Exception: Signature is invalid
Решение: Неправильно задан параметр LPATH. Проверить значение параметра LPATH. Также данная ошибка может возникать, если файл лицензии неправильной структуры
Error creating bean with name 'LStart': Invocation of init method failed; nested exception is java.lang.Exception: Expired
Решение: Истек срок лицензии. Лицензию необходимо обновить.
Error creating bean with name 'LStart': Invocation of init method failed; nested exception is java.lang.Exception: Error reading file
Решение: Раздел license.xml на стенде пустой либо имеент некорректное содержание. Необходимо проверить его содержимое на стенде.
При невыполненной проливке БД или некорректной проливке в интерфейсе будет возникать ошибка:
ResultSet; SQL [n/a]; nested exception is org.hibernate.exception.SQLGrammarException: could not extract ResultSet
Решение: Проверить лог проливки database. При необходимости выполнить проливку заново. Успешно выполненной проливкой является наличие сообщения: The DB-manager worked SUCCESSFULLY
Q.BPM Player не запускается
The deployment contains definitions with same key '<key value>' (id attribute), this is not allowed
Решение: Открыть репозиторий с bpm-плеером. Проверить процессы в каталоге src/main/resources на наличие повторяющихся ключей. Убрать повторение. Пересобрать bpm-плеер.
Сервис не может создать топики:
Failed to create topics. error: Creating topics with default partitions/replication factor are only supported in CreateTopicRequest version 4+. The following topics need values for partitions and replicas: [qpbcd-pbc-ext-bussiness-platform-platform-type-reply]
Решение: В Config Maps сервиса добавить параметр spring.cloud.stream.kafka.binder.replication-factor: '1'
Авторизация
Failed to instantiate [javax.servlet.Filter]: Factory method 'springSecurityFilterChain' threw exception; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'mdpAuthJwtDecoder' defined in class path resource [ru/diasoft/micro/mdp/lib/qoauth/QSecurityConfig.class]
Решение: обновить версию mdpauth