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

Термины и определения#

Термин/аббревиатура

Определение

SMCX

Synapse Managment Console. Административная консоль управления, предназначена для работы администраторов с IBM MQ, Synapse

КТС

Комплекс технических средств

БД

База данных

PostgreSQL

Свободная объектно-реляционная система управления базами данных

OpenShift

Гибридная облачная платформа как сервис, построенная вокруг контейнеров Linux, организованных и управляемых Kubernetes на основе Red Hat Enterprise Linux

СУБД

Система управления базами данных

Liquibase

Система управления версиями базы данных

LDAP

Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой

JWT токен

Открытый стандарт (RFC 7519) для создания токенов доступа, основанный на формате JSON

Jenkins

ПО для непрерывной интеграции

MQ

Messages queue

Jira

Программный инструмент для управления проектами, разработанный компанией Atlassian

Git

Консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте

Nexus

Xранилище артефактов Nexus

SSL

Криптографический протокол

Pod

Набор контейнеров внутри узла кластера Kubernetes

DEV

Сокр. от англ. Development (разработка)

Secman

Сокр. от Secret Management System, система управления секретами

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

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

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

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

Категория ПО

Обязательность установки*

Наименование ПО

Версия

Продукт, функциональная совместимость с которым подтверждена **

Назначение категории ПО

Операционная система

Да

Red Hat Enterprise Linux

7.9.9

Рекомендовано

ОС контейнеров для запуска модулей компонента

Да

ОС Альт 8 СП

10

Рекомендовано

Правообладателем АО «СберТех» также рекомендована ОС – Platform V SberLinux OS Core, см. раздел «Платформенные зависимости»

Среда контейнеризации

Да

Red Hat OpenShift

4.8.25

Рекомендовано

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

Да

Kubernetes

1.25.3

Рекомендовано

Правообладателем АО «СберТех» также рекомендована среда контейнеризации – Platform V DropApp, см. раздел «Платформенные зависимости»

Средство контейнеризации

Да

Docker CE

20.10.10 и выше

Рекомендовано

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

Инструмент сборки, тестирования, развертывания контейнеризированных приложений

Нет

Jenkins

2.332.4

Рекомендовано

Сервер автоматизации, используемый для внедрения непрерывной интеграции и непрерывной доставки (CI/CD) для проектов программного обеспечения

Java-машина

Да

OpenJDK

1.11.0

Рекомендовано

Окружение для работы модулей компонента

Браузер

Да

Google Chrome

98.0.4758.109 и выше

Опционально

Брокер сообщений

Да

IBM MQ

7.x и выше

Рекомендовано

Вывод информации IBM MQ

Сервис централизованного хранения репозиториев артефактов (хранилище артефактов)

Да

Nexus Repository Manager PRO

Sonatype Nexus Repository ManagerPRO 3.37.0-01 и выше

Рекомендовано

Интегрированная платформа для проксирования, хранения и управления зависимостями Java (Maven), образами, а также распространения ПО

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

Да

Bitbucket

Atlassian Bitbucket v7.8.1 и выше

Рекомендовано

Хранение конфигураций при автоматизированной установке

Сервис интеграции и оркестрации микросервисов в облаке

Да

Istio

2.0.6.1 и выше

Рекомендовано

Сервис интеграции микросервисов в облаке

Система управления секретами

Нет

Secret Management System

1.7.0

Рекомендовано

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

Система идентификации, аутентификации и авторизации

Да

Microsoft Active Directory

LDAP 2 и выше

Рекомендовано

Система управления доступом и идентификацией

Примечание:

*

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

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

**

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

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

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

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

Наименование продукта

Код

Версия продукта

Код и наименование компонента

Обязательность установки (да/нет)***

Описание

Аналог других производителей****

Platform V Audit SE

AUD

4.6.8

AUDT Аудит

Да

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

Platform V One-Time-Token

OTT

4.3.1

OTTS One-Time Password (OTP) / OTT

Да

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

Platform V Pangolin SE

PSQ

5.X

PSQL, Platform V Pangolin

Да

Система управления базами данных, основанная на PostgreSQL

Platform V DevOps Tools

DOT

1.2

CDJE, Deploy tools

Да

Предназначен для разворачивания программного компонента на среде контейнеризации

Platform V Synapse Service Mesh

SSM

1.12.1.5.1

IGEG Граничный прокси

Да

Сервис для обеспечения управляемого вызова интеграционных сервисов прикладной части

Platform V Synapse Service Mesh

SSM

1.12.1.5.1

SVPX Сервисный прокси

Да

Сервис для обеспечения управляемого вызова интеграционных сервисов прикладной части

Platform V Synapse Messaging

SMB

1.3.0

SMBX Синапс.Брокер сообщений

Да (идет в составе дистрибутива)

Брокер сообщений ActiveMQ Artemis, обеспечивающий передачу сообщений в шаблоне интеграции Message queue, с развязкой поставщика и потребителя по производительности

Apache ActiveMQ Artemis

Platform V SberLinux OS Core

SLC

37.0

CORE Базовая ОС

Да

ОС предназначена для безопасного развертывания сред контейнеризации с поддержкой масштабирования

ОС Альт 8 СП

Platform V DropApp

K8S

1.0 и выше

K8SC K8S Core

Да

Дистрибутив Kubernetes со встроенными механизмами мультитенантности и бессерверным исполнением

Kubernetes, Red Hat OpenShift Container Platform

Примечание:

***

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

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

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

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

Требования по КТС СУБД#

Наименование компонента

OS

Размещение

CPU

RAM

HDD

СУБД сервер PostgreSQL 12.2 и старше (допустимы от 10.10)
СУБД PostgreSQL SE версии выше или равной 4.5.0

Linux (RHELv.7 и старше)

Виртуальный сервер x86

2 cores

4 Гб

10 Гб

Минимальные требования по КТС OpenShift/DropApp(k8s)#

Номер

Наименование компонента

Request (CPU)

Request (RAM)

Limit (CPU)

Limit (RAM)

Количество pod на один элемент развертывания

1

Frontend

850m

1876M

1100m

1940M

1

2

Backend

1500m

1Gi

1500m

2Gi

1

3

MQ master

1000m

1376M

1500m

1940M

1

4

MQ slave

1000m

1226M

1500m

1640M

1

5

ActiveMQ

1250m

1376M

2000m

1940M

1

6

Ingress

700m

