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

В руководстве приведены инструкции по установке компонента Устранение Сбойных Ситуаций (USSX) продукта Platform V Incident Manager (USS).

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

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

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

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

Примечание:

*

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

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

**

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

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

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

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

Примечание:

***

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

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

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

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

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

Для установки USSX требуется нижеописанная конфигурация аппаратного обеспечения.

USSX состоит из двух модулей – USSX и ERRM, которые разворачиваются каждый в своем пространстве имен.

Типовая квота на проект: 50 CPU, 128 ГБ.

Типовая квота на pod c учетом sidecar-контейнеров:

• модуль USSX: 26 CPU, 64 ГБ;

• модуль ERRM: 26 CPU, 64 ГБ.

Минимальная квота на pod c учетом sidecar-контейнеров: 16 CPU, 26 ГБ.

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

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

В дистрибутиве содержатся темплейты для установки в среду контейнеризации Kubernetes или Red Hat OpenShift и миграции баз данных.

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

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

Единственный способ установки описан в разделе Установка настоящего документа.

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

При подготовки к развертыванию USSX необходимо:

1. Создать БД (PostgreSQL, Pangolin (PSQL), Oracle Database).

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

3. Создать проекты в среде контейнеризации Kubernetes или Red Hat OpenShift и получить к ним доступ.

4. Настроить ссылку для аутентификации средствами компонента IAM Proxy (AUTH) продукта Platform V IAM SE (IAM).

5. Загрузить ролевую модель для авторизации средствами компонента Объединенный сервис авторизации (ОСА) (AUTZ) продукта Platform V IAM SE (IAM).

6. Запросить права на чтение репозитория, содержащего код задания Jenkins для развертывания.

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

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

9. Импортировать задание развертывания в Jenkins (xml в Jenkins, а остальные необходимые файлы в Gitlab CE).

10. Задать права и полномочия в Jenkins для запуска Pipeline DevOps. Есть специальное задание для создания полномочий в Jenkins с правами на доступ к среде контейнеризации. Опционально можно сделать другим способом.

11. Задать права и полномочия в Jenkins, содержащие ТУЗ для доступа к Nexus-Public, где будет лежать дистрибутив приложения.

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

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

14. Сгенерировать сертификаты для компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD) и создать секреты (опционально).

15. Создать ServiceAccount Kubernetes или Red Hat OpenShift. Service-acc-ingress необходимо привязать imagePullSecret, выполнив команды:

kind: ServiceAccount
apiVersion: v1
metadata:
name: default
namespace: <значение>
uid: <значение>
resourceVersion: '<значение>'
creationTimestamp: 'YYYY-MM-DD HH:MM:SS'
secrets:
 - name: default-token-9x95x
imagePullSecrets:
 - name: tuz-image-pull

kind: Secret
apiVersion: v1
metadata:
name: default-token-9x95x
namespace: <значение>
uid: <значение>
resourceVersion: '<значение>'
creationTimestamp: 'YYYY-MM-DD HH:MM:SS'
annotations:
kubernetes.io/service-account.name: default
kubernetes.io/service-account.uid: <значение>
managedFields:
data:
ca.crt: >-
<значение>
namespace:
<значение>
token: >-
<значение>
type: kubernetes.io/service-account-token

Установка#

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

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

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

Настройка сертификатов для компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD)#

Для настройки сертификата для компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD) (является опциональным) необходимо:

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 в заявке на генерацию сертификата для модуля. В заявке нужно в явном виде указать, что сертификат должен быть сгенерирован из приложенного запроса по данной инструкции. Результатом выполнения заявки будет два файла: сертификат УЦ компонента OTTS и сертификат модуля.

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

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

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

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

   # Download OTTS 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 OTTS 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 OTTS Service certificate into JKS store
   keytool -importcert -file ott-service.crt -keystore truststore.jks -storetype JKS -storepass <password> -alias "ott-service" -noprompt   
   

   Необходимо загрузить подготовленное хранилище.

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

   ./cert_generate.py -CR -OTT -c ussx для ussx
   

Создание ТУЗ#

В работе системы АС используется техническая учетная запись, например, uss.

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

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

• сreate table;

• schema;

• index;

• Grant select;

• update;

• delete;

• truncate;

• insert;

• trigger;

• execute;

• references;

• connect;

• temporary;

• usage;

• alter table.

Отсутствие следующих прав приводит к ошибкам на этапе установки:

• сreate table;

• schema.

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

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

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

