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

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

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

Настройки безопасности окружения и перечень платформенных (дополнительных внешних) продуктов, используемых для установки, настройки и контроля в конечной информационной системе (далее — ИС), выбираются при разработке конечной ИС, исходя из характера обрабатываемой в ней информации и иных требований информационной безопасности (далее — ИБ), предъявляемых к ней.

Для установки, настройки, контроля и функционирования компонента Designer (BPMD) продукта Platform V Flow (BPM), далее по тексту – Designer Platform V Flow, необходима установка программного обеспечения сторонних правообладателей, перечисленного в данном разделе.

BPMD разворачивается в кластере системы контейнеризации Platform V.

Рекомендуемые минимальные настройки CPU и выделяемой памяти поставляются в дефолтных значениях файла описания переменных дистрибутива.

Требования к серверу БД рассчитываются индивидуально в зависимости от решаемых задач.

• Кластера системы контейнеризации Platform V с подключенным и настроенным проектом istio;

• Сервера БД;

• S3-совместимое хранилище;

• Серверов Nginx/компонента SynGX (SNGX) продукта Platform V Syngx (SNX) (опционально).

Для работы приложения на целевых стендах рекомендуется использование mTLS (версия 1.2) и OTT. В связи с этим возникает необходимость использовать соответствующие сертификаты:

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

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

Системное программное обеспечение#

Ниже представлены категории системного программного обеспечения (далее — ПО), которые обязательны или опциональны для установки, настройки, контроля и функционирования компонента. В каждой категории перечислены все поддерживаемые продукты сторонних правообладателей. Отдельно обозначены варианты, которые рекомендует АО «СберТех». (Маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена») Клиенту необходимо выбрать один из продуктов в каждой категории, исходя из условий использования конечной ИС.

Примечание:

*

• Да — категория ПО обязательна для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данной категории ПО).

• Нет — категория ПО необязательна для функционирования сервиса (это означает, что сервис может выполнять свои основные функции без установки данной категории ПО).

**

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

1

• Применимо для режима аутентификации и авторизации ("KeyCloak"). Подробнее о режимах аутентификации и авторизации в документе «Настройки режимов аутентификации и авторизации пользователей».

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

Для настройки, контроля и функционирования компонента реализована интеграция с программными продуктами, правообладателем которых является АО «СберТех» рекомендуется установка перечисленных ниже продуктов:

Примечание:

***

• Да — компонент или продукт необходим для функционирования сервиса (это означает, что сервис не может выполнять свои основные функции без установки данного компонента).

• Нет — необязательный для функционирования сервиса компонент или продукт (это означает, что сервис может выполнять свои основные функции без установки данного компонента).

**** Рекомендуется установка программного продукта, правообладателем которого является АО «СберТех», при этом не исключена возможность (допускается правообладателем) использования аналога других производителей. Аналоги, в отношении которых продукт успешно прошел испытания и подтвердил свою работоспособность, указаны в разделе «Системное программное обеспечение».

У компонента реализована интеграция со следующими компонентами из состава продукта:

Аппаратные требования#

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

Для установки компонента/продукта требуется следующая конфигурация аппаратного обеспечения:

Примечание:

*– минимальное количество ядер на namespace.

Браузеры#

Установка того или иного браузера из таблицы ниже обязательна только в случае использования UI компонента BPMD. Отдельно обозначены варианты, которые рекомендует АО «СберТех» (маркировка «Рекомендовано» в столбце «Продукт, функциональная совместимость с которым подтверждена»).

Примечание:

*****

Минимальная версия, на которой гарантируется работоспособность.

******

• Рекомендовано — рекомендованный правообладателем АО «СберТех» продукт.

• Опционально — альтернативный по отношению к рекомендованному правообладателем АО «СберТех» продукт.

Подготовка окружения#

Вне зависимости от выбора способа установки выполните шаги, описанные в разделах ниже.

При deploy в системе контейнеризации все токены, пароли, сертификаты и иная чувствительная информация хранится в одном из типов хранилищ:

• в секретах системы управления контейнерами;

• в файловой системе pod. Получены из внешней системы хранения секретов Secret Management System.

Способ передачи токенов, паролей, сертификатов управляется значением переменной bpmd.ose.secret.secman.enabled. Подробнее об интеграции с Secret Management System описано в разделе Интеграция с Secret Management System.

Требования к окружению#

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

• наличие платформы среды контейнеризации;

• наличие СУБД PostgreSQL (рекомендуется Platform V Pangolin, далее — PostgreSQL);

• наличие в инфраструктуре продукта Platform V Synapse Service Mesh (далее — Istio) (опционально);

• наличие серверов Nginx/SNGX (опционально);

• наличие в инфраструктуре продукта Platform V Backend компонента (OTTS) One-Time Password (OTP)/OTT (далее — OTT) (опционально).

Подключение namespace к Platform V Synapse Service Mesh#

Подключение namespace к компонентам продукта Platform V Synapse Service Mеsh (SSM) осуществляется в соответствии с документацией на необходимый компонент продукта.

Выпуск и подготовка сертификатов#

Правила наименования ingress routes#

Выпуск клиентского/серверного сертификата#

Методика выпуска клиентского и серверного сертификатов практически не отличается, за исключением принципа заполнения значений commonName и [alt_names] шаблона config.cnf, используемого для генерации *.csr запроса.

Сгенерируйте закрытый (приватный) ключ сертификата:

    $ genrsa -out tls.key 2048

Создайте файл config.cnf, на основе содержимого которого будет сформирован запрос на сертификат.

• Для серверного сертификата поле commonName и блок [alt_names] должны содержать FQDN сервера (ВМ) или route в случае, если сертификат выпускается для системы управления контейнерами.

• Если сертификат выпускается для нескольких серверов (ВМ) или route, то их FQDN необходимо также перечислить в [alt_names].

• Для клиентского сертификата поле commonName и блок [alt_names] в общем случае должны содержать понятное имя, однозначно идентифицирующее клиента.

• Другие данные в блоках [ req ], [ req_distinguished_name ] заполняются на усмотрение администраторов на основе используемых ВНД (внутренних нормативных документов).

Конфигурация ниже приведена в качестве возможного примера.

config.cnf:

    [ req ]
    default_bits = 2048
    distinguished_name = req_distinguished_name
    req_extensions = req_ext
    prompt = no
     
    [ req_distinguished_name ]
    countryName = 
    stateOrProvinceName = 
    localityName = 
    organizationName = 
    commonName = fqdn сервера
     
    [ req_ext ]
    subjectAltName = @alt_names
     
    [alt_names]
    DNS.1 = fqdn сервера 1
    DNS.2 = fqdn сервера 2
    ...
    DNS.n = fqdn сервера n

Сгенерируйте запрос на сертификат:

    $ req -out tls.csr -new -key tls.key -config config.cnf

Передайте сформированный *.csr файл в УЦ. От УЦ получите сертификаты в формате *.crt:

• личный (private),

• корневой (root),

• промежуточный (issuer) (опционально).

Объединение сертификатов в цепочку доверия#

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

Измените формат сертификатов на *.pem:

    $ mv root.crt CA.pem
    $ mv issuer.crt issuer.pem

Соберите цепочку:

    $ cat issuer.pem >> CA.pem

Преобразование ключа клиентского сертификата в *.pk8#

Для работы с БД PostgreSQL ключ клиентского сертификата с помощью OpenSSL преобразуйте в формат *.pk8:

    $ OpenSSL> pkcs8 -topk8 -inform PEM -outform DER -in tls.key -out tls.pk8 -nocrypt

Генерация JKS#

Генерация keystore.jks:

    openssl> pkcs12 -export -in tls.crt -inkey tls.key -out keystore.p12 -name keystore	 
    $ keytool -import -trustcacerts -alias root -file "root.crt" -keystore keystore.jks
    $ keytool -import -trustcacerts -alias issuer -file "issuer.crt" -keystore keystore.jks
    $ keytool -importkeystore -srckeystore keystore.p12 -srcstoretype pkcs12 -srcalias keystore -destkeystore keystore.jks -deststoretype jks -destalias keystore

Генерация truststore.jks:

    $ keytool -genkey -alias keystore -keyalg RSA -keysize 2048 -keystore truststore.jks
        What is your first and last name?:
        What is the name of your organizational unit?:
        What is the name of your organization?:
        What is the name of your City or Locality?:
        What is the name of your State or Province?:
        What is the two-letter country code for this unit?:
    $ keytool -import -trustcacerts -alias root -file "Test Root CA 2.crt" -keystore truststore.jks
    $ keytool -import -trustcacerts -alias issuing -file "Test Issuing CA 2.cer" -keystore truststore.jks

Установка серверного сертификата для Ingress (вариант ручной настройки)#

Выпустите серверный сертификат (см. п. «Выпуск клиентского/серверного сертификата»)

Соберите цепочку CA.pem (см. п. «Объединение сертификатов в цепочку доверия»)

Сконвертируйте CA.pem в base64:

    $ base64 -w 0 CA.pem > CA.pem.b64

Сконвертируйте приватный ключ в base64:

    $ base64 -w 0 tls.key > tls.key.b64

Сконвертируйте сертификат в base64:

    $ base64 -w 0 tls.crt > tls.crt.b64

Создайте в namespace в системе управления контейнерами secret ingressgateway-ca-certs, подставив созданные ранее CA.pem.b64:

    kind: Secret
    apiVersion: v1
    metadata:
      name: ingressgateway-ca-certs
    data:
      CA.pem: >-
        ...base64...
    type: Opaque

Создайте в namespace secret ingressgateway-certs, подставив созданные ранее tls.key.b64 и tls.crt.b64:

    kind: Secret
    apiVersion: v1
    metadata:
      name: ingressgateway-certs
    data:
      tls.crt: >-
        ...base64...
      tls.key: >-
        ...base64...
    type: Opaque

Установка серверного сертификата для Ingress (вариант при использовании deploy job компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT))#

Выпустите серверный сертификат (см. п. «Выпуск клиентского/серверного сертификата»)

Создайте хранилище с сертификатами:

Сначала в формате p12:

    openssl> pkcs12 -export -in tls.crt -inkey tls.key -out bpmd-ingress.p12 -name bpmd-ingress

Сконвертируйте в jks:

    $ keytool -importkeystore -srckeystore bpmd-ingress.p12 -srcstoretype pkcs12 -srcalias bpmd-ingress -destkeystore bpmd-ingress.jks -deststoretype jks -destalias bpmd-ingress

Добавьте root.crt и issuer.crt в jks:

    $ keytool -import -trustcacerts -alias root -file "root.crt" -keystore bpmd-ingress.jks
    $ keytool -import -trustcacerts -alias issuing -file "issuer.crt" -keystore bpmd-ingress.jks

Созданный файл bpmd-ingress.jks скопируйте в директорию с common-конфигурацией стенда в папку ansible/files/ssl/bpmd

Alias сертификата, ключа и jks прописываются в репозитории ФП стенда в файле custom_property.conf.yml:

    ingressKeyStoreFile: 'ansible/files/ssl/bpmd/bpmd-ingress.jks'
    ingressKeyStorePass: 'bpmd.ssl.ose.istio.keyStore.ingress.password'
    ingressRootCertAlias: 'root,issuing'
    ingressCertAlias: 'bpmd-ingress'
    ingressPrivateKeyAlias: 'bpmd-ingress'

ingressKeyStoreFile определяет путь до созданного файла bpmd-ingress.jks в репозитории common

ingressKeyStorePass определяет имя переменной, содержащей пароль от файла bpmd-ingress.jks, которая задается в файле _passwords.conf в common репозитории стенда

ingressRootCertAlias определяет имена alias корневого и промежуточных сертификатов, добавленных в файл bpmd-ingress.jks

ingressCertAlias определяет имя alias серверного сертификата, добавленного в файл bpmd-ingress.jks

ingressPrivateKeyAlias определяет имя alias приватного ключа серверного сертификата, добавленного в файл bpmd-ingress.jks

Установка клиентского сертификата для Egress (вариант при ручной настройке):#

Выпустите серверный сертификат (см. п. «Выпуск клиентского/серверного сертификата»)

Соберите цепочку CA.pem (см. п. «Объединение сертификатов в цепочку доверия»)