964M

1050m

1228M

1

7

Egress

700m

964M

1050m

1228M

1

8

ОТТ

1050m

1176M

1400m

1440M

1

ИТОГО

8050m

9982M

11100m

13404M

8

В каждый компонент добавлена нагрузка для Secman и ТС Аудит. Нагрузка для Istio используется во всех компонентах, кроме Ingress и Egress.

Номер

Наименование компонента

Request (CPU)

Request (RAM)

Limit (CPU)

Limit (RAM)

1

Secman

250m

64M

500m

128M

2

ТС Аудит

100m

300M

100m

300M

3

Istio

400m

512M

400m

512M

Комментарии к таблице:

  1. КТС к БД заложен с запасом;

  2. БД должна быть реализована на PostgreSQL SE;

  3. Минимальные требования рассчитаны исходя из 150 менеджеров на 1 mq-slave. При превышении количества менеджеров сервис mq-slave скалируется, ресурсы увеличиваются пропорционально количеству.

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

Элемент дистрибутива

Описание

./bh/UCC.jar

Сервис, обрабатывающий запросы с Frontend. Содержит логику аутентификации/авторизации, аудита, взаимодействия с БД

./bh/mq-master.jar

Сервис, инициирующий запросы к MQ slave, возвращает информацию из кеша/напрямую из MQ slave в Backend

./bh/mq-slave.jar

Сервис, взаимодействующий с IBM MQ

./pl/ucc-frontend.zip

Сервис, который является фронтальным решением

SMCX использует вендорские библиотеки: com.ibm.mq.allclient-9.2.5.0.jar, ibmjsseprovider2-7.0.0.0.jar.****

Примечание:

****

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

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

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

  • Целевая (автоматизированная установка сервиса с использованием программного продукта Platform V DevOps Tools),

  • Опциональная (ручная установка сервиса).

Создание релиза в Jira#

Для установки дистрибутива в промышленную базу потребуется создать Story и Release в Jira. Для установки на тестовые стенды Story в настоящее время не требуется.

Необходимо:

  • Cоздать Story в своем пространстве;

  • Создать Jira релиз, связать с Story в своем пространстве;

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

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

Установка#

Подготовительные этапы#

Подготовительные этапы включают в себя:

  1. Создание БД;

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

  3. Создание необходимых секретов в Secman.

Создание БД#

SMCX использует СУБД PostgreSQL (без модуля переотправки сообщений). Для работы приложения необходимо создать:

  • Роль;

  • Табличное пространство;

  • Базу данных;

  • Схему. Остальные элементы БД (таблицы, последовательности и т.д.) будут созданы при старте приложения с помощью Liquibase.

Инструкция создания и подключения БД (вариант с docker)

Этапы создания БД:

  1. Подключитесь к удаленной машине по SSH;

  2. Перейдите в директорию opt;

  3. Создайте директорию с индивидуальным названием;

  4. Перейдите в созданную директорию;

  5. Создайте docker-compose.yml (содержимое файла описано ниже);

  6. Создайте директорию sql, перейдите в нее и создайте файл init.sh (содержимое файла описано ниже);

  7. Выполните шаг 4;

  8. Запустите команду: docker-compose up -d --build;

  9. В контейнере с Postgres нужно прогнать скрипты для создания БД (init.sh ниже);

  10. Настройте pg_hba.conf для работы по ssl с проверкой клиентского сертификата (пример конфига ниже);

  11. Добавьте данные созданной БД в application.yml.

docker-compose.yaml

docker-compose.yml (с включенным ssl)

version: '3.1'
services:
ucc-db:
restart: always
build:
context: ./db
args:
- SSH_ROOT_USER=root
- SSH_ROOT_PASSWORD=passw0rd
image: pg_image(подставить актуальный)
command: -c ssl=on -c ssl_cert_file=/var/lib/postgresql/server-cert.crt -c ssl_key_file=/var/lib/postgresql/server-key.key -c ssl_ca_file=/var/lib/postgresql/ca-cert.crt -c ssl_ciphers='HIGH:MEDIUM:+3DES:!aNULL' -c ssl_prefer_server_ciphers=on -c ssl_min_protocol_version='TLSv1.2'
container_name: ucc_db_14
environment:
- SSH_USER=sshu
- SSH_PASS=passw0rd
- POSTGRES_USER=postgres
- POSTGRES_PASSWORD=postgres
- DB_USER=ucc
- DB_PASSWORD=passw0rd
- DB_NAME=uccdb
- DB_SCHEMA=ucc_cfg
- DB_TABLESPACE=ucc_cfg_data
volumes:
- ./postgres-data:/var/lib/postgresql/data
- ./certGenerate/server-cert.pem:/var/lib/postgresql/server-cert.crt
- ./certGenerate/server-key.pem:/var/lib/postgresql/server-key.key
- ./certGenerate/ca-cert.pem:/var/lib/postgresql/ca-cert.crt
ports:
- '5432:5432'
- '2223:22' 

pg_hba.conf (режим с проверкой сертификата) hostssl all all all cert clientcert=verify-full

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

init.sh #!/bin/bash set -e psql -v ON_ERROR_STOP=1 --username postgres --dbname postgres <<-EOSQL CREATE ROLE ucc WITH LOGIN PASSWORD 'ВВЕДИТЕ ПАРОЛЬ' VALID UNTIL '2100-03-17'; CREATE TABLESPACE ucc_cfg_data OWNER ucc LOCATION '/var/lib/postgresql/data'; CREATE DATABASE uccdb WITH OWNER = ucc ENCODING = 'UTF8' TABLESPACE = ucc_cfg_data CONNECTION LIMIT = -1; EOSQL psql -v ON_ERROR_STOP=1 --username ucc --dbname uccdb <<-EOSQL CREATE SCHEMA ucc_cfg AUTHORIZATION ucc; ALTER ROLE ucc SET search_path = ucc_cfg,public; EOSQL

Заполнение стендозависимых параметров для дистрибутива#

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

  • через Jenkins Job SynapseInstaller с конфигурацией для менеджера пакетов helm;

  • через единый Jenkins Job развертывания.

Установка в DropApp. Различия в конфигурации

При установке в DropApp(k8s) в стендозависимых параметрах необходимо задать

deploy_kuber: "true"

иначе, если установка происходит в OpenShift, параметр должен иметь значение

deploy_kuber: "false"

