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

В руководстве приведены инструкции по установке компонента Product360 (PD36) продукта Platform V Product360 (Р36).

О документе#

Настоящий документ содержит описание процесса установки и настройки компонента Product360 (PD36) продукта Platform V Product360 (Р36).

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

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

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

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

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

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

**

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

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

В таблице ниже приведена информация по количеству pod, лимитов/реквестов для каждого модуля Компонента, разворачиваемого в среде контейнеризации.

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

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

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

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

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

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

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

• БД PostgreSQL (рекомендуется использование Platform V Pangolin SE (PSQ));

• создана ТУЗ (с доступом в БД и возможностью создания схем в ней);

• созданы проекты в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) и получен туда доступ;

• создан токен для проекта Jenkins;

• создан токен для загрузки из Registry;

• заказаны проекты в Jenkins;

• заказаны сертификаты стенда;

• установлен веб-браузер.

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

Для пространства среды контейнеризации необходим проект с характеристиками 16 CPU и 32 ГБ memory.

Используемые внешние продукты

Общие сведения#

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

• проект / пространство (Namespace) в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально);

• репозиторий Apache Maven (Snapshot, Release) для хранения артефактов в Nexus Public;

• репозиторий / registry (Snapshot, Release) для хранения Docker образов;

• технологическую учетную запись (далее также «ТУЗ») с правами записи (Write) на всех вышеперечисленных ресурсах.

Конвейер компонента расположен в Jenkins. Для работы Job с ресурсами инфраструктуры в проектной области jenkins команды компонента нужно создать следующие секреты / учетные записи (Jenkins Credentials):

1. Jenkins Credentials с Token от ServiceAccount.

2. Jenkins Credentials с ТУЗ (логин/пароль).

3. Jenkins Credentials для доступа к GitLab CE.

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

Job склейки расположен в артефакте owned в архиве -bin-.zip/package/scripts/jenkins под названием buildReassembledDistrib.groovy. Для использования скрипта необходимо добавить его путь в репозитории в настройках Jenkins job и заполнить пустые значения переменных и параметров вверху файла. После первого запуска добавятся параметры. Для последующих запусков требуется предварительно заполнять параметры соответственно их описанию.

Job deploy расположена в артефакте owned в архиве -bin-.zip/package/scripts/jenkins под названием Jenkinsfile-cloud. Для использования скрипта требуется добавить его путь в репозитории в настройках Jenkins job. После первого запуска добавятся параметры. Для последующих запусков требуется предварительно заполнять параметры соответственно их описанию. В качестве ссылки на дистрибутив в Nexus требуется указывать ссылку на дистрибутив, полученный в результате выполнения job buildReassembledDistrib (job склейки).

Миграция в БД#

Миграция БД осуществляется в рамках единого скрипта deploy, скрипт получит данные по подключению к базам данных из заполненного environment файла, хранящегося в Gitlab CE и называющегося в соответствии с именем стенда на который планируется deploy.

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

Логин и пароль для подключения к БД создаются в Jenkins в виде Username/Password. В процессе работы скрипта migration.conf дополняется логином и паролем, а так же параметром подключения к БД, после чего с ним запускается flyway/liquibase.
Описание содержимого migrations.conf

filesystem−обязательный параметр, сообщает что дальнейшая ссылка внутри файловой системы
srcDir/−в данной версии скрипта это директория в которую загружаются данные

В environment файлах существуют следующие параметры для БД (уникальны для каждого pod).

Параметры для баз данных

****_JDBC_URL: 'jdbc:PostgreSQL://XXX:5432/dev_appapi?currentSchema=product360' - URL базы данных для использования в liquidbase
****_INT_JDBC_URL: 'jdbc:PostgreSQL://XXX:54321/dev_appapi?currentSchema=product360'  URL базы данных для pgbouncer
DB_AUTH_USERNAME: "username"
APP_DB_ROLE: "as_tuz"

Данные URL различаются в случае если используется Platform V Synapse Service Mesh (SSM) и равны если его нет ****_JDBC_URL ****_INT_JDBC_URL.

В случае использования V Synapse Service Mesh (SSM) обязательны следующие параметры

DATABASE_SRV_MASTER: "main.database.mycompany.ru"
DATABASE_SRV_MASTER_IP: "XXX" - ip базы данных
DATABASE_PORT_MASTER: "5432" - ее порт 
INTERNAL_DATABASE_PORT_MASTER: "54321" - внутренний порт с которого происходит редирект

При этом ****_INT_JDBC_URL = jdbc:PostgreSQL://{DATABASE_SRV_MASTER_IP}:{INTERNAL_DATABASE_PORT_MASTER}/database/currentSchema="currentSchema"

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

В качестве тестирования использовалась следующая конструкция:

Миграции допускаются в liquibase формате.

Job склейки дистрибутива (merge)

buildReassembledDistrib.groovy – job для склейки переданного дистрибутива перед его установкой. Для использования job:

1. Добавьте ее в git-репозиторий и заполните переменные и параметры. Переменные к заполнению (находятся в начале файла):

NEXUS_CREDENTIAL_ID_DOCKER - ID credentials в Jenkins для доступа к docker registry
nexusCreds - ID credentials в Jenkins для доступа к maven репозиторию
groupId, repoId, artId - GAV параметры для публикации склеенного дистрибутива
mavenSettingsFile - ID config file в Jenkins, содержащего настройки доступа к maven репозиториям

2. Далее ниже в файле есть раздел parameters, заполните варианты параметра NEXUS_URL (вписать значение вместо url1, url2 и так далее при необходимости).

3. Создайте Jenkins pipeline, указав в настройках путь к файлу в git.

При запуске job заполните параметры:

RELEASE_VERSION - версия склеенного дистрибутива
DOCKER_REGISTRY_URL - домен docker registry (url.ru)
DOCKER_REGISTRY_PATH - путь для хранения Docker образов в registry (без домена - registry_dev/folder001)
baseImageJava - полный путь до базового Docker образа Java для сборки приложений
baseImageFrontend - полный путь до базового Docker образа NodeJS для сборки Frontend
NEXUS_URL - выбрать целевой репозиторий для загрузки склеенного дистрибутива
DISTR_URL - ссылка на исходный дистрибутив (полный путь)
NO_UPLOAD_NEXUS - флаг, позволяющий осуществить холостой прогон (склейка дистрибутива и сборка Docker без выгрузки в Nexus). Итоговый дистрибутив в этом случае выгружается в Jenkins.

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

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

1. Получите доступ к модулю. Для получения URL-адрес сервера приложений обратитесь к администратору компонента.

2. Выполните вход в модуль:

• на компьютере запустите браузер для входа в UI;

• в адресной строке интернет-обозревателя нажмите URL-адрес сервера приложения;

• нажмите клавишу Enter. Откроется страница авторизации;

• Чтобы авторизоваться от имени Пользователя, заполните поля Логин и Пароль.

3. Загрузите локальные справочники, через UI интерфейс системы.

Установка#

Подготовка к deploy#

Для подготовки к Deploy необходимо:

1. Заведите ТУЗ для доступа.

2. Запросите права на чтение репозитория содержащего код Job для развертывания.

3. Заведите заявку на предоставления доступа к registry для ТУЗ.

4. Импортируйте job склейки в Jenkins. (xml в Jenkins, а остальные необходимые файлы в GitLab CE).

5. Импортируйте job Deploy в Jenkins. (xml в Jenkins, а остальные необходимые файлы в GitLab CE).

6. Создайте credential в Jenkins для запуска Pipeline (есть специальная job для создания credential с правами на доступ к OpenShift). (Опционально можно другим способом)

7. Создайте credential содержащую ТУЗ для доступа к Nexus (Public), в котором будет лежать дистрибутив приложения.

8. Создайте GitLab CE репозиторий (получение прав) для хранения фалов конфигурации.

9. Создайте клиентский сертификат.

10. Сгенерируйте сертификаты для компонента OTTS, и создайте секреты.

11. Создайте ServiceAccount K8SC/OpenShift. service-acc-ingress (привязать imagePullSecret). Выполнив команды: oc create secret docker-registry registry-sa
    -docker-server=registry.localhost
    -docker-username=username
    -docker-password=passwd
    -docker-email=notused
    oc secrets link default registry-sa -for=pull

Настройка сертификатов для OTTS#

Для того чтобы выполнить настройку сертификата для OTTS:

1. Сгенерируйте ключевую пару. Пример (создание происходит с помощью инструмента keytool c примером команды):

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

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

   keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore ${module_id}.p12 -storetype PKCS12 -alias ${module_id} > ${module_id}_cert_req.pem

В результате выполнения данной команды будет создан файл CSR−**${** module_id}_cert_req.pem.

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

   Результатом выполнения заявки будет два файла: сертификат УЦ ОТТ и сертификат модуля.

4. Добавьте полученные сертификаты в keystore.

5. Получите сертификат публичного ключа OTTService одним из следующих способов:

   Сертификат публичного ключа OTT Service необходим для корректной работы клиента OTT. Используется для проверки подписи OTT Service.

   • Скачать сертификат и импортировать его в хранилище самостоятельно (должны быть установлены утилиты curl и keytool).
     Получение сертификата OTT Service:

     # Download OTT Service certificate
     curl -X GET "https://<ott-service-host>:8442/ejbca/publicweb/webdist/certdist?cmd=lastcert&subject=cn%3Dott-service" --insecure > ott-service.crt
     
     ### Use PKCS12
     # Import OTT Service certificate into PKCS12 store
     keytool -importcert -file ott-service.crt -keystore truststore.p12 -storetype PKCS12 -storepass <password> -alias "ott-service" -noprompt
     
     ### or JKS
     # Import OTT Service certificate into JKS store
     keytool -importcert -file ott-service.crt -keystore truststore.jks -storetype JKS -storepass <password> -alias "ott-service" -noprompt
     

   • Загрузить подготовленное хранилище.

Также для удобства создан скрипт с возможностью генерации такого сертификата. Для генерации запроса на сертификат ОТТ выполните ./cert_generate.py -CR -OTT -c product360 для product360

Создание технической учетной записи для БД#

В работе системы используется ТУЗ, например pct360.

Для того, чтобы получить ТУЗ, обратитесь к системному Администратору или оформите заявку на получение ТУЗ внутри своей организации.

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

• сreate table;

• schema;

• index;

• Grant select;

• update;

• delete;

• truncate;

• insert;

• trigger;

• execute;

• references;

• connect;

• temporary;

• usage;

• alter table.

Отсутствие прав:

• сreate table;

• schema. Приводит к ошибкам на этапе установки.

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

Создание зон репликации прикладного журнала (APLJ)#

Для настройки интеграции с Прикладным Журналом (компонент APLJ) необходимо создать зоны ПЖ. Для каждого микросервиса (апи) создается своя зона. В продукте используется плагин экспорта данных - EXPORT_FUNC_SI с типом данных фабрики - ORM_CV.

Создание клиентского сертификата#

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

Создание делится на 2 этапа:

1. Создание запросов на сертификаты.

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

Для создания запроса необходима консоль с sh.

Для того, чтобы создать закрытый ключ:

1. Создайте в консоли директорию для сертификатов, выполнив команду:

   Создаем директорию

   mkdir -p certs && cd certs
   

2. После создания директории создайте запрос. Создайте закрытый ключ, воспользовавшись утилитой OpenSSL:

   OpenSSL> genrsa -aes256 -out ourPrivatKey.key 2048
   

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

3. В результате в директории certs появится закрытый ключ ourPrivatKey.key.

Для того, чтобы создать открытый ключ:

1. Воспользуйтесь утилитой OpenSSL:

   OpenSSL> req -new -key ourPrivateKey.key -out ourCertificate.csr
   

2. Далее консоль запросит пароль для подтверждения. Введите пароль, который был задан в прошлом шаге.

3. Заполните информацию в сертификате:

   • Country Name: RU;

   • State or Province: <оставьте пустым>;

   • Organization Name: XXXX;

   • Organizational Unit Name: XXXX;

   • Common Name : <our hostname>;

   • emal Address: <оставьте пустым>.

4. В результате на выходе будет получен запрос на открытую часть сертификата, который необходимо направить коллегам из УЦ, для создания сертификата. Создание сертификата происходит через HP SM.

5. После получения сертификатов разделите на корневой, промежуточный и клиентский сертификат. Для этого откройте сертификат для просмотра, нажмите на экспортируемый сертификат и выберите Экспортировать в файл , в качестве кодировки выберите Файлы X.509 (.CER) в кодировке Base64 все эти сертификаты сохраните отдельными файлами.

6. После чего преобразуйте в OpenSSL клиентский сертификат и дешифруйте приватный ключ, для этого обратитесь к OpenSSL:

   OpenSSL> x509 -inform der -in ourCertificate.cer -out ourSertificate.pem
   

7. Далее дешифруйте приватный ключ:

   OpenSSL> rsa -in ourPrivateKey.key -out unencryptPrivateKey.key
   

   Команда попросит ввести пароль, который был задан в 1х шагах.

8. Далее соберите данные ключи в секреты K8SC/OpenShift, для чего выполните следующее:

   1. Авторизуйтесь в OS, зайдите в необходимый проект, в котором планируется устанавливать приложение.

   2. Пройдите в WorkLoads → Secrets → Create Secret → Key/Value Secret.

Для создания секрета secret-ingressgateway-ca-certs

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

1. Перейдите в WorkLoads → Secrets → Create Secret → Key/Value Secret имя секрета−secret-pct360-ingressgateway-certs

   • ключ — tls.crt;

   • значение — текстовое содержимое клиентского ключа в формате OpenSSL созданного ранее.

