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

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

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

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

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

• Red Hat Enterprise Linux Server 7.7;

• Red Hat OpenShift 4.5.

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

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

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

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

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

• Сервера БД;

• Серверов Nginx.

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

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

• ФП Аудит;

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

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

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

• БД PostgreSQL.

Установка#

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

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

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

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

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

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

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

После получения проекта в OSE его требуется настроить для работы с реестром и Jenkins job install_eip.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. Передать данный токен администраторам проектной области jenkins, в которой размещена Jenkins job install_eip для того чтобы в проекте jenkins создать новый credentionals с типом secret text. ID рекомендуется указать равным названию проекта в ose - т.к. у каждого проекта уникальный токен, в поле secret text вставить токен скопированный в п.3.

5. Id созданного credentionals (читай название namespace) нужно будет указать в конфигурации install_eip.

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

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

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

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

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

   • ТУЗ АС — bpmd-admin;

   • Имя схемы — bpmd;

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

3. Подключиться к PostgreSQL через pgadmin:

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

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

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

   • В поле port указать порт, который был указан в почте (обычно это 5433);

   • В поле Maintenance database указать название базы bpmd;

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

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

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

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

   • для того чтобы открыть терминал запуска команд, необходимо нажать правой кнопкой мыши по БД (bpmd) и выбрать Query Tool;

   • выполнить команду set role as_admin; (альтернатива при не корректном назначении владельца группы - set role db_admin)

   • смена транспортного пароля для ТУЗ (пароль по умолчанию Supertransport$123) alter user "bpmd-admin" with password 'password'; пароль должен состоять из 15 символов включая спецсимволы;

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

   • выдать привилегии для ТУЗ командой grant ALL on schema bpmd to "bpmd-admin"; альтернативный вариант (GRANT CREATE, USAGE ON SCHEMA bpmd TO "bpmd-admin";)

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

   • liquibase скрипт при update блокирует параметр в базе (можно проверить командой sql select * from DATABASECHANGELOGLOCK;) если параметр - Locked true, необходимо выполнить команду sql truncate table DATABASECHANGELOGLOCK для очистки значения в таблице;

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

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

6. ДОП команды:

   1. перечислить список схем: sql select schema_name from information_schema.schemata;

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

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

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

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

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

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

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

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

   Для получения доступа к репозиторию и Jenkins job необходимо создать заявку в jira.

   Репозиторий настроек подсистемы и стендов - branch = master

   Файл конфигурации — configuration.xml.

   URL Jenkins job.

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

   Ветка для настройки Pipeline в DPM и прохождения вплоть до ИФТ. Затем администраторы ПСИ сливают эту ветку с веткой ПСИ. Далее все нижеописанные шаги корректируются руками администраторов ПСИ.

   Доступ к job не выдается, запуск только через DPM. Доступ к репозиториям есть у админинистраторов стендов.

   Репозиторий скриптов branch = DEV.

   Репозиторий настроек подсистемы и стендов — branch = master.

   Файл конфигурации — configuration.xml.

   URL Jenkins job.

3. ПСИ/Пром ветка (ПСИ/ПРОМ)

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

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

Для этого нужно воспользоваться инструкцией в Confluence (Выполнить пункты 1-14, с остальными пунктами ознакомиться).

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

Заполнить позже

В файле os_props.conf указаны все стендозависимые переменные со значениями, которыми будут параметризоваться конфигурационные файлы OpenShift при установке.

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

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

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

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

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

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

• designer-secret — секрет для передачи Java опций с паролем от БД, и другой "чувствительной" информацией в designer-backend;

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

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

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

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

• designer-ott-certs - (опционально)секрет с сертификатами ОТТ designer-app;

• designer-ott-passwords - (опционально) секрет с паролями для сертификатов ОТТ designer-app;

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

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

Необходимо:

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

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

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

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

Закодировать в base64 можно следующим образом:

• Для Windows можно воспользоваться утилитой git bash:

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

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

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

• Для Linux:

  • base64 -w0 password.txt > password.base64.

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

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

• На текущий момент необходимые java_opts:

