Руководство по установке#

Термины и сокращения#

Системные требования#

Engine Platform V Flow разворачивается в кластере Openshift/Kubernetes. Рекомендуемые минимальные настройки CPU и выделяемой памяти поставляются в template дистрибутива. Требования к серверу БД рассчитываются индивидуально, в зависимости от решаемых задач.

Для работы компонента используется следующее свободно распространяемое программное обеспечение (Open Source Software):

• Red Hat Enterprise Linux Server 7.7;

• Red Hat OpenShift 4.5.

Для работы приложения на целевых стендах выше dev требуется использования mTLS и OTT в связи с чем требуется использование соответствующих сертификатов:

• Клиентский и серверный сертификат приложения. Серверный сертификат включает в себя в блоке SAN перечень всех необходимых route (mtls, mtls+ott, geo) и используется в Istio ingress. Клиентский используется в Istio egress, ММТ-прокси envoy, а также для соединения по ssl к БД и кафка.

• Keystore и Truststore в формате p12 ОТТ для модуля sberflow-engine

Для установки сервиса необходимо наличие:

• Кластера Openshift с подключенным и настроенным проектом ISTIO;

• Сервера БД;

• Серверов Nginx.

До установки приложений Engine Platform V Flow на площадке развёртывания должны быть установлены следующие инфраструктурные компоненты платформы:

• Сервис аутентификации;

• ФП Аудит;

• ФП Журналирование - для отправки логов;

• ФП Мониторинг - для отправки метрик мониторинга;

• ФП Сервис авторизации;

• БД PostgreSQL.

Установка#

Описание поставки#

На текущий момент разработка Engine Platform V Flow ведется в Sigma. Там же собираются докер образы и дистрибутив в template OpenShift.

Образы модулей выкладываются в релизный реестр — <registry.sigma.sbrf.ru/ci00636574/ci00642471_bpm> и доступны в домене Alpha через прокси репозиторий <registry.sigma.sbrf.ru/sigma/ci00636574/ci00642471_bpm>.

Для установки используются 2 модуля:

• sberflow-engine — основное приложение; Образ так же используется для отдельного экземпляра engine-replica, необходимого для репликации данных в БД StandIn.

• sberflow-engine-admin — портал для взаимодействия с основным приложением — для тестовых стендов возможно использование образа с nginx в OpenShift, в целевом варианте — статика включается с поставку дистрибутива и разворачивается на nginx стенда.

• Istio - каталог, который содержит конфигурационные файлы istio (опционально)

• ott_sidecar - каталог, который содержит конфигурационные файлы ОТТ sidecar (опционально) Также собирается дистрибутив с артефактами модулей и конфигурационными файлами для развертывания в OpenShift.

Дистрибутив выкладывается в Sigma в sbrf-nexus — https://sbrf-nexus.sigma.sbrf.ru/nexus/content/repositories/Nexus_PROD/Nexus_PROD/CI00642471_BPM/SBERFLOW-ENGINE/. И реплицируется в альфу, где доступен по следующей ссылке - https://sbrf-nexus.ca.sbrf.ru/nexus/content/repositories/Nexus_PROD/Nexus_PROD/CI00642471_BPM/SBERFLOW-ENGINE/.

Поставка Engine Platform V Flow 3 поколения

Для установки используются 2 модуля:

bpms-core-app — основное приложение; bpms-portal-app — портал для взаимодействия с основным приложением — статика включается с поставку дистрибутива и разворачивается на nginx стенда.

Дополнительно для использования функций тестирования устанавливается тестовый модуль bpms-testing-roles-module.war.

Дистрибутив выкладывается в Sigma в sbrf-nexus — https://sbrf-nexus.sigma.sbrf.ru/nexus/content/repositories/Nexus_PROD/Nexus_PROD/CI00642471_BPM/BPMS/. И реплицируется в альфу, где доступен по следующей ссылке - https://sbrf-nexus.ca.sbrf.ru/nexus/content/repositories/Nexus_PROD/Nexus_PROD/CI00642471_BPM/BPMS/.

Подготовка проекта Openshift (опционально)#

После получения проекта в ose его требуется настроить для работы с реестром и JOB install_eip

Интеграция с реестром для пуллинга образов (опционально)#

1. В проекте ose перейти в Workloads -> Secrets;

2. Добавить новый секрет с типом Image Pull Secret со следующими настройками:

   1. secret name — имя секрета в нижнем регистре. Рекомендуется формировать имя как - "ТУЗ"+"-pull";

   2. registry server address — для Sigma — registry.sigma.sbrf.ru (без https);

   3. username и password — имя и пароль ТУЗа с доступом в реестр, из под которого будут пуллиться образы в проект Openshift;

3. Добавить созданный секрет в основной сервис аккаунт:

   1. перейти в раздел User Management -> Service Account;

   2. провалиться в аккаунт default -> выбрать вкладку yaml;

   3. в разделе imagePullSecrets: добавить еще одну запись — name: <имя_созданного_image_pull_secret>.

Интеграция с Jenkins - JOB install_eip (опционально)#

1. Зайти в проект ose. перейти в раздел User Management -> Service Account;

2. Выбрать account jenkins;

3. В разделе secrets выбрать секрет jenkins-token провалиться в него и в разделе data скопировать значение поля token;

4. Передать данный токен администраторам проектной области jenkins к которой размещена JOB install_eip для того чтобы в проекте jenkins'а создать новый credentials с типом secret text;

5. ID рекомендуется указать равным названию проекта в ose — т.к. у каждого проекта уникальный токен в поле secret text вставить токен скопированный в п.3.;

6. Id созданного credentials (совпадает с названием namespace) нужно будет указать в конфигурационном файле JOB.

Подготовка БД PostgreSQL#

1. Подготовить КТС PostgreSQL с указанием компонентов:

   • Имя табличного пространства — engine;

   • Имя базы данных — bdengine;

   • Владелец БД — указать УЗ администратора (который будет работать с первичной настройкой/подготовкой базы и сопровождать ее);

   • ТУЗ АС — BPMS, BPMS_CORE_APP, BPMS_READONLY;

   • Имя схемы — engine_schema.