2. Вторым ключом добавьте дешифрованный ключ, для того, чтобы хранить их в 1м секрете:

   • ключ — tls.key;

   • значение — текстовое значение дешифрованного ключа, созданного ранее.

Инструкция создания клиентских сертификатов, представлена в данном документе в разделе Создание клиентских сертификатов.

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

secret-pct360-ingressgateway-certs (клиентский сертификат)
client.crt
tls.crt
tls.key
имя секрета secret-ingressgateway-ca-certs (серверный сертификат)
ca.pem
имя секрета secret-pct360-ott-certs (сертификаты ОТТ)
error-processor-cloud.p12
ott_service_truststore.p12
имя секрета kafka-secret (за сертификатами обращаться к компоненту Прикладной журнал (APLJ) продукта Platform V Backend (BD))  

PCT360APP_certs
PCT360ICON_certs
truststore.jks
key.password
PCT360APP_password
PCT360DM_password
PCT360ICON_password
truststore_password
имя секрета spas-secret-key (за ключом авторизации обращаться в сервис авторизации)
spas.secret.key
имя секрета db-secret (пароли каждого сервиса для подключения к базам данных)
DB_APP_PASSWORD
DB_AUTH_PASSWORD
DB_DM_PASSWORD
DB_INNER_PASSWORD
имя секрета keycloak-cli.password
keycloak-cli.password
Имя секрета kfi-kafka-secret (сертификаты kafka)
server.keystore.jks
trust.jks
key.password
truststore.password
Имя секрета ceph-secret (данные авторизации ceph s3)
s3.access.key.id
s3.secret.access.key

Создание секретов для среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально)#

Для выполнения команд необходим установленный клиент среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально).

Необходимо получить следующие секреты:

• api-key-app-secret;

• db-secret;

• ingressgateway-secret;

• ingressgateway-ca-secret;

• secret-pct360-ott-certs;

• kafka-secret.

1. Создание секрета

   За основу возьмите yaml-файл примерно такого содержания:

    kind: Secret
   apiVersion: v1
   metadata:
   name: <имя секрета>
   data:
   <key>: <value>
   type: Opaque
   

• secret-ingressgateway-ca-certs и secret-ingressgateway-certs — для хранения сертификатов Envoy файлы подготавливаются при создании клиентского сертификата:

1. Логин в K8SC/OpenShift:

   oc login --token=<openshift_user_token> --server=<openshift_api_url>:6443
   

2. Создание секрета istio-certs (вывод содержимого в консоль):

   oc create secret generic istio-certs --from-file=root-ca.pem --from-file=envoy.crt --from-file=envoy.key --dry-run -o yaml > secret-istio-certs.yaml
   

3. Создание секрета secret-ingressgateway-ca-certs:

   oc create secret generic secret-ingressgateway-ca-certs --from-file=ca.pem=root-ca.pem --dry-run -o yaml > secret-ingressgateway-ca-certs.yaml
   

4. Создание секрета secret-ingressgateway-certs:

   oc create secret generic secret-ingressgateway-certs --from-file=tls.key=envoy.key --from-file=tls.crt=envoy.crt --dry-run -o yaml > secret-ingressgateway-certs.yaml
   

5. Применить jenkins job для шифрования файлов.

6. Выложить зашифрованный файл секрета в GitLab CE repository в папку /config/<project_name>/<stand_name>/secrets.

Для простоты использования, секреты можно создать из ранее подготовленных сертификатов с помощью скрипта

./cert_generate.py -h

   usage: cert_generate.py [-h] -c CN [-p PWD] [-r ROOT] [-i INTERMEDIATE]
[-C CLIENT] [-CR] [-I] [-kafka] [-server] [-req REQ]
[-IngressSecret] [-secretname SECRETNAME]
[-OSKafkaSecret] [-Certs CERTS] [-Keys KEYS] [-OTT]
[-OTTSecret] [-ottpem OTTPEM] [-rootmycompany ROOTmycompany]
Create JKS with you
optional arguments:
-h, --help show this help message and exit
-c CN, --cn CN common name
-p PWD, --pwd PWD password for jks
-r ROOT, --root ROOT root certificate
-i INTERMEDIATE, --intermediate INTERMEDIATE
intermediate cert
-C CLIENT, --client CLIENT
client cert
-CR, --create need create jks
-I, --Import need add cert to exist jks
-kafka Crete jks for kafka
-server create openshift ingress cert from req file
-req REQ req файл с параметрами
создаваемого сертификата
-IngressSecret create OpenShift secret for Ingress/Egress from cert
key and trusted CA
-secretname SECRETNAME
имя создаваемого сертификата
-OSKafkaSecret create OpenShift secret for kafka from cert key and
trusted CA
-Certs CERTS массив сертификатов для
kafka, в порядке указанном
для ключей
-Keys KEYS массив ключей, в порядке
указанном для сертификато
для kafka
-OTT create cert for OTT
-OTTSecret create secret for OTT
-ottpem OTTPEM Ott pem from ott ZNO
-rootmycompany ROOTmycompany root pem from ott ZNO

Создать секрет для ОТТ: ./cert_generate.py -OTTSecret -c CommonName -secretname secret-pct360-ott-certs

где, CommonName — созданный на предыдущем шаге, этим же скриптом, сертификат.

Создать kafka-secret

./cert_generate.py -server -req san.cnf -c ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru -OSKafkaSecret -secretname kafka-cert -r ../RootCa.cer -i ../intermediate.cer -Certs ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru/ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru.csr,ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru/ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru.csr -Keys APP_cert,AUTH_cert

Создать серверный сертификат:

./cert_generate.py -server -req san.cnf -c ci02707148-idevgen-errm-kb-ift-1.apps.dev-gen.mycompany.ru -IngressSecret -secretname secret-ingressgateway-certs -r ../RootCa.cer -i ../intermediate.cer

Скрипт для генерации секретов храниться в party дистрибутиве.

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

Файл .env#

Текущий список параметров со стенда K8S (упрощенный запуск).

Параметры запуска Job

• keycloak: true

• ansible_tags: app-api,auth-api,frontend,datamart-api,keycloak,inner-connector-api,mdm-api,simple_ingress

ENABLED_COMPRESSION:false значение по умолчанию ROUND_ROBIN_ENABLED: true значение по умолчанию validate_certs: false значение по умолчанию CONFIG_MAP_DEFAULT_MODE: 256 значение по умолчанию SIDECAR_ISTIO_INJECT: true значение по умолчанию AUDIT_ENABLED: true true если нужна интеграцию с АС аудит, иначе false NEED_LOGGER: true true true если нужна интеграцию с АС logger, иначе false NEED_SPAS: true NEED_OTT: true true если нужна интеграцию с АС OTT, иначе false SUDIR_ENABLED: true значение по умолчанию SA_AUTOMOUNT: true значение по умолчанию STANDIN_ENABLED: true true если нужна интеграцию с APLJ, иначе false path_to_templates: templates_ansible значение по умолчанию USE_SPAS_ROLES: false значение по умолчанию whithout_debug: true значение по умолчанию

SOWA.RRC SOWA_RRC_PORT: 10251 SOWA_RRC_GW: tvlsg-kpr000003.mycompany.ru

Настройка параметров работы Secret Management Активация использования чтения секретов из Hashicorp Vault/SecMan для OpenShift true||false (inject секретов в Openshift-е) -> SecMan_INJECTOR: true включение работы с Hashicorp Vault/SecMan VAULT_NAME: hashicorp название инструмента работы с Hashicorp Vault/SecMan VAULT_PATH: CI03064796_CI03419752/A/IFT/OSH/PD36/KV путь к хранилищу Hashicorp Vault/SecMan VAULT_TENANT: CI03064796_CI03419752 наименование пространства в Hashicorp Vault/SecMan SecMan_GW: "t.secrets.mycompany.ru" - URL адрес Hashicorp Vault/SecMan

FEATURE

TOGGLE REGISTRY_URL: 'registry.mycompany.ru' ALWAYSAWAIBLE: "100%" PCT_VERSION: 'dev' PCT_REPLICA_COUNT: "1" PRODUCT_LABEL: 'product360' STARTER_CLIENT_AUTH_API_URL: 'auth-api' AUTH_SYSTEM: 'SUDIR' система аутентификации в приложении DB_DRIVER: 'org.PostgreSQL.Driver' SPRING_PROFILE: 'xxxx' наименование spring профиля сервисов SUDIR_GEO_AUTH_MODE: SIMPLE SUDIR_AUTH_PORT: 19445

APP-API

APP_API_CPU_LIMIT: "500m" APP_API_KEY: 'appapikey' APP_API_CPU_REQUEST: "500m" APP_API_MEMORY_LIMIT: "1Gi" APP_API_MEMORY_REQUEST: "512Mi" STARTER_CLIENT_APP_API_URL: 'app-api' DB_APP_USERNAME: "username" PROBE_PORT_APP: 8082 APP_API_MODULE_ID: 'app-api-ift1' STANDIN_ZONE_APP_API: 'PCT360A'

AUTH-API

AUTH_API_CPU_LIMIT: "500m" AUTH_API_CPU_REQUEST: "500m" AUTH_API_MEMORY_LIMIT: "1Gi" AUTH_API_MEMORY_REQUEST: "512Mi" AUTH_API_KEY: 'key' DB_AUTH_USERNAME: "username" PROBE_PORT_AUTH: 8081 STANDIN_ZONE_AUTH_API: 'PCT360B' STANDIN_AUTH_API_MODULE_ID: 'auth-api-ift1'

DATAMART

DATAMART_API_KEY: 'datamart-api' DB_DM_USERNAME: "username" DATAMART_SPRING_PROFILE: "xxxx", hazelcast это включает кеш на витрине пример (xxxx,applJournal,hazelcast) альтернатива DATAMART_SPRING_PROFILE: "xxxx", caffeine включает кеш на витрине пример (xxxx,applJournal,caffeine). Компонент PD36 использует опции hazelcast для которого приведены параметры. DATAMART_APP_API_READ_PAGE_SIZE: "100" DATAMART_APP_API_READ_CATEGORY_PAGE_SIZE: "100" PROBE_PORT_DATA: 8083 STANDIN_ZONE_DATAMART_API: "PCT360DATA" STANDIN_DATAMART_API_MODULE_ID: "datamart-api-ift1"

INNER-CONNECTOR-API

ICON_API_KEY: "inner-connector-api" DB_INNER_USERNAME: "username" ICON_SPRING_PROFILE: "xxxx,test-dev" S3_SERVICE_ENDPOINT: "https://nun-edz.mycompany.ru" KFI_INTEGRATION_FEATURE_ENABLED: "true" RISK_RATING_INTEGRATION_FEATURE_ENABLED: "true" STANDIN_ZONE_ICON: PCT360ICON STANDIN_ICON_MODULE_ID: icon-api-ift1 PROBE_PORT_ICON: 8084 CLIENT_CERT_NAME: client.crt CLIENT_CERT_KEY: tls.key KAFKA_TRUSTSTORE_PASS: truststore.password KAFKA_KEYSTORE_PASS: key.password KAFKA_TRUSTSTORE_SECRET: kfi-kafka-secret KAFKA_KEYSTORE_SECRET: kfi-kafka-secret TRUSTSTORE_LOCATION_PJ: /opt/kafka-pj/certs/truststore.jks TRUSTSTORE_LOCATION_KFI: /opt/kafka-pj/certs/truststore.jks

MDM-API

DB_MDM_USERNAME: "username" MDM_API_CPU_LIMIT: "1" MDM_API_CPU_REQUEST: "500m" MDM_API_MEMORY_LIMIT: "1300Mi" MDM_API_MEMORY_REQUEST: "1300Mi" MDM_API_KEY: 'mdmapikey' STARTER_CLIENT_MDM_API_URL: 'mdm-api' PROBE_PORT_MDM: 8085 STANDIN_ZONE_MDM_API: 'PCT360MDM' STANDIN_MDM_MODULE_ID: mdm-api-ift1 MDM_SPRING_PROFILE: 'xxxx' #наименование spring профиля сервисов JAVA_OPTS_MDM: -XX:+AlwaysActAsServerClassMachine -Dlogging.config=/mnt/logback.xml JAVA_DEBUG_OPTS_MDM: APP_OPTS_MDM: --spring.config.additional-location=/etc/vault/kafka.properties,/etc/vault/spas.properties,/etc/vault/db.properties LOGBACK_MaxFileSize_MDM: 10MB LOGBACK_MaxHistory_MDM: 5 LOGBACK_TotalSizeCap_MDM: 50MB

KEYCLOAK

KEYCLOAK_CPU_LIMIT: "1" KEYCLOAK_CPU_REQUEST: "500m" KEYCLOAK_MEMORY_LIMIT: "1Gi" KEYCLOAK_MEMORY_REQUEST: "512Mi" KEYCLOAK_IMAGE_URL: 'registry.ххх.mycompany.ru-dev/ci00611947/ci01558713_pct360_dev/product360keycloak@sha256:21a8cef8bb8c109e8ed9ce4aa1679a09d12d17c0eb1e5caff6db97c21daa2284' KEYCLOAK_AUTH_URL: 'auth' KEYCLOACK_ENABLED: 'false'

INNER-CONNECTOR-APi

ICON_API_CPU_LIMIT: '1' ICON_API_CPU_REQUEST: '500m' ICON_API_MEMORY_LIMIT: '1Gi' ICON_API_MEMORY_REQUEST: '512Mi'

FRONTEND

FRONTEND_CPU_LIMIT: '1' FRONTEND_CPU_REQUEST: '500m' FRONTEND_MEMORY_LIMIT: '512Mi' FRONTEND_MEMORY_REQUEST: '512Mi'