Создание подразумевает два этапа:

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. После получения сертификатов разделить на корневой, промежуточный и клиентский сертификат. Для этого необходимо открыть сертификат для просмотра, нажать на экспортируемый сертификат и выбрать Экспортировать в файл. В качестве кодировки необходимо выбрать Файлы X.509 (.CER) в кодировке Base64. Все сертификаты сохранить отдельными файлами.

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

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

6. Дешифровать приватный ключ:

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

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

7. Собрать данные ключи в секреты среды контейнеризации, для чего выполнить следующее:

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

   • последовательно перейти: WorkLoads → Secrets → Create Secret → Key/Value Secret.

Далее описана последовательность действий для создания секрета istio-ingressgateway-ca-certs.

Чтобы создать цепочку клиентских сертификатов, необходимо:

1. Перейти в WorkLoads → Secrets → Create Secret → Key/Value Secret, где имя секрета – istio-ingressgateway-certs, ключ – tls.crt, значение – текстовое содержимое клиентского ключа в формате OpenSSL созданного ранее.

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

   • ключ – tls.key;

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

Инструкция создания клиентских сертификатов представлена в данном документе. Для настройки HTTPS, а также для общения с рядом сервисов необходимо создать клиентские сертификаты. Создание делится на 2 этапа:

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

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

1. Для создания запроса необходима консоль с sh, в которой нужно создать директорию для сертификатов и перейти в нее, выполнив команду Создание директории mkdir -p certs && cd certs. После создания директории необходимо создать запрос. Сначала создайть закрытый ключ, воспользовавшись утилитой OpenSSL OpenSSL> genrsa -aes256 -out ourPrivatKey.key 2048. Необходимо запомнить пароль к контейнеру, который вводится при создании ключа. В результате в директории certs появится закрытый ключ ourPrivatKey.key.

2. Необходимо создать открытый ключ, для чего используется утилита OpenSSL OpenSSL> req -new -key ourPrivateKey.key -out ourCertificate.csr. Консоль запросит пароль для продолжения, необходимо ввести пароль, который задавали в прошлом шаге. Далее необходимо заполнить информацию в сертификате:

   • Country Name: RU;

   • State or Province: <пустое_значение>;

   • Organization Name: <указать_наименование>;

   • Organizational Unit Name: <указать_наименование>;

   • Common Name : our hostname;

   • Emal Address: <пустое_значение>.

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

Для этого обращаемся к OpenSSL: OpenSSL> x509 -inform der -in ourCertificate.cer -out ourSertificate.pem

Далее дешифруем приватный ключ: OpenSSL> rsa -in ourPrivateKey.key -out unencryptPrivateKey.key

Команда попросит ввести пароль, который был задан на первых шагах. Далее собираем данные ключи в секреты среды контейнеризации. Для этого необходимо:

1. Авторизоваться.

2. Зайти в проект.

3. Пройти по цепочке: WorkLoads → Secrets → Create Secret → Key/Value Secret.

4. Создать цепочку клиентских сертификатов.

5. Перейти в WorkLoads → Secrets → Create Secret → Key/Value Secret. Где имя секрета — istio-ingressgateway-certs, ключ – tls.crt, значение – текстовое содержимое клиентского ключа в формате OpenSSL, созданного ранее. Вторым ключом необходимо добавить дешифрованный ключ, чтобы хранить их в 1-ом секрете: ключ – tls.key, значение – текстовое значение дешифрованного ключа, созданного ранее. Для удобства создания сертификата создан скрипт. Для начала необходимо заполнить san.cnf.

[ req ]
default_bits       = 2048
distinguished_name = req_distinguished_name
req_extensions     = req_ext
prompt = no
 
[ req_distinguished_name ]
countryName                 = RU
stateOrProvinceName         = MOW
localityName                = MOW
organizationName            = NAME
commonName                  = <URL>
 
[ req_ext ]
subjectAltName = @alt_names
 
[alt_names]
DNS.1 = <URL>
DNS.2 = <URL>
DNS.3 = <URL>
DNS.4 = <URL>

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

./cert_generate.py -CR -server -req san.cnf -c CommonName

После чего придет запрос на создание сертификата.

Создание секретов для среды контейнеризации (опционально)#

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

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

• ignite-se-cluster-secrets;

• kafka-secret;

• secret-ingressgateway-ca-certs;

• secret-ingressgateway-certs;

• secret-uss-eggrm;

• secret-uss-ott;

• secret-uss-ott-certs.

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

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

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

secret-ingressgateway-ca-certs и secret-ingressgateway-certs – для хранения сертификатов Envoy.

Файлы подготавливаются при создании клиентского сертификата:

1. Логин в среде контейнеризации: oc login --token=<openshift_user_token> --server=<openshift_api_url>:<значение>
   

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 для шифрования файлов.
   

6. Выложить зашифрованный файл секрета в git 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] [-rootsber ROOTSBER]
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 (Kafka Application Journal), в порядке, указанном для ключей
-Keys KEYS массив ключей, в порядке, указанном для сертификатов для Kafka (Kafka Application Journal)
-OTT create cert for OTT
-OTTSecret create secret for OTT
-ottpem OTTPEM Ott pem from ott ZNO
-rootsber ROOTSBER root pem from ott ZNO

Создание секрета для компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD):

./cert_generate.py -OTTSecret -c CommonName -secretname secret-errm-ott-certs

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

Создание kafka-secret:

./cert_generate.py -server -req san.cnf -c <hostname> -OSKafkaSecret -secretname kafka-cert -r ../RootCa.cer -i ../intermediate.cer -Certs <hostname>/<hostname>,<hostname>/<hostname> -Keys APP_cert,AUTH_cert

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

./cert_generate.py -server -req san.cnf -c <hostname> -IngressSecret -secretname secret-ingressgateway-certs -r ../RootCa.cer -i ../intermediate.cer

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

Автоматизированной установки USSX не предусмотрено.

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

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

Все стендо-зависимые параметры (минимальная конфигурация) и параметры основных интеграций указываются в файле deploy/ansible/vars/varisbles.yaml. Полный список возможных параметров представлен ниже.

Файл .env

NAMESPACE: название namespace (пространства имен)
REGISTRY_URL: URL registry с docker-образами 

############################# Интеграция с компонентом Аудит (AUDT) продукта Platform V Audit SE (AUD) 
AUDIT2_PROXY_URL: целевой URL компонента Аудит (AUDT) продукта Platform V Audit SE (AUD)

############################# Интеграция с компонентом Прикладной Журнал (APLJ) продукта Platform V Backend (#BD)
KAFKA_PJ_PORT: порт Kafka Application Journal, обычно 9093
KAFKA_PJ_HOST_3: хост сервера №1 Kafka Application Journal 
KAFKA_PJ_HOST_2: хост сервера №2 Kafka Application Journal
KAFKA_PJ_HOST_1: хост сервера №3 Kafka Application Journal
KAFKA_PJ_HOST_4: хост сервера №4 Kafka Application Journal
KAFKA_PJ_HOST_5: хост сервера №5 Kafka Application Journal
KAFKA_PJ_HOST_6: хост сервера №6 Kafka Application Journal
KAFKA_PJ_IP_1: ip адрес сервера Kafka №1 Application Journal
KAFKA_PJ_IP_2: ip адрес сервера Kafka №2 Application Journal
KAFKA_PJ_IP_3: ip адрес сервера Kafka №3 Application Journal
KAFKA_PJ_IP_4: ip адрес сервера Kafka №4 Application Journal
KAFKA_PJ_IP_5: ip адрес сервера Kafka №5 Application Journal
KAFKA_PJ_IP_6: ip адрес сервера Kafka №6 Application Journal
KAFKA_PJ_BOOTSTRAP: список ip:порт всех серверов Kafka Application Journal через запятую
STANDIN_CLIENT_ZONEID: зона USS в Application Journal
STANDIN_CLIENT_REFRESH_STATE_PERIOD: частота обновления состояния в Application Journal в секундах, обычно 100
STANDIN_CLIENT_CONCURRENCY: количество потоков для репликации журналов, обычно 10
STANDIN_CLIENT_PRODUCER_SSL_KEYSTORE_LOCATION: путь к keystore с сертификатами для доступа producer'а к Kafka Application Journal, обычно /opt/certs/kafka/keystore.jks
STANDIN_CLIENT_PRODUCER_SSL_TRUSTSTORE_LOCATION: путь к truststore с сертификатами для доступа producer'а к Kafka Application Journal, обычно  /opt/certs/kafka/truststore.jks
STANDIN_CLIENT_PRODUCER_SSL_IDENTIFICATION_ALGORITHM: алгоритм идентификации producer'а в Kafka Application Journal, для автоматического выбора оставляется пустым
STANDIN_CLIENT_CONSUMER_SSL_KEYSTORE_LOCATION: путь к keystore с сертификатами для доступа consumer'а к Kafka Application Journal, обычно /opt/certs/kafka/keystore.jks
STANDIN_CLIENT_CONSUMER_SSL_TRUSTSTORE_LOCATION: путь к truststore с сертификатами для доступа consumer'а к Kafka Application Journal, обычно  /opt/certs/kafka/truststore.jks
STANDIN_CLIENT_CONSUMER_SSL_IDENTIFICATION_ALGORITHM: алгоритм идентификации consumer'а в Kafka Application Journal, для автоматического выбора оставляется пустым