Заполнение стендозависимых параметров для установки через Jenkins Job SynapseInstaller

Дистрибутив включает в себя конфигурацию для установок пакетным менеджером helm. Для каждого поставляемого модуля приложения SMCX имеется свой Chart (пакет) с набором шаблонов (templates) для установки, значения в шаблоны подставляются из конфигурационного yaml-файла values.yaml. На скриншоте ниже демонстрация данной структуры.

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

Структура расположения конфигурационных файлов ниже на снимке, где папка верхнего уровня имя проектной области в OpenShift/DropApp(k8s). Остальная структура конфигурационных файлов должна совпадать.

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

active-mq

release_version: "3.4"
config_version: "0.0.1"
component_type: service

app_prefix: dev

istio:
  proxyLimitsCPU: 400m
  proxyLimitsMemory: 400m
  proxyRequestsCPU: 512Mi
  proxyRequestsMemory: 512Mi

active_mq_name: ucc-activemq-basic
replicas: '1'

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

containers:
  active_mq:
    limits:
      cpu: 1000m
      memory: 1000Mi
    requests:
      cpu: 500m
      memory: 500Mi
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
      periodSeconds: 1
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 50
      periodSeconds: 100
      successThreshold: 1
      failureThreshold: 20

terminationGracePeriodSeconds: 59
priorityClassName: ''

egress

image_envoy: proxyv2_image ***используемый образ для envoy
image_ott: ott_image ***используемый образ для ott-клиента
control_plane_project: devpub-cp-02 ***ControlPanel, к которой подключен проект в OpenShift/DropApp(k8s)
istiod_service: istiod-basic ***имя сервиса в контрольной панели, через которое идет подключение
istio_version: 2.1.1-1.el8-2
namespace: tribe-sy-dev-mmt-services-dev  ***проектная область OpenShift/DropApp(k8s)
replicas: '1'
terminationGracePeriodSeconds: 59
priorityClassName: ''

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

app_prefix: dev

secret: ***группа настроек секретов Secman
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman
  ldap: namespace_Secman/path_kv/ldap-secret ***сертификаты ldap в Secman
  egress:
    keystore: namespace_Secman/path_kv/egress-secret ***сертификаты egress в Secman
    audit: namespace_Secman/path_kv/audit-secret2 ***сертификаты для аудита в Secman
    ott: namespace_Secman/path_kv/ott-certs-2 ***сертификаты для ott-клиента в Secman

containers:
  envoy:
    limits:
      cpu: 450m
      memory: 800Mi
    requests:
      cpu: 350m
      memory: 600Mi

ext_resources: ***группа настроек для подключения к внешним ресурсам
  pg:
    host: pg-host
    port: 5432
    egress_port: {номер порта}
    se_ports:
      - name: tcp-5432
        number: 5432
        protocol: TCP
  audit:
    ip: 'ip_address_audit'
    host: host-audit
    port: 443
    egress_port: {номер порта}
    se_ports:
      - name: https-443
        number: 443
        protocol: HTTPS
      - name: http-8081
        number: 8081
        protocol: HTTP
  secman:
    host: host-secman
    ip: 'ip_address_secman'
    port: 8443
    egress_port: {номер порта}
    port_name: tls-8550
  ldap:
    ip: 'ip_address_ldap'
    host: host-ldap
    port: 636
    port_name: tls-10636
    egress_port: {номер порта}
    se_ports:
      - name: tcp-636
        number: 636
        protocol: TCP
ott: ***группа настроек для взаимодействия с OTT-сервером
  hosts: host-ott:443
  module_id: smcx
  cert_client: eku.crt.pem
  key_client: eku.key.pem
  cert_server: ott-ca.crt.pem
  ca_server: ott-service.crt.pem

spec: ***внутренние порты на egress для внешних ресурсов
  ports:
    - port: {номер порта}
      targetPort: {номер порта}
      name: http
      protocol: TCP
    - port: {номер порта}
      targetPort: {номер порта}
      name: audit-ssl
      protocol: TCP
    - port: {номер порта}
      targetPort: {номер порта}
      name: secman-ssl
      protocol: TCP
    - port: {номер порта}
      targetPort: {номер порта}
      name: tls-15432
      protocol: TCP
    - port: {номер порта}
      targetPort: {номер порта}
      name: tls-10636
      protocol: TCP

gw_template: ***список для генерации новых Gateway для подключаемых менеджеров MQ
  - name: gw-test-1
    port: 8899

vs_template: ***список для генерации новых VirtualService для подключаемых менеджеров MQ
  - name: vs-test-1
    host: host-mq-1
    port: 3331
    port_egress: 8899
    gw_name: gw-test-1


se_template: ***список для генерации новых ServiceEntry для подключаемых менеджеров MQ
  - name: egress-mq-se-84-7
    ip: 'ip_address_mq1'
    host: host-mq-1
    ports:
      - name: tcp-3331
        number: 3331
        protocol: TCP
  - name: egress-mq-se-84-8
    ip: 'ip_address_mq2'
    host: host-mq-2
    ports:
      - name: tcp-3332
        number: 3332
        protocol: TCP
      - name: tcp-1421
        number: 1421
        protocol: TCP

ingress

image: proxyv2_image
istiod_service: istiod-basic 
istio_version: 2.1.1-1.el8-2 
namespace: tribe-sy-dev-mmt-services-dev  ***проектная область OpenShift/DropApp(k8s) 
host_ingress_front: 'http-front-ucc.apps.stands-vdc01.solution' ***внешний хост для внешнего route к приложению SMCX
front_port_name: 'https'
replicas: '1'
terminationGracePeriodSeconds: 59
priorityClassName: ''

ucc_front_name: ucc-front

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

app_prefix: dev

secret: ***группа настроек секретов Secman 
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman 
  ingress: namespace_Secman/path_kv/ingress-secret ***сертификаты ingress в Secman

containers:
  envoy:
    limits:
      cpu: 450m
      memory: 800Mi
    requests:
      cpu: 350m
      memory: 600Mi

mq-master

release_version: "3.4"
config_version: "0.0.1"
component_type: service

registryHost: registryHost
registryPath: /ci90000286_smx
app_prefix: dev

java_opts: '-Xms450m -Xmx900m -XX:ActiveProcessorCount=2'

istio:
  proxyLimitsCPU: 400m
  proxyLimitsMemory: 400m
  proxyRequestsCPU: 512Mi
  proxyRequestsMemory: 512Mi