AUDIT AUDIT_HOST: 'http://ift.audit2-http-proxy-ott.ift-xxxx-apps.ocp-geo.mycompany.ru/v1' AUDIT_GW: 'ift.audit2-http-proxy-ott.ift-xxxx-apps.ocp-geo.mycompany.ru.ru' AUDIT_USER: 'ХХХ-SA-PCT360A' AUDIT_PORT: "443" AUDIT_PROTO: "HTTPS" AUDIT_TIMEOUT: 0.4

SPAS

SPAS_HOST: 'tklia-xxxxu0015.vm.mos.cloud.mycompany.ru' SPAS_PORT: 8443 SPAS_PROTO: "HTTPS" SPAS_URL: 'http://tklia-xxxxu0015.vm.mos.cloud.mycompany.ru/spas/rest'

OTT

NEED_OTT: true OTT_SERVICE_URL: 'https://str-vat-app2141.ххх.mycompany.ru:8443/ott-service/rest/token' OTT_SERVICE_HOST: 'str-vat-app2141.ххх.mycompany.ru:8443,str-vat-app2142.ххх.mycompany.ru:8443' OTT_CLIENT_CERT_ALIAS: 'p36-cloud' OTT_SERVICE_CERT_ALIAS: 'ott-service' OTT_MODULE_ID: 'p36-cloud' OTT_IMAGE: "registry.ххх.mycompany.ru/ххх/xxxx/ci00641491/ci01125613_ott/ott-client-api@sha256:e7c8a9a5745c32ab2157a6c823f1174c31de5d08bd35fbc0bc1918fd24b6c7fc" OTT_CERTSTORE_TYPE: PKCS12 OTT_CERTSTORE_PATH: '/mnt/secrets/p36-cloud.p12' OTT_TRUST_STORE_PATH: '/mnt/secrets/ott_service_truststore.p12'

DATABASE

DATABASE_SRV_MASTER: "tklid-xxxx00558.vm.mos.cloud.mycompany.ru" DATABASE_SRV_MASTER_IP: "XXX" DATABASE_PORT_MASTER: "5432" INTERNAL_DATABASE_PORT_MASTER: "54321" DATABASE_SRV_SLAVE: "tklid-xxxx00559.vm.mos.cloud.mycompany.ru" DATABASE_SRV_SLAVE_IP: "XXX" DATABASE_PORT_SLAVE: "6544" INTERNAL_DATABASE_PORT_SLAVE: "54322"

DATABASE_SRV_DATAMART_SLAVE: "tklid-xxxx00560.vm.mos.cloud.mycompany.ru" DATABASE_DATAMART_SLAVE_IP: "XXX" DATABASE_DATAMART_PORT_SLAVE: "5437" INTERNAL_DATABASE_DATAMART_PORT_SLAVE: "54323"

DATABASE_SRV_DATAMART_MASTER: "tvldd-xxxx01536.ххх.mycompany.ru" DATABASE_DATAMART_MASTER_IP: "XXX" DATABASE_DATAMART_PORT_MASTER: "5433" INTERNAL_DATABASE_DATAMART_PORT_MASTER: "54324"

DATABASE_SRV_MASTER_STDIN: "tvldd-xxxx01537.ххх.mycompany.ru" DATABASE_SRV_MASTER_IP_STDIN: "XXX" DATABASE_PORT_MASTER_STDIN: "5433" INTERNAL_DATABASE_PORT_MASTER_STDIN: "54327" DATABASE_SRV_SLAVE_STDIN: "tklid-xxxx00562.vm.mos.cloud.mycompany.ru" DATABASE_SRV_SLAVE_IP_STDIN: "XXX" DATABASE_PORT_SLAVE_STDIN: "5432" INTERNAL_DATABASE_PORT_SLAVE_STDIN: "54328"

DATABASE_SRV_DATAMART_SLAVE_STDIN: "tklid-xxxx00563.vm.mos.cloud.mycompany.ru" DATABASE_DATAMART_SLAVE_IP_STDIN: "XXX" DATABASE_DATAMART_PORT_SLAVE_STDIN: "5432" INTERNAL_DATABASE_DATAMART_PORT_SLAVE_STDIN: "54325"

DATABASE_SRV_DATAMART_MASTER_STDIN: "tvldd-xxxx01538.mycompany.ru" DATABASE_DATAMART_MASTER_IP_STDIN: "XXX" DATABASE_DATAMART_PORT_MASTER_STDIN: "5432" INTERNAL_DATABASE_DATAMART_PORT_MASTER_STDIN: "54326"

APP_DB_ROLE: "as_admin" AUTH_DB_ROLE: "as_admin" DATAMART_DB_ROLE: "as_admin" ICON_DB_ROLE: "as_admin" MDM_DB_ROLE: "as_admin"

PJ

STANDIN_STUB: true заглушка прикладного журнала KAFKA_BOOTSTRAP_SERVERS: 'XXX' KAFKA_PJ_PORT: "9093" KAFKA_PJ_HOST_1: "tvlsq-xxxx00054.mycompany.ru" KAFKA_PJ_IP_1: "XXX" KAFKA_PJ_HOST_2: "tvlsq-xxxx00056.mycompany.ru" KAFKA_PJ_IP_2: "XXX" KAFKA_PJ_HOST_3: "tvlsq-xxxx00053.mycompany.ru" KAFKA_PJ_IP_3: "XXX" KAFKA_PJ_HOST_4: "tvlsq-xxxx00055.mycompany.ru" KAFKA_PJ_IP_4: "XXX" KAFKA_PJ_HOST_5: "tvlsq-xxxx00052.mycompany.ru" KAFKA_PJ_IP_5: "XXX" KAFKA_PJ_HOST_6: "tvlsq-xxxx00057.mycompany.ru" KAFKA_PJ_IP_6: "XXX" KAFKA_PJ_HOST_7: "kafka-p-j.mycompany.ru" KAFKA_PJ_IP_7: "XXX" KAFKA_PJ_HOST_8: "kafka-p-j.mycompany.ru" KAFKA_PJ_IP_8: "XXX" SSL_IDENTIFICATION_ALGORITHM: "" SSL.endpoint.identification.algorithm: "" KAFKA_MESSAGE_SIZE: 4000000 KAFKA_POLL_RECORDS: 10

KAFKA-KFI

KFI_KAFKA_TOPIC: "KFI.PCT_SECURITY_EVENT.V1"

MTLS_AUTH

EFS_CERT_CN: '.CN=(00ca0001efsukoflwas|00CA0001CUFSufssrusr|riskratingsowatest),OU=(00CA|Risk),O=(Savings Bank of the Russian Federation|mycompany),C=RU.' данные сертификатов для использования DATAMART api EFS_HEADER_VALUE: EFSPFM_CALENDAR UFS_1_HEADER_VALUE: PINS_LOANS_MB UFS_REGEXP_HEADER_VALUE: (EMP_DBANK|PINS_LOANS_MB)

Значения для клиентского сертификата СУДИР (CN)

SUDIR_CERT_CN: '.CN=.' PFPV_CERT_CN: ".*" PFPV_HEADER_VALUE: "PFPV_BH_SEC" DATAMART_API_CPU_LIMIT: "1" DATAMART_API_CPU_REQUEST: "500m" DATAMART_API_MEMORY_LIMIT: "1Gi" DATAMART_API_MEMORY_REQUEST: "512Mi"

LOGGER

LOGGER_ENDPOINT_URI: "/v1/events" LOGGER_GW: "logger-cloud-ift-ott.ingress.apps.dev-gen.ххх.mycompany.ru" LOGGER_ENDP: "logger-cloud-ift-ott.ingress.apps.dev-gen.ххх.mycompany.ru" LOGGER_ENDP_2: "ci00641491-idevgen-logger-ift.ingress.apps.dev-gen.ххх.mycompany.ru" LOGGER_PORT: "443" LOGGER_PROTO: "HTTPs" FLUENT_BIT_IMAGE: 'registry.ххх.mycompany.ru/ххх/ххх/ci00641491/ci02469991_logger/fluent-bit@sha256:767f20b9246a0209cd3236c2e53419d96df2f4f013ce59d634b1fd581ee8c951'

CEEPH

CEPH_GW: "nun-edz.ххх.mycompany.ru" CEPH_PORT: "443" CEPH_ENDPOINT: "nun-edz.ххх.mycompany.ru" CEPH_CA_CERTIFICATE: /etc/istio/ingressgateway-ca-certs/ca.pem CEPH_CLIENT_CERTIFICATE: /etc/istio/ingressgateway-certs/tls.crt CEPH_TLS_MODE: MUTUAL

ISTIO

SIDECAR_ISTIO_CPU_REQ: 1000m SIDECAR_ISTIO_CPU_LIM: 1000m SIDECAR_ISTIO_MEM_REQ: 1000Mi SIDECAR_ISTIO_MEM_LIM: 1000Mi INGRESSGATEWAY_NAME: dp-pct360-ingress EGRESSGATEWAY_NAME: dp-pct360-egress INGRESSGATEWAY_CERTS_SECRET_NAME: secret-pct360-ingressgateway-certs INGRESSGATEWAY_CA_CERTS_SECRET_NAME: secret-ingressgateway-ca-certs INGRESSGATEWAY_CERTS_MOUNT_PATH: /etc/istio/ingressgateway-certs INGRESSGATEWAY_CA_CERTS_MOUNT_PATH: /etc/istio/ingressgateway-ca-certs EGRESSGATEWAY_CERTS_MOUNT_PATH: /etc/istio/ingressgateway-certs EGRESSGATEWAY_CA_CERTS_MOUNT_PATH: /etc/istio/ingressgateway-ca-certs EGRESSGATEWAY_CERTS_SECRET_NAME: secret-pct360-ingressgateway-certs EGRESSGATEWAY_CA_CERTS_SECRET_NAME: secret-ingressgateway-ca-certs PROXY_IMAGE: registry.redhat.io/openshift-service-mesh/proxyv2-rhel8@sha256:51d82b560e467ec59a3b6625b04c31b86df5b4c10070a351d547cb6cf3f26591

6.4 tls

POD_DISRUPTION_BUDGET_ENABLED: True DEPLOY_TO_KUBERNETES: false FLUENT_BIT_SIDECAR_ENABLED: false PDB_V: v1beta1 rls_localCacheSizeInBytes: "524288"

rate-limiter

RATELIMITER_REPLICAS: 2 RATELIMITER_CPU_LIMIT: 500m RATELIMITER_MEM_LIMIT: 300Mi RATELIMITER_CPU_REQ: 250m RATELIMITER_MEM_REQ: 150Mi RATELIMITER_IMAGE: указать ссылку на образ ratelimiter RATELIMITER_PDB: 1 LIMITS_CONFIG_NAME: rate-limit-config LIMITS_ENVOY_V: "1.14" LIMITS_VISIBILITY: namespace LIMITS_SERVICE: rate-limiter-headless-service LIMITS_CONFIG_NAMESPACE: LIMITS_SERVERPORT: 8081

redis

rls_redisUrl: 'mymaster,redis-sentinel-0.redis-sentinel:26379,redis-sentinel-1.redis-sentinel:26379,redis-sentinel-2.redis-sentinel:26379' rls_redisType: 'sentinel' REDIS_PDB: 1 REDIS_REPLICAS: 3 REDIS_IMAGE: указать ссылку на образ redis REDIS_CPU_LIMIT: 300m REDIS_MEM_LIMIT: 500Mi REDIS_CPU_REQ: 150m REDIS_MEM_REQ: 250Mi

redis-sentinel

SENTINEL_PDB: 1 SENTINAL_REPLICAS: 3 SENTINEL_CPU_LIMIT: 200m SENTINEL_MEM_LIMIT: 200Mi SENTINEL_CPU_REQ: 100m SENTINEL_MEM_REQ: 100Mi

rloperator

RLOPERATOR_REPLICAS: 2 RLOPERATOR_CPU_LIMIT: 200m RLOPERATOR_MEM_LIMIT: 200Mi RLOPERATOR_CPU_REQ: 100m RLOPERATOR_MEM_REQ: 100Mi RLOPERATOR_IMAGE: указать ссылку на образ rloperator operator_scope: 'namespace' envoy_filter_grpc_timeout: '1s' RLOPERATOR_PDB: 1 endpoints: (заполнено)

or_ids: [
{
"max_program_size": "<число-максимальный размер регулярного выражения>",
"regex": "<регулярное выражения для сертификата>"
}
]
and_ids: {
"certificates": [
{
"max_program_size": "<число-максимальный размер регулярного выражения>",
"regex": "<регулярное выражения для сертификата>"
}
],
"exact_code": [
{
"exact_match": "<наименование subsystemcode>"
}
],
"regex_code": [
{
"max_program_size": "<число-максимальный размер регулярного выражения>",
"regex": "<регулярное выражения для subsystemcode>"
},
]
}

LIVENESS_DELAY: #время через которое начнется liveness опрос pod после deploy STARTUP_PERIOD: #период startup опроса pod STARTUP_FAILURE: #количество fail ответов для провала startup пробы

7.2

job_launches_interval: '10000' SUDIR_SMART_GEOROUTE: "<вписать значение гео-route для SUDIR" DATAMART_SMART_MTLS_HOST: "<вписать значение route для DATAMART>" KAFKA_TOPICS: "KFI.PCT_SECURITY_EVENT.V1"

7.3