2. Если используется кластер, все команды должны выполняться только на master node;

3. Подключение к postgreSQL через pgadmin:

   • Запускаем ПО pgadmin (откроется вкладка в браузере) с запросом master пароля (нужно ввести и запомнить пароль т.к. будет запрашивать всегда при открытии pgadmin);

   • В разделе Servers выбираем Add New Server, далее во вкладке General указываем имя сервера (для отображения в списке серверов);

   • Открываем вкладку connection (указываем ip/dns name сервера БД в поле host);

   • В поле port указываем порт, который был получен после отработки заявки (обычно это 5432) ;

   • В поле Maintenance database указываем название базы bdengine;

   • В полях username/password указываем логин/пароль УЗ и выполняем подключение к базе;

   • Для выполнения переподключения к базе под другой УЗ к примеру ТУЗ, необходимо нажать правой кнопкой по серверу и выбрать Disconnect, далее зайти в properties и указать необходимый логин/пароль.

4. После получения КТС необходимо выполнить:

   • подключение к БД через pgadmin под УЗ Владелец БД с указанным портом в письме (обычно это порт 5432);

   • смена транспортного пароля для ТУЗ (пароль по умолчанию Supertransport$123) alter user "ТУЗ" with password 'password';

     • пароль должен состоять из 16 символов включая спецсимволы;

   • выполняем команду set role as_admin;

   • далее необходимо нажать правой кнопкой мыши по БД (bdengine) и выбрать Query Tool;

   • указываем использование схемы по умолчанию командой alter role "BPMS" in database bdengine set search_path to engine_schema;

   • выдаем привилегии для ТУЗ командой Grant ALL on schema engine_schema to "BPMS";

   • подключиться к базе под УЗ ТУЗ (в pgadmin) и выполнить команду set role as_admin;

5. Проблемы с которыми приходилось сталкиваться:

   • Баг при выдаче КТС с владельцем группы db_admin (должна быть as_admin), необходимо оформлять ЗНО на группу "SberInfra УБД Администрирование СУБД PostgreSQL";

   • Если схема не выбрана, указать схему для сессии командой SET search_path TO schema_name; P.s. посмотреть можно через pgadmin, для этого нажимаем правой кнопкой мыши по базе bdengine, выбираем properties и смотрим поле owner (должен быть as_admin).

6. Дополнительные команды:

   1. Перечислить список схем:

      select schema_name from information_schema.schemata
   

   2. Просмотр привилегий:

      SELECT n.nspname AS "Name",
       pg_catalog.pg_get_userbyid(n.nspowner) AS "Owner",
   
        pg_catalog.array_to_string(n.nspacl, E' + ') AS "Access privileges",
   
        pg_catalog.obj_description(n.oid, 'pg_namespace') AS "Description"
   
      FROM pg_catalog.pg_namespace n
   
      WHERE n.nspname !~ '^pg_' AND n.nspname <> 'information_schema'
   
      ORDER BY 1;
   

Подготовка в установке через Install_EIP (опционально)#

Название модуля (subsystem) для установки через install_eip - PPRB_BPM_OpenShift.

Все настройки стендов хранятся в репозитории gitlab.

Есть три типа репозиториев, содержащих скрипты и конфигурации:

1. Тестовая ветка (DEV)

   Данный репозиторий предназначен исключительно для отладки перед переносом в целевой репозиторий. Для получения доступа к репозиторию и JOB необходимо создать заявку в https://jira.ca.sbrf.ru/projects/OYEKSISK/summary. Репозиторий настроек подсистемы и стендов — <https://sbt-gitlab.delta.sbrf.ru/PPRB/Install_EIP_configs_DEV.git branch = master>. Файл конфигурации — configuration.xml URL JOB — https://sbt-jenkins.delta.sbrf.ru/jenkins/job/PPRB_DevOps/job/Install_EIP/job/Install_EIP_2_cli/.

2. Целевая ветка (СТ ИФТ)

   Ветка для настройки Pipeline в DPM и прохождения вплоть до ИФТ. Затем администраторы ПСИ сливают эту ветку с веткой ПСИ. Далее все нижеописанные шаги корректируются вручную администраторами ПСИ. Доступ к JOB не выдается, запуск только через DPM. Доступ к репозиториям есть у администраторов стендов. Репозиторий скриптов — <https://sbrf-bitbucket.ca.sbrf.ru/scm/pprbeip/install_eip.git branch = DEV>. Репозиторий настроек подсистемы и стендов — <https://sbt-gitlab.ca.sbrf.ru/PPRB/Install_EIP_Configs_CDL branch = master>. Файл конфигурации — configuration.xml URL JOB — https://sbt-qa-jenkins.delta.sbrf.ru/pprb/job/OAABS/job/PPRB_EIP/job/Install_EIP/.

3. ПСИ/Пром ветка

   Ветка управляется администраторами ПСИ/Пром вручную.

Для первоначальной установки модуля в ose через job install_eip требуется внести настройки в репозиторий необходимого стенда.

Для этого нужно воспользоваться инструкцией — https://confluence.ca.sbrf.ru/pages/viewpage.action?pageId=2524971498 (Выполнить пункты 1-14, с остальными пунктами ознакомиться)

Настройка конфигурационных параметров#

Конфигурирование системы осуществляется через файл application.yml.

Файл содержит следующие обязательные конфигурационные блоки:

• Блок management — содержит настройки Spring Actuator, необходимые для получения метрик для модуля «Контроль инцидентов»;

• Блок logging — в блоке logging необходимо задать требуемый уровень логирования в системе;

• Блок spring — Настройка spring части системы;

• Блок auth — Содержит настройки связанные с аутентификацией пользователя в dev режиме;

• Блок database — Настройка подключений к БД;

• Блок dynamic-invoker — Включение/выключение механизма bootstrap class loader;

• Блок engine — Содержит опции для настройки торттлинга, точек персистирования, настройка размеров пула запуска процессов, настройки кэширования, настройки очистки истории, окна идемпотентности и настройки адаптивного retry;

• Блок flyway — Настройки Flyway миграции;

• Блок htm — Настройка подключения к стенду HTM;

