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

В руководстве приведены инструкции по установке компонента DataSpace Core (DSPC) продукта Platform V DataSpace (APT).

О документе#

Настоящий документ содержит описание процесса установки и настройки компонента DataSpace Core продукта Platform V DataSpace (далее — DataSpace или компонент).

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

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

Расшифровку основных понятий см. в документе "Термины и определения".

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

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

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

Имеются следующие требования к ПО:

• На серверы приложений, использующих DataSpace, должна быть установлена технологическая платформа Kubernetes или Red Hat OpenShift или аналогичная среда контейнеризации приложений.

• Для создания проекта с помощью архетипа необходим доступ к репозиторию Maven Central или его зеркалу.

• Наличие БД (PostgreSQL, H2 или Oracle). Для возможности репликации в StandIn при использовании DataSpace необходимо наличие второй БД (StandIn БД).

• Создан и настроен namespace Kubernetes (см. раздел "Чек-лист по настройке namespace Kubernetes").

• Наличие Kubectl на компьютере, с которого производится установка.

• Наличие пакетного менеджера Helm на ПК, с которого производится установка.

• При построении кластера серверов приложений сервиса DataSpace в случае использования алгоритма SNOWFLAKE для обеспечения уникальности генерации прикладных идентификаторов необходимо соблюсти уникальность IPv4-адресов узлов кластера. Детали см. в разделе "Генерация идентификатора алгоритмом SNOWFLAKE" в документе "Руководство по ведению модели данных".

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

Примечание:

*

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

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

**

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

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

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

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

Примечание:

***

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

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

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

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

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

Требования для запуска приложений DataSpace расчете на 1 pod:

Примечание

Количество pod DataSpace определяется исходя из требований надежности и производительности (рекомендуется предварительное проведение нагрузочного тестирования).

По умолчанию число pod для каждого разворачиваемого приложения DataSpace равно 1.

В дополнение к этому серверы приложений, использующих DataSpace, должны отвечать требованиям к остальным компонентам реализуемых приложений.

Типовые требования к dev КТС для БД PostgreSQL:

При использовании опции функционального StandIn необходимо иметь две БД на разных КТС.

Чек-лист по настройке namespace Kubernetes#

Пространство Kubernetes будет считаться готовым к развертыванию сервисов DataSpace после выполнения всех следующих требований:

• В namespace Kubernetes создан secret типа Dockersecret с логином и паролем ТУЗ.

• Созданный secret прописан в service accounts: default и dataspace-core.

• Произведена настройка Ingress Gateway (опционально).

• Произведена настройка Egress Gateway (опционально).

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

Подготовка базы данных#

Для работы DataSpace требуется развернуть БД. Поддерживаются СУБД PostgreSQL 12.x+, а также Oracle Database 12.2+ (далее Oracle). Для dev-тестов может использоваться H2 версии не ниже 1.4.200.

Рекомендуется использовать продукт Platform V Pangolin SE.

Примечание

Для именования объектов БД (учетных записей, ролей, схем, табличных пространств и т.д.) следует руководствоваться требованиями используемой СУБД для имен без использования кавычек. Обычно в допустимый набор символов входят латинские буквы (a-z, A-Z), цифры (0-9) и символ подчеркивания ( _ ), имена должны начинаться с буквы или символа подчеркивания.

Создание учетных записей#

Для работы модулей DataSpace и для работы скриптов развертывания в БД необходимо создать технологические учетные записи (ТУЗ):

Создание схемы при использовании PostgreSQL#

Необходимо создать:

• Кластер PostgreSQL.

• Роли as_admin, as_TUZ (valid until указать в соответствии с требованиями). Роль as_admin будет являться владельцем схемы, как и в случае использования БД Platform V Pangolin SE.

   -- Скрипт выполняет DB admin c привилегией на создание ролей и пользователей
   CREATE USER as_admin WITH PASSWORD <пароль> LOGIN NOCREATEROLE NOCREATEDB NOSUPERUSER NOINHERIT NOREPLICATION NOBYPASSRLS VALID UNTIL '2099.12.31';
   CREATE USER "as_TUZ" WITH PASSWORD <пароль> LOGIN NOCREATEROLE NOCREATEDB NOSUPERUSER NOINHERIT NOREPLICATION NOBYPASSRLS VALID UNTIL '2099.12.31';

• Каталоги Linuх для табличных пространств. Пользователь Linux Postgres должен иметь для них все права (mkdir /pgdata/11/ts/dspc_t; chown postgres /pgdata/11/ts/dspc_t; chmod u+rwx /pgdata/11/ts/dspc_t).

• Табличные пространства необходимого размера, БД и схему. Необходимо выдать права владельца.

  -- Названия объектов БД и пути даны в качестве примера (обычно они подходят для типовой установки)
  -- Их необходимо проверить и заменить на актуальные
  -- 1) Создание табличного пространства. Выполняет DB admin.
  CREATE TABLESPACE dspc_t OWNER as_admin LOCATION '/pgdata/11/ts/dspc_t';
  GRANT CREATE ON TABLESPACE dspc_t TO as_admin;
  -- 1.1) Следующие 2 команды в случае, если для индексов используется отдельное табличное пространство.
  CREATE TABLESPACE dspc_i OWNER as_admin LOCATION '/pgdata/11/ts/dspc_i';
  GRANT CREATE ON TABLESPACE dspc_i TO as_admin;
  -- 2) Создаем БД. Выполняет DB admin
  CREATE DATABASE dspc_db OWNER as_admin ENCODING 'UTF-8' LC_COLLATE 'en_US.UTF-8' LC_CTYPE 'en_US.UTF-8' TABLESPACE dspc_t;
  -- в зависимости от локали в системе параметры LC_COLLATE и LC_CTYPE могут быть указаны с прописной utf-8. Команда для проверки:
  -- SELECT datname, datcollate, datctype FROM pg_database WHERE datname LIKE 'template%';
  GRANT ALL PRIVILEGES ON DATABASE dspc_db TO as_admin;
  -- 3) Создаем схему. Выполняет DB admin или as_admin
  CREATE SCHEMA dspc AUTHORIZATION as_admin;
  REVOKE ALL ON SCHEMA public FROM public;
  GRANT ALL PRIVILEGES ON SCHEMA dspc TO as_admin;
  ALTER DEFAULT PRIVILEGES IN SCHEMA dspc GRANT ALL PRIVILEGES ON TABLES TO as_admin;
  GRANT USAGE ON SCHEMA dspc TO "as_TUZ";
  GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA dspc TO "as_TUZ";
  ALTER DEFAULT PRIVILEGES IN SCHEMA dspc GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "as_TUZ";
  ALTER ROLE as_admin SET search_path to 'dspc';
  -- 4) Назначаем as_admin владельцем схемы (опционально, если схему создавала УЗ с ролью as_admin)
  ALTER SCHEMA dspc OWNER TO as_admin;
  

• ТУЗ владельца схемы — dspc. ТУЗ приложения — dsc_appl, dsa_appl, dss_appl. Выдать ТУЗ права DML на таблицы схемы DML.

  -- Выполняет DB admin с привилегиями на создание ролей
  -- ТУЗ для Liquibase
  CREATE USER dspc WITH ENCRYPTED PASSWORD <пароль> NOINHERIT;
  ALTER ROLE dspc SET search_path to 'dspc';
  GRANT as_admin TO dspc;
  ALTER ROLE dspc SET ROLE TO as_admin; -- as_admin является владельцем схемы
  -- ТУЗ для модуля dataspace-core
  CREATE USER dsc_appl WITH ENCRYPTED PASSWORD <пароль> INHERIT;
  GRANT "as_TUZ" TO dsc_appl;
  ALTER ROLE dsc_appl SET search_path to 'dspc';
  -- ТУЗ для модуля dataspace-applier  — если необходимо
  CREATE USER dsa_appl WITH ENCRYPTED PASSWORD <пароль> INHERIT;
  GRANT "as_TUZ" TO dsa_appl;
  ALTER ROLE dsa_appl SET search_path to 'dspc';
  -- ТУЗ для модуля dataspace-search  — если необходимо
  CREATE USER dss_appl WITH ENCRYPTED PASSWORD <пароль> INHERIT;
  GRANT USAGE ON SCHEMA dspc TO dss_appl;
  ALTER ROLE dss_appl SET search_path to 'dspc';
  GRANT SELECT ON ALL TABLES IN SCHEMA dspc TO dss_appl;
  ALTER DEFAULT PRIVILEGES IN SCHEMA dspc GRANT SELECT ON TABLES TO dss_appl;
  

Создание схемы при использовании Oracle#

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

1. Создать экземпляр БД Oracle.

2. Создать табличные пространства DSPC_T, DSPC_I необходимого размера (при использовании LOB-типов данных — также табличное пространство DSPC_L).

3. Создать ТУЗ владельца схемы — DSPC (схема будет называться также).

4. Дать ТУЗ DSPC QUOTA UNLIMITED на оба табличных пространства.

5. Дать ТУЗ DSPC привилегии на создание объектов схемы grant CREATE TABLE, CREATE VIEW, CREATE TRIGGER to DSPC.

6. Создать роли DSPC_ROLE, DSPC_READ_ROLE.

7. Создать ТУЗ приложения — DSC_APPL, DSA_APPL, DSS_APPL.

8. Дать ТУЗ права на таблицы схемы DML.

9. При необходимости создать logon-триггеры для выбора в качестве рабочей схемы DSPC.