READINESS_DELAY: 45 #Задержка перед проверкой readiness pod приложения (время, отведенное приложению на запуск) LOGA_xxxx: true/false если true то логи будут писаться в logger LOGA_KAFKA_TOPIC: "KFI.PCT_SECURITY_EVENT.V1" - topic для записи логов в kafka LOGA LOGA_KAFKA_PROTOCOL: PLAINTEXT - протокол подключения к kafka LOGA - указывается именно такой

loga_servers:

[
{"id": "1","ip" : "XXX", "host_internal":"iftp-abyss-kafka-01.opsmon.ХХХ", "port_internal": "19093", "port": "9093", uri: "iftp-abyss-kafka-01.opsmon.ХХХ:9093"},
{"id": "2","ip" : "1XXX", "host_internal":"iftp-abyss-kafka-02.opsmon.ХХХ", "port_internal": "19094", "port": "9093", uri: "iftp-abyss-kafka-02.opsmon.ХХХ:9093"},
 {"id": "3","ip" : "XXX", "host_internal":"iftp-abyss-kafka-03.opsmon.ХХХ", "port_internal": "19095", "port": "9093", uri: "iftp-abyss-kafka-03.opsmon.ХХХ:9093"}
 ]

• loga_servers параметр опциональный и необходим для интеграции c LOGA;

• id - произвольное уникальное число;

• ip - внешний ip KAFKA BROKERS;

• host_internal - адрес хоста преобразуется внутренним DNS на соответствующий внешний ip KAFKA BROKER;

• uri = host_internal + port;

• port -внешний порт каfka brokers;

• port_internal - внутренний порт на egress можно выбрать произвольный диапазон например 19093-19097.

7.4.0

Если для настройки умной геобалансировки потребуется добавить дополнительные route, то необходимо перевести параметр NEED_SECOND_ROUTE в true и заполнить параметры SUDIR_SMART_GEOROUTE и DATAMART_SMART_MTLS_HOST.

HEALTHCHECK_IMAGE: - registry.ххх.xxx.ru/ci01994970/ci03155221_synapse-monitoring/rhel7-java-synapse-geo-healthcheck/healthcheck-ci03155221@sha256:cd0dfdb8f2af14374ddce2f9b6780b1165e09524c0f8f208e5c0d20cfe0abc85

Параметры для настройки kafka для интеграции с LOGA (ожидаем передачи доработки)

LOGA_KAFKA_SERVERS: "example1.com:19093,example2.com:19093,example3.com:19093" - перечислены через запятую адрес хоста и порт адрес (ограничение порт нужно указать 19093 это фейковый внутренний порт, хост нужно указать любой он внутренний и преобразуется внутренним DNS на один из внешних адресов LOGA_KAFKA_IP_1,2,3) LOGA_KAFKA_IP_1: "IP_ADDRESS" - внешний ip 1 KAFKA BROKERS можно указать до 3 брокеров LOGA_KAFKA_IP_2: "IP_ADDRESS" внешний ip 2 KAFKA BROKERS можно указать до 3 брокеров LOGA_KAFKA_IP_3: "IP_ADDRESS" внешний ip 2 KAFKA BROKERS можно указать до 3 брокеров

7.5.0

Опциональные параметры, которые имеют дефолтное значение. secman_ott_certs_path – путь к секрету в secman, где хранятся сертификаты для ОТТ. secman_ingressgateway_ca_certs_path – путь к секрету в secman, где хранится клиентский сертификат для ingress/egress.

OTT_CERTSTORE_NAME – имя ключа в хранилище secman дефолтное значение для обратной совместимости error-processor-cloud, этот ключ в совокупности с параметром OTT_CERTSTORE_PATH. позволяют решить стс с некорректным именем к отт сертификата.

Эти параметры опциональны, но позволяют отказаться от механизма при котором приходилось модифицировать Job развертывания под стенд.

Примечание: Путь к папке с секретами – путь до папки, в которой хранятся секреты (как правило состоит из заглавных букв). Пример – ХХХ/A/ХХХ/BD/ХХХ/PD36/KV. Путь к секрету – путь до самого секрета, внутри которого уже лежат пары ключ/значение. Пример – ХХХ/A/ХХХ/BD/ХХХ/PD36/KV/secret-name.

secman_ingressgateway_ca_certs_path – путь к секрету в secman, где хранится клиентский сертификат для ingress/egress. secman_ott_certs_path – путь к секрету в secman, где хранятся сертификаты для ОТТ. secman_ingressgateway_certs_path – путь к секрету в secman, где хранятся серверный сертификат для ingress/egress. secman_kafka_secret_path – путь к секретам в secman, где хранятся секреты для Прикладного журнала. secman_kfi_kafka_secret_path – путь к секретам в secman, где хранятся секреты для kafka для интеграции с нами в частности интеграция с КФИ. secman_kafka_loga_secret_path – путь к секретам в secman, где хранятся секреты для kafka для интеграции LOGA. secman_spas_secret_key_path – путь к секретам в secman, где хранятся секреты для интеграции c SPAS. secman_keycloak_cli_password_path – путь к секретам в secman, где хранятся секреты для интеграции c KEYCLOAK (Опциональная). secman_db_secret_path – путь к секретам в secman, где хранятся секреты Базы данных. secman_ceph_secret_path – путь к секретам в secman, где хранятся секреты Интеграции c Сeph или иным S3 совместимым объектным хранилищем.

hazelcast_default_time_to_live_seconds - время жизни кеша hazelcast в витрине, дефолтное значение 360 hazelcast_default_idle_seconds время жизни кеша hazelcast в витрине без обращения в данному ключу, дефолтное значение 240

geo_data_health_check_enabled: default true geo healthcheck витрины вкл выкл geo_health_check_enabled: default true geo healthcheck ui вкл выкл geo_data_health_check_delay. default('5000') частота опроса витрины на работоспособность healthcheck geo_health_check_delay. default('5000') частота опроса ui на работоспособность geo healthcheck

geo_data_health_check_failure_threshold | default("'2'") количество неудач geo healthcheck витрины (datamart) geo_health_check_failure_threshold | default("'2'") количество неудач geo healthcheck ui (все остальные приложения)

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

7.6.0-7.7.0

Исправление ошибки 403 в sidecar fluentbit. Поднимаем max_request_bytes в EnvoyFilter в 2 раза LOGGER_EGRESS_MAX_REQUEST_BYTES: "16777216" - обязательный параметр ISTIO_EGRESS_MAX_REQUEST_BYTES: "8192000" - параметр опциональный, имеет дефолтное значение, в данный момент не является обязательным.

Параметризация параметров Logback для каждого API. Все параметры опциональны и имеют дефолтное значение (указано для примера) LOGBACK_MaxFileSize_APP: 10MB LOGBACK_MaxHistory_APP: 5 LOGBACK_TotalSizeCap_APP: 50MB

LOGBACK_MaxFileSize_AUTH: 10MB LOGBACK_MaxHistory_AUTH: 5 LOGBACK_TotalSizeCap_AUTH: 50MB

LOGBACK_MaxFileSize_DATAMART: 10MB LOGBACK_MaxHistory_DATAMART: 5 LOGBACK_TotalSizeCap_DATAMART: 50MB

LOGBACK_MaxFileSize_ICON: 10MB LOGBACK_MaxHistory_ICON: 5 LOGBACK_TotalSizeCap_ICON: 50MB

Параметризация опций запуска приложения (передаются через Config Map как environment переменные в скрипт запуска). Параметры являются обязательными. Параметр DEBUG по умолчанию пустой, это не опечатка. JAVA_OPTS_APP: -XX:+AlwaysActAsServerClassMachine -Dlogging.config=/mnt/logback.xml JAVA_DEBUG_OPTS_APP: APP_OPTS_APP: --spring.config.additional-location=/etc/vault/kafka.properties,/etc/vault/spas.properties,/etc/vault/db.properties

JAVA_OPTS_AUTH: -XX:+AlwaysActAsServerClassMachine-Dlogging.config=/mnt/logback.xml JAVA_DEBUG_OPTS_AUTH: APP_OPTS_AUTH: --spring.config.additional-location=/etc/vault/kafka.properties,/etc/vault/spas.properties,/etc/vault/keycloack.properties,/etc/vault/db.properties

JAVA_OPTS_DATAMART: -XX:+AlwaysActAsServerClassMachine -Dlogging.config=/mnt/logback.xml JAVA_DEBUG_OPTS_DATAMART: APP_OPTS_DATAMART: --spring.config.additional-location=/etc/vault/kafka.properties,/etc/vault/db.properties

JAVA_OPTS_ICON: -XX:+AlwaysActAsServerClassMachine -Dlogging.config=/mnt/logback.xml JAVA_DEBUG_OPTS_ICON: APP_OPTS_ICON: --spring.config.additional-location=/etc/vault/ceph.properties,/etc/vault/db.properties,/etc/vault/kfi.properties,/etc/vault/kafka.properties

Изменение Startup Probe согласно STD-7, все параметры обязательны

STARTUP_DELAY: 30 - новый параметр STARTUP_PERIOD: 10 - изменено значение параметра STARTUP_FAILURE: 5 - изменено значение параметра

Параметризация SA_AUTOMOUNT (КБ-OSE-79), все параметры обязательны

SA_AUTOMOUNT: false - выключаем автомонтирование секрета по требованию SA_SECRET_NAME: default-token-4g8c4 - имя секрета в кластере (если таких 2 с разными хешами - берем тот, что внутри - у него нет части с автогенерацией. Либо можно посмотреть какой привязан был к приложению в информации о pod.) SA_MOUNT_PATH: "/var/run/secrets/kubernetes.io/serviceaccount" - точка монтирования

OTT sidecar 4.2.15

Были изменены названия файла сертификата приложения ОТТ на "p36-cloud.p12" (ранее был error-processor-cloud.p12) Необходимо заменить файл, монтируемый в ott-sidecar ingress/egress. ConfigMaps также были приведены к соответствующей версии - параметры актуализированы выше (в разделе ОТТ)

Теперь принудительно разрываются все соединения ниже TLS 1.2 - параметризация отсутствует.

Для сборки docker контейнеров приложений необходимо использовать базовый образ с JDK 17.

7.8.0

Осуществлен переезд на fluent-bit sidecar v 5.0 с fluent-bit 1.8.8 для интеграции LOGA. Шифрование теперь осуществляется на Egress, поэтому inject секрета secman_kafka_loga_secret_path_default утратил силу.

Параметры maxSurge и maxUnavailable в pod компонентов, ingress и egress. PD36_K8S_MAX_SURGE: 25% PD36_K8S_MAX_UNAVAILABLE: 25% INGRESS_K8S_MAX_SURGE: 25% INGRESS_K8S_MAX_UNAVAILABLE: 25% EGRESS_K8S_MAX_SURGE: 25% EGRESS_K8S_MAX_UNAVAILABLE: 25% Опционально для интеграции с keycloak KEYCLOAK_K8S_MAX_SURGE: 25% KEYCLOAK_K8S_MAX_UNAVAILABLE: 25%

Параметризация количества реплик pod healthcheck, ingress и egress соответственно HEALTHCHECK_REPLICA_COUNT: 1 EGRESS_REPLICA_COUNT: 1 INGRESS_REPLICA_COUNT: 1

Были добавлены параметры классов приоритетов (встроенный механизм в k8s, позволяющий задавать приоритет pod в namespace). При значении false все остальные параметры опциональны. PRIORITY_CLASS: false При установке параметра в true необходимо также указать: APP_API_PRIORITYCLASSNAME AUTH_API_PRIORITYCLASSNAME DATAMART_API_PRIORITYCLASSNAME FRONTEND_PRIORITYCLASSNAME INNER_CONNECTOR_API_PRIORITYCLASSNAME HEALTHCHECK_PRIORITYCLASSNAME EGRESS_PRIORITYCLASSNAME INGRESS_PRIORITYCLASSNAME //только для интеграции с Rate Limiter RLS_PRIORITYCLASSNAME //только для интеграции с Keycloak KEYCLOAK_PRIORITYCLASSNAME Все параметры принимают на вход строку равную названию класса приоритета, предварительно созданного в k8s/openshift.

Рекомендуется устанавливать SA_AUTOMOUNT в значение false. Переменная CONFIG_MAP_DEFAULT_MODE утратила силу

7.9.0 Параметры KAFKA_KFI_IP1-6, KAFKA_KFI_HOST1-6, KAFKA_KFI_PORT утратили силу Для подключения kafka интеграций теперь используются следующие обязательные параметры: //Список хостов kafka, минимально нужен один – максимум не ограничен. INTEGRATION_KAFKA_SERVERS:

[
  {"id": "1","ip" : "x.x.x.x", "host_internal":"url.domain", "port_internal": "21093", "port": "9092"}
  ]

//Topic для чтения в строке через запятую INTEGRATION_KAFKA_R_TOPICS: "TOPIC_NAME_1,TOPIC_NAME_2" //Массив соответствия topic для записи тенантам INTEGRATION_KAFKA_RW_TENANT_TOPICS: [ {"topic": "RW_TOPIC_NAME_1", "tenants": "tenant1, tenant2"}, {"topic": "RW_TOPIC_NAME_2", "tenants": "tenant1, tenant3, tenant4"} ] Не обязательные стендозависимые параметры: //Количество хостов kafka, от которых ожидается подтверждение при записи (-1 означает все) INTEGRATION_KAFKA_WRITE_ACK: -1 //Количество попыток записи INTEGRATION_KAFKA_WRITE_RETRIES: 2

Параметры KAFKA_SERVER1-6 и KAFKA_PORT утратили силу

Для интеграции с OTT рекомендуется переход на использование PEM сертификатов в связи с требованиями безопасности. Для перехода нужно изменить значение параметра OTT_CERTSTORE_TYPE на 'PEM' и разместить в Secman следующие сертификаты/ключи (размещаются в том же секрете, где и сертификаты p12):