• Блок standin — Вкл/выкл функционального StandIn;

• Блок available-zones — Настройки списка зон, в которых работает приложение;

• Блок grafana-config — Настройка подключения к grafana;

• Блок api — Настройки для работы системного и пользовательского API.

Пример файла application.yml:

management:
  endpoints:
    enabled-by-default: false
    web.exposure.include: health,metrics,threaddump,prometheus
  endpoint:
    metrics.enabled: true
    health:
      enabled: true
      show-details: always
    threaddump.enabled: true
    prometheus.enabled: true
logging:
  level:
    ROOT: ERROR
  port: 8080
spring:
  flyway:
    enabled: false
  main:
    allow-bean-definition-overriding: true
  cloud:
    config:
      enabled: false
auth:
  refreshToken:
    path: '/auth/refresh'
  token:
    path: '/auth/token'
    accessLifetime: 3000
    refreshLifetime: 86400
database:
  master:
    driverClassName: org.postgresql.Driver
    idleTimeout: 100
    jdbcUrl: jdbc:postgresql://tkled-pprb00112.vm.esrt.cloud.sbrf.ru:5433/bdengine
    maximumPoolSize: 100
    minimumIdle: 100
    schemaOwner: engine_schema
    username: BPMS
  standin:
    driverClassName: org.postgresql.Driver
    idleTimeout: 100
    jdbcUrl: jdbc:postgresql://tkled-pprb00112.vm.esrt.cloud.sbrf.ru:5433/bdengine
    maximumPoolSize: 100
    minimumIdle: 100
    schemaOwner: engine_schema
    username: BPMS
dynamic-invoker:
  useBootstrap: false
engine:
  activityAsyncExecutorMinThreadPoolSize: 1
  apiMessageLogInterval: 3600000
  asyncExecutorActivate: true
  asyncExecutorResetExpiredJobsInterval: 10000
  asyncExecutorThreadPoolSize: 10
  asyncExecutorTimerLockTimeInMillis: 1200000
  asyncJobAcquireWaitTimeInMillis: 10000
  availableTaskCountCacheMaxSize: 1000
  availableTaskCountCacheTimeToLiveInMilliseconds: 60000
  cciIndexesEnabled: true
  classLoaderScannerIntervalInMilliseconds: 30000
  cleaner:
    batchSize: 1000
    byteArrayCleanEnable: true
    cron: '0 2 * * * SAT'
    depth: 30
    enable: false
    mode: 'BPMSHISTORICIDENTITYLINKENTITYIMPL,BPMSHISTORICEXTRAATTRIBUTEENTITYIMPL,BPMSIDENTITYLINKENTITYIMPL,BPMSVARIABLEINSTANCEENTITYIMPL,BPMSEXTRAATTRIBUTEENTITYIMPL,BPMSHISTORICVARIABLEINSTANCEENTITYIMPL,BPMSHISTORICACTIVITYINSTANCEENTITYIMPL,BPMSEVENTSUBSCRIPTIONENTITYIMPL,HISTORICRETRYPOLICYENTITYIMPL,BPMSEXECUTIONENTITYIMPL,BPMSJOBENTITYIMPL,BPMSTIMERJOBENTITYIMPL,MULTIINSTANCECOUNTERIMPL,BPMSTASKENTITYIMPL,RETRYPOLICYJOBENTITYIMPL,BPMSHISTORICTASKINSTANCEENTITYIMPL,BPMSBYTEARRAYENTITYIMPL,BPMSHISTORICDETAILENTITYIMPL,BPMSHISTORICPROCESSINSTANCEENTITYIMPL'
  cron:
    noApiWaitTime: '0 0/1 * * * ?'
    noResourcesWaitTime: '0 0/1 * * * ?'
  databaseSchemaUpdate: false
  executeJobThreadPoolThrottlingMark: 80
  executeNewJobThreadPoolThrottlingMark: 50
  executeNewProcessThreadPoolThrottlingMark: 50
  executeProcessMinThreadPoolSize: 1
  executeProcessThreadPoolSize: 135
  executeProcessThreadPoolThrottlingMark: 80
  executionMode: 'STICKY'
  namepsaceURL: ''
  htm:
    enabled: true
  idempotenceMaxRetryCount: 5
  insetJobLockExpirationTime: 1200000
  jdbcPoolThrottlingMark: 80
  jdbcPoolThrottlingMarkForNewProcesses: 50
  jobLockExpirationTime: 1200000
  maxDepthForScanner: 10
  maxAsyncJobsDuePerAcquisition: 5
  mbpEnabled: true
  mmtTaskEnabled: true
  noApi:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  noResources:
    maximumTime: 'PT180S'
    waitTime: 'PT60S'
  persistPoints: 'StartEvent,UserTask,IntermediateCatchEvent,ReceiveTask,ServiceTask'
  processOwnerRestrictionEnabled: false
  resetExpiredJobsInterval: 10000
  resetExpiredJobsPageSize: 1000
  resetExpiredRetryPolicyJobsInterval: 10000
  resetExpiredInsertLockJobsInterval: 10000
  retryPolicyJobInterval: 10000
  springAsyncExecutorPoolQueueCapacity: 15
  springAsyncExecutorPoolSize: 10
  statelessAsyncJobAcquireWaitTimeInMillis: 10000
  statelessResetExpiredJobsInterval: 10000
  throttlingEnable: false
  throttlingStateIntervalInMilliseconds: 5000
  timerJobAcquireWaitTimeInMillis: 10000
  waitScannerTimeAfterNoWait: 200
  waitForProcessIdempotenceStarted: 200
flyway:
  master:
    readonlyUser: BPMS_READONLY
  migrationEnabled: true
  standin:
    readonlyUser: BPMS_READONLY
htm:
  app:
    url: 'http://htm-portal-test-ci00636574-edevgen-utm.apps.dev-gen.sigma.sbrf.ru/htm-portal'
  engineBalancerHost: 'http://sberflow-engine-dev-ci00636574-edevgen-ts-bpm-dev.apps.dev-gen.sigma.sbrf.ru'
bridge:
  tech:
    user:
      login: 'TechUser'