Сконвертируйте CA.pem в base64:

    $ base64 -w 0 CA.pem > CA.pem.b64

Сконвертируйте приватный ключ в base64:

    $ base64 -w 0 tls.key > tls.key.b64

Сконвертируйте сертификат в base64:

    $ base64 -w 0 tls.crt > tls.crt.b64

Создайте в namespace в системе управления контейнерами secret egressgateway-ca-certs, подставив созданные ранее CA.pem.b64:

    kind: Secret
    apiVersion: v1
    metadata:
      name: egressgateway-ca-certs
    data:
      CA.pem: >-
        ...base64...
    type: Opaque

Создайте в namespace secret egressgateway-certs, подставив созданные ранее tls.key.b64 и tls.crt.b64

    kind: Secret
    apiVersion: v1
    metadata:
      name: egressgateway-certs
    data:
      tls.crt: >-
        ...base64...
      tls.key: >-
        ...base64...
    type: Opaque

Установка клиентского сертификата для Egress (вариант при использовании job deploy CDJE):#

Выпустите клиентский сертификат (см. п. «Выпуск клиентского/серверного сертификата»)

Создайте хранилище с сертификатами:

Сначала в формате p.12:

    openssl> pkcs12 -export -in tls.crt -inkey tls.key -out bpmd-egress.p12 -name bpmd-egress

Сконвертируйте в jks:

    $ keytool -importkeystore -srckeystore bpmd-egress.p12 -srcstoretype pkcs12 -srcalias bpmd-egress -destkeystore bpmd-egress.jks -deststoretype jks -destalias bpmd-egress

Добавьте root.crt и issuer.crt в jks:

    $ keytool -import -trustcacerts -alias root -file "root.crt" -keystore bpmd-egress.jks
    $ keytool -import -trustcacerts -alias issuing -file "issuer.crt" -keystore bpmd-egress.jks

Созданный bpmd-bpmd-egress.jks скопируйте в директорию с common конфигурационными файлами стенда в папку ansible/files/ssl/bpmd

Alias сертификата, ключа и jks прописываются в репозитории ФП стенда в файле custom_property.conf.yml:

    egressKeyStoreFile: 'ansible/files/ssl/bpmd/bpmd-egress.jks'
    egressKeyStorePass: 'bpmd.ssl.ose.istio.keyStore.egress.password'
    egressRootCertAlias: 'root,issuing,rootold,issueoldalpha,issueolddelta'
    egressCertAlias: 'bpmd-egress'
    egressPrivateKeyAlias: 'bpmd-egress'

egressKeyStoreFile определяет путь до созданного bpmd-egress.jks в репозитории common

egressKeyStorePass определяет имя переменной, содержащей пароль от bpmd-egress.jks, которая задается в файле _passwords.conf в common репозитории стенда

egressRootCertAlias определяет имена alias корневого и промежуточных сертификатов, добавленных в bpmd-egress.jks

egressCertAlias определяет имя alias серверного сертификата, добавленного в bpmd-egress.jks

egressPrivateKeyAlias определяет имя alias приватного ключа серверного сертификата, добавленного в bpmd-egress.jks

Подключение к ОТТ#

Компонент One-Time Password (OTP) / OTTS (OTTS), далее OTTS, – система аутентификации и авторизации межсервисных взаимодействий. Platform V Flow BPMD может быть развернут как в варианте с sidecar OTT, так и без него. Для подключения к серверу ОТТ со стороны BPMD в качестве клиентской части используется sidecar OTT, работающий в pod граничных прокси IGEG (подробнее см. в документации Platform V Backend компонента One-Time Password (OTP)(OTT), Руководство разработчика > Подключение и конфигурирование).

Для настройки подключения:

1. Выпустите сертификат ОТТ:

• сгенерируйте ключевую пару в формате PKCS12 для выбранного module.id. Для примера возьмем module.id=sberflow-designer:

$ keytool -genkey -keyalg EC -sigalg SHA256withECDSA -keystore sberflow-designer.p12 -storetype PKCS12 -keysize 256 -dname "CN=sberflow-designer" -alias sberflow-designer

• сформируйте запрос на сертификат:

$ keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore sberflow-designer.p12 -storetype PKCS12 -alias sberflow-designer > sberflow-designer_cert_req.pem

• на основе сгенерированного sberflow-designer_cert_req.pem получите от администратора ОТТ:

  • готовый pem сертификат,

  • truststore,

  • сертификат выпускающего УЦ ОТТ.

2. Импортируйте сертификат УЦ ОТТ и сертификат модуля в keystore, созданный на предыдущем этапе:

$ keytool -import -keystore sberflow-designer.p12 -storetype PKCS12 -file SberbankPlatformCA_EC.pem -alias SberbankPlatformCA_EC

$ keytool -import -keystore sberflow-designer.p12 -storetype PKCS12 -file sberflow-designer.pem -alias sberflow-designer

Сгенерированное хранилище с импортированными сертификатами модуля и УЦ ОТТ расположите в одном из следующих мест:

• в репозитории общих параметров среды по пути /ansible/files/ssl/bpmd/, truststore OTT разместите в /ansible/files/ssl/;

• во внешней системе хранения Secret Management System. Подробнее см. раздел «Интеграция с Secret Management System».

3. Заполните в файле custom_properties.conf.yml переменные в репозитории среды. При необходимости переопределите значения по умолчанию:

# имя хранилища с выпущенным для выбранного module.id сертификатом
designerCertStoreName: 'sberflow-designer.p12'
# путь файла хранилища с сертификатом модуля
designerOttCertStorePath: 'ansible/files/ssl/bpmd/sberflow-designer.p12'
# имя хранилища truststore OTT, полученного от УЦ ОТТ
ottTrustStoreName: 'ift_sol_std3_ott_public.p12'
# путь до файла хранилища truststore OTT
ottTrustStorePath: 'ansible/files/ssl/ift_sol_std3_ott_public.p12'

После развертывания с помощью job компонента CDJE автоматически создается secret bpmd-ott-certs, содержащий созданные выше хранилища.

При необходимости переопределите имя secret в параметрах:

bpmd.ose.istio.ingress.deployment.spec.volumes.designer-backend-ott-certs.secret.secretName
bpmd.ose.istio.egress.deployment.spec.volumes.designer-backend-ott-certs.secret.secretName

для sidecar ingress и egress соответственно.

Подробнее смотрите в блоке дополнительной документации – «Используемые параметры bpmd.istio.all.conf».

Пароли от сертификатов и хранилищ хранятся в переменных:

  bpmd_designer_backend_istio_ott_pass_OTT_CERTSTORE_PRIVATE_KEY_PWD - пароль от секретного ключа модуля
  bpmd_designer_backend_istio_ott_pass_OTT_CERTSTORE_PWD - пароль от контейнера с сертификатом модуля
  bpmd_designer_backend_istio_ott_pass_OTT_TRUST_STORE_PWD - пароль от контейнера с сертификатом ОТТ сервиса

Обновление сайдкара ОТТ до версии 4.3.х#

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

Для перехода на PEM формат необходимо:

1. Из уже полученных сертификатов от администратора ОТТ собрать хранилище сертификатов (jks):

pkcs12 -export -in sberflow-designer.pem -name sberflow-designer -inkey sberflow-designer.key -out sberflow-designer.p12

keytool -importkeystore -deststorepass ******** -destkeypass ******** -destkeystore sberflow-designer.jks -srckeystore sberflow-designer.p12 -srcstoretype PKCS12 -srcstorepass ********

2. Импортируйте корневой сертификат и сертификат УЦ ОТТ в keystore:

keytool -import -trustcacerts -alias root -file "root.crt" -keystore sberflow-designer.jks

keytool -import -trustcacerts -alias ott-service -file "ott-service.pem" -keystore sberflow-designer.jks

3. Разместить полученное хранилице в одном из следующих мест:

• в репозитории общих параметров среды по пути /ansible/files/ssl/bpmd/, truststore OTT разместите в /ansible/files/ssl/;

• во внешней системе хранения Secret Management System. Подробнее см. раздел «Интеграция с Secret Management System».

4. Заполните переменные в файле custom_properties.conf.yml в репозитории среды, при необходимости, переопределив значении по умолчанию:

bpmdOttKeyStoreFile: 'ansible/files/ssl/bpmd/sberflow-designer.jks'
bpmdOttKeyStorePass: 'bpmd.ssl.ose.istio.keyStore.ott.keystore.password'
bpmdOttRootCertAlias: 'root,issuing,rootold,issueoldalpha,issueolddelta'
bpmdOttCertAlias: 'sberflow-designer'
bpmdOttPrivateKeyAlias: 'sberflow-designer'
bpmdOttServiceCertAlias: 'ott-service'

5. В файле bpmd.istio.all.conf проверить правильность заполнения переменных, при необходимости, переопределить значения:

...
bpmd.ose.istio.deployment.spec.template.spec.containers.ott-sidecar.image=<Обязательно заполнить параметр>
...
# при значении false будет использоваться тип хнанилища сертификатов в формате PKCS12
bpmd.ose.istio.configmap.pem.certstore.type.enabled=true
...
## Кoнфигурация OTT сайдкара Ingress
bpmd.ose.istio.ingress.configmap.ott.service.url=https://ottservice:8443/ott-service/rest/token
bpmd.ose.istio.ingress.configmap.ott.certstore.type=PEM
...
## Кoнфигурация OTT сайдкара Egress
bpmd.ose.istio.egress.configmap.ott.service.url=https://ottservice:8443/ott-service/rest/token
bpmd.ose.istio.egress.configmap.ott.certstore.type=PEM

6. Добавить пароль для собранного хранилища сертификатов в _passwords.conf:

bpmd.ssl.ose.istio.keyStore.ott.keystore.password=***

Переменные должны быть определены одним из двух способов:

3.1. Заранее в файле _passwords.conf (см. раздел Установка п. «Размещение сертификатов и паролей»).

В таком случае после deploy BPMD вместе с компонентами Istio job CDJE автоматически создается secret istio-secret-bpmd с данными переменными.

3.2. Из внешней системы хранения Secret Management System (при использовании) после deploy с помощью job CDJE (хранение в файловой системе pod ingress и egress). Подробнее про Secret Management System в разделе «Интеграция с Secret Management System».

4. Заполните стендозависимые параметры sidecar OTT для ingress и egress файле bpmd.istio.all.conf, при необходимости переопределив значения по умолчанию. Полный список с описанием всех переменных смотрите в блоке дополнительной документации – «Используемые параметры bpmd.istio.all.conf».

Ниже перечислен минимально необходимый набор стендозависимых параметров для ручного заполнения/переопределения:

...
# Образ сайдкара ОТТ
bpmd.ose.istio.deployment.spec.template.spec.containers.ott-sidecar.image=
...
# Имена секретов с сертификатами
bpmd.ose.istio.configmap.ott.keystore.name=sberflow-designer.p12
bpmd.ose.istio.configmap.ott.truststore.name=<имя хранилища truststore OTT, полученного от УЦ ОТТ>
...
## Конфигурация OTT сайдкара Egress
bpmd.ose.istio.egress.configmap.ott.module.id=sberflow-designer
bpmd.ose.istio.egress.configmap.ott.client.cert.alias=sberflow-designer
bpmd.ose.istio.egress.configmap.ott.certstore.path=/home/jboss/secrets/sberflow-designer.p12
bpmd.ose.istio.egress.configmap.ott.sevice.hosts=localhost:8443,localhost:8443
bpmd.ose.istio.egress.configmap.ott.trust.store.path=/home/jboss/secrets/<имя хранилища truststore OTT, полученного от УЦ ОТТ>
bpmd.ose.istio.egress.configmap.ott.service.cert.alias=sberflow-designer
...

## Кoнфигурация отт сайдкара ingress
bpmd.ose.istio.ingress.configmap.ott.module.id=sberflow-designer
bpmd.ose.istio.ingress.configmap.ott.client.cert.alias=sberflow-designer
bpmd.ose.istio.ingress.configmap.ott.certstore.path=/home/jboss/secrets/sberflow-designer.p12
bpmd.ose.istio.ingress.configmap.ott.sevice.hosts=localhost:8443,localhost:8443
bpmd.ose.istio.ingress.configmap.ott.trust.store.path=/home/jboss/secrets/<имя хранилища truststore OTT, полученного от УЦ ОТТ>
bpmd.ose.istio.ingress.configmap.ott.service.cert.alias=sberflow-designer
...

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