mq_master_name: ucc-mq-master
mq_slave_name: ucc-mq-slave
active_mq_name: ucc-activemq-basic
replicas: '1'

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

list_secret: list-mq-master-cm ***список конфигов, которые нужно загрузить из Secman до старта модуля
secret: ***группа настроек секретов Secman
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman
 mfConf: namespace_Secman/path_kv/activemq-conf ***секрет с конфигом mq в Secman

containers:
  mq_master:
    limits:
      cpu: 500m
      memory: 1000Mi
    requests:
      cpu: 250m
      memory: 500Mi
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
      periodSeconds: 1
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 50
      periodSeconds: 100
      successThreshold: 1
      failureThreshold: 20

terminationGracePeriodSeconds: 59
priorityClassName: ''

mq-slave

release_version: "3.4"
config_version: "0.0.1"
component_type: service

app_prefix: dev

java_opts: '-Xms450m -Xmx900m -XX:ActiveProcessorCount=2'

istio:
  proxyLimitsCPU: 400m
  proxyLimitsMemory: 400m
  proxyRequestsCPU: 512Mi
  proxyRequestsMemory: 512Mi

mq_slave_name: ucc-mq-slave
active_mq_name: ucc-activemq-basic
replicas: '1'

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

list_secret: list-mq-sl-cm ***список конфигов, которые нужно загрузить из Secman до старта модуля

secret: ***группа настроек секретов Secman 
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman
  mfConf: namespace_Secman/path_kv/activemq-conf ***секрет с конфигом mq в Secman
  keystore: namespace_Secman/path_kv/keystore-ecu-jks ***хранилища с сертификатами mq

containers:
  mq_slave:
    limits:
      cpu: 500m
      memory: 750Mi
    requests:
      cpu: 250m
      memory: 500Mi
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
      periodSeconds: 1
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 50
      periodSeconds: 100
      successThreshold: 1
      failureThreshold: 20

terminationGracePeriodSeconds: 59
priorityClassName: ''

ucc-back

release_version: "3.4"
config_version: "0.0.1"
component_type: service

registryHost: registryHost
registryPath: /ci90000286_smx
app_prefix: dev

java_opts: '-Xms1000m -Xmx1000m'

istio:
  proxyLimitsCPU: 400m
  proxyLimitsMemory: 512Mi
  proxyRequestsCPU: 400m
  proxyRequestsMemory: 512Mi

is_prom: true
kvr_min_expire: 60
ucc_back_name: ucc-back
mq_slave_name: ucc-mq-slave
mq_master_name: ucc-mq-master
replicas: '1'

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%

list_secret: list-back-cm ***список конфигов, которые нужно загрузить из Secman до старта модуля 

secret:
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman
  ucc_back: namespace_Secman/path_kv/back-secret ***секрет с настройками модуля back
  pg_keystore: namespace_Secman/path_kv/pg_keystore ***хранилища с сертификатами подключения к СУБД PostgreSQL
  ucc_kubernetes: namespace_Secman/path_kv/ucc-kubernetes-secret ***секрет с токенами для подключения к другим проектным областям

containers:
  ucc_back:
    limits:
      cpu: 1500m
      memory: 1Gi
    requests:
      cpu: 1500m
      memory: 1Gi
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
      periodSeconds: 1
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 50
      periodSeconds: 100
      successThreshold: 1
      failureThreshold: 20

terminationGracePeriodSeconds: 59
priorityClassName: ''

ucc_properties: ***конфиги из ConfigMap ucc-properties
  name: ucc-properties
  audit2: 'http://host-audit:8081' ***хост аудита, прописывается фейковый порт 8081, на egress происходит терминация трафика
  modules: ***отображаемые модули в приложении
    - IBM_MQ
    - CACHE
    - AUDIT
    - SYNAPSE
    - ROUTE
  ldap: ***группа настроек для подключения к ldap
    userDn: 'cn=admin,dc=mycomp,dc=ru'
    first:
      urls: 'ldap://ip_address_ldap:636'
      base: 'DC=mycomp,DC=ru'
      ignorePartialResultException: 'true'
    second:
      urls: ''
      base: ''
      ignorePartialResultException: ''
  datasource:
    all_props: ***список настроек подключения к СУБД
      - url: 'jdbc:postgresql://pg-host.:5432/uccdb?reWriteBatchedInserts=true&ssl=true&sslmode=prefer&sslfactory=ru.integration.ucc.listener.UccSSLSocketFactory&trustStore=/data/secret/pg_truststore.jks&keyStore=/data/secret/pg_keystore.jks'
        schema: 'ucc_cfg'
        segment: 'UCC-Postgre-docker'
        is_w3s_debugger: 'true'
        is_url_allowed: 'true'
  logging:
    log_level: 'DEBUG'
  load_changer:
    timer_interval: 120000

ucc-front

release_version: "3.4"
config_version: "0.0.1"
component_type: service

registryHost: registryHost
registryPath: /ci90000286_smx
app_prefix: dev

java_opts: '-Xms1000m -Xmx1000m'

istio:
  proxyLimitsCPU: 400m
  proxyLimitsMemory: 400m
  proxyRequestsCPU: 512Mi
  proxyRequestsMemory: 512Mi

is_prom: 'true'
ucc_front_name: ucc-front
ucc_back_name: ucc-back
replicas: '1'

rollingUpdate:
  maxUnavailable: 100%
  maxSurge: 0%  

secret:
  role: role-ga-secman-smcx ***роль Secman
  namespace: namespace_Secman ***namespace Secman 

containers:
  ucc_front:
    limits:
      cpu: 100m
      memory: 1Gi
    requests:
      cpu: 100m
      memory: 1Gi
    readinessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 10
      periodSeconds: 1
      successThreshold: 1
      failureThreshold: 3
    livenessProbe:
      initialDelaySeconds: 30
      timeoutSeconds: 50
      periodSeconds: 100
      successThreshold: 1
      failureThreshold: 20

terminationGracePeriodSeconds: 59
priorityClassName: ''

Создание необходимых секретов в Secman#

Приватные данные хранятся в секретах Secman, структура секретов ниже.

mq-master

        vault.hashicorp.com/agent-inject-template-application.yml: |
          {{"{{"}}- with secret "{{ .Values.secret.mfConf }}" -{{"}}"}}
            {{"{{"}} base64Decode .Data.app {{"}}"}}
          {{"{{"}}- end {{"}}"}} 