Для выполнения вышеуказанных пунктов 2-7 можно использовать скрипт инициализации: схема и ТУЗ (подставить необходимые параметры tablespace, имена схем и ТУЗ):

-- replace placeholder ${default_password} with actual value
-- create tablespace — assign real names and locations and size
CREATE TABLESPACE dspc_t DATAFILE 'dspc_t' SIZE  10G AUTOEXTEND ON ONLINE;
CREATE TABLESPACE dspc_i DATAFILE 'dspc_i' SIZE  10G AUTOEXTEND ON ONLINE;

-- create schema owner
CREATE USER dspc
IDENTIFIED BY ${default_password}
DEFAULT TABLESPACE dspc_t
TEMPORARY TABLESPACE TEMP;			

-- assign quota
alter user dspc QUOTA UNLIMITED ON dspc_t;
alter user dspc QUOTA UNLIMITED ON dspc_i;
-- allow login
grant CREATE SESSION, ALTER SESSION to dspc;
-- allow object creation
grant CREATE TABLE, CREATE VIEW, CREATE TRIGGER to dspc;	

-- create role for TUZ
create role dspc_role;
create role dspc_read_role;

-- create dsc_appl TUZ
CREATE USER dsc_appl
IDENTIFIED BY ${default_password}
PASSWORD EXPIRE
DEFAULT TABLESPACE dspc_t
TEMPORARY TABLESPACE TEMP;

grant dspc_role to dsc_appl;
alter user dsc_appl default role ALL;
grant CREATE SESSION, ALTER SESSION to dsc_appl;

-- create dsa_appl TUZ
CREATE USER dsa_appl -- если необходимо
IDENTIFIED BY ${default_password}
PASSWORD EXPIRE
DEFAULT TABLESPACE dspc_t
TEMPORARY TABLESPACE TEMP;

grant dspc_role to dsa_appl;
alter user dsa_appl default role ALL;
grant CREATE SESSION, ALTER SESSION to dsa_appl;

-- create dss_appl TUZ — если необходимо
CREATE USER dss_appl
IDENTIFIED BY ${default_password}
PASSWORD EXPIRE
DEFAULT TABLESPACE dspc_t
TEMPORARY TABLESPACE TEMP;

grant dspc_read_role to dss_appl;
alter user dss_appl default role ALL;
grant CREATE SESSION, ALTER SESSION to dss_appl;

Для выполнения пункта 9 можно использовать скрипт создания logon-триггеров:

create or replace trigger dsc_appl.set_default_schema_dsc_appl
after logon on dsc_appl.schema
begin
  execute immediate 'alter session set current_schema=dspc';
end;
/
create or replace trigger dsa_appl.set_default_schema_dsa_appl
after logon on dsa_appl.schema
begin
  execute immediate 'alter session set current_schema=dspc';
end;
/
create or replace trigger dss_appl.set_default_schema_dss_appl
after logon on dss_appl.schema
begin
  execute immediate 'alter session set current_schema=dspc';
end;
/

Для выполнения пункта 8 после каждого выполнения job создания/обновления схемы необходимо выполнять скрипт по грантованию доступов для ролей dspc_role и dspc_read_role:

declare
  granttorole varchar2(254);
  granttoreadrole varchar2(254);
begin
	granttorole := 'dspc_role';
	granttoreadrole := 'dspc_read_role';
	for i in (select t.table_name
				from sys.all_tables t
				where t.owner = USER
				  and NOT (t.table_name like ('DATABASECHANGE%')))
	loop
		execute immediate 'grant SELECT, INSERT, UPDATE, DELETE ON ' || i.table_name || ' to ' || granttorole;
		execute immediate 'grant SELECT ON ' || i.table_name || ' to ' || granttoreadrole;
	end loop;
end;
/

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

Примечание

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

При развертывании на БД Oracle при использовании Binary или Text-атрибутов (BLOB/CLOB полей) целесообразно создать третье табличное пространство dspc_l, в котором будут создаваться LOB-объекты.

В job развертывания DataSpace указывается ТУЗ dpsc и его пароль в качестве владельца схемы БД. Также указывается ТУЗ приложений dsc_appl, dsa_appl, dss_appl, табличные пространства dspc_t, dspc_i, dspc_l и имя схемы dspc.

Настройка соединения с БД в сервисах DataSpace#

В данном разделе описаны шаги настройки сервисов DataSpace и пространства Kubernetes (или OpenShift) для подключения БД (PostgreSQL или Oracle).

Шаги настройки на Kubernetes (или OpenShift)#

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

1. Получить и настроить базу(ы) данных (см. раздел "Подготовка базы данных").

2. Создать secret(s) с параметрами подключения к базе(-ам) данных в Kubernetes (или OpenShift). Смотрите раздел "Создание secret для базы данных в Kubernetes (или OpenShift)".

3. Обеспечить доступ из пространства Kubernetes (или OpenShift) к базе(-ам) данных.

4. Передать в параметры названия созданных secrets в сервисы DataSpace при развертывании в Kubernetes (или OpenShift). Названия параметров:

   • helm:

        appConfig:
          db:
            main:
              secret: "main-db-secret" # имя созданного секрета базы данных main
            standin:
              secret: "standin-db-secret" # имя созданного секрета базы данных функционального standin 
     

     • Platform V DevOps Tools: Секреты создаются автоматически по информации из пункта Проливка Liquibase-скриптов на базу данных

Создание secret для базы данных в Kubernetes (или OpenShift)#

Есть разные варианты хранения секретов: обычные секреты k8s/OpenShift и хранение в системе создания, хранения и распространения секретов HashiCorp Vault.

Для конфигурирования на стендах Kubernetes (или OpenShift) используются объекты secret, содержащие stringData c параметрами подключения. Создать secret можно через cli-приложение (OpenShift cli или kube_ctl).

Внимание!

Secrets для Main и StandIn базы данных отличаются по своему содержимому.

Примечание

В случае использования HashiCorp Vault конфигурация подключения к БД прописывается в ConfigMap приложения (в рамках использования pipeline от продукта Platform V DevOps Tools см. раздел "Настройка параметров подключения к БД").

Пример secret для основной (Main) базы данных PostgreSQL#

apiVersion: v1
kind: Secret
metadata:
  name: main-db-secret
data:
stringData:
  secret.properties: |-
    spring.datasource.username=dsc_appl
    spring.datasource.password=<пароль>
    spring.datasource.url=jdbc:postgresql://dataspace-core-deposit-16923100-pgdb:5432/dataspace
    dataspace.datasource.primary.dbschema=dspc
    spring.datasource.driver-class-name=org.postgresql.Driver
    spring.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
    spring.jpa.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

Пример secret для StandIn базы данных PostgreSQL#

apiVersion: v1
kind: Secret
metadata:
  name: standin-db-secret
data:
stringData:
  secret.properties: |-
    standin.datasource.username=dsc_appl
    standin.datasource.password=<пароль>
    standin.datasource.url=jdbc:postgresql://dataspace-core-deals-17731375-standin-pgdb:5432/dataspace
    dataspace.datasource.standin.dbschema=dspc
    standin.datasource.driver-class-name=org.postgresql.Driver
    standin.jpa.database-platform=org.hibernate.dialect.PostgreSQLDialect
    standin.jpa.hibernate.dialect=org.hibernate.dialect.PostgreSQLDialect

Пример secret для основной (main) базы данных Oracle#

apiVersion: v1
kind: Secret
metadata:
  name: main-db-secret
data:
stringData:
  secret.properties: |-
    spring.datasource.username=dsc_appl
    spring.datasource.password=dsc_appl_password
    spring.datasource.url=jdbc:oracle:thin:@<ip-адрес>:1521:pprb
    dataspace.datasource.primary.dbschema=dspc
    spring.datasource.driver-class-name=oracle.jdbc.OracleDriver
    spring.jpa.database-platform=org.hibernate.dialect.Oracle12cDialect
    spring.jpa.hibernate.dialect=org.hibernate.dialect.Oracle12cDialect

Пример secret для StandIn базы данных Oracle#

apiVersion: v1
kind: Secret
metadata:
  name: standin-db-secret
data:
stringData:
  secret.properties: |-
    standin.datasource.username=dsc_appl
    standin.datasource.password=dsc_appl_password
    standin.datasource.url=jdbc:oracle:thin:@<ip-адрес>:1521:pprbsi
    dataspace.datasource.standin.dbschema=dspc
    standin.datasource.driver-class-name=oracle.jdbc.OracleDriver
    standin.jpa.database-platform=org.hibernate.dialect.Oracle12cDialect
    standin.jpa.hibernate.dialect=org.hibernate.dialect.Oracle12cDialect

Описание параметров, используемых в secrets#

Используются следующие параметры:

• datasource.username — имя пользователя;

• datasource.password — пароль пользователя;

• datasource.url — jdbc-строка соединения с базой данных;

• dbschema — имя схемы;

• datasource.driver-class-name — имя драйвера для соединения с БД;

• database-platform — имя диалекта БД;

• hibernate.dialect — имя диалекта БД, аналогично значению database-platform.

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

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

• опциональная ручная установка сервиса;

• рекомендованная автоматизированная установка.

Установка#

Примечание

Установка в DropApp полностью аналогична установке в Kubernetes.

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

Раздел содержит описание сборки дистрибутива и образов сервисов DataSpace.

Ручная проливка Liquibase скриптов на СУБД#

Примечание