Состав дистрибутива:

Клиенту передается единый дистрибутив Platform V Flow, частью которого являются следующие архивы:

• owned-distrib.zip – дистрибутив продукта, производитель АО «СбеТех»;

• party-distrib.zip – внешние opensource jar библиотеки;

• vendor-distrib.zip – внешние jar библиотеки.

После распаковки отдельные архивы компонентов загружаются в систему хранения дистрибутивов.

Описание дистрибутива для компонента BPMD:

• BPMD-bin-D-x.x.x-xxx-distrib.zip

  • package

    • pl

      • designer-app-D-X.X.X-xxx.zip

    • bh

      • sberflow-oauth2-server-token-D-x.x.x-xxx.jar

      • sberflow-oauth2-server-sudir-D-x.x.x-xxx.jar

      • sberflow-oauth2-server-spas-D-x.x.x-xxx.jar

      • designer-backend-D-x.x.x-xxx-springboot.jar

      • designer-lsp-groovy-D-x.x.x-xxx.jar

      • designer-executor-D-x.x.x-xxx-springboot.jar

    • sdk

    • docker

    • db

      • BPMD-bin-dbupdate-D-x.x.x-xxx.zip

    • conf

• BPMD-cfg-D-x.x.x-xxx-distrib.zip

  • package

    • docker

    • conf

• Каталог package/pl содержит статичные ресурсы для работы АРМ BPMD (JavaScript, CSS, изображения, шрифты);

• Каталог package/bh содержит jar-файлы приложений BPMD;

• Каталог package/sdk содержит SDK компоненты поставляемы клиентам;

• Каталог package/docker содержит набор dockerfile модулей поставки;

• Каталог package/db содержит скрипты для обновления БД при помощи Liquibase;

• Каталог package/conf/config/parameters содержит параметры приложений BPMD и сайдкаров;

• Каталог package/conf/k8s содержит конфигурационные файлы для развертывания BPMD в среде управления контейнера.

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

• designer-app — основное приложение (возможна установка на внешний Nginx/SNGX);

• designer-backend — backend для работы приложения;

• designer-executor — модуль для проверки скриптов;

• designer-lsp-groovy — модуль для автодополнения методов в скриптах;

• server-token /server-sudir/ server-spas — модуль для выбранного режима аутентификации и авторизации;

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

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

Необходимо развернуть БД PostgreSQL на ВМ (подробнее в документе Руководство по установке продукта Platform V Pangolin).

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

1. Подключитесь на ВМ с PostgreSQL по ssh

2. Создайте tablespace (опционально):

$ sudo su - postgres
$ sudo mkdir -p /pgdata/11/data/ts/flowdb
$ sudo chown -R postgres:postgres /pgdata/11/data/ts/flowdb
psql>
    CREATE TABLESPACE flowdb_t
      OWNER dbadmin
      LOCATION '/pgdata/11/data/ts/flowdb';
  
    ALTER TABLESPACE flowdb_t
      OWNER TO dbadmin;

3. Создайте БД:

psql>
    CREATE DATABASE flowdb OWNER "dbadmin" TABLESPACE "flowdb_t";

4. Подключитесь к созданной БД:

\q
psql -d flowdb

5. Создайте пользователей:

flowdb=# 
    create user bpmd_admin password '***';

6. Создайте схемы:

flowdb=#
    create schema bpmd_admin_schema authorization bpmd_admin;

7. Выдайте гранты:

flowdb=#
    grant all on schema bpmd_admin_schema to bpmd_admin;

8. Установите использование схемы по умолчанию:

flowdb=#
    alter role "bpmd_admin" in database flowdb set search_path to bpmd_admin_schema;

9. Увеличьте число подключений к БД, отредактировав config файл:

$ vim /etc/patroni/postgres.yml
Выставить
        max_connections -->1000

Либо, в случае кластерной конфигурации:

$ patronictl -c /etc/patroni/postgres.yml edit-config
Выставить
        max_connections -->1000

10. Перезагрузите БД:

$ reload
$ restart

11. Рекомендуется не использовать pgbouncer. Если используется, то поменяйте в его конфигурационном файле pgbouncer.ini число подключений:

    max_client_conn = 8000
    pool_mode = transaction
    min_pool_size = 0
    default_pool_size = 950
    max_db_connections = 952
    max_user_connections = 950

12. Перезагрузите службу:

 $ systemctl restart pgbouncer

Подготовка БД с помощью скриптов инициализации#

Для корректной работы playbook "VM_SERVICE" необходима версия pipeline CDJE не ниже 01.040.324 и версия скриптов #b624db02566.

1. В репозитории с common конфигурационными файлами стенда в файле environment.json добавьте playbook "VM_SERVICE" в секцию "playbooks_fpi":

  "VM_SERVICE": {
	"id": 5,
	"args": {
	  "services": [
		"db_update"
	  ]
	}
  }

2. В репозитории с common конфигурационными файлами стенда обновите файл /ansible/globalInventory, добавив группу хостов, на которые будет запущен скрипт инициализации БД:

Пример:

[local]
localhost ansible_connection=local

[hosts:children]
local
vm_dbinit

[vm_dbinit]
vm_dbinit ansible_host=<ip адрес ВМ с PostgreSQL> dns_name=<DNS имя ВМ с PostgreSQL> ansible_user="{{ VM_DBINIT_SSH_USER }}" ansible_ssh_pass="{{ VM_DBINIT_SSH_PASS }}"

Переменные "VM_DBINIT_SSH_USER" и "VM_DBINIT_SSH_PASS" задайте в _password.conf.

3. Заполните переменные в файле custom_property.conf в репозитории среды. При необходимости переопределите значения по умолчанию:

DB_ADMIN_USERNAME: 'db_superuser'
DB_INIT_TS_LOCATION: '/pgdata/11/data/ts/designerts'
DB_INIT_USERNAME: 'designer-user'
DB_INIT_TABLESPACE: 'designerts'
DB_INIT_DATABASE: 'designer_init'
DB_INIT_SCHEMA: 'designer_init_schema'
DB_INIT_USER_RIGHT: 'SELECT, INSERT, UPDATE'
TARGET_SCRIPT_LOCATION: '/home/sadmin/'
TARGET_RIGHTS: '0740'

DB_ADMIN_USERNAME – имя пользователя с правами администратора в PostgreSQL
DB_INIT_TS_LOCATION – место расположения tablespace на ВМ с PostgreSQL
DB_INIT_USERNAME – имя пользователя, используемое при подключении к БД приложением
DB_INIT_TABLESPACE – имя tablespace
DB_INIT_DATABASE – имя базы данных
DB_INIT_SCHEMA – имя схемы
DB_INIT_USER_RIGHT – права пользователя, используемого при подключении к БД приложением
TARGET_SCRIPT_LOCATION – место расположения скриптов инициализации на ВМ с PostgreSQL
TARGET_RIGHTS – права назначаемые на скрипты инициализации БД.

4. Запустите playbook "VM_SERVICE". Результатом выполнения будет полностью подготовленная база данных.

Запуск миграции баз данных с помощью playbook "DB_UPDATE"#

Для корректной работы playbook "DB_UPDATE" необходима версия pipeline CDJE не ниже 01.040.324 и версия скриптов #b624db02566.

1. Заполните переменные в файле custom_property.conf в репозитории среды. При необходимости переопределите значения по умолчанию:

jdbc_url: '<jdbc для подключения к PostgreSQL>'
database_change_log_lock_custom: 'databasechangeloglock'
database_change_log_custom: 'databasechangelog'

DB_ADMIN_USERNAME: 'db_superuser'
DB_INIT_DATABASE: 'designer_init'
DB_INIT_SCHEMA: 'designer_init_schema'

2. В _password.conf задайте переменную "DB_UPDATE_PASSWORD" – пароль для пользователя БД, из-под которого будет проходить миграция.

3. Запустите playbook "DB_UPDATE"

Доступны разные варианты работы миграции с помощью playbook "DB_UPDATE":

Настройка SSL на БД#

Механизм SSL на БД PosgreSQL может работать в нескольких режимах (подробнее см. в документации Platform V Pangolin, раздел «Сценарии администрирования»). Для работы в режиме "Verify-CA" и выше на ВМ с БД должны быть настроены сертификаты, подписанные доверенным УЦ. Если используются самоподписанные сертификаты, то их нужно заменить на подписанные в УЦ.

Пример:

• выпустите клиентский и серверный сертификаты для ВМ с БД (см. п. «Выпуск и подготовка сертификатов» настоящего документа);

• переименуйте корневой сертификат УЦ в root.crt;

• подключитесь к серверу с БД по ssh;

• переключитесь на пользователя root:

$ sudo su

• Создайте папку "old" в каталоге /home/postgres/ssl:

$ mkdir /home/postgres/ssl/old

• Переместите все файлы из директории /home/postgres/ssl/ в /home/postgres/ssl/old, скопируйте свои сертификаты, (клиентский сертификат/ключ для пользователя postgres, серверные сертификат/ключ, root сертификат) в /home/postgres/ssl/ :