, где secret.mfConf- путь до конфига mq в кодировке base64, ключ "app". Структура application.yml для mq-master приводятся ниже:

app.services.activemq.user:
  login: {логин}
  password: {пароль}

mq-slave

        vault.hashicorp.com/agent-inject-template-application.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.mfConf }}"
          {{`-}}
            {{- base64Decode .Data.app -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-keystore.jks: |
          {{`{{- with secret`}}
          "{{ .Values.secret.keystore }}"
          {{`-}}
            {{- base64Decode .Data.keystore -}}
          {{- end }}`}}

, где secret.mfConf - путь до конфига mq в кодировке base64, ключ "app". Структура application.yml для mq-master приводятся ниже:

app.services.activemq.user:
  login: {логин}
  password: {пароль}
crypto:
  secret_key_1: "ssdkF$HUy2A#D%ka"
  secret_key_2: "weJiSEvR5yAC5fta"

secret.keystore - путь до хранилища jks для ssl подключения к MQ в кодировке base64, ключ "keystore".        

back

        vault.hashicorp.com/agent-inject-template-db.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ucc_back }}"
          {{`-}}
            {{- base64Decode .Data.db  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-ldap.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ucc_back }}"
          {{`-}}
            {{- base64Decode .Data.ldap  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-sign_key.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ucc_back }}"
          {{`-}}
            {{- base64Decode .Data.key  -}}
          {{- end }}`

        vault.hashicorp.com/agent-inject-template-oauth2.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ucc_back }}"
          {{`-}}
            {{- base64Decode .Data.oauth2  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-pg_keystore.jks: |
          {{`{{- with secret`}}
          "{{ .Values.secret.pg_keystore }}"
          {{`-}}
            {{- base64Decode .Data.keystore  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-pg_truststore.jks: |
          {{`{{- with secret`}}
          "{{ .Values.secret.pg_keystore }}"
          {{`-}}
            {{- base64Decode .Data.truststore  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-kubernetes.yml: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ucc_kubernetes }}"
          {{`-}}
            {{- base64Decode .Data.secret  -}}
          {{- end }}`}}

secret.ucc_back содержит путь до конфигов db.yml, ldap.yml, key.yml, oauth2.yml в SecMan Структура данных настроек приводит ниже.
---
db.yml

spring:
  datasource:
    all-secret-props:
      - username: 'login'
        password: 'pass'
        group: cn=email,dc=mycomp,dc=ru
        url-secret: '&trustStorePassword=123456&keyStorePassword=123456'
crypto:
  secret_key_1: "pass1"
  secret_key_2: "pass2"

---
ldap.yml

spring:
  ldap-secret:
    username: cn=admin,dc=mycomp,dc=ru
    password: 'pass'
---
oauth2.yml

oauth2:
  clients:
    - client_id: "client_id"
      client_secret: "secret_val"
      grant_types:
        - password
        - authorization_code
---
sign-key.yml

ucc:
  sign_key: "key_val"
---

secret.pg_keystore содержит хранилище с клиентским сертификатом postgreSQL (ключ pg_keystore) и хранилище с доверенными серверными сертификатами (ключ pg_truststore).
{
  "keystore": "keystoreBase64",
  "truststore": "truststoreBase64"

}

---

ucc_kubernetes
{
  "secret": "secretBase64"
},

где secretBase64 имеет структуру согласно примеру ниже:

apiVersion: v1
clusters:
  - cluster:
      insecure-skip-tls-verify: true
      server: host-server-api:6443
    name: foo
contexts:
  - context:
      cluster: foo
      user: example
    name: foo-context
  - context:
      cluster: foo
      user: example1
    name: foo-context1
current-context: foo-context1
users:
  - name: example
    user:
      token: eyJhbGciOiJSUzI1NiIsImtpZCI6IloyZm9aS29XV2RlMERndkV3eGdPWkJEXzlSQTdMemk2am1OZVZhdGUzdUEifQ.eyJpc3MiOiJrdWJlcm5ldGVzL3NlcnZpY2VhY2NvdW50Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9uYW1lc3BhY2UiOiJ0cmliZS1zeS11Y2MtZGV2Iiwia3ViZXJuZXRlcy5pby9zZXJ2aWNlYWNjb3VudC9zZWNyZXQubmFtZSI6ImV4YW1wbGUtdG9rZW4tcjI3OGwiLCJrdWJlcm5ldGVzLmlvL3NlcnZpY2VhY2NvdW50L3NlcnZpY2UtYWNjb3VudC5uYW1lIjoiZXhhbXBsZSIsImt1YmVybmV0ZXMuaW8vc2VydmljZWFjY291bnQvc2VydmljZS1hY2NvdW50LnVpZCI6ImMxZjM0ZTgyLTM4NDAtNDA5Ny04ZTM0LTQ1YWE0MjUwZWFkNiIsInN1YiI6InN5c3RlbTpzZXJ2aWNlYWNjb3VudDp0cmliZS1zeS11Y2MtZGV2OmV4YW1wbGUifQ.IsPVh5lYgdmiMJnarjyLNBpzH6dlorVnBy0TrBHDDOZsgzEnLPImyBxUCNCes2yt63126WW90B3FYrRJGk13ugQTYUGrhFW55irugaNsqY8opdG70nAW0gwGbJ1s84rsl1-SulMNenz6cqzvqyC_CczKB6mTbujTPDp-VA_zL91Iqv8W2H63sX80YnbzRTQM1SeeAOpTXCa08zYHwcfpwOMG0trGFZzo0b4w5zSNr1_aYLJl_C7PFtEN3-8K66w5TGoo12z76wCpDujevHB_SH-eKPuyhhnzfFo8FGI2wPLqParc-mYl7UfYKzx6-ZTDV37JyGu-eDfwQlc3jrO95w     

ingress

        vault.hashicorp.com/agent-inject-template-tls.crt: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ingress }}"
          {{`-}}
            {{- base64Decode .Data.crt -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-root.crt: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ingress }}"
          {{`-}}
            {{- base64Decode .Data.root -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-tls.key: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ingress }}"
          {{`-}}
            {{- base64Decode .Data.key -}}
          {{- end }}`}}

Где secret.ingress - путь до секрета ingress_secret (tls.key(ключ key), tls.crt(ключ crt), root.crt(ключ root)) в SecMan.

egress

        vault.hashicorp.com/agent-inject-template-chain.crt: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.keystore }}"
          {{`-}}
            {{- base64Decode .Data.chain -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-tls.crt: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.keystore }}"
          {{`-}}
            {{- base64Decode .Data.crt  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-tls.key: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.keystore }}"
          {{`-}}
            {{- base64Decode .Data.key  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-chain_audit.pem: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.audit }}"
          {{`-}}
            {{- base64Decode .Data.chain  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-tls_audit.key: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.audit }}"
          {{`-}}
            {{- base64Decode .Data.key  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-tls_audit.pem: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.audit }}"
          {{`-}}
            {{- base64Decode .Data.crt  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-{{ .Values.ott.cert_client }}: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.ott }}"
          {{`-}}
            {{- base64Decode .Data.eku_crt  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-{{ .Values.ott.key_client }}: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.ott }}"
          {{`-}}
            {{- base64Decode .Data.eku_key  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-{{ .Values.ott.ca_server }}: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.ott }}"
          {{`-}}
            {{- base64Decode .Data.ott_ca_crt  -}}
          {{- end }}`}}
        vault.hashicorp.com/agent-inject-template-{{ .Values.ott.cert_server }}: |
          {{`{{- with secret`}}
          "{{ .Values.secret.egress.ott }}"
          {{`-}}
            {{- base64Decode .Data.ott_service_crt  -}}
          {{- end }}`}}

        vault.hashicorp.com/agent-inject-template-ldap_chain.crt: |
          {{`{{- with secret`}}
          "{{ .Values.secret.ldap }}"
          {{`-}}
            {{- base64Decode .Data.chain  -}}
          {{- end }}`}}