###################################### ISTIO
PROXY_IMAGE: адрес образа istio proxyv2

############################# INGRESS
ISTIO_CONTROL_PLANE: адрес контрольной панели istio
INGRESSGATEWAY_NAME: название gateway на ingress'е, обычно dp-uss-app-ingress
INGRESSGATEWAY_ISTIO_LABEL: лейбл для сущностей ingress istio, обычно <название-namespace>-uss-<rb/kb>-ingress
INGRESSGATEWAY_APP_LABEL: лейбл для прикладных сущностей ingress, обычно <название-namespace>-uss-<rb/kb>-ingress
INGRESSGATEWAY_CERTS_SECRET_NAME: название серверных секретов для ingress gateway, обычно secret-ingressgateway-certs
INGRESSGATEWAY_CA_CERTS_SECRET_NAME: название секретов с УЦ для ingress gateway, обычно secret-ingressgateway-ca-certs
INGRESSGATEWAY_CERTS_MOUNT_PATH: путь к серверным секретам для ingress gateway, обычно /etc/istio/ingressgateway-certs
INGRESSGATEWAY_CA_CERTS_MOUNT_PATH: путь к секретам с УЦ для ingress gateway, обычно /etc/istio/ingressgateway-ca-certs

############################# EGRESS
EGRESSGATEWAY_NAME: название gateway на egress'е, обычно dp-uss-app-egress
EGRESSGATEWAY_ISTIO_LABEL: лейбл для сущностей egress istio, обычно <название-namespace>-uss-<rb/kb>-egress
EGRESSGATEWAY_APP_LABEL: лейбл для прикладных сущностей egress, обычно <название-namespace>-uss-<rb/kb>-egress
EGRESSGATEWAY_CERTS_SECRET_NAME: название серверных секретов для egress gateway, обычно  secret-ingressgateway-certs
EGRESSGATEWAY_CA_CERTS_SECRET_NAME: название секретов с УЦ для egress gateway, обычно secret-ingressgateway-ca-certs
EGRESSGATEWAY_CERTS_MOUNT_PATH: путь к серверным секретам для egress gateway, обычно /etc/istio/ingressgateway-certs
EGRESSGATEWAY_CA_CERTS_MOUNT_PATH: путь к секретам с УЦ для egress gateway, обычно /etc/istio/ingressgateway-ca-certs