$ mv /home/postgres/ssl/* /home/postgres/ssl/old/

• Отредактируйте файл /etc/patroni/postgres.yml, включите SSL режим и пропишите имена своих сертификатов:

ssl: 'on'
ssl_cert_file: /home/postgres/ssl/server.crt
ssl_key_file: /home/postgres/ssl/server.key
ssl_ca_file: /home/postgres/ssl/root.crt

• Скорректируйте права и владельца для новых файлов в /home/postgres/ssl/:

$ chmod -R 600 /home/postgres/ssl/*
$ chown postgres:postgres -R /home/postgres/ssl/

• Переключитесь на пользователя postgres и выполните рестарт БД:

$ sudo su - postgres
$ reload
$ restart

Настройка S3 (minio)#

Разверните на ВМ объектное хранилище Minio любым подходящим способом, например, через rpm пакет:

• Загрузите на ВМ rpm пакет

$ sudo wget http://<репозиторий rpm пакетов>/minio.rpm

• Установите rpm пакет

$ sudo dnf --install minio.rpm

• Создайте пользователя и группу для работы с minio:

$ sudo groupadd -r minio-user
$ sudo useradd -M -r -g minio-user minio-user

• Создайте каталоги для монтирования:

$ sudo mkdir -p /mnt/data/disk1 \
$ sudo mkdir -p /mnt/data/disk2 \
$ sudo mkdir -p /mnt/data/disk3 \
$ sudo mkdir -p /mnt/data/disk4

• Выдайте на них права для созданного пользователя:

$ sudo chown minio-user:minio-user /mnt/data/disk1 /mnt/data/disk2 /mnt/data/disk3 /mnt/data/disk4

• Создайте файл /etc/systemd/system/minio.service со следующим содержимым:

[Unit]
Description=MinIO
Documentation=https://docs.min.io
Wants=network-online.target
After=network-online.target
AssertFileIsExecutable=/usr/bin/minio
 
[Service]
WorkingDirectory=/usr/bin/
 
User=minio-user
Group=minio-user
ProtectProc=invisible
 
EnvironmentFile=-/etc/default/minio
ExecStartPre=/bin/bash -c "if [ -z \"${MINIO_VOLUMES}\" ]; then echo \"Variable MINIO_VOLUMES not set in /etc/default/minio\"; exit 1; fi"
ExecStart=/usr/bin/minio server $MINIO_OPTS $MINIO_VOLUMES
#/usr/bin/minio server $MINIO_OPTS $MINIO_VOLUMES
 
# Let systemd restart this service always
Restart=always
 
# Specifies the maximum file descriptor number that can be opened by this process
LimitNOFILE=1048576
 
# Specifies the maximum number of threads this process can create
TasksMax=infinity
 
# Disable timeout logic and wait until process is stopped
TimeoutStopSec=infinity
SendSIGKILL=no
 
[Install]
WantedBy=multi-user.target
 
# Built for ${project.name}-${project.version} (${project.name})

• Создайте файл /etc/default/minio со следующим содержимым:

# Volume to be used for MinIO server.
MINIO_VOLUMES="http://<fqdn сервера>:9000/mnt/data/disk{1...4}/minio"
# Use if you want to run MinIO on a custom port.
MINIO_OPTS="--console-address :9001"
# Root user for the server.
MINIO_ROOT_USER=minio-user
# Root secret for the server.
MINIO_ROOT_PASSWORD=<указать пароль>
# Change auth type for prometheus monitoring
MINIO_PROMETHEUS_AUTH_TYPE=public
# set this for MinIO to reload entries with 'mc admin service restart'
MINIO_CONFIG_ENV_FILE=/etc/default/minio
# Set to the URL of the load balancer for the MinIO deployment
# This value *must* match across all MinIO servers. If you do
# not have a load balancer, set this value to to any *one* of the
# MinIO hosts in the deployment as a temporary measure.
MINIO_SERVER_URL="http://<fqdn сервера>:9000"

• Включите и запустите службу minio.service:

$ sudo systemctl enable minio.service
$ sudo systemctl start minio.service

• Убедитесь, что служба запустилась успешно:

$ sudo systemctl status minio.service

• Откройте консоль Minio в браузере по адресу http://<fqdn сервера>:9001/dashboard.

Настройка TLS шифрования для S3 (Minio)#

• Выпустите сертификат безопасности. Подробнее в разделе «Выпуск и подготовка сертификатов» настоящего документа.

• Создайте каталог для хранения сертификатов:

$ mkdir /etc/minio/certs

• Задайте права доступа для каталога:

$ sudo chown -R minio-user:minio-user /etc/minio/certs

• Скопируйте в созданный каталог:

  • серверный сертификат;

  • ключ;

  • корневой сертификат/цепочку УЦ.

• Перезапустите сервис minio:

$ systemctl restart minio.service

• Откройте консоль Minio в браузере по адресу https://<fqdn сервера>:9001/dashboard.

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

• Установите на ВМ сервис nginx любым доступным способом, например, через rpm пакет:

$ sudo yum install nginx-1.20.2-1.el8.ngx.x86_64.rpm

• Отредактируйте конфигурационный файл nginx.conf:

$ sudo nano /etc/nginx/nginx.conf

• Приведите содержимое к виду:

user nginx;
worker_processes auto;
error_log /var/log/nginx/error.log;
pid /run/nginx.pid;
 
# Load dynamic modules. See /usr/share/doc/nginx/README.dynamic.
include /usr/share/nginx/modules/*.conf;
 
events {
    worker_connections 1024;
}
 
http {
    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';
 
    access_log  /var/log/nginx/access.log  main;
 
    sendfile            on;
    tcp_nopush          on;
    tcp_nodelay         on;
    keepalive_timeout   65;
    types_hash_max_size 4096;
 
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;
 
    # Load modular configuration files from the /etc/nginx/conf.d directory.
    # See http://nginx.org/en/docs/ngx_core_module.html#include
    # for more information.
    include /etc/nginx/conf.d/*.conf;
 
    server {
        listen       <порт для http взаимодействия>;
        listen       [::]:<порт для http взаимодействия>;
        server_name  _;
        root         /usr/share/nginx/html;
 
        # Load configuration files for the default server block.
        include /etc/nginx/sites-available/*.conf;
 
        error_page 404 /404.html;
            location = /40x.html {
        }
 
        error_page 500 502 503 504 /50x.html;
            location = /50x.html {
        }
    }
}

• Задайте пароль для пользователя nginx:

$ sudo passwd nginx

• Добавьте командную оболочку для пользователя nginx:

$ sudo chsh -s /bin/bash nginx

• Создайте необходимые директории:

$ sudo mkdir /etc/nginx/html
$ sudo mkdir /etc/nginx/sites-available

• Сделайте владельцем директории и поддиректорий в /etc/nginx/ пользователя nginx:

$ sudo chown nginx:nginx -R /etc/nginx/

• Отключите для пользователя nginx ввод пароля sudo:

$ sudo visudo

• Добавьте строчку nginx ALL=(ALL) NOPASSWD: ALL

• Запустите сервис nginx

$ sudo systemctl start nginx.service

• Проверьте статус, он должен быть в 'RUNNING'

$ sudo systemctl status nginx.service

• Если установка статической части компонента BPMD на nginx происходит с помощью deploy job компонента CDJE, то заполните параметры в блоке # NGX Static в файле custom_property.conf.yml в репозитории стенда. Подробнее в «Описание параметров custom_property.conf.yml.

...
## Nginx Static

nginx_home_path_custom: '/etc/nginx/html'
nginx_conf_dir: '/etc/nginx/sites-available'
location_bpmd: '/designer-app'
designer_backend_url: 'https://designer-backend.solution.sbt' # url, по которому будет доступен designer-backend
proxy_ssl_name: 'designer-backend.solution.sbt' # fqdn designer-backend
proxy_ssl_server_name: 'on'
...

• Заполните параметры для работы с nginx в common репозитории стенда.

Подробнее смотрите в документации компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT).

Настройка SSL на nginx#

• Выпустите серверный сертификат и собрать *.pem цепочку. Подробнее в разделе «Выпуск и подготовка сертификатов» настоящего документа.

• Создайте каталог /etc/nginx/cert для хранения сертификатов.

• Скопируйте личный, промежуточный (при наличии), корневой сертификаты, цепочку и закрытый ключ в каталог /etc/nginx/cert/.

• Сделайте пользователя nginx владельцем каталога.

$ sudo chown nginx:nginx -R /etc/nginx/cert/

• Отредактируйте конфигурационный файл nginx.conf, добавив в него блок с параметрами для работы SSL:

...
# Settings for a TLS enabled server.
#
     server {
                 server_name <fqdn сервера>;
                 listen *:<порт для ssl взаимодействий> ssl;
                 ssl_certificate /etc/nginx/cert/server_bundle.pem; # собранная pem цепочка с личным, промежуточным (при наличии) и корневым сертификатами
                 ssl_certificate_key /etc/nginx/cert/server.key; # закрытый ключ от личного сертификата
                 access_log /var/log/nginx/access.log;
                 access_log on; 
                 error_log /var/log/nginx/error.log debug;
                 root /usr/share/nginx/html;
                 include /etc/nginx/sites-available/*.conf;
     }

...

• Перезапустите сервис nginx

$ sudo systemctl restart nginx.service

• Проверьте статус, он должен быть в 'RUNNING'

$ sudo systemctl status nginx.service

• Если установка статической части компонента BPMD на nginx происходит с помощью deploy job компонента CDJE, то заполните параметры для работы по SSL в блоке # NGX Static в файле custom_property.conf.yml в репозитории стенда:

...
# Включение в генерируемый bpmd.conf файл пропертей ниже для работы с Nginx по SSL. false - если проперти уже есть в основном nginx.conf или если на nginx нет сертификатов
properties_proxy_ssl: 'true'
# Проперти для работы с Nginx по SSL - вынесены в дистрибутив из общего nginx.conf
proxy_ssl_certificate: '/etc/nginx/cert/server.pem'
proxy_ssl_certificate_key: '/etc/nginx/cert/server.key'
proxy_ssl_trusted_certificate: '/etc/nginx/cert/ca.pem'
proxy_ssl_verify: 'off'
...

Установка компонента SynGX (SNGX) продукта Platform V Syngx (BPM)#

С подробной инструкцией по установке продукта SNGX рекомендуется ознакомиться в Руководстве по установке на SNGX.

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

В качестве платформы виртуализации используется среда контейнеризации Kubernetes (1.25 и выше) (опционально – Red Hat OpenShift 4.7 и выше, рекомендовано - Platform V DropApp).

Необходимо подготовить пространство (проект) в платформе контейнеризации в соответствии с минимальными требованиями по квотам сервиса. Опционально проект можно подключить к service mesh – Istio (рекомендуется использование продукта Platform V Synapse Service Mesh (SSM)). Названия проектов одинаковы для любых сред контейнеризации.

Переменные, используемые в манифестах системы управления контейнерами#

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

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

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

Установка#

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

Выбор способа установки#

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

• ручная установка.

• установка с помощью централизованного инструмента платформы.

Ручная установка#

Для BPMD предусмотрена ручная установка.

Для этого:

1. Разархивируйте дистрибутив компонента;

2. При необходимости соберите образы с помощью CRI-O совместимого движка и файлов в каталоге package/docker, используя бинарные артефакты из каталогов package/bh и package/pl;

3. С помощью файлов из вложенных каталогов в package/conf/data произведите импорт в соответствующие системы;

4. В файлах с параметрами из каталога package/conf/config/parameters укажите значения переменных манифестов для вашего стенда;

5. Манифесты из каталога package/conf/config/openshift параметризуйте вышеописанными параметрами и загрузите в систему управления контейнерами.

Установка с помощью централизованного инструмента платформы#

Дистрибутив поддерживает установку с помощью централизованного инструмента развертывания – компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT). Рекомендованная версия конвейера указывается в требованиях к комплексу технических средств для размещения среды контейнеризации и Platform V.

С описанием инструмента CDJE и его настройкой можно ознакомиться в соответствующей документации по продукту.

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

Пререквизиты использования централизованного инструмента установки компонент платформы#

Подготовка окружения Deploy Job#

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

• Разместите в своем проекте набор Jenkins Jobs;

• Разместите в своем проекте необходимые Git-репозитории.

О создании Jenkins Jobs, составе и правилах наименования Git-репозиториев читайте в Руководстве по установке компонента CDJE.

Файл конфигурации environment.json#

Настройки Deploy Job задаются в конфигурационном файле environment.json, размещенном в Git-репозитории общих параметров среды. Перечень всех параметров с описанием указан в Руководстве по системному администрированию компонента CDJE.

Рекомендуется не переопределять значения параметров в блоке __default, а описывать параметры, которые необходимо переопределить в блоке с именем среды:

• в блоке "credentials": {} укажите ваши учетные записи для работы с инфраструктурой среды;

• В блоке "platformVersions": [] укажите список доступных Deploy Job GIT-branch с конфигурацией компонента, каждая GIT-branch соответствует релизу;

• В блоках "playbooks_fpi": {} и "playbooks_import": {} вы можете ограничить список playbook на стартовой странице Deploy Job.

Файл конфигурации subsystems.json#

Список компонентов, доступных для установки описывается в конфигурационном файле subsystem.json, размещенном в Git-репозитории общих параметров среды.

Для возможности выбора компонента BPMD в DEPLOY JOB добавьте в subsystem.json следующий блок:

  "bpmd": {
    "app_name": ["designer-backend", "designer-executor", "server-sudir"]
    "fpi_name": "bpmd",
    "groupId": "sbt_PROD.CIxxxxxxxx_bpmd",
    "nexus_repo": "sbt_PROD",
    "artifactId": "BPMD",
    "fpType": "bts",
    "versionFilter": "D-",
    "openshiftProjectName": "namespace",
    "openshiftControlPlane": "isioCPnamespace"
  }

• имя блока (в данном примере - "bpmd") задает имя компонента, который будет в выпадающем списке Deploy Job;

• app_name — задает, какие модули будут установлены при развертывании дистрибутива, т.к. в поставку включено максимальное количество модулей;

  • в зависимости от типа авторизации, который используется в инсталляции, может быть указан один из 3 модулей авторизации – "server-sudir", "server-spas", "server-token". Подробнее описано в документе «Настройки режимов аутентификации и авторизации пользователей».;

• fpi_name — код компонента, не зависит от инсталляции;

• fpType — тип компонента, не зависит от инсталляции;

• nexus_repo — репозиторий, в котором размещен дистрибутив компонента;

• groupId — идентификатор группы репозитория, в котором размещен дистрибутив компонента;

• artifactId — идентификатор артефакта дистрибутива компонента;

• versionFilter — параметр, который по заданной маске может ограничить версии дистрибутивов, доступных в выпадающем списке Deploy Job;

• openshiftProjectName — namespace системы управления контейнерами, в который будет производиться установка BPMD. При мультикластерной установке данный параметр может быть переопределен в файле конфигурации multiClusters.json;

• openshiftControlPlane — namespace системы управления контейнерами, в котором установлена контрольная панель service mash сети. При мультикластерной установке данный параметр может быть переопределен в файле конфигурации multiClusters.json.

Перечень всех параметров с описанием указан в Руководстве по системному администрированию компонента CDJE.

Файл конфигурации multiClusters.json#

Используется для задания конфигурации интеграции Deploy Job с кластером системы управления контейнерами.

Пример конфигурации:

{
"datacenters": {
    "megacod": {
        "openshiftCluster"                              : "<адрес вашего ose кластера 1>",
        "openshiftSATokenCred"                          : "<имя jenkins cred (тип - secret text), содержащего токен сервисной учетки сервисного проекта вашего ose кластера 1. Используется для доступа к API OpenShift>",
        "openshiftProjectName"                          : "<имя вашего проекта в ose в кластере 1>",
        "openshiftAppsDomain"                           : "<суффикс домена для сервисов вашего кластера. Значение этого параметра подставляется в параметр {{appsDomain}} в конфиги развертывания OSE в процессе деплоя>",
        "openshiftWebConsole"                           : "<ссылка на кластер шфита для формирования корректной ссылки на проект в описании deploy job>",
        "openshiftRoutersFQDN": [                       : "<fully qualified domain name или ip адрес роутера/ов OpenShift. Этот адрес можно узнать у ЦИ. Либо, на средах до ПСИ, можно попробовать сделать ping любому routes в проекте. Все роуты внутри прокта (скорее, кластера) по вайлдкард резолвятся в один или более адресов нод, на которых располагаются HAProxy Openshift (или, возможно, в балансировщик перед этими нодами). >"
            "<ip или hostname router'а OpenShift 1>",
            "<ip или hostname router'а OpenShift 2>"
        ]
    }
}
}

Перечень всех параметров с описанием указан в разделе документации компонента CDJE развертывание в Kubernetes/OpenShift/Platform V DropApp.

Размещение сертификатов и паролей#

В случае, когда со стороны приложения отключена интеграция с Secret Management System, пароли и сертификаты размещаются в GIT-репозитории с общими параметрами среды.

Файл с паролями _passwords.conf располагается по пути /ansible/_passwords.conf. Содержит в себе перечень паролей в формате ключ-значение, где ключом является параметр, использующейся в манифестах развертывания, а значение — сам пароль/токен. До размещения в GIT-репозитории данный файл должен быть зашифрован с помощью OpenSSL.

Подробнее о процедуре шифрования _passwords.conf описано в руководстве по установке компонента CDJE.

Сертификаты размещаются в виде защищенных JKS-хранилищ по пути /ansible/files/ssl/bpmd. Хранилища общие для всех компонент можно разместить по пути /ansible/files/ssl/. Пути размещения и имена сертификатов указываются в параметрах, используемых при генерации манифестов секретов в /conf/config/custom_properties.conf.yml

Описание процесса установки с помощью компонента CDJE

Для установки приложения запустите с параметрами Deploy Job с преднастроенной конфигурацией.

После запуска Deploy Job выберете следующие параметры, описанные в таблице:

Создание git branch параметров дистрибутива для релиза

Для промежуточного хранения параметров манифестов используется git-репозиторий компонента. Для хранения параметров разных релизов используйте разные git branch с именем соответствующим номеру релиза.

Для это первоначально в конфигурационный файл environment.json инструмента развертывания добавьте версию релиза в переменную platformVersions.

"platformVersions": [
  "R5.0"
]

После данного изменения произведите реконфигурацию jenkins job инструмента развертывания (запуск с не заданными параметрами).

После добавления версии релиза в jenkins job инструмента развертывания в параметре Репозиторий/ветка с настройками ФП появится возможность создания новой git branch. Возможно как создание пустой git branch, так и с копией параметров другого релиза. Рекомендуется создавать копию с параметрами предыдущего релиза, т.к. при этом большинство параметров уже будут преднастроены специфическими для стенда значениями и различие между составом параметров будет минимальным.

При запуске jenkins job в режиме создания git branch любые выбранные playbook исполнены не будут.

Миграция параметров

Дистрибутив включает в себя перечень всех используемых в манифестах переменных с заданными значениями по умолчанию. Данные переменные и значения располагаются в каталоге package/conf/config/parameters и разбиты на файлы, относящиеся к конкретной единице развертывания. Общие параметры располагаются в файлах *.all.conf для параметров приложения и *.istio.all.conf для параметров Istio.

Параметры разбиты по логическим блокам и по возможности снабжены комментариями и примерами заполнения.

Часть заданных параметров подразумевает генерацию однотипных манифестов по ранее подготовленным шаблонам, в дистрибутиве такие файлы начинаются с custom-*. Правила, по которым происходит шаблонизация, описаны в комментарии рядом с параметром и обычно подразумевают задание параметров в строку с заранее определенным делимитером.

При первоначальной установке новой версии релиза произведите процедуру миграции. Данная процедура запускается в jenkins job инструмента развертывания при помощи выбора playbook MIGRATION_FP_CONF. В результате выполнения из дистрибутива BPMD в промежуточный репозиторий конфигурации переносятся параметры шаблонизации. При этом ранее добавленные параметры и их значения не изменяются.

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

Часть параметров, которые содержаться в дистрибутиве, имеют значения по умолчанию и редко требуют изменения. Другая же часть параметров имеет специфику относительно среды развертывания и не может иметь значений по умолчанию. К таким параметрам относятся адреса баз данных, адреса брокеров Apache Kafka, имена хостов кластеров систем управления контейнерами, хосты систем, с которыми необходима интеграция и т.п. Для таких параметров после процедуры миграции администратору стенда необходимо задать значения специфичных стенду.

Принципы шаблонизации

В дистрибутиве BPMD содержатся манифесты развертывания приложения в облачной системе управления контейнерами в виде файлов в формате yaml. Данные манифесты могут содержать placeholders (подсказки внутри поля), указывающие, что в процессе шаблонизации инструменту установки необходимо заменить данный параметр на его значение, которое указано в git репозитории компонента в каталоге стенда в файле подкаталога /conf/config/parameters, имя которого содержит название модуля.

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

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

Шаблоны секретов

В дистрибутиве содержатся шаблоны манифестов секретов, которые используются при работе приложения. Это сделано для упрощения подготовки стенда, снимая необходимость ручной подготовки манифестов секретов администраторами стенда. Шаблоны секретов не содержат чувствительной информации — пароли, сертификаты, токены и т.п. При запуске deploy job происходит подстановка чувствительной информации в манифесты секретов.

Часть секретов (основной секрет для приложения и основной секрет для Istio) создается автоматически по значениям из _passwords.conf. Для соответствия требованиям безопасности в данном релизе предусмотрен формат задания паролей с возможностью их хранения вне переменных окружения. Поэтому вместе с паролем в приложение также передается и значение конфигурационного параметра. Каждая строка состоит из ключа, по которому осуществляется получение чувствительной информации.

Ключ состоит из двух элементов:

• имя конфигурационного параметра;

• значение конфигурационного параметра в формате JAVA Properties.

Для формирования основного секрета приложения в файле _passwords.conf укажите переменные:

bpm.common.clipas.secret-key=clipas.secret-key=<укажите секретный ключ>
bpmd.designer-backend.spring.datasource.username=spring.datasource.username=<Имя пользователя для доступа к основной БД>
bpmd.designer-backend.spring.datasource.password=spring.datasource.password=<Пароль УЗ для доступа к основной БД>
bpmd.designer-backend.aws.accessKeyId=aws.accessKeyId=<ID ключа доступа к S3 совместимому хранилищу>
bpmd.designer-backend.aws.secretAccessKey=aws.secretAccessKey=<Ключ доступа к S3 совместимому хранилищу>
bpmd.designer-backend.app.meta-user-name=app.meta-user-name=<Имя пользователя для доступа к МЕТА>
bpmd.designer-backend.app.meta-password=app.meta-password=<Пароль УЗ для доступа к МЕТА>
bpmd.designer-backend.oidc.endpoints.settings.client-secret=oidc.endpoints.settings.client-secret=<Секрет для работы микросервиса авторизации>

# Ключи для задания чувствительной информации для прежних версий BPMD оставлены для обратной совестимости

bpmd_designer_backend_extra_java_opts=<указать перечень опций>
-Dspring.datasource.password=<Пароль УЗ для доступа к основной БД>
-Dstandin.datasource.password<Пароль УЗ для доступа к резервной БД>
-Dapp.meta-password=<Пароль УЗ для доступа к МЕТА>
-Daws.secretAccessKey=<Пароль УЗ для доступа к S3 совместимому хранилищу>

bpmd_designer_executor_extra_java_opts=<указать перечень опций>
На текущий момент нет обязательных опций

Для формирования секрета с паролями ОТТ добавьте переменные, в которых укажите пароли к хранилищам сертификатов ОТТ:

bpmd_designer_backend_istio_ott_pass_OTT_CERTSTORE_PRIVATE_KEY_PWD
bpmd_designer_backend_istio_ott_pass_OTT_CERTSTORE_PWD
bpmd_designer_backend_istio_ott_pass_OTT_TRUST_STORE_PWD

Установка BPMD#

Установка BPMD осуществляется запуском deploy job CDJE c заполненными параметрами и выбором набора playbook.

Список основных playbook, которые необходимо выбрать для установки:

• MIGRATION_FP_CONF — миграция параметров с дефолтными значениями в репозиторий компонента на среде.

• OPENSHIFT_DEPLOY — шаблонизация и загрузка манифестов модулей в систему управлениями контейнерами.

• OPENSHIFT_INGRESS_EGRESS_DEPLOY — шаблонизация и загрузка манифестов для граничных прокси (IGEG) Istio Ingress/Egress в систему управлениями контейнерами.

• NGINX_DEPLOY — шаблонизация конфигурационного файла Nginx/SNGX и загрузка статического сайта на выделенный сервер Nginx/SNGX.

MIGRATION_FP_CONF

playbook выбирается для миграции параметров манифестов развертывания в git репозиторий компонента. Описан ранее.

OPENSHIFT_DEPLOY

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

В namespace системы управления контейнерами разворачиваются следующие модули:

• designer-backend – микросервис web-дизайнера для работы с внешним СПО;

• designer-executor – микросервис для проверки скриптов;

• designer-app – целевой вариант развертывания ui web-дизайнера процессов.

Опциональный вариант установки на выделенный сервер Nginx/SNGX описан далее.

Общие параметры для всех модулей расположены в дистрибутиве в файле /package/conf/config/parameters/bpmd.all.conf, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания и работы модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров bpmd.all.conf.

Установка designer-backend

Параметры для данного модуля расположены в дистрибутиве в файле /package/conf/config/parameters/bpmd_designer-backend.conf, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания данного модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров bpmd_designer-backend.conf.

Установка designer-executor

Параметры для данного модуля расположены в дистрибутиве в файле /package/conf/config/parameters/bpmd_designer-executor.conf, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания данного модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров bpmd_designer-executor.conf.

Установка designer-app

Параметры для данного модуля расположены в дистрибутиве в файле /package/conf/config/parameters/bpmd_designer-app.conf, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания данного модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров bpmd_designer-app.conf.

Изменение профиля приложения

Переключение spring-профиля приложения было перенесено из jvm-опций основной конфигурации приложения в переменную окружения SECURITY_PROFILE образа. Аналогичным образом выключатель аудита также перенесен из основной конфигурации приложения в переменную окружения SECURITY_PROFILE образа.

Установка значений SECURITY_PROFILE производится через переменные:

• bpmd.designer-backend.ose.deployment.spec.template.spec.containers.designer-backend.env.security_profile.value, в которой задается перечень jvm-опций для профиля и аудита.

  • Опции, которые необходимо добавить по умолчанию: -Dspring.profiles.active=oauth2-flow -Daudit.enabled=true

• bpmd.designer-executor.ose.deployment.spec.template.spec.containers.designer-executor.env.security_profile.value, в которой задается перечень jvm-опций для профиля и аудита.

  • Опции, которые необходимо добавить по умолчанию: -Dspring.profiles.active=

OPENSHIFT_INGRESS_EGRESS_DEPLOY

playbook выбирается для шаблонизации манифестов развертывания элементов граничных прокси (IGEG), загрузки в систему управления контейнерами и мониторингом успешности процесса развертывания. Также содержит набор манифестов для маршрутизации запросов между BPMD и граничными прокси (IGEG) посредством service mash сети.

Параметры для данного модуля расположены в дистрибутиве в файле /package/conf/config/parameters/istio.all.conf, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания данного модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров bpmd.istio.all.conf.

NGINX_DEPLOY

playbook выбирается для шаблонизации конфигурационного файла Nginx/SNGX и загрузки статического сайта на выделенный сервер Nginx/SNGX.

Параметры для данного модуля расположены в дистрибутиве в файле /package/conf/custom_property.conf.yml, который в процессе установки мигрирует в репозиторий среды. Для успешного развертывания данного модуля заполните корректными стендозависимыми параметрами. Описание параметров приводится в файле Описание параметров custom_property.conf.yml.

Процесс установки

Для установки BPMD заполните параметры в deploy job, выбрав один или несколько playbook и запустите установку. После описанных выше этапов шаблонизации и загрузки манифестов в систему управления контейнерами перейдите в административный интерфейс системы управления контейнерами для контроля успешного завершения установки.

Установка компонентов для аутентификации и авторизации#

Для установки компонентов аутентификации и авторизации воспользуйтесь инструкцией «Настройки режимов аутентификации и авторизации пользователей».

Ограничение компонентов к установке#

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

Переменные и значения по умолчанию#

Дистрибутив включает в себя перечень всех используемых в манифестах переменных с заданными значениями по умолчанию. Данные переменные и значения располагаются в каталоге package/conf/config/parameters и разбиты на файлы, относящиеся к конкретной единице развертывания. Общие параметры располагаются в файлах *.all.conf для параметров приложения и istio.all.conf для параметров Istio.

Параметры разбиты по логическим блокам и по возможности снабжены комментариями и примерами заполнения.

Часть заданных параметров подразумевает генерацию однотипных манифестов по ранее подготовленным шаблонам, в дистрибутиве такие файлы начинаются с custom-*. Правила, по которым происходит шаблонизация, описаны в комментарии рядом с параметром и обычно подразумевают задание параметров в строку с заранее определенным делимитером.

Параметры приложения вместе со значениями по умолчанию мигрируют в репозиторий на стенде конкретного сервиса при прохождении заданного playbook. Актуальные значения для стендов необходимо задавать в репозитории стенда конкретного сервиса.

Взаимная аутентификация внутри проекта#

В связи с возможностью передачи в рамках пользовательских процессов уровня информации К-1, К-2 соединение между pod внутри проекта системы управления контейнерами происходит по протоколу mTLS. Данное изменение не требует дополнительной конфигурации и реализуется за счет добавления/изменения следующих конфигурационных манифестов в дистрибутиве.

Route в поставке BPMD#

В поставке BPMD передается 2 пары route (MTLS/MTLS+OTT) для доступа к приложению:

• Route, содержащий имя компонента BPMD;

• Route для доступа через гео-балансировщик нагрузки.

Параметры, используемые в манифестах route, располагаются в файле package/conf/config/parameters/bpmd.istio.all.conf.

Имя в route можно переопределить через параметр:

bpmd.ose.ingress.route.host.name=designer

Домен кластера системы управления контейнерами задается переменной:

bpmd.ose.istio.openshiftAppsDomain

Домен гео-балансировщика задается с помощью переменной:

bpmd.ose.istio.common.spec.servers.hosts.cluster-lb-host

На средах, где отсутствует гео-балансировка, не требуется наличие route для доступа через гео-балансировщик нагрузки и рекомендуется указать:

bpmd.ose.istio.ingress.route.lb.deploy.enabled=false
bpmd.ose.istio.ingress.route.lb.ott.deploy.enabled=false

По умолчанию добавление указанных route включено.

Для Route гео-балансировщика нагрузки возможно добавление метки "shard": "geo" для поддержки со стороны балансировщика. По умолчанию данная опция отключена.

Для включения укажите:

bpmd.ose.istio.ingress.route.lb.metadata.labels.shard.geo.enabled=true

Настройка Kafka#

Настройки Kafka описаны в документах: Руководство по установке, раздел «Настройки для отправки/получения сообщений по событиям в процессах» и Руководство по системному администрированию, раздел «Настройки для отправки/получения сообщений по событиям в процессах» компонента BPMX.

Дополнительные настройки со стороны BPMD не требуются.

Настройка аутентификации и авторизации#

Настройка каждого режима аутентификации и авторизации описана в документе «Настройки режимов аутентификации и авторизации пользователей».

Интеграция с внешними системами#

Интеграция с использованием граничного прокси IGEG#

В случае использования граничного прокси IGEG исходящие запросы должны быть маршрутизированы через него.

Маршрутизация HTTPS запросов#

Для стандартных платформенных интеграций (AUTX/LOGA) при установке BPMD разворачиваются необходимые манифесты, осуществляющие маршрутизацию запросов во вне namespace.

Также задается порт шлюза граничного прокси IGEG, через который будет идти запрос:

bpmd.ose.istio.egress.common.internal.port=8080

Если необходимо добавить дополнительные интеграций с внешними сервисами, укажите:

bpmd.ose.istio.egress.common.http_integration_map.enabled=true

и заполните параметр:

bpmd.ose.istio.egress.common.http_integration_map

Заполните параметр следующим образом — разные интеграции разделить ";", параметры для одной интеграции - ":". Для описания одной интеграции укажите:

alias:hostname:internal_port:external_port

где:

• alias – короткое имя внешнего сервиса, которое может быть указано в модели процесса;

• hostname – доменное имя сервиса, с которым настраивается интеграция;

• internal_port – порт шлюза граничного прокси IGEG, через который будет идти запрос;

• external_port – порт сервиса, с которым настраивается интеграция;

По указанным параметрам при запуске playbook OPENSHIFT_INGRESS_EGRESS_DEPLOY deploy job будут сгенерированы и установлены необходимые манифесты.

При указании в конфигурации приложения адресов интеграций используйте:

• протокол HTTP;

• порт шлюза граничного прокси IGEG.

После маршрутизации запроса вне namespace он будет направлен по целевому порту и протоколу HTTPS, а также обогащен клиентскими сертификатами и заголовками OTT.

Поддержка бинарного тела запроса#

Поддержка бинарного тела запроса работает при использовании sidecar istio-proxy версии istio-release-1.6.14-se-release-1.2.2 и выше.

Настройки производятся для envoy filter ОТТ. По умолчанию, заданы необходимые настройки для поддержки прохождения бинарных данных.

Имя фильтра:

# Envoy filter входящего граничного прокси IGEG
bpmd.ose.istio.ingress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.name=envoy.sbt_authz
bpmd.ose.istio.ingress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.grpc_service.google_grpc.stat_prefix=sbt_authz

# Envoy filter исходящего граничного прокси IGEG
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.name=envoy.sbt_authz
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.grpc_service.google_grpc.stat_prefix=sbt_authz

Включено указание роли sidecar:

# Envoy filter входящего граничного прокси IGEG
bpmd.ose.istio.ingress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.grpc_service.sidecar_role.enabled=true

# Envoy filter исходящего граничного прокси IGEG
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.grpc_service.sidecar_role.enabled=true

Включено добавление опции поддержки бинарного тела и значение опции:

# Envoy filter входящего граничного прокси IGEG
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.pack_as_bytes.enabled=true
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.pack_as_bytes=true

# Envoy filter исходящего граничного прокси IGEG
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.pack_as_bytes.enabled=true
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.pack_as_bytes=true

Максимальное количество байт в запросе, который передается на sidecar ОТТ:

# Envoy filter входящего граничного прокси IGEG
bpmd.ose.istio.ingress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.max_request_bytes=2097152

# Envoy filter исходящего граничного прокси IGEG
bpmd.ose.istio.egress.ef.ott-auth-filter.spec.configPatches.HTTP_FILTER.patch.value.config.with_request_body.max_request_bytes=2097152

Настройка tls-совместимости с внешними хостами#

Реализуется с помощью отдельного egress envoyFilter. Используется в случае, когда используемая версия tls протокола на хосте, а также поддерживаемый набор tls шифров не совпадают с версией и поддерживаемым набором tls шифров на IGEG. Для включения режима tls-совместимости необходимо:

• Задать значение параметра для включения режима tls-совместимости в true (значение по умолчанию false):

bpmd.ose.istio.egress.common.tls_compatibility_mode.enabled=true

• Указать список внешних хостов и портов, для которых необходим режим tls-совместимости в формате external_host1:external_port1;…external_hostN:external_portN:

bpmd.ose.istio.egress.common.tls_compatibility_mode_integration_map=

• Указать (при необходимости скорректировать значения, заданные по умолчанию) список подходящих для внешнего хоста tls-шифров:

bpmd.ose.istio.egress.ef.tls-filter.configPatches.CLUSTER.patch.value.transport_socket.common_tls_context.cipher_suites=<Обязательно заполните параметр>

Маршрутизация TCP запросов#

Запросы к БД#

Для добавления манифестов для интеграции с БД укажите:

bpmd.ose.istio.egress.common.tcp_bd_map.enabled=true

и заполните параметр:

bpmd.ose.istio.egress.common.tcp_bd_map

Заполните параметр следующим образом — разные интеграции разделить ";", параметры для одной интеграции - ":". Для описания одной интеграции указать:

alias:hostname:app_port:internal_port:external_port

где

• alias — короткое имя БД, будет использоваться в манифестах;

• hostname — доменное имя БД с которой настраивается интеграция;

• app_port — виртуальный порт для разграничения трафика, должен быть уникальным для всех tcp-соединений в namespace;

• internal_port — порт шлюза граничного прокси IGEG, через который будет идти запрос, должен быть уникальным для всех tcp-соединений в namespace;

• external_port — целевой порт БД с которой, настраивается интеграция.

По указанным параметрам при запуске playbook OPENSHIFT_INGRESS_EGRESS_DEPLOY deploy job будут сгенерированы и установлены необходимые манифесты.

При указании в конфигурации приложения параметров БД используйте виртуальный порт для разграничения трафика (app_port). После маршрутизации запроса вне namespace он будет направлен по целевому порту. В случае использования кластера БД укажите параметры для обоих адресов БД.

Укажите открытые порты шлюза граничного прокси IGEG для каждого hostname и внешний порт подключения к БД в параметре:

bpmd.ose.istio.egress.svc.external.ports

Данный параметр задается для всех внешних соединений, кроме того следует учитывать, что часть портов, используемых в других манифестах, задается в SVC IGEG с помощью других переменных.

Запросы к брокерам Kafka#

Начиная с релиза 5.2.0 добавлена возможность TLS Origination трафика к брокерам Kafka на граничном прокси IGEG. Возможность TLS Origination трафика на прикладном pod оставлена для режима обратной совместимости и последовательного перехода на актуальный режим. В случае TLS Origination на прикладном pod укажите, что не используется TLS Origination трафика на граничном прокси:

bpmx.ose.istio.egress.kafka.origination.enable=false

Для добавления манифестов для интеграции с Kafka укажите:

bpmd.ose.istio.egress.common.tcp_kafka_ssl_map.enabled

и заполните параметр:

bpmd.ose.istio.egress.common.tcp_kafka_ssl_map

Заполните параметр следующим образом — разные интеграции разделить ";", параметры для одной интеграции - ":". Для описания одной интеграции укажите:

alias:hostname:ip:app_port:internal_port:external_port

где

• alias — короткое имя брокера Kafka, будет использоваться в манифестах;

• hostname — доменное имя брокера kafka кластера, с которым настраивается интеграция;

• ip — IP адрес брокера Kafka

• app_port — виртуальный порт для разграничения трафика, должен быть уникальным для всех tcp-соединений в namespace;

• internal_port — порт шлюза граничного прокси IGEG, через который будет идти запрос, должен быть уникальным для всех tcp-соединений в namespace;

• external_port — целевой порт БД, с которой настраивается интеграция.

По указанным параметрам при запуске playbook OPENSHIFT_INGRESS_EGRESS_DEPLOY deploy job будут сгенерированы и установлены необходимые манифесты.

При указании в конфигурации приложения адреса брокера kafka используйте виртуальный порт для разграничения трафика (app_port). После маршрутизации запроса вне namespace он будет направлен по целевому порту. В случае использования кластера kafka с количеством брокеров более 1 укажите уникальные параметры для каждого брокера Kafka.

В случае TLS Origination на граничном прокси IGEG, укажите:

bpmd.ose.istio.egress.kafka.origination.enable=true

И воспользуйтесь параметрами для интеграции с брокерами Kafka без SSL, перенеся в них описание хостов для интеграции

bpmd.ose.istio.egress.common.tcp_kafka_map.enabled
bpmd.ose.istio.egress.common.tcp_kafka_map

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

bpmd.ose.istio.egress.svc.external.ports

Данный параметр задается для всех внешних соединений. Кроме того, следует учитывать, что часть портов, используемых в других манифестах, задается в SVC IGEG с помощью других переменных.

В конфигурации приложения следует использовать режим PLAINTEXT и порт, равный внешнему порту интеграции. После развертывания BPMD манифесты будут перезаписаны и TLS Origination трафика будет происходить на граничном прокси.

При использовании PKI движка SecMan возможна генерация отдельного клиентского сертификата под каждое соединение. Для этого воспользуйтесь параметром:

bpmd.ose.istio.egress.kafka.origination.use_personal_certs=true

Данный параметр задается для всех внешних соединений. Кроме того, следует учитывать, что часть портов, используемых в других манифестах, задается в SVC IGEG с помощью других переменных.

Интеграция с базой данных BPMD#

Для длительного хранения данных используется реляционная база данных Platform V Pangolin. Также возможен вариант использования ванильной сборки PostgreSQl. В промышленной эксплуатации рекомендуется использовать геораспределенный кластер БД. Первичная настройка БД описана в разделе «Подготовка БД».

Интеграция осуществляется со стороны designer-backend.

В данном разделе указаны обязательные к заполнению переменные. Остальные переменные имеют значения по умолчанию, которые можно переопределить в конфигурационном файле по пути /conf/config/parameters/bpmd_designer-backend.conf. Описание всех параметров приведено в файле bpmd_designer-backend.conf

Адрес БД задается в виде JDBC URL и определяется значением переменной:

bpmd.designer-backend.ose.configmap.application.spring.datasource.jdbc-url

Формат задания JDBC URL:

jdbc:postgresql://${FQDN HOSTAME}:${POST}/${DB name}?currentSchema=${schema name}&searchPath=${schema name}&sslmode=verify-ca&sslkey=${путь для ключ сертификата в формате PKCS8}&sslcert=${путь до клиентского сертификата}&sslrootcert=${Путь до цепочки доверия}

При работе через граничный прокси IGEG в качестве порта указывайте открытый порт шлюза для данного TCP взаимодействия. Также для данной интеграции должны быть подготовлены необходимые манифесты. Подробнее о необходимой конфигурации см. раздел «Интеграция с использованием граничного прокси IGEG».

По умолчанию миграция структуры БД включена. В случае необходимости отключения воспользуйтесь параметром:

bpmd.ose.configmap.application.spring.liquibase.enabled

Задание реквизитов доступа и использование сертификатов без интеграции с Secret Management#

Задайте реквизиты доступа через основной secret secret-bpmd.unver.

Необходимо задать значение в ключе
bpmd.designer-backend.spring.datasource.username=spring.datasource.username=<Имя пользователя доступа к основной БД>
bpmd.designer-backend.spring.datasource.password=spring.datasource.password=<Пароль УЗ для доступа к основной БД>
файла _passwords.conf

Для развертывания секрета, содержащего сертификат для подключения к БД, задайте:

bpmd.ose.secret.bd.enabled=true

При необходимости переопределите имя секрета через параметр:

bpmd.ose.secret.bd.secretName

Задание реквизитов доступа и использование сертификатов при интеграции с Secret Management#

В случае использования KV хранилища имя пользователя и пароль к БД хранятся в секрете, размещенном в Secret Management System.

В случае использования DB хранилища имя пользователя задается и обновляется с помощью Secret Management System.

В случае использования PKI хранилища сертификаты для доступа к БД через SSL генерируются с помощью Secret Management System.

Подробнее настройка данной интеграции описана в разделе «Интеграция с Secret Management System».

Интеграция с S3-совместимым хранилищем#

Укажите URL S3-совместимого хранилища:

bpmd.designer-backend.ose.configmap.application.aws.awsUrl=http://s3:8080

URL задается в формате:

${protocol}://${host}:{port}

При работе через граничный прокси IGEG в качестве порта указывайте открытый порт шлюза для HTTP взаимодействий. Также для данной интеграции должны быть подготовлены необходимые манифесты. Подробнее о необходимой конфигурации см. раздел «Интеграция с использованием граничного прокси IGEG».

Укажите реквизиты для работы с S3-совместимым хранилищем через основной secret secret-bpmd.unver.

Необходимо задать значение в ключе
bpmd.designer-backend.aws.awsAccessKeyId=aws.awsAccessKeyId=<ID ключа доступа>
bpmd.designer-backend.aws.secretAccessKey=aws.secretAccessKey=<Значениеключа доступа>
файла _passwords.conf

Либо получить из Secret Management System при включенной интеграции. Подробнее настройка данной интеграции описана в разделе «Интеграция с Secret Management».

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

Укажите URL для получения токена и запросов к META:

bpmd.designer-backend.ose.configmap.application.meta.token-url=${protocol}://${host_meta}:${port}/oauth/token
bpmd.designer-backend.ose.configmap.application.meta.graphql.api-url=${protocol}://${host_meta}:${port}/meta-token/graphql
bpmd.designer-backend.ose.configmap.application.meta.building-blocks.api-url=${protocol}://${host_meta}:${port}/reestrbb/buildingblock/search

При работе через граничный прокси IGEG в качестве порта указывайте открытый порт шлюза для HTTP взаимодействий. Также для данной интеграции должны быть подготовлены необходимые манифесты. Подробнее о необходимой конфигурации см. раздел «Интеграция с использованием граничного прокси IGEG».

Указать реквизиты для работы с S3-совместимым хранилищем задается через основной secret secret-bpmd.unver.

Необходимо задать значение в ключе
bpmd.designer-backend.app.meta-user-name=app.meta-user-name=<Имя пользователя для доступа к МЕТА>
bpmd.designer-backend.app.meta-password=app.meta-password=<Пароль УЗ для доступа к МЕТА>
файла _passwords.conf

Либо получить из Secret Management System при включенной интеграции. Подробнее настройка данной интеграции описана в разделе «Интеграция с Secret Management».

Импорт моделей из интерфейса BPMD в BPMX#

Предусмотрена возможность отправки бинарных данных через отдельный шлюз граничного прокси IGEG без подписи ОТТ для импорта моделей. Данная возможность – в статусе deprecated и будет удалена в одной из ближайших версий, в целевом варианте используется единый шлюз граничного прокси IGEG для HTTP трафика.

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

bpmd.ose.istio.egress.common.http_deploy_map.enabled=true

Заполнить параметр, по которому подготовятся необходимые манифесты:

bpmd.ose.istio.egress.common.http_deploy_map=

Шаблон заполнения аналогичен стандартной интеграции «Маршрутизация HTTPS запросов», но в качестве порта шлюза граничного прокси IGEG используйте отдельный порт, значение которого при необходимости можно переопределить переменной:

bpmd.ose.istio.egress.common.internal.deploy.port=8090

Сценарий отказа от использования выделенного сервера Nginx/SNGX и переход на использование приложения с UI в системе управления контейнерами#

• Добавить Deployment Unit UI к описанию компонента в файле subsystem.json git-репозитория среды.

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

• В качестве требуемого route bpmu-data-index рекомендуется указывать внешний гео-резервируемый route, аналогичный указываемому ранее на выделенном сервере SynGX/Nginx.

• Для корректной работы в конфигурацию исходящего граничного прокси IGEG необходимо добавить интеграцию с route backend service.

• Добавить к перечню DNS серверных сертификатов новые hostname для UI route.

• Произвести установку Deployment Unit UI в систему управления контейнерами.

• При успешной устанoвке Deployment Unit UI скорректировать route в настройках IAMProxy.

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

Платформенные интеграции#

Интеграция со СПАС#

Манифесты для маршрутизации запросов через граничный прокси IGEG входят в состав дистрибутива BPMD. Для корректной шаблонизации укажите следующие параметры:

Протокол запроса, с учетом маршрута запроса:

bpmd.ose.istio.egress.common.spas.app.config.protocol=http

Адрес сервиса авторизации AUTX:

bpmd.ose.istio.egress.common.spas.ingress.host={{ lookup('custom_vars', 'global.platform.spas.host') }}

Порт шлюза граничного прокси IGEG:

bpmd.ose.istio.egress.common.spas.app.config.port=8080

Порт сервиса авторизации AUTX:

bpmd.ose.istio.egress.common.spas.ingress.port={{ lookup('custom_vars', 'global.platform.spas.port') }}

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

bpmd.server-spas.ose.configmap.application.clipas.spas-server-url
bpmd.server-sudir.ose.configmap.application.clipas.spas-server-url

Токен для работы с AUTX задается через основной secret secret-bpmd.unver.

Необходимо задать значение в ключе
bpm.common.clipas.secret-key=clipas.secret-key=<укажите секретный ключ>
файла _passwords.conf

Либо получается из Secret Management System при включенной интеграции. Подробнее настройка данной интеграции описана в разделе «Интеграция с Secret Management».

Интеграция с компонентом Журналирование (LOGA) Platform V Monitor (OPM)#

Манифесты для маршрутизации запросов через граничный прокси IGEG входят в состав дистрибутива BPMD. Для корректной шаблонизации укажите следующие параметры:

Протокол запроса с учетом маршрута запроса:

bpmd.ose.istio.egress.common.logger.app.config.protocol=http

Адрес компонента Журналирование (LOGA) Platform V Monitor (OPM):

bpmd.ose.istio.egress.common.logger.ingress.host={{ lookup('custom_vars', 'global.platform.logger.host') }}

Порт шлюза граничного прокси IGEG:

bpmd.ose.istio.egress.common.logger.app.config.port=8080

Порт компонента Журналирование (LOGA) Platform V Monitor (OPM):

bpmd.ose.istio.egress.common.logger.ingress.port={{ lookup('custom_vars', 'global.platform.logger.port') }}

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

bpmd.logger-sidecar.ose.deployment.spec.template.spec.containers.logger-sidecar.env.serviceHostname

Интеграции с компонентом Аудит (AUDT) Platform V Audit SE (AUD)#

Включите отправку событий аудита, добавив опцию в параметр:

bpmd.designer-backend.ose.deployment.spec.template.spec.containers.designer-backend.env.security_profile.value='-Daudit.enabled=true'

Манифесты для маршрутизации запросов через граничный прокси IGEG входят в состав дистрибутива BPMD. Для корректной шаблонизации укажите следующие параметры:

Протокол запроса с учетом маршрута запроса:

bpmd.ose.istio.egress.common.audit.app.config.protocol=http

Адрес компонента Аудит (AUDT) Platform V Audit SE (AUD):

bpmd.ose.istio.egress.common.audit.ingress.host={{ lookup('custom_vars', 'global.platform.audit2.host') }}

Порт шлюза граничного прокси IGEG:

bpmd.ose.istio.egress.common.audit.app.config.port=8080

Порт компонента Аудит (AUDT) Platform V Audit SE (AUD):

bpmd.ose.istio.egress.common.audit.ingress.port={{ lookup('custom_vars', 'global.platform.audit2.port') }}

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

bpmd.designer-backend.ose.configmap.application.audit.proxy-uri

Интеграция с компонентом Объединенный мониторинг Unimon (MONA) Platform V Monitor (OPM)#

Модули BPMD публикуют метрики приложения, которые могут быть получены агентом мониторинга компонента Объединенного мониторинга Unimon (MONA) Platform V Monitor (OPM). Все необходимые модули MONA устанавливаются отдельно и независимо от BPMD по инструкции компонента MONA.

Интеграция с Secret Management System#

Компонентом опционально поддерживается хранение секретов в Secret Management System (далее Secman). Имена секретов, которые необходимо создать в Secman, и точки их монтирования совпадают с секретами системы управления контейнерами для прошлых версий.

Интеграция с Secman управляется следующими параметрами файла bpmd_secman.all.conf:

## Общие параметры

# Включение интеграции
bpmd.ose.secret.secman.enabled=true
# URL сервера secman
bpmd.ose.secret.secman.host=<обязательно заполнить параметр>
bpmd.ose.secret.secman.port=<обязательно заполнить параметр>
bpmd.ose.secret.secman.uri=<обязательно заполнить параметр>
# Пространство имен в SecMan
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.namespace=<обязательно заполнить параметр>
# Права для монтиривания конфигурации агента SecMan
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-volumes-default-mode='0400'
# Путь расположения роли для интеграции
bpmd.ose.secret.secman.config.auto_auth.method.mount_path=<обязательно заполнить параметр>
#  Имя роли  для интеграции
bpmd.ose.secret.secman.config.auto_auth.method.config.role=<обязательно заполнить параметр>
# Имя секрета в SecMan из которого будет получаться пароли для работы приложения
bpmd.ose.secret.property.name=bpmd-property
bpmd.ose.secret.ott.property.name=bpmd-ott-passwords

# Путь до образа агента SecMan, при необходимости переопределения. Если параметр не заполнен - будет использован образ по умолчанию
bpmd.ose.annotations.vault.hashicorp.com.agent-image=
# Ресурсы контейнера агента SecMan
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-cpu=100m
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-mem=128Mi
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-cpu=50m
bpmd.ose.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-mem=64Mi

# Ресурсы для подов SecMan в граничных прокси Istio Ingress/Egress
bpmd.ose.istio.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-cpu=500m
bpmd.ose.istio.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-limits-mem=128Mi
bpmd.ose.istio.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-cpu=250m
bpmd.ose.istio.deployment.spec.template.metadata.annotations.vault.hashicorp.com.agent-requests-mem=64Mi

## Настройки KV движка

# Путь до key-value хранилища в secman
bpmd.ose.secret.secman.kv.path=<обязательно заполнить параметр>
# Получение сертификатов из KV движка (true - сертификаты получаем из KV | false - сертификаты получаем из PKI)
# При получении сертификатов из KV, опция получения сертификатов из PKI должна быть отключена
bpmd.ose.secret.secman.kv.cert.enabled=true
# Получение цепочки доверия сертификатов из KV движка (true - сертификаты получаем из KV | false - сертификаты получаем из PKI)
# При получении сертификатов из KV, опция получения сертификатов из PKI должна быть отключена
bpmd.ose.secret.secman.kv.ca.enabled=true


## Настройки PKI движка

# Путь до PKI хранилища в секмане
bpmd.ose.secret.secman.pki.path=<обязательно заполнить параметр>
# Получение сертификатов из PKI движка (true - сертификаты получаем из PKI | false - сертификаты получаем из KV)
# При получении сертификатов из PKI, опция получения сертификатов из KV должна быть отключена
# Common name Subject Alternative Name формируются на основе хостов в роутах
bpmd.ose.secret.secman.pki.cert.enabled=false
# Получение цепочки доверия сертификатов из PKI движка (true - сертификаты получаем из PKI | false - сертификаты получаем из KV)
# При получении сертификатов из PKI, опция получения сертификатов из KV должна быть отключена
bpmd.ose.secret.secman.pki.ca.enabled=false
# Метод получения сертиикатов из PKI
bpmd.ose.secret.secman.pki.method=issue
# Время жизни сертификата
bpmd.ose.secret.secman.pki.ttl=5m
# Common name клиентского сертификата БД. Задается произвольно, либо совпадает с именем пользователя учетной записи БД
bpmd.ose.secret.secman.db.client.cert.cn=<задайте CN>
# Common name клиентского сертификата egress. Задайте произвольно, либо оставьте пустым - в таком случае CN и SAN заполнятся роутом
bpmd.ose.secret.secman.pki.client.cert.cn=

# Порты листенеров ингресса для формирования envoy фильтров для бесшовной ротации сертификатов
bpmd.ose.istio.ingress.common.listeners.enabled=false
bpmd.ose.istio.ingress.common.listeners.ports=11443;11444
bpmd.ose.istio.egress.secman.inner.port=8550

# Поддержка получения сертификатов ОТТ из PKI (true - не поддерживается | false - поддерживается)
bpmd.ose.secret.secman.kv.cert.ott.enabled=true

Для задания чувствительной информации в формате Key-Value, которая будет использоваться в качестве дополнительных параметров при старте приложения, в secman необходимо создать секрет следующего формата:

Имя секрета задается параметром bpmd.ose.secret.property.name=bpmd-property

{
    "client_secret": "***"
}

Предусмотрено получение паролей из KV движка самим приложением без использования vault-sidecar с поддержкой hot reload.

Для соответствия требованиям безопасности имя учетной записи также считается чувствительной информацией и хранится в Security Manager. Для получения приложением учетных записей и паролей для баз данных укажите:

bpmd.ose.secret.secman.appPullSecrets.enable=true

Для хранения учетных данных используются следующие секреты:

Имя секрета для учетных записей для работы с базой данных задается переменной:

bpmd.designer-backend.ose.configmap.application.spring.datasource.datasourceProperties.secretName='designer-postgresql'

И имеет формат:

{
    "username": "Имя пользователя",
    "password": "Пароль"
}

Имя секрета для учетных записей для работы с S3 совместимым хранилищем задается переменной:

bpmd.designer-backend.ose.configmap.application.aws.vaultSecretName='designer-s3'

И имеет формат:

{
    "accessKeyId": "ID ключа доступа",
    "secretAccessKey": "Значение ключа доступа"
}

Имя секрета для учетных записей для работы с Meta задается переменной:

bpmd.designer-backend.ose.configmap.application.meta.secretName='designer-meta'

И имеет формат:

{
    "username": "Имя пользователя",
    "password": "Пароль"
}

Сертификаты запрашиваются в центре сертификации в автоматическом режиме с использованием Secman PKI engine. Автоматический выпуск и использование сертификатов для ОТТ с использованием Secman возможно после перехода на версию ОТТ не ниже 4.3.

В случае использования Key-Value хранилища для сертификатов необходимо создать секреты описанные ниже. Имена секретов указываются в конфигурации компонента и по умолчанию совпадают с именами секретов системы контейнеризации.

Секрет для хранения сертификатов БД

Имя секрета задается параметром bpmd.ose.secret.bd.secretName=designer-certs-bd

{
    "tls.crt": "Cертификат в base64",
    "tls.pk8": "Cертификат в base64",
    "CA.pem": "Cертификат в base64"
}

Секрет для серверных сертификатов граничного прокси

Имя секрета задается параметром bpmd.ose.istio.ingress.deployment.spec.volumes.ingressgateway-certs.secret.secretName=ingressgateway-certs

{
    "tls.crt": "Серверный сертификат в base64",
    "tls.key": "Ключ серверного сертификата в base64"
}

Секрет для цепочки доверия серверных сертификатов граничного прокси

Имя секрета задается параметром bpmd.ose.istio.ingress.deployment.spec.volumes.ingressgateway-ca-certs.secret.secretName=ingressgateway-ca-certs

{
    "CA.pem": "Цепочка доверенных сертификатов в base64"
}

Секрет для клиентских сертификатов граничного прокси

Имя секрета задается параметром bpmd.ose.istio.egress.deployment.spec.volumes.egressgateway-certs.secret.secretName=egressgateway-certs

{
    "tls.crt": "Клиентский сертификат в base64",
    "tls.key": "Ключ клиентского сертификата в base64"
}

Секрет для цепочки доверия клиентских сертификатов граничного прокси

Имя секрета задается параметром bpmd.ose.istio.egress.deployment.spec.volumes.egressgateway-ca-certs.secret.secretName=egressgateway-ca-certs

{
    "CA.pem": "Цепочка доверенных сертификатов в base64"
}

Секрет для ОТТ сертификатов

Имя секрета задается параметром bpmd.ose.istio.ingress.deployment.spec.volumes.designer-backend-ott-certs.secret.secretName=bpmd-ott-certs

{
    "sberflow-designer.p12": "Хранилище сертификатов в base64",
    "<имя хранилища>": "Хранилище доверенных сертификатов в base64"
}

Имена ключей параметризованы. Параметры и описания параметров указаны в файле bpmd_secman.all.conf

Обновление#

Специальной процедуры обновления компонента не предусмотрено.

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

Обновление дополнительных средств защиты информации (Platform V IAM SE, Аудит, OTT, Platform V Synapse Service Mesh, Secret Management System) осуществляется в соответствии с документацией к ним. Количество выбранных средств зависит от выбора клиента с учетом уровня конфиденциальности обрабатываемой информации и иных требований информационной безопасности.

Стратегия обновления pods компонента — Rolling update, с параметрами, указанными в template.

Для обновления:

1. Выполните установку дистрибутива необходимой версии.

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

   • designer-app,

   • designer-backend,

   • один из модулей для режима аутентификации и авторизации server-sudir/server-token/server-spas;

   • designer-lsp-groovy,

   • designer-executor.

Обновление статики на Nginx/SNGX происходит в момент обновления модуля designer-app. Дополнительных действий не требуется.

Процедура установки подробно описана в разделе «Установка» настоящего документа.

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

Необходимость и расписание создания бэкапов БД регулируется сотрудниками сопровождения или администраторами.

Удаление#

Процедура удаления BPMD (designer-backend, designer-executor, designer-lsp-groovy (один из установленных модулей server-sudir/server-token/server-spas)) представляет собой удаление собранного namespace.

При удалении UI BPMD (designer-app) необходимо:

1. Удалить архив со статикой сервера Nginx/SNGX.

2. Удалить Locations из конфигурации Nginx/SNGX.

Для удаления БД:

• Подключиться к БД через любой клиент СУБД (например: встроенный клиент PostgreSQL, dbeaver, pgadmin и т.п):

  • удалить bpmd.

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

1. Проверка через health check

Проверить работоспособность компонента BPMD (designer-backend, designer-executor,designer-lsp-groovy (один из модулей для режима аутентификации и авторизации server-token/server-sudir/server-spas) можно с помощью команды health check:

http://localhost:8086/actuator/health

Данный запрос должен отправляться с терминала pod.

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

Проверить работоспособность UI Designer Platform V Flow (designer-app) можно перейдя по URL сервиса. Если после перехода попадаем на UI с авторизацией, то designer-app работает успешно.

2. Через UI среды контейнеризации

Проверить успешность установки сервиса можно через UI среды контейнеризации.

Для этого нужно перейти на вкладку Pods. Если все Pods находятся в статусе running, значит сервис успешно установлен.

3. Через вызов API

Для проверки успешности установки сервиса можно выполнить запрос по API.

Проверка интеграции с внешними компонентами:

Проверку интеграции с внешними компонентами можно осуществить, выполнив запрос по API.

Откат#

Откат компонента#

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

Стратегией отката pods компонента является Rolling update, с параметрами, указанными в template.

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

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

   • Откат должен быть произведен для:

     • UI компонента BPMD designer-app;

     • Компонент BPMD designer-backend, designer-executor, designer-lsp-groovy один из модулей для режима аутентификации и авторизации server-token/server-sudir/server-spas.

2. При откате на версию без mTLS в проекте – дополнительно удалите файлы, описанные в разделе «Взаимная аутентификация внутри проекта».

Процедура установки подробно описана в разделе «Установка» настоящего документа.

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

Откат версии можно осуществить путем изменения config-переменных в config-файлах на конфигурационные параметры необходимой версии (данный метод отката не рекомендован).

Необходимость и расписание создания бэкапов БД регулируется сотрудниками сопровождения или администраторами.

Откат БД#

Скрипты, необходимые для отката к предыдущим версиям, находятся в changelog базы данных в файле rollback.sql в папке соответствующей версии.

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

1. Если при старте pod возникает следующая ошибка:

l.lockservice.StandardLockService: Waiting for changelog lock.... liquibase.executor.jvm.JdbcExecutor: SELECT LOCKED FROM bpmd.databasechangeloglock WHERE ID=1

Необходимо выполнить следующую операцию:

• delete FROM bpmd.databasechangeloglock WHERE ID=1

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

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

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

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