portal:
  businessFamilyContext:
    - uri: ''
      name: ''
  sudirBaseUri: ''
  taskListURL: ''
 zones:
    - name: ''
      isTaskListEnable: false
standin:
  func:
    enabled: false
    retryBackOffTime: 5000
    retryCount: 18
    retryEnabled: false
  platform:
    enabled: false
    isStandIn: false
    standInPollSchedule: 30000
available-zones:
  zones:
    - default:
        code: 'DEFAULT_ZONE'
        name: 'DEFAULT'
        url: http://sberflow-engine-dev-ci00636574-edevgen-ts-bpm-dev.apps.dev-gen.sigma.sbrf.ru
grafana-config:
  root: 'https://tkles-pprb00078.vm.esrt.cloud.sbrf.ru'
  orgId: 1

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

Настройка os_yaml_dirs.conf (опционально)#

На текущий момент все template OpenShift расположены в дистрибутиве в каталоге config/openshift, его и требуется указать в файле os_yaml_dirs.conf:

/config/openshift
# при поставке с istio и ОТТ нужно добавить каталог с конфигурационными файлами istio
/config/openshift/Istio
/config/openshift/ott_sidecar

Подготовка секретов#

Вся чувствительная информация — пароли, сертификаты, токены в OpenShift хранится в секретах.

Для работы Engine Platform V Flow необходимо создать следующие секреты:

• engine-secret — секрет для передачи java опций с паролем от БД, и другой чувствительной информацией в Engine Platform V Flow;

• envoy-secret — (опционально) секрет с сертификатами для работы envoy ММТ-прокси;

• fluent-bit-sct — (опционально) секрет с сертификатами для работы sidecar fluent-bit в ММТ-прокси для отправки сообщений брокерам логгера ;

• ingressgateway-certs - (опционально) секрет с сертификатами istio ingress (серверные сертификаты приложения);

• ingressgateway-ca-certs - (опционально) секрет с сертификатами с доверенной цепочкой сертификатов для istio ingress;

• egressgateway-certs - (опционально) секрет с сертификатами istio egress (клиентские сертификаты приложения);

• egressgateway-ca-certs - (опционально) секрет с сертификатами с доверенной цепочкой сертификатов для istio egress;

• sberflow-engine-ott-certs - секрет с сертификатами ОТТ;

• sberflow-engine-ott-passwords - секрет с паролями для сертификатов ОТТ;

• engine-certs-bd - секрет с клиентскими сертификатами для работы с БД по SSL;

• sberflow-engine-events-keystore-secret - секрет с клиентскими сертификатами для работы с kafka бизнес-мониторинга;

• sberflow-engine-events-keystore-passwords-secret - секрет с паролями к jks для работы с kafka бизнес-мониторинга;

• engine-appjounalsettings-secret - (опционально) секрет с настройками функционального StandIn;

• engine-appjounalsettings-keystore-secret - (опционально) секрет при подключении к кафкам прикладного журнала по ssl.

Алгоритм подготовки секретов ose которые будут устанавливаться job install_eip подробно описан в инструкции.

Вкратце нужно:

• Подготовить шаблон секрета;

• Вставить в него Java опцию/сертификаты предварительно закодировать в base64;

• Завольтовать полученный конфигурационный файл секрета JOB ANSIBLE_VAULT_file;

• Положить завольтованный секрет в репозиторий стенда в каталог openshift/secret.

Закодировать в base64 можно следующим образом (на win можно воспользоваться git bash):

• Создаем файл с содержимым которое нужно закодировать в base64, например password.txt;

• base64.exe --wrap=0 password.txt > password.base64;

• После выполнения команды в файле password.base64 будет закодированный пароль.

Новый механизм автогенерации секретов в install_eip (опционально)

В проекте стенда в каталоге openshift/certs:

1. Создать каталог — его имя будет именем секрета

2. В каталог секрета добавить один или несколько файлов, которые станут содержимым секрета, т.о. что имя файла станет именем ключа, а содержимое — значением

3. Предварительно каждый файл необходимо завольтовать с помощью JOB ANSIBLE_VAULT_file

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

1. При создании текстового файла win всегда добавляет расширение .txt которое попадает в имя ключа — необходимо дополнительно переименовывать файл

2. При вольтовании сертификата с расширением .crt JOB настройки системы безопасности блокируют вложение письма и завольтованный сертификат не приходит на почту. Решение — изменение расширения на txt до вольтования и обратно на crt после

Пример механизма для секрета типа db-secret (c jvm опциями):

1. Переходим в каталог <openshift/certs>

2. Создаем каталог db-secret

3. Создаем файл extra_java_opts

4. А файл extra_java_opts добавляем текст и опциями jvm — -Dspring.datasource.password=<Подставить ПАРОЛЬ_БД> -Dclipas.secret-key=<Подставить secret-key SPAS>

5. Вольтуем файл JOB и размещаем его в <openshift/certs/db-secret>

6. При установке создастся нужный секрет в openshift проекте

Пример механизма для секрета типа envoy-secret (c сертификатами):

1. Переходим в каталог openshift/certs

2. Создаем каталог envoy-secret

3. В созданный каталог кладем предварительно завольтованные сертификаты:

   1. envoy.crt

   2. envoy.key

   3. root-ca.pem

4. При установке создастся нужный секрет в openshift проекте

Секреты не являются частью поставки дистрибутива, поэтому их необходимо подготовить заранее по следующим шаблонам:

Шаблон секрета engine-secret#

apiVersion: v1
data:
  extra_java_opts: <Подставить необходимые java_opts с паролем закодированные в base64>*
kind: Secret
metadata:
  labels:
    app: sberflow-engine
  name: engine-secret
type: Opaque

• На текущий момент необходимые java_opts =  -Ddatabase.master.password=<Подставить ПАРОЛЬ_БД> -Ddatabase.standin.password=<Подставить ПАРОЛЬ_БД> -Dflyway.master.ownerPassword=<Подставить ПАРОЛЬ_БД> -Dflyway.standin.ownerPassword=<Подставить ПАРОЛЬ_БД> -Dauth.token.secret=<Подставить secret> -Dclipas.secret-key=<Подставить clipas.secret-key> -Dott.trust.store.pwd=<подставить пароль> -Dott.certstore.pwd=<подставить пароль> -Dott.certstore.key.pwd=<подставить пароль>