###################################### Компонент One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD)
OTT_SERVICE_HOSTS: список хост:порт всех серверов OTTS через запятую
OTT_SERVICE_URL: основной адрес сервиса OTTS
OTT_CERTSTORE_PATH: путь к keystore с сертификатами для доступа к OTTS, обычно /mnt/secrets/error-processor-cloud.p12
OTT_TRUST_STORE_PATH: путь к truststore с сертификатами для доступа к OTTS, обычно /mnt/secrets/ott_service_truststore.p12
OTT_CLIENT_CERT_ALIAS: название сервиса в компоненте OTTS, обычно error-processor-cloud
OTT_SERVICE_SI_HOSTS: хост:порт standin компонента One-Time Password / One-Time-Token (OTTS) продукта Platform V Backend (#BD)
OTT_MODULE_ID: идентификатор модуля в компоненте OTTS, обычно error-processor-cloud
OTT_IMAGE: адрес образа ott-client-api-v2

###################################### Квота USS
USS_REPLICA_COUNT: количество реплик приложения, обычно 1
USS_CPU_LIMIT: количество ядер, выделяемых приложению из квоты, обычно 1
USS_MEM_LIMIT: количество оперативной памяти, выделяемых приложению из квоты, обычно 6000Mi
USS_CPU_REQ: максимальное количество ядер, выделяемых приложению из квоты, обычно 1
USS_MEM_REQ: максимальное количество оперативной памяти, выделяемых приложению из квоты, обычно 6000Mi
SERVER_PORT: порт, на котором поднято приложение внутри контейнера, 8080
USS_CPU_ISTIO_REQ: количество ядер, выделяемых istio sidecar из квоты, обычно 100m
USS_CPU_ISTIO_LIM: максимальное количество ядер, выделяемых istio sidecar из квоты, обычно 100m
USS_MEM_ISTIO_REQ: количество оперативной памяти, выделяемых istio sidecar из квоты, обычно 1000Mi
USS_MEM_ISTIO_LIM: максимальное количество оперативной памяти, выделяемых istio sidecar из квоты, обычно 1000Mi
USS_MEM_FB_LIMIT: количество оперативной памяти, выделяемых fluent-bit из квоты, обычно 32Mi
USS_MEM_FB_REQ: максимальное количество оперативной памяти, выделяемых fluent-bit из квоты, обычно 32Mi
USS_CPU_FB_REQ: количество ядер, выделяемых fluent-bit из квоты, обычно 200m
USS_CPU_FB_LIMIT: максимальное количество ядер, выделяемых fluent-bit из квоты, обычно 200m

############################# DATABASES
MASTER_DATABASE_IP: ip адрес основной БД
MASTER_DATABASE_PORT: порт основной БД
MASTER_DATABASE_HOST: хост основной БД
STANDIN_DATABASE_HOST: хост standin БД
STANDIN_DATABASE_PORT: порт standin БД
STANDIN_DATABASE_IP: ip адрес standin БД

###################################### Настройки USS-APP
SERVER_PORT: порт, на котором поднимется приложение внутри контейнера, 8080
POSTGRES_ENABLED: включение/выключение режима работы с PGSE Platform V
SUDIR_ENABLED: включение/выключение режима работы с компонентом IAM Proxy (AUTH) продукта Platform V IAM SE (IAM)
DATASOURCE_MAIN_CLASS: класс драйвера для основного datasource, для PGSE Platform V - org.postgresql.Driver
DATASOURCE_MAIN_URL: URL основной БД
INT_MASTER_DATABASE_PORT: порт основной БД
DATASOURCE_MAIN_USER: имя пользователя в основной БД
DATASOURCE_MAIN_MAXPOOLSIZE: максимальный размер пула соединений для основной бд, обычно 100
DATASOURCE_MAIN_MINPOOLSIZE: минимальный размер пула соединений для основной бд, обычно 60
DATASOURCE_STANDIN_CLASS: класс драйвера для standin datasource, для PGSE Platform V - org.postgresql.Driver
DATASOURCE_STANDIN_URL: URL standin БД
INT_STANDIN_DATABASE_PORT: порт standin БД
DATASOURCE_STANDIN_USER: имя пользователя в standin БД
DATASOURCE_STANDIN_MINPOOLSIZE: минимальный размер пула соединений для standin бд, обычно 60
DATASOURCE_STANDIN_MAXPOOLSIZE: максимальный размер пула соединений для standin бд, обычно 100
SPAS_SERVER_URL: адрес компонента Объединенный сервис авторизации (AUTZ) продукта Platform V IAM SE (IAM)
SPAS_MAX_CLIENT_POOL_SIZE: количество потоков для клиента OCA, обычно 10
SEND_MESSAGE_TO_JOURNAL_USS: включение/выключение репликации данных через Application Journal
STANDIN_CLIENT_USS_APP_ZONEID: зона USS в Application Journal
USS_SUDIR_ROUTE: название route для входа через компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM)
USS_SUDIR_GEO_ROUTE: название route с поддержкой георезервирования для входа через компонент IAM Proxy (AUTH) продукта Platform V IAM SE (IAM)
SPAS_HOSTNAME: хост сервиса OCA
SPAS_PORT: порт сервиса OCA
SPAS_IP: ip адрес сервиса OCA
SPAS_KEYSTORE_PKEY: путь к приватному ключу к keystore сервиса ОСА, обычно оставляется пустым
SPAS_KEYSTORE_CERT: путь к keystore сервиса ОСА, обычно оставляется пустым
SPAS_TRUSTED_CERT: путь к truststore сервиса ОСА, обычно оставляется пустым

############################## FLUENT
FLUENTBIT_IMAGE: адрес образа fluent-bit
LOGGER_HOST: хост сервиса Logger Platform V
LOGGER_PORT: порт сервиса Logger Platform V
STAND_VERSION: идентификатор стенда для Logger Platform V

############################## Дополнительные настройки
IGNITE_CLIENT_ENABLED: включение/выключение режима работы
SAME_DB_ENABLED: настройка топологии БД, должна быть всегда false
CONTOUR_ID: идентификатор контура
SUDIR_LOGOUT_URL: URL страницы логина сервера компонента IAM Proxy (AUTH) продукта Platform V IAM SE (IAM)
AUDIT_DEV_MODE: включение/выключение интеграции с компонентом Аудит (AUDT) продукта Platform V Audit SE (AUD)
STANDIN_CLOUD_CLIENT_STUB: включение/выключение интеграции с Application Journal