В шаблонном проекте, сформированном на базе архетипа (см. "Быстрый старт") существуют профили dbScriptsWithOracle и dbScriptsWithoutOracle, по которым формируется архив по пути *-model-jpa/target/db/db-scripts.zip.

• dbScriptsWithOracle - добавляется JDBC драйвер для проливки Liquibase скриптов на СУБД Postgres и Oracle;

• dbScriptsWithoutOracle - добавляется JDBC драйвер для проливки Liquibase скриптов только на СУБД Postgres.

Все необходимое для проливки liquibase скриптов лежит в полученном архиве.

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

Определение Liquibase параметров запуска (LIQUIBASE_OPTS):

Определение Java параметров запуска (JAVA_OPTS):

export JAVA_OPTS="<JAVA_OPTS>"
export LIQUIBASE_OPTS="<LIQUIBASE_OPTS>"
export LIQUIBASE_HOME=`pwd` # Абсолютный путь до директории исполнения команды
java ${JAVA_OPTS} -classpath './*' liquibase.integration.commandline.Main ${LIQUIBASE_OPTS} update

Сборка базового образа#

В составе дистрибутива компонента DSPC (см. документ "Быстрый старт") в папке package/docker лежит все необходимое для сборки базовых образов сервисов DataSpace.

Основной передаваемый при сборке аргумент — ARG BASE_IMAGE — URL образа операционной системы c OpenJDK, на основе которой будет собираться базовый образ DataSpace.

Сборка производится следующим образом:

• Выполняется команда сборки образа из каталога package дистрибутива:

  export BASE_IMAGE=<url образа>
  docker build -f ./docker/<имя сервиса>/Dockerfile -t <имя:тэг> ./ --build-arg BASE_IMAGE
  

Ручная сборка образов сервисов DataSpace с моделью потребителя#

В данном разделе описаны шаги сборки образов сервисов DataSpace с целью их дальнейшей инсталляции в Kubernetes (или OpenShift).

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

1. Выбрать версию базового дистрибутива сервиса DataSpace.

2. Скачать базовый дистрибутив.

3. Разработать модель согласно инструкциям, описанным в документе "Руководство по ведению модели данных".

4. Осуществить генерацию артефактов согласно инструкциям, описанным в разделе "Генерация артефактов серверного компонента" документа "Структура артефактов DataSpace".

Примечание

dataspace-core.model.packagesToScan - в этом параметре должно фигурировать значение пакета ранее созданной модели.

5. Создать следующую структуру папок и файлов:

   • package

     • bh/

       • ext/ — папка с JPA-классами, сгенерированными в шаге 4.

       • lib/ — папка, в которую можно добавить дополнительные библиотеки. Эти библиотеки будут добавлены в classpath сервиса DataSpace (например, oracleJdbcDriver).

6. Скопировать сгенерированные на шаге 4 JPA-классы в формате jar (например, quickstart-model-jpa-1.0.0.jar) в созданную папку ./bh/ext.

7. В случае необходимости работы с Oracle, добавить в созданную папку ./bh/lib артефакт OJDBC. Пример maven-зависимости OJDBC:

   <artifactItem>
       <groupId>com.oracle.jdbc</groupId>
       <artifactId>ojdbc8</artifactId>
       <version>18.3.0.0</version>
   </artifactItem>
   

8. Создать в папке ./package/docker файл Dockerfile со следующим ниже содержимым:

   • urlToDataspaceService — ссылка на базовый образ интересующего сервиса DataSpace.

   • serviceVersion — версия данного сервиса DataSpace.

   ARG BASE_IMAGE=urlToDataspaceService:serviceVersion
   FROM ${BASE_IMAGE}
   

9. Должна получиться следующая структура файлов:

   • package (папка)

     • bh (папка)

       • ext

         • model-jpa.jar

       • lib

         • ojdbc8.jar (опционально, в дистрибутиве не поставляется)

   • docker (папка)

     • Dockerfile

10. В корне папки package выполнить команду сборки docker образа, где yourServiceName:tag — имя и тег результирующего образа. Обычно присваивают наименование по следующему шаблону: {областьDockerRegistry}/{имяСервиса}-{имяМодели} (например, docker.registry/project/dataspace-core-deposit:1.0.0).

    docker build -f ./docker/Dockerfile -t yourServiceName:tag ./
    

11. Произвести загрузку собранного образа в хранилище образов:

docker push yourServiceName:tag

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

1. Произвести загрузку Liquibase-скриптов на базу данных, к которой будет подключен сервис DataSpace. Описано в пункте "Ручная проливка Liquibase скриптов на СУБД".

2. Произвести установку сервиса при помощи HelmChart или OpenShift Template, хранящихся в базовом дистрибутиве.

Внимание!

Базовый дистрибутив не содержит ссылки на образ. Ссылку на образ необходимо передать при установке шаблона HelmChart или OpenShift, как параметр шаблона, или указать в секцию image: *** в сущности Deployment.

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

Возможность использования объединенного модуля#

DataSpace поставляет сервис, который включает несколько компонентов: dataspace-core, dataspace-applier (dataspace-gigabas), dataspace-state-machine, dataspace-migration, dataspace-reference-updater (dataspace-duplication). Пользователи, для которых развертывание всех модулей является затратной операцией, а также избыточной в части ознакомления с функциональностью, могут воспользоваться развертыванием объединенного модуля dataspace-bundle.

Конфигурирование требуемых к включению модулей осуществляется через параметры в ConfigMap сервиса dataspace-bundle:

  bundle-configuration: |-
    -Ddataspace.core.enable=true
    -Ddataspace.applier.enable=true
    -Ddataspace.state-machine.enable=true
    -Ddataspace.migration.enable=true
    -Ddataspace.reference-updater.enable=true

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

Примечание

Разные модули могут требовать доступность разных систем, соответственно при включении компонента с зависимостью на работу другой системы накладывается требование на весь dataspace-bundle. Например, при включении dataspace.applier.enable=true требуется настройка StandIn (Прикладной журнал (APLJ)).

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

Пример развертывания deployment:

Установка DataSpace с помощью Helm в Kubernetes (или OpenShift)#

Внимание!

Предварительно необходимо выполнить авторизацию через cli kubectl/oc в среде контейнеризации.

Примечание

Необходимо наличие Helm на компьютере, с которого производится установка.

Реализована возможность установки DataSpace с помощью Helm — пакетного менеджера Kubernetes. Для данного вида установки нужен специально подготовленный установочный пакет helm chart.

Пакет helm chart#

Структура пакета helm chart DataSpace:

Внутри дистрибутива находится папка helm, содержащая:

• Chart.yaml — файл со служебной информацией о chart и приложении, который он разворачивает.

• values.yaml — содержит свойства chart с их значениями.

• templates/.yaml* — файлы с шаблонами объектов Kubernetes.

• templates/tests/.yaml* — файлы с шаблонами для тестов Helm.

Для базовой установки дистрибутива DataSpace необходимо заполнить следующие значения в values.yaml:

appConfig:
  packagesToScan: ru.sbt.platformv.dev.duser1 # GroupID Maven артефакта - имя пакета генерируемых JPA-классов, разработанных ранее

fluentBit:
  enabled: true # включить/выключить использование Fluent Bit
  image: '' # URL образа Fluent Bit

Примечание

Описание defaultSecret в разделе "Опциональные настройки".

defaultSecret:
  create: true # создавать/не создавать (false) дефолтный secret, задается в default-secret.yaml

image:
  registryUrl: '' # URL Nexus
  registryProject: '' # Project ID
  name: "dataspace-core-m7107684626437177346:0.0.1" # имя образа

istio:
  enabled: true # использовать/не использовать

appConfig:
  jvmArguments: "<преднастроенные JVM-опции для сервиса DataSpace>" 

Проверка пакета helm chart:

helm install --dry-run --debug <имя> <путь к папке с chart на локальной машине>

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

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

helm install <имя> <путь к папке с chart на локальной машине>

В случае успешной установки, в консоль выводится сообщение вида:

NAME: <имя развертывания>
LAST DEPLOYED: <дата последнего успешного развертывания>
NAMESPACE: <namecpace, в котором осуществлено развертывание>
STATUS: deployed
REVISION: 1
NOTES:
You have installed dataspace-core app with model
1.Get the application URL in namespace
http://svc-dataspace-core:8080
2. Get the application URL by running these commands:

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

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

helm uninstall <имя>

Это делается для того, что бы избежать ошибок следующего вида:

helm install dataspace-core dataspace-core-123
Error: INSTALLATION FAILED: cannot re-use a name that is still in use

Опциональные настройки#

Опционально настраиваются следующие файлы:

• appJournalStub.yaml — пример настройки подключения к Прикладному журналу (по умолчанию ведет на "заглушку").

  apiVersion: v1
  kind: Secret
  metadata:
    name: {{ include "dataspace-core.appJournalSetting" . }}
  data:
  stringData:
    appJournal.properties: |-
      standin.cloud.client.stub=true
      standin.cloud.client.zoneId=test
      standin.cloud.client.kafka.bootstrapServers=localhost
  