Шаблон секрета envoy-secret#

Добавлять при установке mmt-proxy envoy. В качестве сертификатов - используются клиентские сертификаты приложения

kind: Secret
apiVersion: v1
metadata:
  name: envoy-secret
data:
  envoy.crt: >-
    <Подставить сертификат в base64>
  envoy.key: >-
    <Подставить сертификат в base64>
  root-ca.pem: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон fluent-bit-sct#

Добавлять при установке mmt-proxy envoy. В качестве сертификатов - используются клиентские сертификаты приложения.

kind: Secret
apiVersion: v1
metadata:
  name: fluent-bit-sct
data:
  envoy.crt: >-
    <Подставить сертификат в base64>
  envoy.key: >-
    <Подставить сертификат в base64>
  root-ca.pem: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон ingressgateway-certs#

Добавлять при установке с istio. Указать серверный сертификат и ключ.

kind: Secret
apiVersion: v1
metadata:
  name: ingressgateway-certs
data:
  tls.crt: >-
    <Подставить сертификат в base64>
  tls.key: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон ingressgateway-ca-certs#

Добавлять при установке с istio. Указать цепочку доверенных сертификатов.

kind: Secret
apiVersion: v1
metadata:
  name: ingressgateway-ca-certs
data:
  CA.pem: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон egressgateway-certs#

Добавлять при установке с istio. Указать клиентский сертификат и ключ.

kind: Secret
apiVersion: v1
metadata:
  name: egressgateway-certs
data:
  tls.crt: >-
    <Подставить сертификат в base64>
  tls.key: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон egressgateway-ca-certs#

Добавлять при установке с istio. Указать цепочку доверенных сертификатов.

kind: Secret
apiVersion: v1
metadata:
  name: egressgateway-ca-certs
data:
  CA.pem: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон sberflow-engine-ott-certs#

Указать сертификаты ОТТ в формате p12. Имя truststore ОТТ для стенда может быть разное - требуется указать актуальное; дополнительно указывается в конфигурационных файлах.

kind: Secret
apiVersion: v1
metadata:
  name: sberflow-engine-ott-certs
data:
  <name_ott_public.p12>: >-
    <Подставить сертификат в base64>
  sberflow-engine.p12: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон sberflow-engine-ott-passwords#

Пароли для keystore ОТТ.

kind: Secret
apiVersion: v1
metadata:
  name: sberflow-engine-ott-passwords
data:
  OTT_CERTSTORE_PRIVATE_KEY_PWD: <Подставить пароль в base64>
  OTT_CERTSTORE_PWD: <Подставить пароль в base64>
  OTT_TRUST_STORE_PWD: <Подставить пароль в base64>
type: Opaque

Шаблон engine-certs-bd#

Можно использовать клиентский сертификат, конвертированный в pk8.

kind: Secret
apiVersion: v1
metadata:
  name: engine-certs-bd
data:
  tls.crt: >-
    <Подставить сертификат в base64>
  tls.key: >-
    <Подставить сертификат в base64>
  tls.pk8: >-
    <Подставить сертификат в base64>
  CA.pem: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон sberflow-engine-events-keystore-secret#

Можно использовать клиентский сертификат, конвертированный в jks

kind: Secret
apiVersion: v1
metadata:
  name: sberflow-engine-events-keystore-secret
data:
  keystore.jks: >-
    <Подставить сертификат в base64>
  trusted-keystore.jks: >-
    <Подставить сертификат в base64>
type: Opaque

Шаблон sberflow-engine-events-keystore-passwords-secret#

kind: Secret
apiVersion: v1
metadata:
  name: sberflow-engine-events-keystore-passwords-secret
data:
  PROCESS_EVENT_KEY_PASS: <Подставить пароль в base64>
  PROCESS_EVENT_KEY_STORE_PASS: <Подставить пароль в base64>
  PROCESS_EVENT_TRUST_KEY_STORE_PASS: <Подставить пароль в base64>
type: Opaque

Шаблон секрета engine-appjounalsettings-secret#

kind: Secret
apiVersion: v1
metadata:
  name: engine-appjounalsettings-secret
stringData:
  appJournal.yml:  <Подставить необходимые настройки StandIn>

Шаблон секрета при подключении к кафкам прикладного журнала по ssl#

kind: Secret
apiVersion: v1
metadata:
  name: engine-appjounalsettings-keystore-secret
data:
  server.keystore.jks: <jks в base64>
  trust.jks: <jks в base64>

Получение сертификатов (опционально)#

• Шаги по получению сертификатов описаны в разделах по интеграции с платформенными сервисами.

Настройка установки портала на общий nginx#

1. Архив со статикой портала включен в дистрибутив поставки и располагается по пути /other/nginx/sberflow-engine-admin-static-{version}.zip;

2. Конфигурация locations nginx включена в дистрибутив поставки и располагается по пути /other/nginx/sberflow-engine-admin.conf.

В action.xml указать стандартный action deploy_nginx_default.

Также необходимо указать параметры для nginx'а в файле system_nginx_default.conf.

nginx_path: "" # указать место расположение статики на nginx
nginx_conf_path: "" # указать место расположение пользовательских конфигурационных файлов на nginx
location_sberflow_engine_admin: /sberflow_engine_admin
alias_sberflow_engine_admin: # указать место расположение статики на nginx
 
sberflow_engine_admin_url: #route на backend
 
# при использовании istio
proxy_ssl_name: # route на backend без указания протокола
proxy_ssl_server_name: 'on' # обязательно в кавычках

Загрузка ролевой модели и тех юзеров#

Файлы ролевой модели и данные ТУЗ содержаться в дистрибутиве.

В случае установки через Install_EIP, в action.xml необходимо указать стандартный action configure_spas, в противном случае загрузка осуществляется вручную.

Установка sberflow-engine-admin#

При установке в ose — поднимается Pod с nginx и статикой; Портал доступен по route — sberflow-engine-admin-$stand_id-$namespace.apps.$openshift_cluster/sberflow-engine-admin.