OTT_CERTSTORE_TYPE: тип keystore для компонента One-Time Password (OTP) / OTT (OTTS) продукта Platform V Backend (#BD), обычно PKCS12
AUDIT_CLIENT_CRT: имя файла сертификата для компонента Аудит (AUDT) продукта Platform V Audit SE (AUD), обычно tls.crt
AUDIT_CLIENT_KEY: имя файла приватного ключа сертификата для компонента Компонент Аудит (AUDT) продукта Platform V Audit SE (AUD), обычно tls.key
NOTIFICATIONS_ENABLED: включение/выключение отправки уведомлений
NOTIFICATIONS_KEYSTORE_PATH: путь к keystore с сертификатами почтового сервера, обычно /opt/certs/kafka/keystore.jks
NOTIFICATIONS_TRUSSTORE_PATH: путь к truststore с сертификатами почтового сервера, обычно /opt/certs/kafka/truststore.jks
NOTIFICATIONS_MAIL_USERNAME: логин в почтовом сервере
NOTIFICATIONS_MAIL_FROM: почтовый адрес, с которого будет осуществляться рассылка уведомлений по почте
NOTIFICATIONS_SMS_USERNAME: логин в сервисе SMS
NOTIFICATIONS_SMS_FROM: адрес, с которого будет осуществляться рассылка уведомлений по SMS
NOTIFICATIONS_SMS_TO: целевой адрес для рассылки уведомлений по SMS
NOTIFICATIONS_SMTPS_DEBUG_ENABLED: включение/выключение подробного логирования для отправки уведомлений
NOTIFICATIONS_SMTPS_HOST: адрес SMTP почтового сервера
NOTIFICATIONS_SMTPS_PORT: порт SMTP почтового сервера, обычно 587
NOTIFICATIONS_SMTPS_PORT_CM: внешний порт для отправки уведомлений, обычно 8443

CORRSCEN_PORT: целевой порт для вызова корректирующих сценариев, обычно 443
CORRSCEN_HOST_1: хост для вызова корректриующего сценария №1

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

Данный компонент предназначен для сбора прикладных и инфраструктурных метрик и отправки их в целевую систему хранения. С детальным описанием можно ознакомиться в документации к продукту Platform V Monitor (OPM).

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

Для интеграции с компонентом необходимо корректно заполнить enviroment файл стенда (см. документацию для компонента Журналирование (LOGA) продукта Platform V Monitor (OPM)). За настройки подключения к компоненту отвечают параметры:

• LOGGER_GW: – предпочитаемый хост logger;

• LOGGER_ENDP: — node балансировки;

• LOGGER_ENDP_2 — node балансировки;

• LOGGER_PORT: — порт logger (443);

• LOGGER_PROTO: — протокол HTTP/HTTPS (HTTPS).

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

Pipeline DevOps для развертывания проекта USSX в среду контейнеризации Kubernetes или Red Hat OpenShift

Запуск осуществляется в задании Jenkins типа pipeline, definition у которого выставлен как Jenkinsfile из данного репозитория. Данный Pipeline DevOps можно сразу настроить на все стенды среды контейнеризации Kubernetes или Red Hat OpenShift, для достижения универсальности созданных template.

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

Каждый стенд может иметь уникальный список секретов, например, пароли в БД. Внутри Git секреты сохранены в виде зашифрованных с помощью ansible-vault файлов. Является опциональным шагом, т.к. для минимальной конфигурации достаточно двух секретов (к основной и SI БД), указываемые в Jenkins, указываемые с ID секрета: MAIN_DB, STANDIN_DB.

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

Существует отдельный pipe, который на входе имеет четыре параметра:

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

• gitBranch – ветка репозитория, в которой находятся секреты;

• folder – папка, в которой находятся секреты;

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

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

Jenkinsfile

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

Сборка артефакта USSX через Jenkins

Внешний вид задания Jenkins (с примером заполнения):

Параметры:

• AGENT – Jenkins-агент для исполнения задания Jenkins;

• jdk – версия jdk;

• maven – версия maven;

• OWNED_DISTR_URL – ссылка на owned дистрибутив в Nexus-Public;

• PUBLISH_URL – ссылка на Nexus-Public репозиторий для загрузки дистрибутива;

• PARTY_DISTR_URL – ссылка на party дистрибутив в Nexus-Public;

• DOCKER_REGISTRY – Docker репозиторий;

• DOCKER_REGISTRY_PATH – путь к дистрибутиву в Docker репозитории;

• DOCKER_DIR – директория для хранения дистрибутива в Docker репозитории;

• MAVEN_XML – ID Maven Setting.xml файла в Jenkins;

• nexusSecrets – ID Nexus-Public секрета в Jenkins;

• baselmageJava – базовый Docker образ Java;

• VERSION – версия релиза;

• ARTIFACT_ID – ID артефакта;

• GROUP_ID – ID группы;

• REPOSITORY_ID – ID репозитория;

• MODULE – модуль для сборки;

• OPENSHIFT – среда контейнеризации (опционально).

Развертывание USSX через Jenkins

Внешний вид задания Jenkins (с примером заполнения):

Параметры:

• ARTIFACT_URL – ссылка на артефакт дистрибутива;

• NEXUS_SECRET – ID секрета для доступа в Nexus-Public;

• NAMESPACE – название пространства имен в k8s;

• REGISTRY_URL – ссылка на Docker registry;

• MAIN_INGRESS_HOST – основной хост Ingress;

• MAIN_DB_URL – строка подключения основной БД;

• STANDIN_DB_URL – строка подключения StandIn БД;

• K8S_HOST_API – адрес endpoint для доступа к API k8s;

• K8S_SECRET_ID – ID секрета с токеном для доступа к пространству имен;

• MODULE – модуль для установки;

• DELETE – очищение пространства имен перед установкой;

• LIQUIBASE_STAGE – обновление схемы БД;

• MAIN_DB_STAGE – обновление основной БД;

• STANDIN_DB_STAGE – обновление StandIn БД;

• CLEAR_CHECKSUMS – обнуление checksums Liquibase.

СУБД PSQL

Чтобы подготовить базу данных, необходимо:

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

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

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

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

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

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

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

-- на сервере создать папки для пространств
mkdir /mnt/uss_l
mkdir /mnt/uss_t

--в СУБД выполнять пользователем с правами db_admin (PSQL)

CREATE TABLESPACE uss_t
OWNER as_admin
LOCATION '/pgdata/11/';

CREATE TABLESPACE uss_l
OWNER as_admin
LOCATION '/pgdata/11/';

GRANT CREATE ON TABLESPACE uss_t TO as_admin;
GRANT CREATE ON TABLESPACE uss_l TO as_admin;

GRANT CREATE ON TABLESPACE uss_t TO "as_TUZ";
GRANT CREATE ON TABLESPACE uss_l TO "as_TUZ";

• Создать БД:

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

GRANT CREATE ON DATABASE uss TO as_admin;

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

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

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

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

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

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

Внимание! Настройка интеграции с остальными сервисами не требуется.

Обновление#

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

• Обновить БД скриптами, входящими в дистрибутив из каталога \DB\ (см. подробнее в разделе Обновление базы данных настоящего документа).

• Обновить ролевую модель в компоненте Объединенный сервис авторизации (ОСА) (AUTZ) продукта Platform V IAM SE (IAM) (опционально): \config\roleModel.xml. Обновление ролевой модели происходит путем загрузки файла roleModel.xml в компонент Объединенный сервис авторизации (ОСА) (AUTZ) продукта Platform V IAM SE (IAM) (опционально). Загрузка файла выполняется вручную администратором системы.

• Обновить модули uss и error-processor: \modules. Обновление модулей описано в разделе «Установка модуля uss» документа Руководство по установке.

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

Обновление базы данных#

Для обновления БД используется liquibase, запускающийся вручную (подробности в тексте ниже) либо преднастроенным шагом job-ы установки приложения.

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

1. Создан профиль с именем: TECHNO_PROFILE_PCIDSS;

2. Создана роль: OWNER_ROLE;

3. Созданы табличные пространства: USS_T, USS_I, USS_L.

4. При первой установке от имени администратора БД необходимо выполнить скрипты:

   • USS_Model_00_User.sql (только при первой установке);

   • USS_Model_01.sql (только при первой установке);

   • USS_Model_02.sql (только при первой установке).

5. При обновлении БД необходимо выполнить скрипты из директории Patches. Скрипты из данной директории являются идемпотентными. Но для удобства ниже приведена информация с привязкой скриптов к релизным версиям USSX.

Пример запуска liquibase:

1. Выполнить скрипты из файла USS_Model_00_User.sql (если на данной БД модуль никогда не разворачивался).

2. Выполнить команду (пример): java -jar liquibase.jar --classpath=ojdbc6.jar --driver=oracle.jdbc.OracleDriver --url=jdbc:oracle:thin:@00.000.000.00:0000:username --username=0000 --password=000 --changeLogFile=./liquibase/changelog.xml update/

3. Сообщение Liquibase Update Successful говорит об успешном накате скриптов.

Удаление#

Для удаления USSX необходимо удалить БД USSX и Docker Images USSX, развернутые в модулях USS и ERRM (в отдельных неймспейсах).

Удаление Docker Images выполняется стандартными механизмами Kubernetes или Red Hat OpenShift.

Удаление БД USSX выполняется либо через liquibase скриптами отката, входящего в дистрибутив, либо средствами БД. Подробнее скрипты liquibase описаны в разделе Обновление базы данных настоящего документа. Для полного удаления выполняются все скрипты отката.

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

В данный момент работоспособность компонентов определяется путем запроса на сервере приложения http://host/component-name/actuator/health, (это ссылка, по которой можно получить статус работы приложения). Где:

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

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

http://auth-api/actuator/health

http://app-api/actuator/health

http://inner-connector/actuator/health

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

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

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

После установки компонентов необходимо проверить отсутствие ошибок в системных журналах подов компонента в среде контейнеризации Kubernetes или Red Hat OpenShift и, в случае инсталляции в конфигурации с включенным компонентом Граничный прокси (IGEG) продукта Platform V Synapse Service Mesh (SSM) (является опциональным), проверить в системных журналах подов компонента Граничный прокси (IGEG) продукта Platform V Synapse Service Mesh (SSM) наличие HTTP-запросов со статусом отличным от 200.

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

Проверка работоспособности интеграций приведена в разделе Чек-лист валидации установки.

Откат#

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

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

2. При откате выполняется откат скриптов БД средствами liquidbase. Возможен откат БД средствами СУБД PostgreSQL, Pangolin (PSQL), Oracle Database.

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

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

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

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

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

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

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

Чек-лист валидации установки следующий:

1. Установлена среда контейнеризации Kubernetes или Red Hat OpenShift. Администратору доступны консоли OpenShift и namespace.

2. Установлена БД (PostgreSQL, Pangolin (PSQL), Oracle Database) и выполнена инициализация БД USSX. Администратор БД видит схему uss и таблицы, основная таблица ERRPRIFO.

3. Посредством liquibase должны быть обновлены основная и SI БД. Администратор БД в логах liquidbase видит, что скрипты БД отработали успешно.

4. Настроены DataSource USSDS для main и stand-in баз.

5. В среде контейнеризации Kubernetes или Red Hat OpenShift установлены модули USSX и ERRM. В консоли OpenShift в отдельных namespace (проектах) видит запущенные поды uss, eggrm, ingress, egress.

6. Настроено логирование для модулей USSX и ERRM. По умолчанию логирование настроено в файл средствами Red Hat OpenShift 4+. В консоли OpenShift можно посмотреть логи по каждому pod и sidecar.

7. Установлены и настроены компоненты Платформы.

   • Компоненты IGEG и OTTS не требуют отдельной настройки, разворачиваются в процессе deploy USSX. В консоли OpenShift в проектах USS и ERRM видны pods Ingress, Egress и sidecar OTTS.

   • Настроено ответвление на сервер USSX в компоненте авторизации СУДИР или компоненте AUTH (опционально). При выборе ссылки на UI USS запрашивается логин и пароль.

   • В компонент AUTZ 3g или AUTZ (опционально) загружена ролевая модель USSX. После этого в интерфейсе администратора сервиса авторизации доступно назначение пользователям ролей USSX.

   • Настроена интеграция с компонентом AUDT. В интерфейсе пользователя компонента AUDT видны события аудита USSX. Событиями аудита могут быть действия пользователя в UI USS и старт модулей USSX и ERRM.

   • Настроена интеграция с компонентом APLJ. В логах USSX нет ошибок отправки сообщений в APLJ и в интерфейсе администратора APLJ виден нормальный статус репликации из модулей USSX.

   • Настроена интеграция с компонентом MONA. В интерфейсе MONA видны метрики USSX.

8. При установке каждого программного продукта, указанного в разделе Платформенные зависимости настоящего документа, необходимо осуществлять проверку согласно разделу «Чек-лист валидации установки» документа «Руководство по установке» для соответствующего программного продукта.

При успешном выполнении всех вышеперечисленных пунктов можно приступать к использованию сервиса.

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

• DB_UPDATE – проверить, что применена последняя миграция скриптов из папки liquibase/scripts дистрибутива;

• OPENSHIFT_DEPLOY – проверить, что в проектной области среды контейнеризации Kubernetes или Red Hat OpenShift появились ConfigMaps, VirtualService, DeploymentConfig, Service, Route, ServiceEntry, Gateway, DestinationRule и создались POD;

• OPENSHIFT_INGRESS_EGRESS_DEPLOY – проверить, что в проектной области среды контейнеризации Kubernetes или Red Hat OpenShift, появились POD INGRESS и EGRESS.