-Dspring.datasource.password=*** -Dstandin.datasource.password=*** -Dauth.token.secret=some_string # опционально для дев и дев+spas режимов -Dclipas.secret-key=123456 # при использовании SPAS/ОСА -Dapp.meta-password=***

Шаблон ingressgateway-certs#

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

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

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

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

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

Шаблон egressgateway-certs#

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

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

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

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

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

Шаблон designer-ott-certs#

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

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

Шаблон designer-ott-passwords#

Пароли для keyStore ОТТ

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

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

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

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

• Для всех тестовых стендов используются одинаковые сертификаты, поэтому можно забрать из репозитория стенда BOSTON уже завольтованные секреты envoy-secret и fluent-bit-sct.

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

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

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

• Архив со статикой портала включен в дистрибутив поставки и располагается в — other/nginx/designer-app-static-${version};

• Конфигурация locations nginx включена в дистрибутив поставки и располагается в — other/nginx/designer-app.conf.

• В action.xml необходимо указать стандартный action — deploy_nginx_default;

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

Пример system_nginx_default.conf:

worker_processes 1;

events { worker_connections 1024; }

http {
    sendfile on;
    include    /etc/nginx/mime.types;
    charset UTF-8;
    proxy_http_version 1.1;

    server {
        listen 0.0.0.0:8080;
        port_in_redirect off;

        location / {
            root    /usr/share/nginx/html/;
            index   index.html;
        }

        location /designer-app {
            alias            /usr/share/nginx/html/designer-app/;
        }

        location /designer-app/user/ {
            proxy_pass         $DESIGNER_BACKEND_URL/user/;
        }
    }
}

Настройка автоматической загрузки ролевой модели#

• Файл ролевой модели включен в дистрибутив поставки и располагается в — /other/roleModel/roleModel.xml.

Установка приложения в OSE#

Установка производится запуском job install_eip с выбором стенда и модуля, и указанием ссылки на дистрибутив.

Данный job скачивает дистрибутив из nexus-sbrf, параметризует template OpenShift и производит их доставку в проект OpenShift, в котором производится развертывание приложения.

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

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

• В проекте OpenShift перейти в раздел Workloads -> Deployments Configs и в интересующем dc, перейти через вкладку Pods на связанные ПОДы;

• В связанном Pod можно посмотреть события (event) и логи (logs).

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

• файл ролевой модели содержится в дистрибутиве;

• в action.xml необходимо указать стандартный action — configure_spas.

Установка designer-app в проект openshift#

При установке в OSE - поднимается pod с nginx и статикой.

При старте портала ему необходимо передать адрес backend через переменную DESIGNER_BACKEND_URL

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

Для игнорирования установки портала в OSE в репозитории стенда, в файле os_ignore.conf нужно указать имя template OpenShift — designer-app-template.yaml.

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

Конфигурация приложения задается через файл application.yml который идет в составе configMap в template OpenShift. В него перенесены все параметры ранее задававшиеся через JVM-опции Стендозависимые параметры представлены в виде переменных, значения которых можно переопределить через репозиторий среды

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

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

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

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

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

• keycloak — аутентификация с помощью сервиса keycloak.

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

• СУДИР;

• SPAS.

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

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

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

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

Пример roleModel.xml:

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

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

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

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

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

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

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

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

-Dspring.profiles.active=anonymousDeploy

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

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

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

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

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

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

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

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

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

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

Интеграция с СУДИР/IAMProxy (опционально)#

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

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

Режим Keycloak#

Информация об учетных записях пользователей хранится в Keycloak.

В случае успешной аутентификации и авторизации пользователя, на стороне сервера будет сгенерирован JWT токен.

Подробнее о настройке режимов авторизации см. "Руководство по системному администрированию"

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

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

Переменные designer-app#

INCLUDE_DESIGNER_APP_PARAMETERS

Переменные designer-backend#

INCLUDE_DESIGNER_BACKEND_PARAMETERS

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

INCLUDE_INGRESS_PARAMETERS

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

INCLUDE_EGRESS_PARAMETERS

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

Интеграция с платформенными сервисами#

Аудит#