При старте портала в переменной SBERFLOWENGINE_URL указать адрес backend (начиная с версии 5.0.8 URL включает в себя протокол (например, http://)).

В целевом варианте установка портала производится на общий nginx стенда.

Для игнорирования установки портала в ose в репозиторий стенда в файле os_ignore.conf нужно указать имя template OpenShift sberflow-engine-admin-template.yaml.

Наименование location — sberflow-engine-admin, т.е. при работе через СУДИР ссылка будет вида SUDIR/react/sberflow-engine-admin.

пример nginx.conf

worker_processes 1;
 
events { worker_connections 1024; }
 
http {
    sendfile on;
    include    /etc/nginx/mime.types;
 
    server {
        listen 0.0.0.0:8080;
        port_in_redirect off;
 
        location / {
            root    /usr/share/nginx/html/;
            index   index.html;
            try_files $uri $uri/ /index.html;
        }
 
        location /sberflow-engine-admin {
            alias            /usr/share/nginx/html/sberflow-engine-admin/;
            try_files $uri $uri/ /sberflow-engine-admin/index.html;
        }
 
        location /sberflow-engine-admin/v4/ {
            proxy_pass         http://$SBERFLOWENGINE_URL/v4/;
        }
 
        location /sberflow-engine-admin/settings/ {
            proxy_pass         http://$SBERFLOWENGINE_URL/settings/;
        }
 
        location /sberflow-engine-admin/auth/ {
            proxy_pass         http://$SBERFLOWENGINE_URL/auth/;
        }
    }
}

Установка sberflow-engine#

Статус работы приложения можно посмотреть по route — http://sberflow-engine-$stand_id-$namespace.apps.$openshift_cluster/actuator/health.

Установка engine-replica#

Статус работы приложения можно посмотреть по route — http://engine-replica$stand_id-$namespace.apps.$openshift_cluster/actuator/health.

Установка engine-replica идентична установке sberflow-engine за исключением значения Java опции -Dspring.profiles.active которая должна быть равна replication

Настройка режима авторизации пользователей#

Авторизация и аутентификация может осуществляться в разных режимах в зависимости от настроек указанных при конфигурировании приложения.

Доступные режимы:

• dev — используется в тех случаях когда информация о пользователях хранится в файле users.yml (используется на тестовых средах в качестве заглушки для систем авторизации/аутентификации);

• СУДИР + SPAS — аутентификация производится на стороне СУДИР, список пользователей и ролевая модель хранится в SPAS;

• iamproxy + SPAS — аутентификация производится через сервер iamproxy, список пользователей и ролевая модель хранится в SPAS;

• keycloak — не используется на текущий момент.

Информация о внешних сервисах:

• СУДИР;

• SPAS.

Режим dev#

Информация об учетных записях пользователей хранится в файле users.yml, расположенном в директории проекта.

В случае успешной аутентификации и авторизации пользователя, на стороне сервера будет сгенерирован JWT токен. JWT токен — содержит три блока, разделенных точками: заголовок(header), набор полей (payload) и сигнатуру (signature).

Токены генерируются на сервере основываясь на секретном ключе и payload. Токен в итоге хранится на стороне клиента и используется при необходимости авторизации какого-либо запроса.

Для настройки dev режима авторизации необходимо выполнить следующие шаги:

1. Создать файл users.yml и наполнить его учетными данными пользователей;

2. В java опциях проекта:

   1. активировать профиль dev и добавить путь к файлу с пользователями;

   2. задать параметры генерации токена.

Формат данных учетной записи пользователя (файл users.yml) приведен ниже:

    login:          "sbt-test"
    name:           "sbt-test"
    lastName:       "sbt-test"
    middleName:     "sbt-test"
    rang:           "manager"
    email:          "sbt-test@sberbank.ru"
    depNameEasup:   "test"
    depCodeEasup:   "test"
    orgCode:        "test"
    tabNum:         "test"
    departmentName: "test"
    lockStatus:     false
    roles:
      - id:           333
        code:         "bpms-core-app_BpmsAdminMonitoring"
        name:         "Администратор мониторинга исполнения процессов"
        description:  "Видит интерфейс Контроль исполнения, список моделей процессов, может просматривать список экземпляров"
        archive:      false

В java опциях проекта необходимо активировать профиль dev и добавить путь к файлу с пользователями:

-DuserPath=/home/jboss/config/users.yaml
-Dspring.profiles.active=dev,anonymousDeploy

Параметры для генерации токена определяются в конфигурации приложения (файл application.yml):

1. путь к токену на стороне клиента — token.path;

2. время жизни токена — token.accessLifetime;

3. время жизни refresh токена — token.refreshLifetime;

4. ключ шифрования — token.secret;

5. путь к refresh токену на стороне клиента — refreshToken.path.

auth:
  refreshToken:
    path: '/auth/refresh'
  token:
    path: '/auth/token'
    accessLifetime: 300
    refreshLifetime: 86400
    secret: 

Режим СУДИР/iamproxy + SPAS#

Список пользователей загружается из внешних систем в SPAS.

Ролевая модель загружается в SPAS в формате xml в момент разворачивания системы.

В режиме СУДИР + SPAS аутентификация производится на стороне СУДИР. Для аутентификации используется внутренняя БД СУДИР, синхронизируемая со SPAS.

В случае успешной аутентификации СУДИР сохраняет пользовательскую сессии у себя в cookies и проверяет ее валидность при каждом запросе из стороннего приложения. Все запросы требующие аутентификации пользователя должны проходить через СУДИР. Если пользователь аутентифицирован, то СУДИР пробрасывает запрос дальше обогащая его заголовком, содержащим аутентификационную информацию (заголовок iv-user содержит логин пользователя).

Для прохождения авторизации и назначения ролей пользователю, приложение получает логин пользователя из сгенерированного СУДИРом заголовка и посылает запрос в SPAS на выдачу прав.

В SPAS хранится состав полномочий для ролей, также SPAS предоставляет механизм загрузки ролей в СУДИР/iamproxy. Подробнее об интеграции со SPAS.

Пользователи и их роли хранятся и назначаются в СУДИР/iamproxy. Подробнее об интеграции с СУДИР/iamproxy.

Ролевая модель загружается в SPAS в формате xml в момент разворачивания системы.

Пример roleModel.xml:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<module xmlns="http://AccessSystem/namespace" moduleVersion="${project.version}" name="htm-app" roleModelVersion="20201029.1726">
    <nodes>
        <node type="entity" display-name="Группа для TaskList">
            <form id="htm_access" display-name="TaskList/access"/>
        </node>
    </nodes>
    <roles>
        <role code="FreeFlowUser" name="Freeflow Исполнитель"
              description="Имеет доступ к назначенным на него задачам и задачам из общей очереди. Доступные интерфейсы: Мои задачи, Доступные задачи">
            <permission-ref id="htm_access"/>
        </role>
    </roles>
</module>

В настройках проекта необходимо указать:

• Профиль аутентификации:

  • Для СУДИР не указывается (пустой);

  • Для аутентификации через iamproxy — Dspring.profiles.active=iamproxy.

• Путь к SPAS серверу:

• Ключ доступа к данным SPAS — secret_key;

• Настройки аутентификации через СУДИР (для iamproxy не указываются).

-Dspring.profiles.active=anonymousDeploy

-Dclipas.spas-server-url=https//000.000.00.00:0000/spas/rest
-Dclipas.secret_key=1111

-Dclipas.security.sudirAuthenticationEnable=true
-Dclipas.security.token-Authentication-Enable=false
-Dclipas.security.user-password-authentication-Enable=true

Аутентификация в режиме iamproxy + SPAS происходит аналогично режиму СУДИР + SPAS.

Если пользователь успешно аутентифицирован, то iamproxy сервер пробрасывает запрос дальше обогащая его заголовком в виде JWT токена.

Интеграция со SPAS#

Для интеграции со SPAS необходимо:

• Включить в секрет engine-secret jvm-опцию -Dclipas.secret-key=<секретный ключ сервиса SPAS>;

• Задать значение переменной в application.yml SPAS_SERVER_URL=<адрес rest сервиса SPAS на который будут отправляться запросы>.

####### КОНФИГУРАЦИЯ SPAS
clipas:
  spas-server-url: ${SPAS_SERVER_URL}

Адреса rest SPAS и secret-key обычно известны администраторам стенда, при указании значения есть особенности:

• адрес сервиса не совпадает с URL SPAS и часто представлен в формате https://xx.xx.xx.xx:8443/spas/rest;

• адрес сервиса необходимо указывать с использованием fqdn (доменного имени), т.к. запросы в него уходят через egress istio. Для этого ip нужно поменять на доменное имя wildfly, на котором располагается сервис SPAS на стенде.

Интеграция с СУДИР и IamProxy#

Для корректного выхода из приложения из приложения (портала) при работе через СУДИР в backend при старте необходимо задать значение переменной в application.yml с URL СУДИР/IamProxy — LOGOUT_URL.

####### СУДИР/IamProxy
auth:
  logoutUrl: ${LOGOUT_URL}

Параметры OpenShift манифестов#

По умолчанию, при развертывании используются настройки описанные в OpenShift манифестах. Данные параметры можно переопределить вручную на стенде при установке.

Переменные sberflow-engine#

INCLUDE_ENGINE_PARAMETERS

Переменные engine-replica#

INCLUDE_ENGINE_REPLICA_PARAMETERS

Переменные sberflow-engine-admin#

INCLUDE_ENGINE_ADMIN_PARAMETERS

Переменные mmt-proxy envoy#

INCLUDE_ENVOY_PARAMETERS

Переменные istio-ingress#

INCLUDE_INGRESS_PARAMETERS

Переменные istio-egress-ott#

INCLUDE_EGRESS_PARAMETERS

Переменные istio-ingress#

Генерация типовых конфигурационных файлов#

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

Шаблоны для https соединений:#

Шаблоны для https соединений располагаются в каталоге config/openshift/Istio/custom/egress-http:

• svc-external-http-custom.yml - шаблон для сервиса для переадресации запросов;

• vs-egress-http-custom.yml - шаблон для Virtual Service;

• se-egress-http-custom.yml - шаблон для Service Entry;

• dsr-egress-http-custom.yml - шаблон для Destination Rule.

И включают в себя следующие параметры:

При этом для работы с ПФ на стенде необходимо переопределить валидационные envoy фильтры и указать в них CN хостов, у которых должен быть доступ к Engine.

При использовании install_eip - в uniqueParams можно указать следующий блок:

  uniqueParams:
    # Integration https via egress
    svc-external-http-custom.yml:
      INTEGRATION_INNER_SERVICE:
        - some svc name
      INTEGRATION_INGRESS_HOST:
        - some fqdn host
      INTEGRATION_INGRESS_PORT:
        - some port
    vs-egress-http-custom.yml:
      INTEGRATION_INNER_SERVICE:
        - some svc name
      INTEGRATION_INGRESS_HOST:
        - some fqdn host
      INTEGRATION_INGRESS_PORT:
        - some port  
    se-egress-http-custom.yml:
      INTEGRATION_INNER_SERVICE:
        - some svc name
      INTEGRATION_INGRESS_HOST:
        - some fqdn host
      INTEGRATION_INGRESS_PORT:
        - some port
    dsr-egress-http-custom.yml:
      INTEGRATION_INNER_SERVICE:
        - some svc name
      INTEGRATION_INGRESS_HOST:
        - some fqdn host
      INTEGRATION_INGRESS_PORT:
        - some port  
 

Шаблоны для tcp соединений (Kafka)#

Конфигурационные файлы для соединений с plaintext и ssl протоколами различаются по структуре. Доступно 2 набора шаблонов: Шаблоны для подключения по plaintext располагаются в каталоге config/openshift/Istio/custom/egress-kafka

• egress-gw-tcp-kafka-custom.yml - шаблон для Gateway;

• egress-se-tcp-kafka-custom.yml - шаблон для Service Entry;

• egress-vs-tcp-kafka-custom.yml - шаблон для Service Entry;

Шаблоны для подключения по ssl располагаются в каталоге config/openshift/Istio/custom/egress-kafka-ssl

• egress-gw-tcp-kafka-ssl-custom.yml - шаблон для Gateway;

• egress-se-tcp-kafka-ssl-custom.yml - шаблон для Service Entry;

• egress-vs-tcp-kafka-ssl-custom.yml - шаблон для Service Entry;

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

Порты INTERNAL_KAFKA_PORT и KAFKA_PORT должны быть также описаны в сервисе Egress с именами tcp-<Порт>

При использовании install_eip - в uniqueParams можно указать следующий блок: При подключении по PLAINTEXT

uniqueParams:
  # Integration with kafka tcp
    egress-gw-tcp-kafka-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      INTERNAL_KAFKA_PORT:
        - some port
    
    egress-se-tcp-kafka-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      KAFKA_HOST_IP:
        - some ip
      APP_OUT_KAFKA_PORT:
        - some port
      KAFKA_PORT:
        - some port
    
    egress-vs-tcp-kafka-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      KAFKA_HOST_IP:
        - some ip
      APP_OUT_KAFKA_PORT:
        - some port
      INTERNAL_KAFKA_PORT:
        - some port
      KAFKA_PORT:
        - some port

При подключении по SSL

uniqueParams:
  # Integration with kafka tcp (SSL)
    egress-gw-tcp-kafka-ssl-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      INTERNAL_KAFKA_PORT:
        - some port
    
    egress-se-tcp-kafka-ssl-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      KAFKA_HOST_IP:
        - some ip
      APP_OUT_KAFKA_PORT:
        - some port
      KAFKA_PORT:
        - some port
    
    egress-vs-tcp-kafka-ssl-custom.yml:
      KAFKA_NAME:
        - some name
      KAFKA_HOST:
        - some host
      KAFKA_HOST_IP:
        - some ip
      APP_OUT_KAFKA_PORT:
        - some port
      INTERNAL_KAFKA_PORT:
        - some port
      KAFKA_PORT:
        - some port

Шаблоны для tcp соединений c базами данных:#

Располагаются в каталоге config/openshift/Istio/custom/egress-bd

• egress-gw-tcp-bd-custom.yml - шаблон для Gateway;

• egress-se-tcp-bd-custom.yml - шаблон для Entry;

• egress-vs-tcp-bd-custom.yml - шаблон для Virtual Service.

При использовании install_eip - в uniqueParams можно указать следующий блок:

uniqueParams:
  # Integration with db tcp wia istio egress
  egress-gw-tcp-bd-custom.yml:
    BD_NAME:
      - some name
    INTERNAL_POSTGRES_PORT:
      - some port
  egress-se-tcp-bd-custom.yml:
    BD_NAME:
      - some name
    POSTGRES_HOST:
      - some host
    POSTGRES_PORT:
      - some port
    APP_OUT_POSTGRES_PORT:
      - some port
  egress-vs-tcp-bd-custom.yml:
    BD_NAME:
      - some name
    POSTGRES_HOST:
      - some port
    APP_OUT_POSTGRES_PORT:
      - some port
    INTERNAL_POSTGRES_PORT:
      - some port
    POSTGRES_PORT:
      - some port

Поддержка RHSM 2.0.*#

C версии Monosolution 4.6 модули Platform V Flow Engine и TaskList используют RHSM 2.0 Для обновления требуется

• Переключить проект на control plain с поддержкой RHSM 2.0.*

• Изменить в конфигурации стенда параметры:

  • CONTROL_PANEL - указать новый control plain;

  • PROXY_IMAGE - указать ссылку на istio прокси envoy, По умолчанию для rhsm 2.0. используется - registry.redhat.io/openshift-service-mesh/proxyv2-rhel8@sha256:51d82b560e467ec59a3b6625b04c31b86df5b4c10070a351d547cb6cf3f26591;

  • Скорректировать переопределенный на стенде egress-svc - labels, selector, status port;

  • Скорректировать валидационные фильтры - selector, safe_regexp_match (пример в дистрибутиве);

  • При использовании конфигурационных файлов для внешних http интеграций, хранящихся на среде - задать порту в svc external (локальный сервис с коротким именем интеграции) имя порту (name: http-8080, при использовании порта 8080 для внутреннего порта Egress http интеграций);

• Дождаться переключения на новый control plain, отключить текущие pod istio Ingress/Egress;

• Развернуть новую версию, проверить работоспособность. При положительном исходе - удалить старые версии istio из проекта.

При переходе на rhsm 2 был осуществлён отказ от 2 Ingress и теперь запросы и на пользовательскую и на системную апи используют единый Ingress.

Обновление#

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

Для того чтобы выполнить обновление, необходимо:

1. выполнить установку дистрибутива новой версии через Install_EIP;

   • установка должна быть произведена для двух модулей: sberflow-engine, sberflow-egine-admin.

Процедура установки подробно описана в разделе Установка.

Принудительное удаление предыдущей версии не требуется.

Удаление#

При установке в OSE процедура удаления Platform V Flow Engine представляет собой удаление собранного nameSpace в OpenShift.

Проверка работоспособности#

Проверить работоспособность компонента можно с помощью команды health check:

http://<URL>/actuator/health

URL — должен содержать IP адрес и порт развернутого стенда Engine Platform V Flow.

В результате должно быть получено сообщение "status":"UP" и перечень данных о компонентах приложения и их актуальных статусах.

Откат#

Откат приложения на предыдущую версию выполняется посредством развертывания артефактов предыдущей версии.

Для того чтобы выполнить откат на предыдущую версию приложения:

1. Выполнить установку дистрибутива предыдущей версии через Install_EIP

   • Откат должен быть произведен для двух модулей: sberflow-engine, sberflow-egine-admin.

Процедура установки подробно описана в разделе Установка.

Часто встречающиеся проблемы и пути их устранения#

Не выявлено.

Чек-лист валидации установки#

После установки необходимо проверить:

1. Все запланированные при разворачивании pod поднялись успешно;

2. Логи не содержат сообщений об ошибке старта компонента;

3. Проверка health check проходит успешно.