• cm-appConfig.yaml — основной ConfigMap модуля DataSpace, в котором задаются override.properties, переопределяющие стандартные значения application.properties, например:

  kind: ConfigMap
  apiVersion: v1
  metadata:
    name: {{ include "dataspace-core.appConfigName" . }}
  data:
    override.properties: |-
      #-------------------   Static application properties start Don't change this properties after build ds with model-----------------------
      dataspace-core.model.packagesToScan={{ .Values.appConfig.packagesToScan }}
      #-------------------   Application Mode end -----------------------
      # Активация бинарных файлов для работы с пакетом
          
      dataspace.packet.enable={{ .Values.appConfig.dataspace.packet.enabled }}
          
      # Активация бинарных файлов для работы с поиском
          
      dataspace.search.enable={{ .Values.appConfig.dataspace.packet.enabled }}
          
      dataspace.endpoint.jsonrpc.enabled=true
  

Примечание

dataspace-core.model.packagesToScan - в этом параметре должно фигурировать значение пакета ранее созданной модели.

В этом же файле имеется секция standOverride.yml:

```yaml
  standOverride.yml: |-
    {{- with .Values.appConfig.overrideProperties }}
```

В standOverride.yml дописываются параметры, определенные в overrideProperties из values.yaml. Это полезно в том случае, когда нужно переопределить стандартные значения override.properties, добавить свои параметры приложений DataSpace, а так же добавить или изменить параметры, общие для SpringBoot приложений.
Кроме того в cm-appConfig.yaml прописываются JVM-аргументы, задаваемые values.yaml (представлен вариант по умолчанию):

```yaml
 jvmArguments: "-XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=20 -XX:HeapDumpPath=./ -XX:+UnlockDiagnosticVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -XX:+ScavengeBeforeFullGC -XX:PrintSafepointStatisticsCount=1 -XX:+ParallelRefProcEnabled -XX:+PrintClassHistogram -XX:+PrintFlagsFinal -XX:+LogVMOutput -Xlog:gc*=debug:file=/tmp/gc_log_memory.log:time,uptime,level,tags -Xlog:safepoint=debug:/tmp/gc_log_memory.log:time,uptime,level,tags -Dcom.sun.management.jmxremote.port=5000 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.perf=ALL-UNNAMED --add-exports java.management/com.sun.jmx=ALL-UNNAMED"
 ```

• cm-fluentbit.yaml — дефолтный ConfigMap Fluent Bit, включается в deployment.yaml через значения из values.yaml:

  fluentBit:
    enabled: true # включить/выключить
    image: '' # путь к образу Fluent Bit
    secret: fluentBitSecret
    config: '' # если здесь пусто, создается ConfigMap по умолчанию. Если здесь указан собственный ConfigMap Fluent Bit, то дефолтный не создается, а используется указанный в данном поле
  

• cm-logback.yaml — дефолтный ConfigMap для логбэка, его использование задается значением customLogback: '' в values.yaml.

• default-secret.yaml — дефолтный secret для подключения main-db. Пример:

  kind: Secret
  apiVersion: v1
  metadata:
    name: {{ include "dataspace-core.mainDataBaseSecret" . }}
  stringData:
    secret.properties: |-
      dataspace.replication.enabled=false
      spring.datasource.url=jdbc:h2:mem:test
      spring.datasource.username=sa
      spring.datasource.password=
      spring.datasource.driver-class-name=org.h2.Driver
      spring.jpa.database-platform=org.hibernate.dialect.H2Dialect
      spring.jpa.show-sql=true
      spring.jpa.properties.hibernate.format_sql=true
      spring.jpa.hibernate.ddl-auto=none
      spring.liquibase.enabled=true
      spring.liquibase.change-log=classpath:db/changelog.xml
      spring.liquibase.parameters.role=sa
      spring.liquibase.parameters.tablespace_t=sc_t
      spring.liquibase.parameters.tablespace_i=sc_i
      spring.liquibase.parameters.tablespace_l=sc_l
      dataspace.warmup.enable=false
  

  По умолчанию создается при развертывании с локальной базой данных H2, если в values.yaml не указан иной secret для подключения к базе данных.

  db:
  ...
    main:
      secret: ''
  

  Аналогичным образом можно создать свои secrets для Kubernetes (или OpenShift).

• destination-rule.yml — сетевые правила для Istio. Задействуется в том случае, если в values.yaml "включены" значения.

  istio:
    enabled: true
  

  и

  destinationRule:
    enabled: true # по умолчанию установлено значение false
  

• hpa.yaml — правила горизонтального масштабирования, берет из values.yaml следующие параметры:

  autoscaling:
    enabled: true # включено/выключено
    minReplicas: 1 # минимальное количество одновременно запущенных реплик
    maxReplicas: 3 # максимальное количество одновременно запущенных реплик
    targetCPUUtilizationPercentage: 80 # процент утилизации CPU
  

  Необходимо для того, чтобы при увеличении нагрузки на приложение, автоматически создавались новые pods (реплики) с приложением и распределяли нагрузку между собой. Когда нагрузка уменьшается, "лишние" реплики удаляются. В базовом варианте указано минимальное значение — "1", максимальное — "3" и утилизация по CPU. Это значит, что в случае повышения нагрузки на pod более 80% процессорного времени, создается вторая реплика приложения и нагрузка распределяется между ними. Когда нагрузка уменьшается, "лишняя" реплика удаляется.