В связи с требованиями безопасности необходимо осуществлять передачу информации о произведенных действиях в АС Аудит.

Для настройки отправки сообщений в АС Аудит необходимо в файле application.yml определить следующие переменные:

Взаимодействие производится через Rest.

Среда исполнения осуществляет отправку следующих данных для фиксации события в АС Аудит:

1. Метамодель - http://audit2-client-proxy.apps.test-ose.ca.sbrf.ru/v1/metamodel;

2. Событие - http://audit2-client-proxy.apps.dev-gen.sigma.sbrf.ru/v1/event.

Метамодель

curl -X POST http://audit2-client-proxy.apps.test-ose.ca.sbrf.ru/v1/metamodel -d @proxy-metamodel.json -H "Content-Type: application/json"

Пример содержимого proxy-metamodel.json (метамодель):

{
  "metamodelVersion": "00001",
  "module": "test_proxy_module",
  "description": "Тестовый модуль для тестирования proxy-приложения",
  "events": [
    {
      "name": "test-name-1",
      "description": "Тестовое событие №1",
      "success": true,
      "mode": "speed",
      "params": [
        {
          "name": "test-name-11",
          "description": "Тестовый параметр 1 события 1"
        }
      ]
    }
  ]
}

Событие

curl -X POST http://audit2-client-proxy.apps.dev-gen.sigma.sbrf.ru/v1/event -d @proxy-event.json -H "Content-Type: application/json"

Пример proxy-event.json (событие):

{
  "metamodelVersion": "00001",
  "name": "test-name-1",
  "session": "test_user_ticket:1234567987987987",
  "module": "test_proxy_module",
  "createdAt": 1585198271185,
  "userLogin": "test-proxy-user",
  "userName": "Иванов Иван Иванович",
  "userNode": "proxy-audit",
  "params": [
    {
      "name": "test-name-11",
      "value": "Значение параметра 1 события 1"
    }
  ],
  "tags": [
  "tag 1",
  "tag 2",
  "tag 3"
]
}

Параметры фиксируемые в АС Аудит#

Заполнить позже

Журналирование#

Протоколирование операций для их дальнейшего анализа осуществляется в следующую директорию:

-DloggingDir = home/logs
-DloggingJSONFile = log.json

Для отправки событий журнала в Logger, sidecar-контейнер должен быть подключен к тому же каталогу, что обеспечит ему возможность чтения и обработки событий.

Для корректного разбора событий необходимо, чтобы формат событий соответствовал шаблону разбора fluent-bit. Формат событий можно описать в xml-файле конфигурации для библиотеки logback.

Запись лога производится в json формате и требует подключения зависимости в pom.xml:

<dependency>
<groupId>net.logstash.logback</groupId>
<artifactId>logstash-logback-encoder</artifactId>
<version>6.3</version>
</dependency>

Для работы интеграции designer-app с Logger необходимо:

1. Включить логгирование в приложении:

   • -Dlogging.json;

   • -Dlogging.json.dir=/home/logs;

   • -Dlogging.json.file=log.json;

2. Указать адрес и порт сервиса приема событий Logger на стенде в файле конфигурации стенда. Значения для конкретного стенда можно взять со страницы в Confluence:

   • serviceHostname;

   • servicePort.

Подробнее настройка взаимодействия с Logger описана в статье "Руководство администратора по запуску sidecar контейнера".

Интеграция с Прикладным журналом (опционально)#

На текущий момент интеграция с ПЖ отключена.

Для отключения интеграции с ПЖ все настройки добавлены в application.yml

####### ОТКЛЮЧЕНИЕ ПЖ (временно)
standin:
  enabled: false
  cloud:
    client:
      stub: true
      zoneId: test
      mmt-proxy-url: localhost
      kafka.bootstrapServers: localhost

Обновление#

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

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

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

   • обновление должно быть произведено для двух модулей: designer-app, designer-backend.

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

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

Удаление#

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

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

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

http://<URL>/actuator/health

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

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

Откат#

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

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

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

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

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

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

Основные сценарии связанные с администрированием Designer Platform V Flow описаны в "Руководстве по системному администрированию".

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

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

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

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

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