• клиентский сертификат (имя параметризовано как .crt) и закрытый ключ (.key)

• сертификат самого сервиса OTT (ott-service.crt)

• сертификат CA (цепочка, если необходимо), которым подписаны клиентский и сертификат сервиса (trustCa.crt)

Наличие параметра OTT_AUDIT_PROXY_URL является условием включения параметра AUDIT2_PROXY_URL OTT Sidecar (см. документацию ОТТ). !!Параметр строго стендозависимый.

Параметр OTT_CERTSTORE_NAME - утратил силу

Рекомендуется переход на зашифрованное по SSL соединение с БД. Для этого необходим клиентский сертификат и закрытый ключ, а также корневой сертификат УЦ, которому будут доверять БД и приложение. На стороне БД необходимо настроить принудительное двухстороннее шифрование с клиентом, рекомендуется режим verify-ca, и задать следующие параметры: Обязательный параметр, true включает шифрование, false отключает DB_SSL_ENABLED: true DB_SSL_SETTINGS: 'ssl=true&sslmode=verify-ca' DB_SSL_CERTS: 'sslrootcert=/mnt/secrets/db/root.crt&sslcert=/mnt/secrets/db/app.crt&sslkey=/mnt/secrets/db/app.key' Сертификаты и ключ необходимо примонтировать к pod приложения по путям, указанным в параметре DB_SSL_CERTS

7.10.0

Новые обязательные параметры, отвечающие за выбор платформы развертывания: DEPLOY_TO_KUBERNETES: true/false (true – для развертывания в k8s/DropApp, false для OpenShift) ISTIO_SYNAPSE: true/false (true – при использовании istio synapse service mesh, false – redhat service mesh) ANCIENT_CLUSTER: false (устанавливать в true только в случае если используется старый кластер (k8s < 1.21). Отвечает за apiVersion kind'ов deployment.

Для OTT-Sidecar рекомендуется переход на версию 4.3.1. Версии обратно-совместимы, изменение конфигурации не требуется, достаточно заменить образ. Для параметра OTT_CERTSTORE_TYPE доступно новое значение – PKI Это значение включает интеграцию с PKI движком SecMan вместо KV для OTT sidecar, поддерживается ротация hot reload. CLUSTER_DOMAIN – обязательный параметр при интеграции с PKI. Сюда вносится домен (который применяется в маршрутах) кластера. Пример: 'apps.dev.domain.com'

Для интеграций с Kafka (Integration и APLJ) шифрование было перенесено на egress. Настройки аналогичны интеграции LOGA. KAFKA_PJ_ISTIO_MTLS: true/false – флаг, отвечающий за включение шифрования на egress для APLJ KAFKA_INTEGRATION_ISTIO_MTLS: true/false – флаг, отвечающий за включение шифрования на egress для Kafka Integration

kafka_pj_servers:

[
                    {"id": "1","ip" : "x.x.x.x", "host_internal":"url.domain", "port_internal": "23093", "port": "9092"}
]

Для INTEGRATION_KAFKA_SERVERS изменились названия полей массива (см. выше)

Добавлен раздел MDM-API

Для deploy в k8s/dropapp для kind: Ingress была добавлена параметризация аннотаций (для выбора балансировщика). Пример для haproxy: INGRESS_ANNOTATIONS: ["kubernetes.io/ingress.class: haproxy", "haproxy-ingress.github.io/ssl-passthrough: 'true'"] INGRESS_ANNOTATIONS_DATAMART: ["kubernetes.io/ingress.class: haproxy", "haproxy-ingress.github.io/ssl-passthrough: 'true'", "haproxy-ingress.github.io/balance-algorithm: roundrobin", "haproxy-ingress.github.io/timeout-server: 10s"]

Компонент в принудительном порядке требует 2 пары сертификат/ключ для Ingress/Egress (по одной для каждого, согласно требованиям безопасности рекомендуем использовать разные пары) (2 разных секрета в SecMan).

Для kafka интеграция была добавлена настройка для внесения topic для обратной отправки квитанций о доставке сообщения. Формат аналогичен INTEGRATION_KAFKA_RW_TENANT_TOPICS. INTEGRATION_KAFKA_RECEIPT_TENANT_TOPICS:

{"topic": "RECEIPT_TOPIC", "tenants": "Tenant1"}

Для реализации Secman Hot Reload добавлены следующие переменные: SECRET_HOT_RELOAD: true – включение поддержки ротации секретов; SECRET_APPLY_TIME: '30' – время применения секретов; SECRET_INITIAL_DELAY: '5' – задержка обновления секретов; SECRET_RETRY_COUNT: '3' – количество попыток чтения обновленных секретов; Параметры путей до секретов стали обязательными к внесению в env. secman_ingressgateway_certs_path: '' secman_egressgateway_certs_path: '' secman_ott_certs_path: '' secman_kfi_kafka_secret_path: '' secman_kafka_secret_path: '' secman_kafka_loga_secret_path: '' secman_spas_secret_key_path: '' secman_keycloak_cli_password_path: '' secman_db_secret_path: '' secman_ceph_secret_path: ''

Для маршрута OTT Datamart добавлен новый параметр (хост): DATAMART_OTT_HOST (должен отличаться от DATAMART_MTLS_HOST)

7.11.0

Для Risk Rating S3 интеграции появились 2 новых параметра: rr_s3_bucket_read_prefix – путь до Bitbucket S3 rr_s3_bucket_name – имя Bitbucket S3

Настройки валидации Kafka import. 2 необязательных параметра (true по умолчанию) characteristic_type_value_validation – Включение валидации (true/false) characteristic_substring_value_to_max_size - (true/false). Если включен, при получении textArea длиной > 4000 символов или text > 255 - содержимое будет обрезано до этих значений. Если выключен – произойдет ошибка валидации (если она включена).

LOGA_EGRESS_DISCRETE_CERT: (true/false) – обязательный параметр. Отвечает за то, нужно ли монтировать дополнительный отдельный сертификат для интеграции с LOGA (через mTLS на Egress). В случае с false используется обычный сертификат Egress. При установке значения в true – в Egress будут смонтированы из Secman секреты (loga-tls.crt, loga-tls.key, loga-ca.pem). Их наличие ожидается в том же разделе где и сертификатов Egress - secman_egressgateway_certs_path

Для установки количества pod в Deployment теперь используются следующие параметры: EGRESS_REPLICA_COUNT: 1 – Istio Egress INGRESS_REPLICA_COUNT: 1 – Istio Ingress APP_REPLICA_COUNT: 1 – App API AUTH_REPLICA_COUNT: 1 – Auth API DATAMART_REPLICA_COUNT: 1 – Datamart API FRONTEND_REPLICA_COUNT: 1 – Frontend (статика) ICON_REPLICA_COUNT: 1 – Inner-Connector API MDM_REPLICA_COUNT: 1 – MDM API HEALTHCHECK_REPLICA_COUNT: 1 – Geo Healtcheck KEYCLOAK_REPLICA_COUNT: 1 – Keycloak (сервер авторизации)

PCT_REPLICA_COUNT – утратил силу

KEYCLOAK_HTTPS – отвечает за протокол подключения по Route Keycloak. Если true – HTTPs, false – HTTP. Переменная обязательна, но только при установке keycloak.

8.1.0

KEYCLOAK_BASE_URL – не обязательная переменная для интеграции с внешней инсталляцией Keycloak (когда нет контроля над настройками). Default – /auth

AUTH_PROXY_EXIT_URL – не обязательная переменная. URL для редиректа при разлогинивании. Default – /pkmslogout AUTH_PROXY_EXIT_AJAX – не обязательная переменная. Включает использование Ajax при запросе на деавторизацию. Default – false

compress_kryo – не обязательная переменная. Отвечает за включение framework kryo для сериализации в datamart (настройки кеширования hazelcast). Default – true

Для переменных INTEGRATION_KAFKA_RW_TENANT_TOPICS и INTEGRATION_KAFKA_RECEIPT_TENANT_TOPICS вместо имени тенанта можно указать * что будет означать, что topic доступен во всех тенантах.

Для интеграций с AUDIT, S3, SOWA и SPAS были добавлены необязательные переменные (имеют дефолтные значения) для кастомизации таймаутов соединения: AUDIT_TIMEOUT: 5 (Общий таймаут на все попытки подключения в секундах) AUDIT_RETRY_ATTEMPTS: 2 (Количество повторных попыток подключения) AUDIT_RETRY_TIMEOUT: 1 (Таймаут одной попытки подключения в секундах) Для остальных сервисов описание параметров идентично CEPH_TIMEOUT: 5 CEPH_RETRY_ATTEMPTS: 2 CEPH_RETRY_TIMEOUT: 1 SOWA_TIMEOUT: 45 SOWA_RETRY_ATTEMPTS: 2 SOWA_RETRY_TIMEOUT: 15 SPAS_TIMEOUT: 5 SPAS_RETRY_ATTEMPTS: 2 SPAS_RETRY_TIMEOUT: 1

Обязательная переменная INTERNAL_MTLS_MODE - отвечает за включение mTLS внутри namespace (с помощью kind: PeerAuthentication). Принимает значения DISABLE (выключено), PERMISSIVE (разрешены подключения как с mTLS так и без), STRICT (принудительное использование mTLS). В рамках данного релиза не рекомендуется включение STRICT режима.

Появилась возможность настроить лимиты (k8s resources) для ott-sidecar (не обязательные параметры). EG - Egress, IG - Ingress. OTT_EG_CPU_LIMIT/OTT_IG_CPU_LIMIT - CPU limit OTT_EG_MEMORY_LIMIT/OTT_IG_MEMORY_LIMIT - Memory limit OTT_EG_CPU_REQUEST/OTT_IG_CPU_REQUEST - CPU requests OTT_EG_MEMORY_REQUEST/OTT_IG_MEMORY_REQUEST - Memory requests

Изменились пути монтирования секретов. Необходимо проверить все существующие environment файлы на следующие значения и при необходимости изменить: /etc/istio/egressgateway-certs -> /mnt/istio/egressgateway-certs /etc/istio/ingressgateway-certs -> /mnt/istio/ingressgateway-certs /etc/vault -> /mnt/secrets/properties Также, для информации, изменились и эти пути (не требует изменения в env файле) /etc/istio/kafka-integration -> /mnt/istio/kafka-integration /opt/kafka/certs -> /mnt/secrets/kafka-aj/certs /opt/kafka-kfi/certs -> /mnt/secrets/kafka-kfi/certs

Для получения доступа к api datamart у потребителя должен пройти проверку сертификат или сертификат и subsystemcode. Если потребитель передал только свой сертификат, то его необходимо добавить в блок or_ids. Если потребитель передал сертификат и subsystemcode, то сертификат необходимо внести в список certificates в and_ids, а subsystemcode в exact_code или regex_code.

Pipeline для deploy проекта компонента Product360 (PD36) продукта Platform V Product360 (Р36) в среду контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально)#

Запуск осуществляется в Jenkins Job типа pipelne, definition у которого выставлен как Jenkinsfile из данного репозитория. Данный Pipeline можно сразу настроить на все стенды среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально), для достижения универсальности созданных template. Для каждого стенда создается свой enviroment файл расположенный по пути config/stand_name, где вместо stand_name создается директория для нового стенда, в которую подкладывается индивидуальные настройки для стенда.(Пример выше)

В репозитории необходимо создать структуру каталогов (\config\<project_name>\<stand_name>\.env). В одном репозитории допускается хранение нескольких наборов конфигураций для разных проектов и разных стендов.

В файле all.env описываются параметры приложения, общие для обоих стендов. В файле .env описываются параметры приложения, уникальные для текущего стенда. Для удобства рекомендуется называть файл по имени стенда например: dev-gen.env или dev-gen2.env.

Секреты стендов#

Каждый стенд может иметь уникальный список секретов, например пароли в БД. Внутри git секреты сохранены в виде зашифрованных с помощью ansible-vault файлов.

Зашифровать созданный ранее секрет можно командой

Зашифровать файл командой

ansible-vault encrypt file

Расшифровать файл командой

ansible-vault decrypt file

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

Для того, чтобы зашифровать секреты создан отдельный pipe, который на входе принимает четыре параметра:

• gitSshUrl — репозиторий, в котором временно находятся секреты, которые необходимо шифровать;

• gitBranch — ветка репозитория, в которой лежать секреты;

• folder — папка, в которой сложены секреты;

• workMode — режим работы скрипта, encrypt — шифруем, decrypt — расшифровываем.

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

Jenkinsfile#

В Jenkinsfile находится сам скрипт, в котором объявлен так же ряд переменных:

• standsApi — адрес api стендов среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) (массив, пример):

  standsApi = [ 
        'stand1' : 'insecure://api.openshift.example.com:8080',
        'stand2': 'insecure://api.openshift.stand2.ru:8081'
        ]   
  

• projectNames — соответствие короткого имени в choice(на странице запуска) и имени проекта в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) (массив, пример):

  projectNames = [
        'stand1' : 'Example_project-dev',
        'stand2': 'Example_project-test',
        'stand3' : 'Example_project-master'
 ]

• projectSecrets — уникальные токены для работы Jenkins в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально), токены задаются в виде jenkins credential с типом secret text:

  projectSecrets = [
        'stand1' : 'OS_token_dev',
        'stand2': 'OS_token_master',
        'stand3' : 'OS_token_test'
  ]
  

Завести эти токены можно следующим образом.

Как получить секрет среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально)