, где secret.egress.keystore - путь до секрета egress_secret (tls.key(ключ key), tls.crt(ключ crt), chain.crt(цепочка корневых сертификатов, ключ chain)) в SecMan. 

secret.egress.ott - путь до секрета ott_egress_secret (eku_crt - клиентский серт, eku_key - клиентский закрытый ключ, ott_ca_crt - цепочка доверенных сертификатов, ott_service_crt - серверный сертификат) в SecMan.

secret.egress.audit - путь до секрета аудита, который содержит клиентский сертификат crt, приватный ключ key и цепочку доверенных сертификатов chain. 

secret.ldap - путь до секрета для ssl подключения к ldap, который содержит цепочку доверенных сертификатов chain. Сертификат для ldap используется от egress /etc/istio/egressgateway-certs/tls.crt. 

active-mq-artemis

Логин и пароль, использумые в Artemis, хранятся в Secman в формате base64 в конфигурационном файле args.yaml.

{ "args": "fileConfigBase64" }

Файл args.yaml должен иметь следующую структуру:

arg1:loginBase64 arg2:passwordBase64

Значения arg1 и arg2 должны совпадать со значениями, заданными в KEYSTORE_MQ_SECRET.

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

Инструкция предназначена для первоначальной настройки SMCX.

1. Создание Config Maps#

  • Необходимо перейти в раздел Config Maps;

  • Нажать Add to Project (обычно правый верхний угол), затем Import YAML / JSON;

  • Вставить содержимое yaml файла настроек (в архиве в директории ConfigMaps);

  • Проверить правильность указываемых логинов/паролей/url;

  • Нажать кнопку Create;

  • Повторить п. 1-3 для всех файлов типа ConfigMaps.

2. Создание секретов#

  • Необходимо перейти в раздел Secrets (обычно располагается по пути Resources/Secrets);

  • Нажать Add to Project (обычно правый верхний угол), затем Import YAML / JSON;

  • Вставить содержимое yaml файла настроек (в архиве в директории Secrets);

  • Проверить правильность указываемых логинов/паролей;

  • Нажать кнопку Create;

  • Повторить п. 1-3 для всех файлов типа Secrets.

3. Создание deployment конфигов#

  • Необходимо перейти в раздел Deployments (обычно располагается по пути Applications/Deployments);

  • Нажать Add to Project (обычно правый верхний угол), затем Import YAML / JSON;

  • Вставить содержимое yaml файла настроек (в архиве в директории Deployment configs);

  • Нажать кнопку Create;

  • Повторить п. 1-3 для всех файлов типа Deployment configs;

  • Дождаться статуса Active для созданных pod-ов.

4. Создание сервисов#

  • Необходимо перейти в раздел Services (обычно располагается по пути Applications/Services);

  • Нажать Add to Project (обычно правый верхний угол), затем Import YAML / JSON;

  • Вставить содержимое yaml файла настроек (в архиве в директории Services);

  • Нажать кнопку Create;

  • Повторить п. 1-3 для всех файлов типа Services.

5. Создание маршрутов для доступа к сервисам#

  • Необходимо перейти в раздел Routes (обычно располагается по пути Applications/Routes);

  • Нажать Create Route (обычно правый верхний угол);

  • Ввести название маршрута (ex. "ucc-front");

  • Выбрать соответствующий сервис (ex. "general-ucc-front");

  • Нажать кнопку Create;

  • Повторить, пока не будут созданы 2 маршрута (1 для сервиса фронта, 1 для сервиса бэка);

  • На странице Routes проверь созданный маршрут, приложение будет доступно по ссылке, указанной в столбце Hostname.

6. [Опционально] Установка keystore и truststore для подключения к менеджерам#

  1. Добавить Secret с keystore и truststore:

    • Перейти на странице Resources/Secrets;

    • Нажать Create Secret;

    • Указать Secret Type = Generic Secret;

    • Указать Secret Name для использования в Deployment Config (любое удобное, не повторяющее ранее созданных секретов);

    • Указать Key = название файла (например "keystore.jks");

    • В поле Value нажать Browse и выбрать загружаемый файл с секретом;

    • При необходимости хранить несколько файлов нажать Add Item и повторить пункты 1.a-f необходимое количество раз;

    • Нажать кнопку Create.

  2. Подключить секреты к pod-ам slave:

    1. Перейти на странице Deployments:

      • Для добавления ключей в mq зайти в mq-slave-deployment-config.

    2. На странице deployment config нажать Actions/Edit YAML;

    3. Найти параметр spec.template.spec.volumes;

    4. Задать новый volume по шаблону:

      - name: volume-name 		# Имя, используемое внутри deployment config
        secret:
          secretName: secret-name # Имя секрета, созданного в п.1
          items:
            - key: file_key		# Ключ файла в секрете
              path: file_path		# Путь к файлу в volume (часто дублируют из file_key)
            - key: file_key2
              path: file_path2
      
    5. Найти параметр spec.template.spec.containers.volumeMounts;

    6. Задать подключение volume по шаблону:

      - mountPath: /data_path		# Путь до подключенных файлов внутри контейнера
        name: volume_name			# Имя volume, созданного в п.2.d поле name
        readOnly: true			# Запрет на перезапись файла
      
  3. Перезапустить измененные pod-ы.