• ingress.yaml — настройки Ingress, заполняется параметрами из values.yaml.

  ingress:
      enabled: false   # По умолчанию отключено, для использования поменять на true
      servicePort: ''  # Порт сервиса, с которого ожидается входящий трафик. Если одного порта недостаточно, то для других портов прописываются правила маршрутизации
      annotations: {}
      rules: {}        # Здесь указываются правила маршрутизации для Ingress
      hosts:           # Хосты, с которых ожидается входящий трафик
          - host: chart-example.local
            paths: []
      tls: []         (Путь к файлам сертификатов, при использовании ssl
  

• NOTES.txt — параметры сообщения, выдаваемого в консоли после успешного запуска DataSpace. Если включен и настроен Ingress, также выводит в консоль ссылку для внешнего доступа к развернутому приложению.

• service.yaml — настройка сетевого сервиса приложения.

• serviceaccount.yaml — параметры для service account Kubernetes (или OpenShift), создаваемого если это было задано:

  serviceAccount:
    create: false
    annotations: {}
    name: ''
  

• virtualservice.yml — параметры виртуального сервиса для Istio, заполняется следующими значениями из values.yaml:

  virtualService:
    enabled: false    # По умолчанию отключено, включить поставив в значение true
    gateways: []      # Имена шлюзов и sidecars для маршрутизации
    hosts: []         # Список хостов, на которые направляется трафик
    http:             # Правила маршрутизации HTTP-трафика
      - name: reviews-v1-route
        route:
          - destination:
            host: reviews.prod.svc.cluster.local
            subset: v1
  

Альтернативный вариант установки DataSpace в OpenShift#

Обязательные параметры для передачи в OpenShift template при установке:

• MODULE_NAME — имя модуля.

• МainDataBasesecretId — имя secret с конфигурацией подключения к Primary БД (см. раздел "Настройка соединения с БД в сервисах DataSpace").

• FLUENTBIT_IMAGE — ссылка на образ Fluent Bit.

С дополнительными возможностями конфигурации (ресурсами, readiness/liveness probe и прочим) можно ознакомиться в OpenShift template конкретного сервиса в секции parameters.

Примечание

Blue/green развертывание — это метод развертывания, который снижает время простоя и риски за счет запуска двух идентичных производственных сред, называемых blue и green. В любой момент времени только одна из сред является активной (рабочая среда). Активная среда обслуживает весь производственный трафик.

Данное руководство содержит информацию о загрузке Liquibase-скриптов на базу данных, а также проведения blue/green развертывания средствами Istio в ручном режиме.

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

1. Сконфигурировать подключения к базам данных согласно разделу "Настройка соединения с БД в сервисах DataSpace".

2. Подключиться к OpenShift через OpenShift cli (oc):

   oc login
   

3. Скачать дистрибутив, который необходимо установить, из Nexus.
   Архив дистрибутива содержит:

   • Манифесты (template) OpenShift с сервисами Data (параметры перечислены для Liquibase cli).

   • Скрипты Liquibase для создания физики в Базе данных (папка db)

4. Выполнить скрипты Liquibase. Описано в пункте "Ручная проливка Liquibase скриптов на СУБД"

5. Установку сервисов DataSpace необходимо производить в соответствии с приоритетом. Чтобы узнать приоритеты сервисов, необходимо открыть манифесты (template.yml) в дистрибутиве и найти следующие поля:

   apiVersion: template.OpenShift.io/v1
   kind: Template
   labels:
      app: ${MODULE_NAME}
      version: dataspace-release-snapshot
      type: application
      installPriority: "4"
      template: dataspace-core-template
      template_version: v1
      deleteLabel: ${MODULE_NAME}
   

   Информация о приоритете хранится в labels.installPriority.
   Порядок установки: первым устанавливается приложение с меньшим значением installPriority.

6. Необходимо узнать, какая версия установлена на стенд в текущий момент, чтобы правильно переключать нагрузку средствами istio. Текущая версия хранится в yaml deployments в labels.version.
   Выполнить команду, где MODULE_NAME: имя устанавливаемого модуля.

   oc describe deployments --selector app=MODULE_NAME | grep version
   

    % oc describe deployments --selector app=dataspace-core-deals-17724333 | grep version
                        template_version=v1
                        version=develop-17724333-snapshot
      Selector:               app=dataspace-core-deals-17724333,version=develop-17724333-snapshot
      version=develop-17724333-snapshot
   

7. Создать правило маршрутизации DestinationRule, где:

   • MODULE_NAME — имя устанавливаемого модуля;

   • blueVersion — версия в текущий момент установленного сервиса (если нет, то создать равным текущей устанавливаемой версии);

   • greenVersion — версия устанавливаемого сервиса.

   apiVersion: networking.istio.io/v1alpha3
   kind: DestinationRule
   metadata:
     name: dr-${MODULE_NAME}
   spec:
     host: svc-${MODULE_NAME}
     subsets:
       — name1: oldVersion
         labels:
           version: ${blueVersion}
       — name2: canaryVersion
         labels:
           version: ${greenVersion}
   

   Данное правило создает два subset, которыми мы сможем в будущем воспользоваться для маршрутизации трафика.

8. Создать правило маршрутизации VirtualService, где MODULE_NAME — имя устанавливаемого модуля.

   apiVersion: networking.istio.io/v1alpha3
   kind: VirtualService
   metadata:
      name: vs-${MODULE_NAME}
   spec:
      exportTo:
         — .
      hosts:
         — svc-${MODULE_NAME}
      http:
         — route:
              — destination1:
                   host: svc-${MODULE_NAME}
                   subset: oldVersion
                weight: 100
              — destination2:
                   host: svc-${MODULE_NAME}
                   subset: canaryVersion
                weight: 0
   

   Данным правилом мы гарантируем, что весь трафик в текущий момент будет идти на blue (рабочую) версию (если она имеется).

9. Произвести установку сервиса из манифеста (template).

   oc process -f имяФайла.yaml -p MODULE_NAME=имяМодуля -p ...(перечисляем все параметры, которые необходимо передать при установке) | oc apply -f -
   

10. Дождаться успешного развертывания сервиса.
    Deployment ready:

    oc get deployments --selector app=dataspace-core-deals
    

    Вывод команды:

    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
    dataspace-core-deals-4.0.0   1/1     1            1           3h16m
    

    READY 1/1 означает, что Pods успешно поднялись.

11. В случае, если Pods долго не переходят в состояние READY необходимо зайти в лог-записи Pod, deployment или event, найти причину и устранить проблемы.
    Если проблема не была устранена, произвести удаление установленных объектов deployment, configmap.

12. В случае успешного поднятия всех Pods произвести переключение трафика на green-версию. Применить DestinationRule, где

    • MODULE_NAME — имя устанавливаемого модуля;

    • greenVersion — версия устанавливаемого сервиса.

    apiVersion: networking.istio.io/v1alpha3
    kind: DestinationRule
    metadata:
      name: dr-${MODULE_NAME}
    spec:
      host: svc-${MODULE_NAME}
      subsets:
        — name: oldVersion
          labels:
            version: ${greenVersion}
        — name: canaryVersion
          labels:
            version: ${greenVersion}
    

    Данная операция исключит из маршрутизации старую blue-версию, сделает рабочей новую установленную версию.

13. Повторить пункты 5-11 для всех template в поставке.

Автоматизированная сборка и установка сервиса#

Сборка с помощью компонента Build Tools (CIJE)#

Для сборки приложений DataSpace с помощью компонента Build tools (CIJE) продукта Platform V DevOps Tools (DOT) достаточно воспользоваться вложенным в архетип проекта файлом Jenkinsfile. Он будет находиться в корне проекта после его развертывания из архетипа.

Основные шаги для подготовки вашего проекта DataSpace к сборке#

Необходимо создать шаблонный проект одним из двух способов:

• локально на машине разработчика;

• с помощью задачи в Jenkins.

Создание шаблонного проекта на локальной машине#

При использовании данного способа создания шаблонного проекта предварительно необходимо ознакомиться с документом "Руководство прикладного разработчика" компонента Build tools (CIJE) продукта Platform V DevOps Tools (DOT).

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

1. Осуществить генерацию артефактов согласно инструкциям, описанным в документе "Быстрый старт".

   Внимание!

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

   • подменить файлы модели (model.xml, status.xml (опционально)) в папке model/src/main/resources/model;

   • удалить модуль демонстрационных тестов model-local-test (в том числе удалить упоминание о нем среди модулей в корневом pom.xml проекта).

2. Заполнить конфигурационный файл pipeline.yml согласно документации продукта Platform V DevOps Tools (DOT), а также ориентируясь на комментарии в файле. При необходимости можно модифицировать данный файл, добавлять требуемые разделы, разрешенные документацией компонента Build tools (CIJE).

   Внимание!

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

   Во избежание ошибки вида "cp: cannot stat ‘/target/*.jar’: No such file or directory", значение artifactId должно совпадать с именем репозитория, из которого берется jenkinsfile.

3. После заполнения файла pipeline.yml запустить сборку проекта.

Пример заполнения pipeline.yml#

# Свойства дистрибутива
fp:
  groupId:  # Область в Nexus
  artifactId: "${artifactId}" # КЭ, для которого есть область в репозитории
  version: "${version}" # К данному свойству будет добавляться номер сборки. Например, для сборки с номером 123 в Nexus артефакт будет выгружен с версией ${version}-123

# Настройки MAVEN
maven:
  settings_id: "MavenSetting" # Id maven settings в Jenkins
  jdk: "openjdk-11.0.2_linux" # JDK, настроенный в Jenkins (один на все проекты, меняться не должен)
  home: "Maven 3.6.3" # Версия maven
  # Использовать ли maven для загрузки дистрибутива в Nexus, по умолчанию — "false",
  # Чтобы использовать этот параметр, требуется завести credentials в settings-файле и указать их serverId в Nexus_<...>
  use_for_deploy: "true"


# Ссылки на сборочные Jenkins-файлы (берется Jenkinsfile из корня проекта)
jenkinsfiles:
  - name: "${artifactId}" # Имя артефакта
    repo:  # URL без хоста, например, "DSPC/dataspace-client.git". Без .git в конце сборки проходить будут, но не получится пройти проверки sast/oss
    branch:  # Ветка сборки, например, "develop"

# Настройки NEXUS-central
nexus:
  creds:  # Id ТУЗ c доступом на чтение из root_url
  root_url: ""  # Адрес репозитория с артефактами для сборки

# Настройки NEXUS-sbrf
nexus_sbrf:
  repository: "" # Имя репозитория
  creds:  # Id ТУЗ с доступом на запись в root_url
  serverId: "" # Идентификатор адреса Nexus из settings.xml
  root_url: "" # Корневой URL Nexus
  upload_url: "" # URL репозитория в Nexus, в который выгружается дистрибутив
  groupId: # Имя загрузочной области в Nexus
  artifact: "${artifactId}"

# Настройки сборки Dockerfile
docker:
  builder_token:  # Id ТУЗ с доступом на запись в Nexus3
  registry_address: "" # Имя docker репозитория
  nexus_url:  # Путь до области с образами
  
#Настройки dataspace
dataspace:
  # Если добавлен параметр, то в dc.yaml будет прописан в явном виде
  # Вида {{ registry }}{{ registry_path }}<component_code>/<deployment_unit>@sha256:<hash>
  # ВАЖНО! docker.nexus_url должен заканчиваться на /<component_code>
  component_code: dspc
  # Не должно быть параметризаций образов, если эта секция не закомментирована, в dc.yaml будет прописан константой используемый образ
  fluentbitSidecar:
    component_code: loga
    name: fluent-bit
    sha: 2e430ac283dc6d09a5cc2de5eb49b3da42696bd71c272dbe4b4806c66e9e29ec
  model:
    jpaModelVersion: "" # Указать версию модели в semver, если не задано, то возьмется fp.version
    build:
      mvnArgs: "-P dbScriptsWithoutOracle" # Если требуется проливка liquibase-скриптов на Oracle, использовать dbScriptsWithOracle, также можно задавать дополнительные аргументы для сборки maven-проекта
  # Опциональное добавление зависимостей из списка в дистрибутив
  externalDependencies:
    # - ucp-corp-events
    # - ojdbc8
  config:
    version: "" # Версия dataspace-bom используемых конфигураций для установки сервисов на стенд, по умолчанию берется текущая версия bom
    copyDisribYmlAsIs: false # Копирование distrib.yml из корня проекта без обработки
  services: # Ниже перечислены доступные сервисы, которые попадут в дистрибутив, ненужные можно удалить или закомментировать
    - dataspace-core
    # - dataspace-gigabas
    # - dataspace-cr-duplication-service
    # - dataspace-cr-migration-service
    # - dataspace-cr-state-machine
    # - dataspace-subscription
    # - dataspace-bundle
  ownerId: #Параметр, идентифицирующий потребителя DataSpace. Это может быть, например, ТУЗ, КЭ, rn или какая-то другая строка
  docker:
    registry_address: "" # Корневой URL docker-registry
    nexus_url: "" # Путь от корня к целевой папке
    images:
      version: "" # Версия, с которой будут браться базовые образы DataSpace, если "" — будут браться образы с версией сервисов из dataspace-bom
      versionSuffix: "" # Суффикс версии образа, например, dataspace-bom версии 1.0.0. Если образы сервисов 1.0.0_alt — тогда суффикс будет "_alt"

Сборка шаблонного проекта с помощью Build tools (CIJE)#

Для сборки шаблонного проекта с помощью job Jenkins необходимо:

1. Осуществить генерацию артефактов согласно инструкциям, описанным в документе "Быстрый старт".

   Внимание!

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

   • подменить файлы модели (model.xml, status.xml (опционально)) в папке model/src/main/resources/model;

   • удалить подмодуль демонстрационных тестов model-local-test (в том числе удалить упоминание о нем среди модулей в корневом pom.xml проекта).

2. Создать пустой git-репозиторий и выгрузить в него полученный проект.

3. Подготовить job Build tools (CIJE) (см. документ "Руководство прикладного разработчика" компонента Build tools (CIJE) продукта Platform V DevOps Tools (DOT)).

4. Заполнить конфигурационный файл pipeline.yml компонента Build tools (CIJE) (<корень_проекта>/config/ufs/pipeline.yml). При необходимости можно модифицировать данный файл, добавлять требуемые разделы, разрешенные документацией компонента Build tools (CIJE) (см. раздел "Пример заполнения pipeline.yml").

5. Запустить сборку проекта.

Внимание!

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

В pom.xml, находящемся в корне проекта, необходимо изменить Url репозиториев в секции distributionManagement на свои. Данный блок используется на шаге mvn deploy для публикации артефактов.

<distributionManagement>
   <repository>
     <id>release.repo</id>
     <url>url_to_maven_repo</url>
   </repository>
   <snapshotRepository>
     <id>corp-snapshots</id>
     <url>url_to_maven_repo</url>
   </snapshotRepository>
 </distributionManagement>

Обратите внимание, что id в repository должен совпадать с именем самого репозитория, а также для них должен быть прописан server в <корень_проекта>/config/settings.xml.

Важно, чтобы структура проекта соответствовала архетипу. Названия модулей с model-jpa, model-sdk обязательно должны быть следующего вида: имяМодели-model-jpa, имяМодели-model-sdk.

При сборке используются те версии артефактов, которые указаны в используемом dataspace-bom (версия dataspace-bom указывается в корневом pom.xml собираемого проекта).

Важно, чтобы имена модулей совпадали с именами артефактов в dataspace-bom.

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

• имя модуля — "test-service";

• artifactId в pom.xml — "mega-test-service";

• имя модели в ее xml-описании — "mega-test-model".

Это может привести к ошибкам сборки, так как подключаемая библиотека DevOps может ориентироваться на имена модулей при анализе вашего проекта.

Добавление пользовательских параметров в дистрибутив#

При работе с Platform V DevOps Tools (DOT) может потребоваться дополнительно определить пользовательские параметры в рамках работы с модулями DataSpace. Для этого необходимо создать ConfigMap, например, customer-properties-core.yaml с ключом data customer.properties по пути conf/openshift/dataspace-${module}-${modelName} (например, dataspace-core-deposit) в вашем шаблонном проекте(в качестве примера в шаблонный проект добавлен configMap по пути ./dataspace-core-${modelName}/configmaps/customer-properties-core.yaml). Необходимо определить в нем параметры в формате:

kind: ConfigMap
apiVersion: v1
metadata:
  name: customer-properties
data:
  customer.properties: |-
    dataspace.customer.param1=value1
    dataspace.customer.param2={{ customer.value2 }}

Параметризацию параметров можно определить, например, в custom_property.conf.yml, после чего иметь доступ к этой конфигурации в репозитории FP на этапе работы Deploy tools (CDJE):

# custom_property.conf.yml
customer.value2=1000
# ...

Обновление конфигурации#

Примечание

Конфигурации выгружаются из репозитория артефактов (например, Nexus) на основе информации из файла pom_dependencies.xml в сформированном на базе архетипа шаблонном проекте.

Существует возможность зафиксировать конфигурацию, явно указав в секции pipeline.yml, какую версию конфигурации использовать:

dataspace:
  config:
     version: "${CONFIG_BOM_VERSION}" 

где CONFIG_BOM_VERSION — версия dataspace-bom, для которой будут выгружаться инсталляционные манифесты. При "" по умолчанию будет браться текущая выбранная в pom.xml проекта версия dataspace-bom.

При обновлении версии dataspace-bom для корректной работы манифестов инсталляции необходимо сформировать шаблонный проект из архетипа соответствующей версии и актуализировать следующие папки и файлы:

/conf/**/**
/config/**/**
/Jenkinsfile
/distrib.yml
/modelName-model-jpa/assembly/**

В случае отсутствия из /*-model-jpa/pom.xml необходимо добавить профили dbScriptsWithOracle и dbScriptsWithoutOracle.

Установка с помощью Deploy tools (CDJE)#

При использовании данного способа развертывания по всем возникающим вопросам рекомендуется обращаться к документации компонента Deploy tools (CDJE). Ниже представлен краткий алгоритм действий, необходимых для разворачивания дистрибутива Platform V DataSpace.

Подготовка к установке#

1. Наличие у пользователя, производящего установку, возможности создания репозиториев в хранилище (например, Git) и доступов в целевые области хранилища дистрибутива (в Nexus).

2. Наличие технической учетной записи для работы с репозиториями и с целевыми областями в Nexus.

3. Созданы и проинициализированы следующие Git-репозитории в проектной области с основной веткой master:

   • Репозитории для работы с pipeline Build tools (CIJE):

     • pipeline — репозиторий с кодовой базой релизов pipeline (на каждый стенд формируется свой репозиторий (например, ci90000026_dspc_pipeline_ift / ci90000026_dspc_pipeline_lt));

     • common — репозиторий с глобальными (одинаковыми для всех компонент в рамках одного стенда) переменными среды (на каждый стенд формируется свой репозиторий (например, ci90000026_dspc_common_ift / ci90000026_dspc_common_lt)).

   • Репозитории с конфигурациями функциональных подсистем, для каждой ФП формируется свой репозиторий (например, для ФП dspc-deposit-client — ci90000026_dspc_dspc-deposit-client_ift / ci90000026_dspc_dspc-deposit-client_lt).

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

• JOB Service — job обновления (первичная загрузка кода JOB Deploy, обновление кода JOB Deploy при выпуске новых релизов JOB Deploy).

• JOB Deploy — job для развертывания дистрибутивов.

После настройки репозиториев pipeline и common через JOB Service необходимо заполнить и зашифровать файл _passwords.conf в репозитории common по пути /ansible:

• _passwords.conf — файл, содержащий пароли для баз данных, Kafka и т.д., которые будут использоваться для создания secrets в среде контейнеризации.

Необходимо добавить ФП для развертывания в конфигурационный файл subsystems.json в корне common проекта, например:

...
  "DSPC_DEPOSIT_CLIENT": {
    "fpi_name": "dspc-deposit-client",
    "artifactId": "dspc-deposit-client",
    "groupId": "nexusProject/dspc",
    "versionFilter": "1.1",
    "strict": "false",
    "fpType": "fp",
  }
...

Необходимо добавить стенд для развертывания в конфигурационный файл multiClusters.json в корне common проекта, например:

 "Test1": {
   "openshiftCluster"                   : "https://api.apps.example.com:6443",
   "openshiftSATokenCred"               : "jenkins_auth_stand_token",  
   "openshiftProjectName"               : "project",
   "openshiftAppsDomain"                : "apps.example.com",
   "openshiftWebConsole"                : "https://console-openshift-console.apps.example.com/k8s/cluster/projects",
   "openshiftRoutersFQDN"               : "1.1.1.1",
   "openshiftControlPlane"              : "example-controlplanev20",
   "openshiftControlPlaneIstiodService" : "istiod-common-install"      
 }
        
Где openshiftSATokenCred — созданные реквизиты для входа в Jenkins, содержащие токен подключения к среде контейнеризации (это может быть токен пользователя или ServiceAccount)

Подготовка параметров к установке#

После выполнения всех действий произвести миграцию конфигурационных файлов ФП через playbook MIGRATION_FP_CONF (миграция конфигурационных файлов ФП) в JOB Deploy.

Заполнить конфигурационные файлы по пути conf/config/parameters/ в репозитории ФП в соответствии с окружением стенда. Параметры сгруппированы, указаны комментарии в самих файлах.

Файлы:

• model_name.all.conf — в файле собраны параметры из application.properties, общие для всех модулей DataSpace:

Внимание!

Для включения k8s совместимой конфигурации, необходимо указать dataspace.k8s.configuration.enabled=true.

Примечание

Значение global.dataspace.vault_paths:

/secrets/properties/keystore-passphrase-aj.properties,  /secrets/properties/truststore-passphrase-aj.properties,  /secrets/properties/key-passphrase-aj.properties,  /secrets/properties/maindb.properties,  /secrets/properties/standin.properties,  /secrets/properties/passphrase-db.properties,  /secrets/properties/truststore-passphrase-db.properties,  /secrets/properties/passphrase-tsa.properties,  /secrets/properties/key-passphrase-tsa.properties,  /secrets/properties/truststore-passphrase-tsa.properties,  /secrets/properties/passphrase-epk.properties,  /secrets/properties/truststore-passphrase-epk.properties,  /secrets/properties/subscription.properties

• istio.all.conf — указываются параметры работы с Istio: настройка создания Ingress/Egress, создание обвязки для внешних сервисов.

Примечание

Необходимо обратить внимание на параметры:

• dataspace.ose.istio.deployment.spec.template.spec.containers.istio_proxy.image - ссылка на образ istio sidecar контейнера;

• dataspace.ose.istio.deployment.spec.template.spec.containers.ott-sidecar.image - ссылка на образ ott sidecar контейнера;

• dataspace.k8s.istio.SSM_CONFIGURATION_ENABLED - флаг, включающий совместимость конфигурации с Synapse Service Mesh.

• dataspace-*.conf — файлы с параметрами для конкретного сервиса.

Примечание

Необходимо обратить внимание на блок override.properties с параметрами по паттерну <prefix>.<параметр_application.properties>:

• dataspace-core: prefix = core.cm.properties.*

• dataspace-gigabas: prefix = gigabas.cm.properties.*

• dataspace-cr-duplication-service: prefix = duplication.cm.properties.*

• dataspace-cr-migration-service: prefix = migration.cm.properties.*

• dataspace-cr-state-machine: prefix = statemachine.cm.properties.*

• dataspace-subscription: prefix = subscription.cm.properties.*

• dataspace-bundle: prefix = bundle.cm.properties.*

Проливка Liquibase-скриптов на базу данных#

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

• добавить в _passwords.conf пароли для подключения к БД и проливки liquibase-скриптов:

  • dataspace_main_db_password = "user_main_password";

  • dataspace_standin_db_password = "user_si_password".

• заполнить файл custom_property.conf.yml, расположенный в репозитории по пути conf/custom_property.conf.yml:

# Данные для проливки liquibase-скриптов на main
dataspace_main_db_user: "user_main"
dataspace_main_db_url: "jdbc:postgresql://url:port/user_main_db"
dataspace_main_db_schema: "user_main_schema"
dataspace_main_db_driver: "org.postgresql.Driver"
dataspace_main_db_dialect: "org.hibernate.dialect.PostgreSQLDialect"
dataspace_main_db_tablespace_t: "user_main_tablespace_t"
dataspace_main_db_tablespace_i: "user_main_tablespace_i"
dataspace_main_db_tablespace_l: "user_main_tablespace_l"
# Данные для проливки liquibase-скриптов на standin
dataspace_standin_db_user: "user_si"
dataspace_standin_db_url: "jdbc:postgresql://url:port/user_si_db"
dataspace_standin_db_schema: "user_si_schema"
dataspace_standin_db_driver: "org.postgresql.Driver"
dataspace_standin_db_dialect: "org.hibernate.dialect.PostgreSQLDialect"
dataspace_standin_db_tablespace_t: "user_si_tablespace_t"
dataspace_standin_db_tablespace_i: "user_si_tablespace_i"
dataspace_standin_db_tablespace_l: "user_si_tablespace_l"
# Определяет тип блока SI или нет: "true" — проливка на main, "false" — проливка на standin
isMain: true

Проливка скриптов выполняется путем запуска JOB Deploy с playbook DB_UPDATE (запуск Liquibase-скриптов).

Если необходимо дополнительно проливать БД Standin, то в файле custom_property.conf.yml репозитория ФП необходимо переключить флаг isMain и перезапустить JOB Deploy с playbook DB_UPDATE.

Использование пользовательских параметров в рамках сервиса DataSpace#

Примечание

Изначально требуется, чтобы в дистрибутив был добавлен пользовательский ConfigMap (см. раздел "Добавление пользовательских параметров в дистрибутив").

Для того чтобы пользовательский ConfigMap использовался сервисом DataSpace, необходимо указать его имя в конфигурации .conf (например, dataspace-core-deposit.conf) требуемого сервиса: dataspace.service.cm.customer.properties=customer-properties.

Для добавления пользовательских jvm-аргументов для сервиса DataSpace необходимо перечислить их в конфигурации .conf (например, dataspace-core-deposit.conf) требуемого сервиса (необходимые опции по умолчанию уже перечислены):

dataspace.service.jvm-arguments="-XX:+AlwaysPreTouch -server -XX:InitialRAMPercentage=50.0 -XX:MaxRAMPercentage=70.0 -XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:ParallelGCThreads=2 -XX:+ParallelRefProcEnabled -XX:-ResizePLAB -XX:G1ReservePercent=10 -XX:+UnlockExperimentalVMOptions -XX:G1NewSizePercent=20 -XX:HeapDumpPath=/tmp -XX:+UnlockDiagnosticVMOptions -XX:+HeapDumpOnOutOfMemoryError -XX:+DisableExplicitGC -XX:+ScavengeBeforeFullGC -XX:PrintSafepointStatisticsCount=1 -XX:+PrintClassHistogram -XX:+PrintFlagsFinal -XX:+LogVMOutput -Xlog:gc*=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize={{lookup('custom_vars','core.cm.jvm-arguments.gc.log.gcLogFileSize')}},filecount={{lookup('custom_vars','core.cm.jvm-arguments.gc.log.gcLogFileCount')}} -Xlog:safepoint=info:file=/tmp/gc_log_memory.log:time,uptime,level,tags:filesize={{lookup('custom_vars','core.cm.jvm-arguments.gc.log.gcLogFileSize')}},filecount={{lookup('custom_vars','core.cm.jvm-arguments.gc.log.gcLogFileCount')}} -Djdk.attach.allowAttachSelf=true --add-exports java.base/jdk.internal.perf=ALL-UNNAMED --add-exports java.management/com.sun.jmx=ALL-UNNAMED -Dfile.encoding=UTF8 -Duser.timezone={{lookup('custom_vars','core.cm.jvm-arguments.user.timezone')}}"

При использовании logback.xml, отличного от предоставляемого в поставке, его необходимо указать в dataspace-.conf* используемого сервиса (в данном случае — dataspace-core):

#custom logback config map ( customLogback )
dataspace.service.cm.customer.logback=stub-logback

Используя значение stub-logback в данном параметре, будет использован logback.xml из поставки, находящийся в configmap dataspace-logger-cm.yaml модуля DataSpace.

Пример logback.xml (находится в примере пользовательского configmap, находящегося в шаблонном проекте по пути ./dataspace-core-${modelName}/configmaps/customer-properties-core.yaml):

  logback.xml: |-
        #Содержание logback.xml

Установка дистрибутива на стенд#

Установка дистрибутива на стенд выполняется путем запуска JOB Deploy с playbook OPENSHIFT_DEPLOY (установка в OpenShift).

Примечание

Все необходимые секреты для взаимодействия с базой данных и Kafka сформируются автоматически на основании параметров из репозитория ФП conf/config/parameters/*.all.conf.

Обзор параметров для подключения по SSL#

Внимание!

Вся описанная ниже конфигурация используется при установке дистрибутива на стенд без Secret Management System.

SSL-конфигурация для DB#

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов DB".

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

• Заполнить параметры в файле ${modelName}.all.conf в репозиторий FP:

  # Путь до хранилища относительно common-репозитория
  # После заполнения данного параметра должен создаться секрет с хранилищем
  dataspace.db.cert.keystore.path=/ansible/files/ssl/db/keystore.jks
  dataspace.main.db.url={{ dataspace_main_db_url }}?sslmode=verify-ca&sslfactory=org.postgresql.ssl.DefaultJavaSSLFactory
  

• Добавить параметры в _passwords.conf:

  • dataspace.main.db.keystore.password = "changeit";

  • dataspace.main.db.truststore.password = "changeit".

SSL-конфигурация для Kafka компонента APLJ#

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов Kafka ПЖ".

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

• Указать путь до хранилища с сертификатами в файле ${modelName}.all.conf в репозиторий FP:

  # Путь до хранилищ относительно common-репозитория    
  dataspace.aj.kafka.cert.keystore.path=/ansible/files/ssl/aj/keystore.jks
  dataspace.aj.kafka.cert.truststore.path=/ansible/files/ssl/aj/keystore.jks
  dataspace.app.journal.ssl.enabled=true
  

• Добавить параметры в _passwords.conf:

  # пароли для приватного ключа и хранилищ сертификатов для подключения к Kafka по SSL 
  dataspace.standin.kafka.producerConfig.ssl.key.password="changeit"
  dataspace.standin.kafka.producerConfig.ssl.keystore.password="changeit"
  dataspace.standin.kafka.producerConfig.ssl.truststore.password="changeit"
  
  dataspace.standin.kafka.consumerConfig.ssl.key.password="changeit"
  dataspace.standin.kafka.consumerConfig.ssl.keystore.password="changeit"
  dataspace.standin.kafka.consumerConfig.ssl.truststore.password="changeit" 
  

После заполнения параметров выше должен создаться секрет с хранилищами.

SSL-конфигурация для Kafka LOGA#

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов Kafka компонента Журналирование (LOGA)".

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

• Включить ssl-режим для подключения к Kafka в файле ${modelName}.all.conf в репозиторий FP: dataspace.logger.kafka.ssl.enabled=true.

• Добавить параметр в _passwords.conf: dataspace.logger.kafka.keyStore.password="changeit".

• Добавить в репозиторий common в installer/system/efs/config/parameters/ssl.conf следующие параметры:

  dataspace.logger.kafka.keyStore.RootCertAlias=root
  dataspace.logger.kafka.keyStore.CertAlias=cert
  dataspace.logger.kafka.keyStore.PrivateKeyAlias=key
  dataspace.logger.kafka.keyStore.password=dataspace.logger.kafka.keyStore.password
  dataspace.logger.kafka.keyStore.KeyStoreFromFile=ansible/files/ssl/logger/keystore.jks
  

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

SSL-конфигурация для Kafka LOGA для отправки трейсинга#

Примечание

Если используются те же сервера Kafka, что и для LOGA, то необходимо использовать те же значения параметров в конфигурации, что и для LOGA.

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов Kafka компонента Журналирование (LOGA) для отправки трейсинга".

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

• Включить ssl-режим для подключения к Kafka в файле ${modelName}.all.conf в репозиторий FP: dataspace.logger.tracing.kafka.ssl.enabled=true.

• Добавить параметр в _passwords.conf: dataspace.logger.tracing.kafka.keyStore.password="changeit".

• Добавить в репозиторий common в installer/system/efs/config/parameters/ssl.conf следующие параметры:

  dataspace.logger.tracing.kafka.keyStore.RootCertAlias=root
  dataspace.logger.tracing.kafka.keyStore.CertAlias=cert
  dataspace.logger.tracing.kafka.keyStore.PrivateKeyAlias=key
  dataspace.logger.tracing.kafka.keyStore.password=dataspace.logger.tracing.kafka.keyStore.password
  dataspace.logger.tracing.kafka.keyStore.KeyStoreFromFile=ansible/files/ssl/tracing/keystore.jks
  

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

SSL-конфигурация для Kafka ARCH#

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов Kafka компонента Архивирование (ARCH)".

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

• Указать путь до хранилища с сертификатами в файле ${modelName}.all.conf в репозиторий FP:

  # Путь до хранилищ относительно common-репозитория    
  dataspace.tsa.kafka.cert.keystore.path=/ansible/files/ssl/tsa/keystore.jks
  dataspace.tsa.kafka.cert.truststore.path=/ansible/files/ssl/tsa/keystore.jks
  dataspace.tsa.kafka.ssl.enabled=true
  

• Добавить параметры в _passwords.conf:

  # Пароли для приватного ключа и хранилищ сертификатов для подключения к Kafka по SSL 
  dataspace.tsa.kafka.consumerConfig.ssl.key.password="changeit"
  dataspace.tsa.kafka.consumerConfig.ssl.keystore.password="changeit"
  dataspace.tsa.kafka.consumerConfig.ssl.truststore.password="changeit"
  
  dataspace.tsa.kafka.producerConfig.ssl.key.password="changeit"
  dataspace.tsa.kafka.producerConfig.ssl.keystore.password="changeit"
  dataspace.tsa.kafka.producerConfig.ssl.truststore.password="changeit"
  

После заполнения параметров выше должен создаться секрет с хранилищами.

SSL-конфигурация для подключения к Kafka источника событий слияния/разъединения клиентов#

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Получение сертификатов Kafka источника событий слияния/разъединения клиентов".

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

• Указать путь до хранилища с сертификатами в файле ${modelName}.all.conf в репозиторий FP:

  # Путь до хранилищ относительно common репозитория    
  dataspace.epk.kafka.cert.keystore.path=/ansible/files/ssl/epk/keystore.jks
  dataspace.epk.kafka.cert.truststore.path=/ansible/files/ssl/epk/keystore.jks
  dataspace.epk.kafka.ssl.enabled=true
  

• Добавить параметры в _passwords.conf:

  # пароли хранилищ сертификатов для подключения к Kafka по SSL 
  dataspace.epk.synapse.integration.ssl.keystore.password="changeit"
  dataspace.epk.synapse.integration.ssl.truststore.password="changeit"
  

После заполнения параметров выше должен создаться секрет с хранилищами.

Конфигурирование Istio Service Mesh в рамках CDJE#

После проведения необходимого конфигурирования можно воспользоваться JOB Deploy с playbook OPENSHIFT_INGRESS_EGRESS_DEPLOY (установка ingress/egress в OpenShift).

Примеры разворачиваемых модулей и их конфигурации есть в проекте компонента Build tools (CIJE), на базе которого был сформирован дистрибутив для дальнейшей его установки на стенд (см. раздел "Создание шаблонного проекта на локальной машине"). Шаблоны в формате .yaml расположены по пути /conf/openshift/istio.

Конфигурация Ingress#

В репозитории ФП необходимо заполнить секцию с Ingress в conf/config/parameters/istio.all.conf.

Необходимо обратить внимание на параметры:

• Флаги инсталляции Ingress:

  • Флаг включения в Ingress OTT sidecar контейнера, создание OTT-секретов, сущностей EnvoyFilter: dataspace.ose.istio.ingress.common.ott.enabled=true.

  • Установка сущностей Deployment, Service, Routes, Secrets, Gateway, ConfigMap, EnvoyFilter (если OTT-флаг в true): dataspace.ose.istio.ingress.deployment.install=true.

  • Установка сущностей VirtualService, DestinationRule, ServiceEntry для устанавливаемых модулей:

    dataspace.ose.istio.ingress.config.install=true
    # Создание VirtualService с endpoint для доступа к сервисам извне по Ingress Route
    dataspace.ose.istio.service.route.out.enabled=true
    

• Флаги конфигурации — конфигурирования в Ingress Gateway TLS-режима работы:

  # PASSTHROUGH | SIMPLE | MUTUAL | AUTO_PASSTHROUGH | ISTIO_MUTUAL
  dataspace.ose.istio.ingress.gw.tls.mode
  

Добавить в ansible/_passwords.conf репозитория common параметр dataspace.ingress.keyStore.password = "changeit".

Примечание

Для установки Ingress требуется создание TLS серверных сертификатов и помещение их в хранилище в формате JKS.

Добавить в репозиторий common в installer/system/efs/config/parameters/ssl.conf следующие параметры:

dataspace.ssl.ose.istio.ingress.keyStore.RootCertAlias=root
dataspace.ssl.ose.istio.ingress.keyStore.CertAlias=cert
dataspace.ssl.ose.istio.ingress.keyStore.PrivateKeyAlias=key
dataspace.ssl.ose.istio.ingress.keyStore.password=dataspace.ingress.keyStore.password
dataspace.ssl.ose.istio.ingress.keyStore.KeyStoreFromFile=ansible/files/ssl/ingress.jks

Конфигурация Egress#

В репозитории ФП необходимо заполнить секцию с Egress в conf/config/parameters/istio.all.conf:

• Флаги инсталляции Egress:

  • Флаг включения в Egress OTT sidecar контейнера, создание OTT-секретов, сущностей EnvoyFilter: conf dataspace.ose.istio.egress.common.ott.enabled=true.

  • Установка сущностей Deployment, Service, Secrets, ConfigMap: dataspace.ose.istio.egress.deployment.install=true.

  • Установка сущностей VirtualService, DestinationRule, ServiceEntry, Gateway, Secrets, EnvoyFilters (если OTT-флаг в true) для сервисов взаимодействия: dataspace.ose.istio.egress.config.install=true.

• Флаги конфигурации — конфигурирование политики для исходящего трафика:

  # REGISTRY_ONLY | ALLOW_ANY
  dataspace.ose.istio.egress.configmap.outboundTrafficPolicy
  

Добавить в ansible/_passwords.conf репозитория common параметр dataspace.egress.keyStore.password = "changeit".

Примечание

Для установки Egress требуется создание TLS клиентских сертификатов и помещение их в хранилище в формате JKS.

Добавить в репозиторий common в installer/system/efs/config/parameters/ssl.conf следующие параметры:

dataspace.ssl.ose.istio.egress.keyStore.RootCertAlias=root
dataspace.ssl.ose.istio.egress.keyStore.CertAlias=cert
dataspace.ssl.ose.istio.egress.keyStore.PrivateKeyAlias=key
dataspace.ssl.ose.istio.egress.keyStore.password=dataspace.egress.keyStore.password
dataspace.ssl.ose.istio.egress.keyStore.KeyStoreFromFile=ansible/files/ssl/egress.jks

Конфигурирование режимов работы mTLS внутри кластера#

В репозитории ФП необходимо заполнить в conf/config/parameters/istio.all.conf конфигурирование режима mTLS внутри кластера — создается сущность PeerAuthentification:

 # STRICT | PERMISSIVE | DISABLE | UNSET
 dataspace.ose.istio.egress.peerauthentication.mtls.mode=STRICT

Конфигурация One-Time Password (OTP) / OTT (OTTS)#

В репозитории ФП необходимо заполнить секцию с OTT для Ingress/Egress в conf/config/parameters/istio.all.conf.

Необходимо обратить внимание на параметры:

• Идентификатор модуля, для которого были сформированы необходимые сертификаты: dataspace.ose.istio.ott.module.id=changeit.

• Адреса OTT-серверов: dataspace.ose.istio.ott.service.hosts=ip:port,ip:port.

• Указание портов, для которых будет создан EnvoyFilter для обертывания трафика OTT-токенами: dataspace.ose.istio.egress.ott.ef.external.ports=.

Примечание

Если производится интеграция с HashiCorp Vault (Secret Management System), то см. раздел "Конфигурирование компонента One-Time Password (OTTS) на граничных прокси".

Добавить в ansible/_passwords.conf репозитория common следующие параметры:

dataspace_ingress_OTT_CERTSTORE_PRIVATE_KEY_PWD="changeit"
dataspace_ingress_OTT_CERTSTORE_PWD="changeit"
dataspace_ingress_OTT_TRUST_STORE_PWD="changeit"
dataspace_egress_OTT_CERTSTORE_PRIVATE_KEY_PWD="changeit"
dataspace_egress_OTT_CERTSTORE_PWD="changeit"
dataspace_egress_OTT_TRUST_STORE_PWD="changeit"

Добавить в репозиторий common в installer/system/efs/config/parameters/ssl.conf следующие параметры:

dataspace.ssl.ose.istio.ingress.ott.keyStore.path=ansible/files/ssl/module.p12
dataspace.ssl.ose.istio.ingress.ott.trustStore.path=ansible/files/ssl/ott_truststore.p12

dataspace.ssl.ose.istio.egress.ott.keyStore.path=ansible/files/ssl/module.p12
dataspace.ssl.ose.istio.egress.ott.trustStore.path=ansible/files/ssl/ott_truststore.p12