Для стендов разработки:
       Получите токен:
            1) Зайдите в UI OpenShift, выбрать Administrator > Workloads > Secrets.
            2) Отфильтруйте по "jenkins" и выбрать секрет "jenkins-token".
            3) В первой вкладке Overview найдите поле token и скопировать его в буфер обмена, нажатием Control + C.
            4) Создайте пользователя в своем аккаунте Jenkins. В Jenkins в правом верхнем углу нажмите на свой логин, далее выберите credentials > global > добавить учетные данные. При этом:
                 Kind = secret text;
                 Secret = скопированный токен;
                 ID — имя проекта;
                 Description — заполнить так, чтобы было понятно, для чего этот аккаунт.
 
 

Credentials для deploy в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) создаются через специальный job в Jenkins.

• secretRepo — репозиторий в котором лежат template, файлы параметров и секреты

  secretAndParametersRepo = 'ssh://git@example.com:8080/project/repo.git'
  

• secretAndParametersRepoBranch — ветка из указанного выше репозитория, из которой нужно взять template и параметры(для каждого стенда может быть разная):

  secretAndParametersRepoBranch = [
        'stand1' : 'pipe-develop',
        'stand2': 'develop',
        'stand3' : 'pipe-develop'
]

• secretAndParametersRepoCredentials — id credentials для работы с git (credential так же заведена в jenkins и тут нужно указать только ее id):

  secretAndParametersRepoCredentials = "git"
  

• templatesConfigurationPath — путь в репозиторий до enviroment файла

  templatesConfigurationPath = [
        'kb': [
                'stand1' : 'config/dev.env',
                'stand2' : 'config/master.env',
                'stand3' : 'config/test.env'
        ]
  

• secretConfigurationPath — путь до файлов с секретами:

  secretConfigurationPath = [
        'stand1' : 'secrets/dev',
        'stand2': 'secret/master',
        'stand3' : 'secret/test'
]

• Секреты с Api-ключ для доступа к k8s/openshift (опционально)

def projectSecrets = [
        'dev-gen' : 'OS_token_dev-gen',
        'dev-gen2': 'OS_token_dev-gen2',
        'nt-gen': 'OS_token_nt-gen',
        'k8s': 'K8STokenCred',
]

• Сертификат для доступа к k8s/openshift (опционально)

def projectCertSecrets = [
'dev-gen' : 'CaCertOpenshift',
'dev-gen2': 'CaCertOpenshift',
'k8s': 'CaCertK8S',
]

• storyPass — Ansible-vault пароль для расшифровки секретов, перед их развертыванием в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально):

  storyPass = "AnsibleVaultPassword"
  

Сборка артефакта компонента через Jenkins#

Внешний вид job

Параметры

1. URL с предварительно загруженным дистрибутивом.

2. URL nexus куда будет загружаться склеенный дистрибутив (этот параметр нужно указать в Job deploy nexusUrl).

3. URL nexus куда будет загружаться image (этот параметр потом нужно прописать в env deploy REGISTRY_URL ).

Deploy компонента через Jenkins#

В Jenkins job присутствует параметр SecMan.

Требуется создать секрет в АС SecMan с наименованием "credCertPath". Его содержание берется из секрета ca.crt сервис аккаунта типа deployer проектной области openshift. На jenkins node должен быть установлен python 2.7 и python библиотека openshift.

Для того, чтобы Jenkins job брала секректы из SecMan, проставьте чек-бокс напротив этого параметра. Если секреты для контейнеров расположены в SecMan, то нужно, чтобы было выполнено условие:

SecMan_injector:true

Также, заполнены параметры в evn файлах для Job deploy:

• vault_path — путь к хранилищу в SecMan (пример: CI03064796_CI03419752/A/IFT/OSH/PD36/KV);

• vault_tenant — наименование тенанта в SecMan (пример: CI03064796_CI03419752);

• vault_id — наименование роли пользователя SecMan (пример: ci00611947-idevgen-product360-ift1).

Внешний вид job

nexusUrl — параметр указывает nexus url где лежит склеенный артефакт deploy;

standType — параметр указывает стенд, на который будет производиться установка;

releaseVersion — версия релиза, которая будет устанавливаться;

Migrations — необходимость обновления БД;

MigrationsOnly — установка только миграций, без установки среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) темплейтов;

DropSchemas — удаление данных и миграций из БД (dev only);

secretsApply — установка/обновление секретов на стенде;

Keycloak — установка Keycloak как системы авторизации (dev и NT);

debug — DEBUG режим для работы системы;

delete — удаление всех сущностей из среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально);

tags — теги deploy (есть значения по умолчанию для полной установки);

tags — для упрощенного запуска app-api,auth-api,frontend, datamart-api,keycloak,inner-connector-api,mdm-api,simple_ingress

Для отката миграций необходимо в параметрах job поставить галочку dbRollback и указать в поле migrationsTag - "release-<номер релиза>, чьи миграции требуется отменить.

Использование программного компонента Synapse Rate Limiter – сервис ограничения (квотирования) входящих запросов (SRLS) продукта Platform V Synapse Enterprise Integration#

Программный компонент SRLS необходим для ограничения прикладной нагрузки (payload) со стороны потребителя на защищаемые сервисы, исполняемые в рамках Synapse Service Mesh.

Потребитель может превысить допустимый поток запросов по причине программно-аппаратного сбоя. Для предотвращения подобных сбойных ситуаций на стороне компонента реализована защита от превышения допустимой нагрузки в виде ограничения максимального потока запросов (rate limit).

Компонент SRLS выполняет расчет лимитов, принимает gRPC запросы от Ingress Gateway в прикладных namespace, содержащие информацию о домене (в качестве домена используется название namespace), о вызываемом сервисе и данные из заголовка synapse-consumerid. Такие gRPC-вызовы формируются на каждый вызов целевого сервиса в прикладном namespace.

Для установки rate limiter необходимо выдать роль администратора для service account "default".

Более детально ознакомиться с компонентом, а также его установкой можно в Руководстве по установке компонента Synapse Rate Limiter – сервис ограничения (квотирования) входящих запросов (SRLS) продукта Platform V Synapse Enterprise Integration.

Deploy в среду контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально)#

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

1. Запустите job с параметром action = applySecrets для загрузки секретов. Расшифровка секретов произойдет с созданным заранее JenkinsCredential с именем, переданным в storyPass.

2. Для deploy миграций запустите Job с action = Migrations.

3. Если не установлен параметр MigrationsOnly, то основной набор приложений будет обновлен в любом случае.

Настройка интеграции#

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

Интеграции компонента PD36 с внешними системами#

Для интеграции с системным программным обеспечением дополнительные настройки на стороне компонента PD36 не требуются.

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

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

Для интеграции с компонентом LOGA корректно заполните enviroment файл стенда (смотри документацию продукта Компонент Журналирование (LOGA) продукта Platform V Monitor (OPM)), за настройки подключения к компоненту PD36 отвечают параметры, указанные в разделе Конфигурация данного руководства. LOGA_xxxx: true/false - значение false включает интеграцию

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

Для того, чтобы выполнить подключение к AUDT:

1. Выполните согласование со специалистами по кибербезопасности состав данных, отправляемых в Аудит, для этого:

• определите точки аудирования (места отправки событий в Аудит);

• состав отправляемых событий в каждой из точек.

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

• среднее количество сообщений в сутки;

• редкий размер события;

• название и КЭ вашего модуля/сервиса/АС.

3. После определения характеристик потока согласуйте свою квоту по хранимым данным.

4. При развертывании на стендах промышленной эксплуатации создайте сертификат (создание сертификатов описано в документе Руководство по установке компонента Product360 (PD36) продукта Platform V Product360 (Р36)) и сформируйте хранилища ключей.

Компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM)#

Параметр SUDIR_CERT_CN: '.*CN=' отвечает за проверку сертификата при интеграции с AUTH.

Компонент KCSE KeyCloak.SE продукта Platform V IAM SE (IAM)#

Интеграция выполняется на стороне платформенного продукта. Дополнительные настройки со стороны компонента PD36 не требуются.

Компонент OTTS#

Выпустите сертификаты и создайте секреты. С созданием сертификатов можно ознакомиться в документации компонента OTTS One-Time Password (OTP) / OTT (OTTS).

СУБД#

Для того, чтобы подготовить базу данных:

• В СУБД проверьте наличие ролей as_admin, as_TUZ. При разворачивании в СУБД PSQL роли входят в поставку. При использовании СУБД PostgreSQL, предварительно создать роли (смотри скрипт создания ролей).

-- скрипт проверки на наличие ролей
SELECT rolname FROM pg_roles WHERE rolname in ('as_TUZ', 'as_admin');

-- скрипт создания ролей
CREATE ROLE as_admin;
CREATE ROLE "as_TUZ";

• Создайте пользователя владельца, от имени которого выполняется накат скриптов по разворачиванию БД:

-- создание пользователя 360
CREATE USER 360 WITH
    PASSWORD '***************'
    LOGIN
    NOCREATEDB
    NOCREATEROLE
    NOSUPERUSER
    NOINHERIT
    NOREPLICATION
    NOBYPASSRLS;

-- Устанавливаем порядок поиска схем для пользователя
ALTER ROLE 360 SET search_path = "$user";
GRANT as_admin TO 360;
ALTER ROLE rspit SET role TO 'as_admin';

• Создайте табличные пространства:

-- на сервере создать папки дл пространств
mkdir /mnt/360_i
mkdir /mnt/360_t

--в СУБД выполнять пользователем с правами db_admin (psql)
CREATE TABLESPACE 360_t
OWNER as_admin
LOCATION '/pgdata/11/';

CREATE TABLESPACE 360_i
OWNER as_admin
LOCATION '/pgdata/11/';

GRANT CREATE ON TABLESPACE 360_t TO as_admin;
GRANT CREATE ON TABLESPACE 360_i TO as_admin;

GRANT CREATE ON TABLESPACE 360_t TO "as_TUZ";
GRANT CREATE ON TABLESPACE 360_i TO "as_TUZ";

• Создайте БД:

--выполнять пользователем с правами db_admin (360)
CREATE DATABASE 360 
WITH
OWNER = db_admin
ENCODING = 'UTF8'
LC_COLLATE = 'en_US.UTF-8'
LC_CTYPE = 'en_US.UTF-8'
TABLESPACE = 360_t
CONNECTION LIMIT = -1;

GRANT CREATE ON DATABASE 360 TO as_admin;

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

-- Схема для владельца схемы приложения
CREATE SCHEMA 360 AUTHORIZATION as_admin;
GRANT ALL ON SCHEMA 360 TO as_admin;
GRANT USAGE ON SCHEMA 360 TO "as_TUZ";

• Предоставьте дефолтовые привилегии на схему для ролей as_admin, as_TUZ:

GRANT USAGE ON SCHEMA 360 TO "as_TUZ";
GRANT SELECT, UPDATE, INSERT, DELETE ON ALL TABLES IN SCHEMA 360 TO "as_TUZ";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA 360 TO "as_TUZ";
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA 360 TO "as_TUZ";
GRANT EXECUTE ON ALL ROUTINES IN SCHEMA 360 TO "as_TUZ";
GRANT EXECUTE ON ALL PROCEDURES IN SCHEMA 360 TO "as_TUZ";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO "as_TUZ";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON SEQUENCES TO"as_TUZ";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT EXECUTE ON FUNCTIONS TO"as_TUZ";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT EXECUTE ON ROUTINES TO"as_TUZ";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT USAGE ON TYPES TO "as_TUZ";
  
GRANT ALL PRIVILEGES ON SCHEMA 360 TO "as_admin";
GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA 360 TO "as_admin";
GRANT ALL PRIVILEGES ON ALL SEQUENCES IN SCHEMA 360 TO "as_admin";
GRANT ALL PRIVILEGES ON ALL FUNCTIONS IN SCHEMA 360 TO "as_admin";
GRANT ALL PRIVILEGES ON ALL ROUTINES IN SCHEMA 360 TO "as_admin";
GRANT ALL PRIVILEGES ON ALL PROCEDURES IN SCHEMA 360 TO "as_admin";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON TABLES TO"as_admin";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON SEQUENCES TO"as_admin";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON FUNCTIONS TO"as_admin";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON ROUTINES TO"as_admin";
ALTER DEFAULT PRIVILEGES FOR ROLE as_admin IN SCHEMA 360 GRANT ALL PRIVILEGES ON TYPES TO"as_admin";

• Создайте пользователя системы datamart_appl:

--Выполнять пользователем с правами dba
CREATE USER datamart_appl WITH
    PASSWORD '***************'
    LOGIN
    NOCREATEDB
    NOCREATEROLE
    NOSUPERUSER
    NOINHERIT
    NOREPLICATION
    NOBYPASSRLS;
    
ALTER ROLE datamart_appl SET search_path = 360;
ALTER ROLE datamart_appl SET role TO "as_TUZ";
GRANT "as_TUZ" TO datamart_appl;

Для работы приложения с БД требуется создать 4 схемы app, auth, datamart, icon и 4 пользователя системы app, auth, datamart, icon. Search path пользователя настроен на одноименную схему.

Компонент Объединенный мониторинг Unimon (MONA) продукта Platform V Monitor (ОРМ)#

Для интеграции с компонентом Объединенный мониторинг Unimon (MONA) никаких специальных действий производить не нужно. С детальным описанием можно ознакомиться в документации продукта Platform V Monitor (ОРМ).

Компонент Граничный прокси (IGEG) продукта Platform V Synapse Service Mesh (SSM)#

Для интеграции с IGEG никаких специальных действий производить не нужно. С детальным описанием можно ознакомиться в документации Компонент Граничный прокси (IGEG) продукта Platform V Synapse Service Mesh (SSM).