Автоматизированная установка сервиса с использованием Deploy Tools#

Сборка SMCX осуществляется универсальной единой job (целевой).

Сборка. UCC Builder по универсальной job#

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

, где CONFIG_DIR - директория в проекте с шаблонами yml, Dockerfile и конфигурационных файлов с параметрами.

Установка. Synapse Installer

Если происходит первоначальная установка проекта, то необходимо загрузить токен OpenShift/DropApp(k8s) в Jenkins и создать секрет для загрузки образов из Docker-репозитория. Список подготовительных шагов приведен ниже.

  1. Сформировать OpenShift/DropApp(k8s) token credential(чтобы jenkins SynapseInstaller смог взаимодействовать с кластером OpenShift/DropApp(k8s)):

    1. Извлечь secret jenkins-token из OpenShift/DropApp(k8s) (значения ключа token)

    2. Использовать job'у OpenShiftToken.

  2. Установка секрета для пула образов в OpenShift/DropApp(k8s) (если не выполнить этот пункт, то в event'ах OpenShift/DropApp(k8s) выпадет следующая ошибка "unauthorized: access to the requested resource is not authorized / rpc error: code = Unknown desc = Error reading manifest". Необходимо использовать job'у PullSecretCreate.

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

  1. Зайти в job SynapseInstaller и выбрать "Cобрать с параметрами";

  2. В поле CI выбрать значение CI02584231_UCC (можно воспользоваться фильтром);

  3. Выбрать дистрибутив для установки:

    • В поле distribName выбрать собранный в SynapseBuilder дистрибутив. Примечание: номер версии дистрибутива может не совпадать с номером версии SMCX.

    • Либо вставить ссылку на дистрибутив в поле nexusLink;

  4. Выбрать кластер OpenShift/DropApp(k8s) clusterName, в который будет производиться установка;

  5. Выбрать ссылку на кластер OpenShiftUrl (должна заполниться автоматически, лучше перепроверить);

  6. Выбрать репозиторий стендозависимых параметров projectsConfigGitUrlSources;

  7. Задать имя проекта OpenShift/DropApp(k8s):

    • Задать строкой в поле OpenShiftProject,

    • Или выбрать из выпадающего списка OpenShiftProjectArray;

  8. Задать список дополнительных ресурсов к установке projectConfigResourcesList. Например для установки секретов из корня репозитория стендозависимых параметров - secret*.yml

  9. При установке секретов выбрать галочку needUploadSecret.

  10. Поставить галочку needOCValidate для валидации шаблонов OpenShift/DropApp(k8s).

  11. Нажать кнопку "Собрать".

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

Настройка интеграции со смежными сервисами происходит в процессе конфигурирования параметров в ConfigMap, заданием сертификатов в секретах SecMan, настройки маршрутизации трафика через Egress.

Обновление#

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

Удаление предыдущих версий компонент перед обновлением не требуется. В исключительных случаях установщик не может переустановить некоторые компоненты: VS, DR, при этом в логе будет явно указан конфиг, с обновлением которого возникли проблемы. В этом случае следует удалить данный компонент вручную. При обновлении используется стратегия RollingUpdate.

Удаление#

Удаление происходит посредством либо удаления манифестов OpenShift/DropApp(k8s) либо удаления полностью namespace.

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

Проверки работоспособности интеграции с Openshift и с Platform V DropApp идентичны и проводятся по чек-листу из раздела "Чек-лист проверки работоспособности интеграций".

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

  1. Интеграция с Red Hat Enterprise Linux/Platform V SberLinux OS Server. Должны быть успешно собраны Docker-образы для поставляемых в дистрибутиве Dockerfile-ов. Собранные Docker-образы должны быть успешно запущены.

  2. Интеграция с SecMan. Успешный запуск модулей SMCX в OpenShift/DropApp(k8s). Все модули за исключением active-mq и front получают секреты из хранилища SecMan. Запуск основного модуля происходит только после получения секретов из хранилища. Эта проверка позволяет проверить интеграцию с SecMan.

  3. Проверка LDAP. Вход в систему через веб-интерфейс позволяет проверить интеграцию с LDAP.

  4. mTLS MQ. Проверить интеграцию с MQ по mTLS можно через непосредственно внутри приложения SMCX, поскольку в промышленной среде подключение к MQ возможно только через mTLS.

  5. Интеграция с OTT-сервером и настройки Istio в проекте. Успешный запуск Egress показывает корректную работу Ott-клиента и связь с ControlPlane OpenShift/DropApp(k8s).

  6. Модуль back требует настроенного mTLS с PostgreSQL, успешный запуск которого показывает нам корректность настроек. Позволяет проверить интеграцию с PostgreSQL.

  7. Интеграция с ТС Аудит. На модуле back при установке уровня логирования DEBUG при старте приложения должна быть информация о регистрации метамодели с возвращенным id. Далее после авторизации в веб-интерфейс ТС Аудит необходимо убедиться, что в нем присутствуют события от SMCX.

  8. Интеграция с Istio. Поддержка istio включена во всех свервисах. Необходимо зайти в pod и проверить наличие контейнера istio-proxy.

  9. Проверка работы сервиса «Журнал активности». Сервис логирует операции пользователя в системе, сохраняет изменения в БД. Отключить или изменить набор логируемых операций через пользовательский интерфейс нельзя. После запуска необходимо проверить наличие отражаемых операций.

  10. Первичная проверка работоспособности. Необходимо зайти в SMCX через веб-интерфейс, проверить отображение модулей (отображаемые модули перечислены в modules в ConfigMap ucc-properties).

Чек-лист проверки работоспособности модулей#

  1. Модуль active-mq. Успешный запуск всех контейнеров в deployment (istio, прикладной модуль active-mq), отсутствие ERR в логе контейнера.

  2. Модуль ingress. Успешный запуск всех контейнеров в deployment (istio, агент Secman), отсутствие ERR в логе контейнера. Модуль использует секреты, загружаемые из Secman, успешный запуск возможен только при доступности системы Secman. Обязательное требование: должна быть доступна Control Plane, к которой подключен проект.

  3. Модуль egress. Успешный запуск всех контейнеров в deployment (istio, агент Secman, ott-sidecar) , отсутствие ERR в логе контейнера. Модуль использует секреты, загружаемые из Secman, успешный запуск возможен только при доступности системы Secman.

  4. Модуль mq-master. Успешный запуск всех контейнеров в deployment (istio, прикладной модуль mq-master, агент Secman), отсутствие ERR в логе контейнера. Модуль использует секреты, загружаемые из Secman, успешный запуск возможен только при доступности системы Secman. Обязательное требование: должен работать модуль egress.

  5. Модуль mq-slave. Успешный запуск всех контейнеров в deployment (istio, прикладной модуль mq-slave, агент Secman), отсутствие ERR в логе контейнера. Модуль использует секреты, загружаемые из Secman, успешный запуск возможен только при доступности системы Secman. Обязательное требование: должен работать модуль egress.

  6. Модуль ucc-front. Успешный запуск всех контейнеров в deployment (istio, прикладной модуль ucc-front), отсутствие ERR в логе контейнера, доступ к веб-интерфейсу системы через route. Обязательное требование: должен быть запущен модуль ingress.

  7. Модуль ucc-back. Успешный запуск всех контейнеров в deployment (istio, прикладной модуль ucc-back, агент Secman), отсутствие ERR в логе контейнера. Модуль использует секреты, загружаемые из Secman, успешный запуск возможен только при доступности системы Secman. Обязательное требование: должен работать модуль egress. Также для запуска должен быть доступ к СУБД, настройки заданы в конфигурации ucc-properties (блок datasource).

Откат#

Процесс отката осуществляется путем установки предыдущей версии дистрибутива. Перед обновлением рекомендуется делать бэкап проекта при помощи соответствующих job.

Для отката на предыдущую версию нужно либо установить соответствующий дистрибутив, либо восстановиться из собранного бэкапа. Если в текущей версии есть какие-то манифесты OpenShift/DropApp(k8s), которых нет в старой, но такие манифесты необходимо удалить вручную.

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

Проблема

Причина

Решение

Ошибка при подключении к проекту

Пользователю не предоставлен доступ в проект

Запросите доступ к проекту

Ошибка при подключении к проекту

Нет физического доступа к кластеру

Зарегистрируйте обращение в поддержку для восстановления доступа

Ошибка при загрузке Docker-образа из репозитория

Отсутствуют права на загрузку образа из репозитория

Запросите права

Ошибка при загрузке Docker-образа из репозитория

Недоступен репозиторий

Зарегистрируйте обращение в поддержку для восстановления доступа

Ошибка при загрузке Docker-образа из репозитория

Неверная ссылка на имя образа Docker-контейнера в Deployment

Проверьте ссылку, при необходимости скорректируйте Deployment

Не стартует pod

Ошибки, связанные с доступом к внешнему ресурсу

1. Проверить физическую доступность ресурса;
2. Проверить,что заданы ServiceEntry для ресурсов

Не стартует pod

Ошибки, связанные с загрузкой секретов из Secman

1. Проверить физическую доступность Secman;
2. Проверить доступ к SecMan у проекта OpenShift/DropApp(k8s) для заданной в настройках роли;
3. Проверить корректность задания секрета в хранилище Secman. При корректном настроенной интеграции с SecMan секреты можно увидеть в терминале pod-а по подмонтированному пути

Не стартует pod

Ошибки связанные с подключением к БД

1. Неверно настроен SSL на сервере БД (обратиться к администраторам БД);
2. Некорретные хранилища с сертификатами для БД в Secman (можно вручную скачать и посмотреть состав через утилиту keytool);
3. Ошибки настройки БД (проверить настройки в конфиге ucc-properties и в соотвтествующем секрете PostgreSQL в Secman)

Ошибки с sidecar-контейнером OTT

Ошибки при запуске или работе OTT-контейнера в Egress

1. Проверить корректность настроек в ConfigMap ucc-ott-settings в проекте;
2. Проверить, что модуль SMCX зарегистрирован на ОТТ-сервере;
3. Проверить хранилища с сертификатами ОТТ (keystore и truststore). Проверку можно выполнить утилитой keytool

Ошибки с LDAP

Ошибки, связанные с аутентификацией через LDAP

1. Проверить настройки доступа к LDAP (в конфиге ucc-properties и в секрете back/ldap);
2. Проверить физическую доступность LDAP (обратиться к администраторам ActiveDirectory);
3. Проверить принадлежность учетной записи пользователя к группе администраторов SMCX (за информацией обратиться к администраторам ActiveDirectory);

Ошибки при интеграции с Аудит

Проблема с доставкой событий в ТС Аудит

1. Проверить корректность url аудита в ConfigMap ucc-properties;
2. Проверить физическую доступность сервиса (команда curl с egress, проверка корректно ли заданы ли ServiceEntry аудита);
3. Проверить зарегистрирован ли клиентский сертификат SMCX на сервере ТС Аудит (запросить информацию у коллег из ТС Аудит);
4. Проверить хранилища с сертификатами Аудита (выгрузить из Secman, проверить валидность подходящей утилитой)

Ошибки подключения к MQ

В логах бека ошибки подключения к менеджерам MQ

1. Проверить разрешение на доступ в OpenShift/DropApp(k8s) (наличие ServiceEntry для данного MQ);
2. Проверить физический доступ до ресурса (выполнение команды curl из терминала модуля back);
3. Проверить корректность настроек подключения в веб-интерфейсе приложения;
4. Проверить подмонтированный keystore с клиентским сертификатом

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

  1. Проверить что в label всех Deployment прописалась версия устанавливаемой сборки;

  2. Проверить что все Deployment запустились (Frontend, Backend, MQ master, MQ slave, Active MQ, Ingress GW, Egress GW);

  3. Зайти в систему SMCX через веб-интерфейс, сделать любое изменение, проверить изменение в соответствующей таблице БД;

  4. Зайти в систему ТС Аудит, проверить наличие уведомления об изменении.

Проверка работоспособности интеграций осуществляется в соответствии с пунктом "Чек-лист проверки работоспособности интеграций".