Пользователи под ролью Системный Администратор (SYSTEM_ADMIN в пользовательском интерфейсе компонента не осуществляют настройку каких-либо параметров, влияющих на функционирование сервиса в целом, а также параметров безопасности.

Описание параметров подключения для функционирования с компонентом Аудит продукта Platform V Audit SE

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

1. Выполните согласование со специалистами по кибербезопасности состав данных, отправляемых в Аудит, для этого:

• определите точки аудирования (места отправки событий в Аудит);

• состав отправляемых событий в каждой из точек.

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

• среднее количество сообщений в сутки;

• средний размер события;

• название и КЭ вашего модуля/сервиса/АС.

3. После определения характеристик потока согласуйте свою квоту по хранимым данным.

4. При развертывании на стендах промышленной эксплуатации создайте сертификат (создание сертификатов описано в документе Руководство по установке) и сформируйте хранилища ключей.

Параметры подключения для функционирования с СУБД

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

GATEWAY

- apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
name: gw-pct360-database
labels:
app: database
product: product360
type: istio-edge
spec:
selector:
app: ${PCT_NAMESPACE}-egress //наименование пространства проекта
servers:
- hosts:
- ${DATABASE_SRV_MASTER}//хост основной базы данных
port:
name: tcp-15432
number: 15432
protocol: TCP

VirtualServcie

- apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
    name: vs-pct360-database
    labels:
      app: database
      product: product360
      type: istio-edge
  spec:
    exportTo:
      - .
    gateways:
      - gw-pct360-database
      - mesh
    hosts:
      - ${DATABASE_SRV_MASTER} //хост основной базы данных
    tcp:
      - match:
          - gateways:
              - mesh
            port: "${{INTERNAL_DATABASE_PORT_MASTER}}" //порт подключения pgbouncer к основной базе данных
        route:
          - destination:
              host: svc-pct360-egress
              port:
                number: 15432
            weight: 100
      - match:
          - gateways:
              - gw-pct360-database
            port: 15432
        route:
          - destination:
              host: ${DATABASE_SRV_MASTER} //хост основной базы данных
              port:
                number: "${{DATABASE_PORT_MASTER}}" //порт подключения к основной базе данных
            weight: 100

ServiceEntry

- apiVersion: networking.istio.io/v1beta1
  kind: ServiceEntry
  metadata:
    name: se-pct360-database
    product: ${PRODUCT_LABEL}//вставить 'product360'
  spec:
    exportTo:
      - .
    addresses:
      - ${DATABASE_PORT_MASTER} //порт подключения к основной базе данных
    endpoints:
      - address: ${DATABASE_SRV_SLAVE_IP_STDIN}//ip адрес standin базы данных
    hosts:
      - ${DATABASE_SRV_SLAVE_STDIN} //хост standin базы данных
    location: MESH_EXTERNAL
    ports:
      - name: mongodb
        number: "${{DATABASE_PORT_MASTER}}" //порт подключения к основной базе данных
        protocol: TCP
      - name: internal
        number: "${{INTERNAL_DATABASE_PORT_SLAVE_STDIN}}" //порт подключения pgbouncer к standin базе данных
        protocol: TCP
    resolution: STATIC

Параметры подключения для функционирования с Компонентом Журналирование продукта Platform V Monitor

GATEWAY

- apiVersion: networking.istio.io/v1beta1
  kind: Gateway
  metadata:
    name: gw-pct360-logger
    labels:
      app: logger
  spec:
    explore:
      - .
    exportTo:
      - .
    selector:
      app: ${PCT_NAMESPACE}-egress //наименование пространства проекта
    servers:
      - hosts:
          - ${LOGGER_GW}} //хост АС Журналирование
        port:
          name: http-8445
          number: 8445
          protocol: HTTP

ServiceEntry

- apiVersion: networking.istio.io/v1beta1
 kind: ServiceEntry
 metadata:
   name: se-pct360-logging
   labels:
     app: logger
 spec:
   exportTo:
     - .
   hosts:
     - ${LOGGER_ENDP_2} //хост АС Журналирование
     - ${LOGGER_ENDP} //хост АС Журналирование
   location: MESH_EXTERNAL
   ports:
     - name: http-80
       number: 80
       protocol: HTTP
     - name: https-${LOGGER_PORT} //наименование порта подключения к АС Журналирование
       number: "${{LOGGER_PORT}}" //номер порта подключения к АС Журналирование
       protocol: TLS
   resolution: DNS

VirtualServcie

- apiVersion: networking.istio.io/v1beta1
  kind: VirtualService
  metadata:
    name: vs-pct360-logger
    labels:
      app: logger
  spec:
    exportTo:
      - .
    gateways:
      - gw-pct360-logger
      - mesh
    hosts:
      - ${LOGGER_GW}
    http:
      - match:
          - gateways:
              - mesh
            port: 80
        rewrite:
          authority: ${LOGGER_GW}//хост АС Журналирование
        route:
          - destination:
              host: svc-pct360-egress
              port:
                number: 8445
            weight: 100
        retries:
          attempts: 2
          perTryTimeout: 1s
          retryOn: gateway-error,connect-failure,refused-stream
      - match:
          - gateways:
              - gw-pct360-logger
            port: 8445
        route:
          - destination:
              host: ${LOGGER_ENDP}//хост АС Журналирование
              port:
                number: 443
            weight: 50
          - destination:
              host: ${LOGGER_ENDP_2}//хост АС Журналирование
              port:
                number: 443
            weight: 50
        retries:
          attempts: 2
          perTryTimeout: 1s
          retryOn: gateway-error,connect-failure,refused-stream

ConfigMap

- apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap-pct360-ott-ingress-logback
  labels:
    app: pct360-ingress
    product: product360
    type: istio-edge
data:
  logback.xml: |-
    <?xml version="1.0" encoding="UTF-8"?>
    <configuration scan="true" scanPeriod="60 seconds">
        <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
            <encoder>
                <pattern>%X{ott.req.id} %d{HH:mm:ss.SSS} [%-5level] [%logger{36}] [%thread] - %msg%n</pattern>
            </encoder>
            </appender>
                <appender name="FILE" class="ch.qos.logback.core.FileAppender">
                <file>/tmp/OttTest.log</file>
                <append>false</append>
                <encoder>
                    <pattern>%X{ott.req.id} %d{HH:mm:ss.SSS} [%-5level] [%logger{36}] [%thread] - %msg%n</pattern>\r\n
                </encoder>
            </appender>
            <root level="info">
                <appender-ref ref="STDOUT"/>
                <appender-ref ref="FILE"/>
            </root>\r\n
            <logger name="com.ХХХ.ott" level="TRACE"/>
            <logger name="com.ХХХ.ott.api.rest" level="error"/>
            <logger name="com.ХХХ.core" level="error"/>
            <logger name="com.fasterxml" level="error"/>
    </configuration>

EnvoyFilter

 - apiVersion: networking.istio.io/v1alpha3
kind: EnvoyFilter
metadata:
  name: pct360-egress
spec:
  configPatches:
    - applyTo: HTTP_FILTER
      match:
        context: GATEWAY
        listener:
          filterChain:
            filter:
              name: envoy.http_connection_manager
          portNumber: 8445
      patch:
        operation: INSERT_BEFORE
        value:
          config:
            authorization_headers:
              - ott-token
              - ott-hash
            failure_mode_allow: false
            grpc_service:
              google_grpc:
                stat_prefix: ext_authz
                target_uri: 'unix:/mnt/ott-uds-socket/ott.socket'
              timeout: 2s
            with_request_body:
              allow_partial_message: false
              max_request_bytes: 8192000
          name: envoy.ext_authz
  exportTo:
    - .
  workloadSelector:
    labels:
      istio: ${PCT_NAMESPACE}-egress //наименование пространства проекта

Компонент Abyss (LGDB) продукта Platform V Monitor (OPM)#

Настройки и параметры для интеграции с компонентом Abyss (LGDB) в составе дистрибутива компонента PD36 отсутствуют.

Компонент Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT)#

Интеграция выполняется в соответствии с документацией компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT). Необходимые к заполнению параметры (environment-переменные) и их значения указаны в разделе Конфигурация данного руководства.

Компонент Build tools (CIJE) продукта Platform V DevOps Tools (DOT)#

Интеграция выполняется на стороне платформенного продукта. Дополнительные настройки со стороны компонента PD36 не требуются.

Компонент Synapse Rate Limiter (SRLS) продукта Platform V Synapse Enterprise Integration#

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

Компонент Kafka Gateway (KFGT) продукта Platform V Synapse Enterprise Integration (SEI)#

Интеграция выполняется на стороне платформенного продукта. Дополнительные настройки со стороны компонента PD36 не требуются.

Компонент Сервис передачи событий (EVTD) продукта Platform V Synapse Event Transfer Service (EVD)#

Интеграция проведена на уровне приложения (inner-connector-api), которое через клиентскую библиотеку пишет и читает из Kafka. Параметры представлены в разделе Конфигурация данного руководства.

Компонент Объединённый сервис авторизации (ОСА) (AUTZ) продукта Platform V Backend (#BD)#

Для настройки интеграции достаточно указать параметры SPAS_HOST: 'url.ru' SPAS_PORT: 8443 SPAS_PROTO: "HTTPS" SPAS_URL: 'http://url.ru/spas/rest'

Компонент K8S Core (K8SC) продукта Platform V DropApp (K8S)#

Дистрибутив поддерживает развертывание в среде Kubernetes и DropApp. Для выбора этих вариантов вместо Openshift используется переменная: DEPLOY_TO_KUBERNETES.

Компонент Базовая ОС (CORE) продукта Platform V SberLinux OS Core (SLC)#

Дистрибутив поддерживает использование SberLinux в качестве базового образа для сборки контейнеров приложений. Базовый образ указывается в параметрах запуска job Merge (склейки) дистрибутива. Дополнительные настройки со стороны компонента PD36 не требуются.

Запуск Job deploy#

После заполнения всех параметров перейдите в Jenkins, где слева в меню выберите Собрать с параметрами:

• standType — выберите один из указанных ранее стендов, с которым необходимо работать;

• secretsApply — параметр, позволяющий залить секреты на стенд при необходимости;

• Migrations — параметр, установки миграций, при необходимости.

Обновление#

Обновление компонента осуществляется стандартным образом аналогично установке с актуализацией env файлов, в случае необходимости, а так же изменением версии релиза в параметрах Job deploy. Установку новой версии компонента необходимо осуществить согласно описанным шагам в пункте Установка текущего документа. Дополнительных настроек не требуется. Удаление предыдущей версии перед установкой обновления не требуется. Перед обновлением рекомендуется сделать backup БД.

Удаление#

Удаление дополнительных средств защиты информации осуществляется в соответствии с документацией к ним. Для удаления компонента необходимо удалить в K8S Core (K8SC) или Red Hat OpenShift 4+ (опционально) следующие объекты:

• ConfigMap;

• Deployment;

• DeploymentConfig;

• DestinationRule;

• Service;

• Route.

Таким образом, происходит удаление собранного пространства в платформе приложений-контейнеров. Происходит удаление и всех созданных ранее дашбордов и организаций.

Для удаления ресурса необходимо подключиться к компоненту K8S Core (K8SC) или Red Hat OpenShift 4+ (опционально) через терминал и выполнить команду:

kubectl -n <имя namespace> delete <тип компонента Kubernetes (или Openshift)> <имя компонента Kubernetes (или Openshift)>

Для подключения рекомендуется использовать Kubectl версии, соответствующей версии Kubernetes. Kubectl является составной частью Kubernetes, устанавливается на рабочей станции.

Отдельное удаление БД, сертификатов не требуется.

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

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

http://host/component-name/actuator/health. где:

• host — адрес сервера;

• component-name — имя компонента.

http://host/auth-api/actuator/health http://host/app-api/actuator/health http://host/inner-connector/actuator/health

В том числе для проверки работоспособности web-интерфейса компонента:

1. Успешно войти в АРМ компонента под пользователем, которому назначена определенная роль.

2. Перейти по всем разделам сайдбара компонента и убедиться, что при переходе отсутствуют ошибки.

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

4. наличие успешного события репликации журналов в компоненте Прикладной журнал (APLJ) продукта Platform V Backend (#BD).

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

Чек-лист проверки работоспособности интеграций#

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

• интеграция с HashiCorp Vault;

• интеграция с Platform V Audit SE;

• интеграция с Platform V Monitor.

Проверка работоспособности интеграции с HashiCorp Vault/Secret Management System

С целью проверки интеграции с HashiCorp Vault/Secret Management System для каждого pod, в котором запущен контейнер Vault-agent, необходимо удостовериться, что в логах этого контейнера были получены необходимые сертификаты. Пример логов, с получением сертификатов из Vault-agent:

 [INFO] (runner) creating watcher
 [INFO] (runner) starting
....
 [INFO] (runner) rendered "(dynamic)" => "/secrets/keystore/keystore-aj.jks"
 [INFO] (runner) rendered "(dynamic)" => "/secrets/properties/passphrase-aj.properties"

В случае успешного получения сертификатов из HashiCorp Vault/Secret Management System в контейнере PD36 в начале лога будет выведена соответствующая информация на предмет получения необходимых сертификатов для работы:

/opt/kafka/certs/truststore.jks /opt/kafka/certs/keystore.jks /etc/vault/db.properties /etc/vault/kafka.properties /etc/vault/spas.properties

5
Waiting 1 s.
Waiting 2 s.
Waiting 3 s.
Waiting 4 s.
Waiting 5 s.

После чего последуют логи запуска приложения.

В случае, если интеграция с HashiCorp Vault/Secret Management System настроена некорректно, будет бесконечное ожидание получения сертификатов на контейнере приложения:

/opt/kafka/certs/truststore.jks /opt/kafka/certs/keystore.jks /etc/vault/db.properties /etc/vault/kafka.properties /etc/vault/spas.properties

5
Waiting 1 s.
Waiting 2 s.
Waiting 3 s.
Waiting 4 s.
Waiting 5 s.
Waiting 6 s.
Waiting 7 s.
Waiting 8 s
...

Проверка интеграций с Platform V Audit SE

В случае интеграции с данным сервисом необходимо убедиться в наличии событий дедубликации в пользовательском интерфейсе сервиса Platform V Audit SE.

Проверка интеграций с Platform V One-Time-Token

Данный сервис используется для установки защищенного соединения внутри платформы с компонентом Audit SE. Для проверки работоспособности достаточно осуществить проверку компонента Audit. Дополнительно можно открыть лог sidecar OTT для Ingress/Egress подов и убедиться в отсутствии ошибок.

Проверка интеграций с Объединённым сервисом авторизации (ОСА)

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

Проверка интеграций с IAM Proxy

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

Проверка интеграций с Platform V Monitor

В случае интеграции с данным сервисом необходимо убедиться в наличии:

• метрик в компоненте Объединенный мониторинг Unimon (MONA);

• журнала логов в компоненте Журналирование (LOGA).

Откат#

Для отката компонента к ранним версиям ПО после установки обновлений необходимо восстановить предыдущие версии Docker Images, либо путем включения предыдущего Replication Controller (предыдущая версия конфигурации в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально)), либо путем наката предыдущего релиза.

1. Откат к предыдущей версии представляет собой удаление и установку последней стабильной версии.(Запуск Job установки с параметром delete и указанием предыдущей версии релиза)

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

Перед откатом рекомендуется сделать backup БД. Из текущей версии продукта не рекомендуется откат ниже версии 7.8.0.

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

При ошибке импорта Компонент Объединенный мониторинг Unimon (MONA) продукта Platform V Monitor(OPM), инструментов аудита Platform V Audit SE (AUD) проверьте корректность настройки URL для импорта в common репозитории Pipelline DevOps, а также работоспособность самих инструментов.

При ошибке установки SQL-скриптов посмотрите лог сборки в Jenkins на предмет ошибки, проверьте подключение к БД, выполните необходимые правки в common репозитории Pipelline DevOps или репозитории с конфигурацией компонента, если ошибка связана с настройками, или обратитесь к команде разработки компонента для внесения изменений в SQL-скрипты и пересборки дистрибутива.

При ошибке установки в среде контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) посмотрите лог сборки в Jenkins на предмет ошибки, выполните необходимые правки в common репозитории Pipelline DevOps или репозитории с конфигурацией компонента, если ошибка связана с настройками, или обратитесь к команде разработки компонента для внесения изменений в SQL-скрипты и пересборки дистрибутива.

При ошибке авторизации убедитесь что пользователь заведен в опциональном компоненте KeyCloak.SE (KCSE) продукта Platform V IAM SE (IAM).

Возникающие ошибки зависят от этапа развертывания и описаны выше.

Пример ошибки при накате базы

[DEBUG] No configuration value for liquibase.filterLogMessages found
[DEBUG] Running Changeset:../migrations/changeset.xml::01_create_role-grant::ХХХХ
[DEBUG] Changeset ../migrations/changeset.xml::01_create_role-grant::ХХХХ
[DEBUG] No configuration value for liquibase.outputLineSeparator found
[DEBUG] Configuration liquibase.outputLineSeparator is using the default value of
  
[INFO] Continuing past: ../migrations/changeset.xml::01_create_role-grant::ХХХХ despite precondition failure due to onFail='CONTINUE':
            db.changelog-master.xml : Changelog property 'test_password' was not set
  
[DEBUG] Executing with the 'jdbc' executor
[DEBUG] 0 row(s) affected
[DEBUG] Skipping ChangeSet: ../migrations/changeset.xml::01_create_role-grant::ХХХХ
[DEBUG] Executing with the 'jdbc' executor
[DEBUG] Running Changeset:../migrations/changeset.xml::01_create_appl_user::ХХХХ
[DEBUG] Changeset ../migrations/changeset.xml::01_create_appl_user::ХХХХ
[DEBUG] Executing with the 'jdbc' executor
[INFO] Continuing past: ../migrations/changeset.xml::01_create_appl_user::ХХХХ despite precondition failure due to onFail='CONTINUE':
            db.changelog-master.xml : SQL Precondition failed.  Expected '0' got '1'
  
[DEBUG] Executing with the 'jdbc' executor
[DEBUG] 0 row(s) affected
[DEBUG] Skipping ChangeSet: ../migrations/changeset.xml::01_create_appl_user::ХХХХ
[DEBUG] Executing with the 'jdbc' executor
[DEBUG] Running Changeset:../migrations/changeset.xml::01_create_appl_user-schema::ХХХХ
[DEBUG] Changeset ../migrations/changeset.xml::01_create_appl_user-schema::ХХХХ
[DEBUG] Executing with the 'jdbc' executor
[INFO] Continuing past: liquibase.precondition.core.PreconditionContainer@79ca7bea despite precondition error:
       1 preconditions failed
       db.changelog-master.xml : liquibase.precondition.core.SqlPrecondition@115c946b : ERROR: column "tuz_ХХХ_ci_catalogci" does not exist
   Position: 48
  
[DEBUG] Executing with the 'jdbc' executor
[DEBUG] 0 row(s) affected
[DEBUG] Executing with the 'jdbc' executor

Пример ошибки при установке на k8s openshift

 [localhost] (item={'path': 'templates_ansible/app-api/PodDisruptionBudget.yaml'}) => {
     "ansible_loop_var": "item",
     "changed": false,
     "invocation": {
         "module_args": {
             "api_key": "VALUE_SPECIFIED_IN_NO_LOG_PARAMETER",
             "api_version": "v1",
             "append_hash": false,
             "apply": false,
             "ca_cert": "cloud_ca.pem",
             "client_cert": null,
              "client_key": null,
              "context": null,
              "definition": {
                 "apiVersion": "policy/v1beta1",
                  "kind": "PodDisruptionBudget",
                 "metadata": {
                      "name": "app-api"
                  },
                  "spec": {
                      "minAvailable": "100%",
                      "selector": {
                          "matchLabels": {
                              "app": "app-api"
                          }
                      }
                  }
              },
              "delete_options": null,
              "force": false,
              "host": "https://XXX:6443",
              "kind": null,
              "kubeconfig": null,
              "merge_type": null,
              "name": null,
              "namespace": "tribe-pf-dev-pd36-k8s",
              "password": null,
              "persist_config": null,
              "proxy": null,
              "resource_definition": {
                 "apiVersion": "policy/v1beta1",
                  "kind": "PodDisruptionBudget",
                  "metadata": {
                      "name": "app-api"
                  },
                  "spec": {
                      "minAvailable": "100%",
                     "selector": {
                          "matchLabels": {
                              "app": "app-api"
                          }
                      }
                  }
             },
              "src": null,
             "state": "present",
              "template": null,
              "username": null,
              "validate": null,
             "validate_certs": false,
              "wait": false,
              "wait_condition": null,
              "wait_sleep": 5,
              "wait_timeout": 120
         }
      },
      "item": {
          "path": "templates_ansible/app-api/PodDisruptionBudget.yaml"
      },
     "msg": "Failed to get client due to HTTPSConnectionPool(host='XXX', port=6443): Max retries exceeded with url: /version (Caused by SSLError(FileNotFoundError(2, 'No such file or directory'),))"
  }
  <localhost> EXEC /bin/sh -c '( umask 77 && mkdir -p "` echo $HOME/.ansible/tmp `"&& mkdir "` echo $HOME/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036 `" && echo ansible-tmp-1657279706.817063-30568-75500627184036="` echo $HOME/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036 `" ) && sleep 0'
  redirecting (type: modules) ansible.builtin.k8s to kubernetes.core.k8s
  Using module file /usr/local/lib/python3.6/site-packages/ansible_collections/kubernetes/core/plugins/modules/k8s.py
  <localhost> PUT /home/jenkins/.ansible/tmp/ansible-local-305109nzez916/tmpmqnfwreu TO /home/jenkins/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036/AnsiballZ_k8s.py
  <localhost> EXEC /bin/sh -c 'chmod u+x /home/jenkins/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036/ /home/jenkins/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036/AnsiballZ_k8s.py && sleep 0'
  <localhost> EXEC /bin/sh -c '/usr/bin/python3 /home/jenkins/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036/AnsiballZ_k8s.py && sleep 0'
  <localhost> EXEC /bin/sh -c 'rm -f -r /home/jenkins/.ansible/tmp/ansible-tmp-1657279706.817063-30568-75500627184036/ > /dev/null 2>&1 && sleep 0'
  The full traceback is:
    File "/tmp/ansible_k8s_payload_kynh2424/ansible_k8s_payload.zip/ansible_collections/kubernetes/core/plugins/module_utils/common.py", line 294, in get_api_client
      return DynamicClient(kubernetes.client.ApiClient(configuration))
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/client.py", line 71, in __init__
      self.__discoverer = discoverer(self, cache_file)
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 259, in __init__
      Discoverer.__init__(self, client, cache_file)
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 31, in __init__
      self.__init_cache()
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 77, in __init_cache
      self.invalidate_cache()
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 92, in invalidate_cache
      self.__init_cache(refresh=True)
   File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 78, in __init_cache
      self._load_server_info()
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/discovery.py", line 158, in _load_server_info
      'kubernetes': self.client.request('get', '/version', serializer=just_json)
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/client.py", line 42, in inner
      resp = func(self, *args, **kwargs)
    File "/usr/local/lib/python3.6/site-packages/openshift/dynamic/client.py", line 249, in request
      _return_http_data_only=params.get('_return_http_data_only', True)
    File "/usr/local/lib/python3.6/site-packages/kubernetes/client/api_client.py", line 353, in call_api
      _preload_content, _request_timeout, _host)
    File "/usr/local/lib/python3.6/site-packages/kubernetes/client/api_client.py", line 184, in __call_api
      _request_timeout=_request_timeout)
    File "/usr/local/lib/python3.6/site-packages/kubernetes/client/api_client.py", line 377, in request
      headers=headers)
    File "/usr/local/lib/python3.6/site-packages/kubernetes/client/rest.py", line 243, in GET
      query_params=query_params)
    File "/usr/local/lib/python3.6/site-packages/kubernetes/client/rest.py", line 216, in request
      headers=headers)
    File "/usr/local/lib/python3.6/site-packages/urllib3/request.py", line 75, in request
      method, url, fields=fields, headers=headers, **urlopen_kw
    File "/usr/local/lib/python3.6/site-packages/urllib3/request.py", line 96, in request_encode_url
      return self.urlopen(method, url, **extra_kw)
    File "/usr/local/lib/python3.6/site-packages/urllib3/poolmanager.py", line 375, in urlopen
      response = conn.urlopen(method, u.request_uri, **kw)
    File "/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py", line 796, in urlopen
     **response_kw
    File "/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py", line 796, in urlopen
      **response_kw
    File "/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py", line 796, in urlopen
      **response_kw
    File "/usr/local/lib/python3.6/site-packages/urllib3/connectionpool.py", line 756, in urlopen
      method, url, error=e, _pool=self, _stacktrace=sys.exc_info()[2]
    File "/usr/local/lib/python3.6/site-packages/urllib3/util/retry.py", line 574, in increment
      raise MaxRetryError(_pool, url, error or ResponseError(cause))
  failed: [localhost] (item={'path': 'templates_ansible/app-api/cm-app-logback.yaml'}) => {

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

1. На сервере развернуто необходимое ПО из раздела Системные требования.

2. Развернута и настроена система управления базами данных.

3. Созданы docker-образы.

4. Выделен проект системы оркестрации контейнеризированных приложений.

5. Произведена настройка проекта системы оркестрации контейнеризированных приложений.

6. Выделена VM системы управления базами данных.

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

8. Выпущены сертификаты [клиентские/серверные] для:

• Istio [ingress, egress] при использовании;

• сертификаты для подключения к системе управления базами данных по SSL при необходимости;

• сертификат для ОТТ при необходимости;

9. Имеются все необходимые смежные компоненты, описанные в разделе Платформенные зависимости. Настроена интеграция с ними (раздел Настройки интеграции).

10. Произведен Deploy в системе оркестрации контейнеризированных приложений.

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

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

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

• DB_UPDATE — проверить, что применена последняя миграция скриптов из папки liquibase/scripts дистрибутива; По env переменным отвечающим за строку коннекта к базе, зайдите и проверьте, что в соответствующих схемах создались таблицы ответственные за работу приложения. ENV переменные

  APP_API_JDBC_URL
  AUTH_API_JDBC_URL
  INNER_COONECTOR_API_JDBC_URL
  DATAMART_API_JDBC_URL
  MDM_API_JDBC_URL
  

Таблицы с логом Миграции - databasechangelog, databasechangeloglock.

• OPENSHIFT_DEPLOY — проверить, в проектной области среды контейнеризации Kubernetes, компонента K8S Core (K8SC) или Red Hat OpenShift (опционально) появились ConfigMaps, VirtualService, DeploymentConfig, Service, Route, ServiceEntry, Gateway, DestinationRule и создались POD.

Проверьте, что появились pode pct360-auth-api, pct360-app-api

• OPENSHIFT_INGRESS_EGRESS_DEPLOY — проверить, что появились POD INGRESS и EGRESS.

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