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

В данном документе представлено руководство по установке Компонента Фасад НСИ (NSIС) продукта Platform V Dictionaries (SDT).

Назначение документа#

Настоящий документ представляет собой набор инструкций для установки компонента Фасад НСИ (NSIC) продукта Platform V Dictionaries (SDT).

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

установка при первом развертывании компонента NSIC на продуктивной или иной площадке;
обновление компонента NSIC на продуктивной или иной площадке.

Обозначения, сокращения, термины и определения приведены в документе Термины и определения.

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

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

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

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

Обязательность установки (Да/Нет) `*`	Наименование ПО и версия `**`	Описание
Да	Альт 8 СП 10.0 и выше или Platform V SberLinux OS Server (SLO) 8.7 и выше (Операционная система (INST)) или Platform V SberLinux OS Core (SLC) 37.0 и выше (Базовая ОС (CORE)) или Red Hat Enterprise Linux 3.10	Операционная система
Да	Platform V DropApp (K8S) 1.1 и выше (K8S Core (K8SC)) или Kubernetes 1.21.6 и выше или Red Hat OpenShift Container Platform 4.8.53 и выше	Среда контейнеризации
Да	Kubectl 1.21.0 и выше или OpenShift command-line interface (CLI) (версия, соответствующая версии OpenShift)	Командная строка (консольная утилита)
Да	Docker CE — любая актуальная версия	Средство контейнеризации
Да	Jenkins 2.361.4 и выше или Platform V DevOps Tools (DOT) 1.2 и выше (Deploy tools (CDJE))	Инструмент сборки, тестирования, развертывания контейнеризированных приложений
Да	OpenJDK 11 и выше или AdoptOpenJDK (или Adoptium) 11 и выше	Java-машина
Да	PostgreSQL 11.7 и выше или Platform V Pangolin SE (PSQ) 5.3.1 и выше (Pangolin (PSQL))	Система управления базами данных (СУБД)
Да	Яндекс.Браузер 19.10 и выше или Google Chrome любая — актуальная версия и выше или Safari — любая актуальная версия	Браузер
Нет	Secret Management System (SecMan) 1.7.0 и выше или HashiCorp Vault 1.15.4 и выше	Система создания, хранения и распространения secrets
Да	Nexus-Public 2.5.1 и выше или Nexus Repository Manager PRO — любая актуальная версия или Nexus Repository Manager OSS — Любая актуальная версия	Сервис централизованного хранения репозиториев артефактов (хранилище артефактов)
Да	GitLab CE 15.0 и выше или BitBucket 7.6	Сервис централизованного хранения репозиториев исходного кода
Да	Istio 1.12 и выше или Platform V Synapse Service Mesh (SSM) 2.10 и выше (Сервисный прокси (SVPX), Граничный прокси (IGEG))	Сервис интеграции и оркестрации микросервисов в облаке
Нет	Prometheus 2.22.2 и выше или Platform V Monitor (OPM) 4.1 и выше (Журналирование (LOGA), Объединенный мониторинг Unimon (MONA))	Система мониторинга
Нет	Platform V Backend (#BD) 4.3 и выше (One-Time Password (OTP) / OTT (OTTS))	Сервис для аутентификации и авторизации межсервисных взаимодействий
Нет	Platform V Backend (#BD) 4.3 и выше (Прикладной журнал (APLJ)	Сервис для обеспечения отказоустойчивости приложения на уровне базы данных
Да	Apache Maven 3.5.4 и выше	Инструмент управления проектом
Да	Liquibase — любая актуальная версия	Система для управления изменениями баз данных

Примечание

*

Да — ПО, необходимое для функционирования сервиса, без установки которого не гарантирована работоспособность.
Нет — ПО, необязательное для функционирования сервиса, установка которого не влияет на работоспособность основных функций.

** Минимальная версии программного обеспечения, на которой гарантируется работоспособность. Использование версий выше заявленной возможно до потери обратной совместимости.

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

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

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

Название модуля	ПО среды функционирования	Количество	CPU (кол-во ядер)	ОЗУ (ГБ)	Внутренние диски (ГБ)	Горизонтальное масштабирование
nsi-api	Kubernetes/DropApp (опционально Openshift)	2 pods	2	2	—	Да

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

Дистрибутив NSIC представляет собой zip-файл, опубликованный в хранилище. Дистрибутив содержит следующие архивы в формате .zip:

Архив с конфигурацией развертывания продукта (*-owned-distrib.zip);
Архив с open source зависимостями (*-party-distrib);
Архив с вендорскими зависимостями (*-vendor-distrib.zip);
Архив с документацией продукта (NSIC-doc-std-version-distrib-zip).

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

Подготовка и создание secrets. Настройка серверного сертификата#

Чтобы создать secret, выполните следующие действия:

Для каждого кластера создайте секреты, которые нужно поместить систему создания/хранения/распространения secrets (Secret Management System или Hashicorp Vault), либо в хранилище job:
- secret-nsi.unver;
- secret-nsi-ott-certs.unver;
- ingress-secret-nsi-istio-gateway-ca-certs.unver;
- ingress-secret-nsi-istio-gateway-certs.unver;
- egress-secret-nsi-istio-gateway-ca-certs.unver;
- egress-secret-nsi-istio-gateway-certs.unver;
- egress-secret-nsi-istio-kafka-certs.unver.
Зашифруйте secrets паролем с помощью job.
Сохраните secrets в зашифрованном виде в репозитории, в директории с secrets.

Чтобы создать secrets с сертификатами для nsi-ingress, выполните следующие действия:

Создайте файл конфигурации config.cfg.

 [ 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 = MYCOMPANY
commonName = *.apps.mycompanydomain

[ req_ext ]
subjectAltName = @alt_names

[alt_names]
DNS. 1 = *.apps.mycompanydomain
DNS. 2 = *.*.apps.mycompanydomain
DNS. 3 = *.apps.ocp.geo.mycompanydomain

Создайте заявку на сертификат. Выполните команду: openssl req -out envoy.csr -newkey rsa: 2048 -nodes -keyout envoy.key -config config.cfg.
Убедитесь, что в результате выполнения команды получены два файла:
- запрос на сертификат envoy.csr;
- приватный ключ envoy.key.
Создайте серверный сертификат, приложите envoy.csr. Результатом выполнения будут три файла:
- подписанный сертификат на хост NSIC envoy.cer;
- сертификат УЦ — Test Root CA 2.cer;
- chain — сертификат промежуточного УЦ.

Сконвертируйте сертификаты в нужные форматы, подставив параметры компании:

openssl x509 -inform DER -in MYCOMPANY\ Test\ Issuing\ CA\ 2 .cer -out root-ca-cert.pem
openssl x509 -inform DER -in Test\ Root\ CA\ 2 .cer -out issue-ca.pem
openssl x509 -inform DER -in envoy.cer -out envoy.crt

Получите общий сертификат УЦ путем склеивания из сертификата root- и chain-сертификата.

cat root-ca-cert.pem issue-ca.pem > root-ca.pem
Создайте envoy-secret для nsi-mmt-proxy. Ключ – dry-run не создает объектов в ОС, создайте его вручную, по содержимому из заданного командой файла.
oc create secret generic envoy-secret --from-file=root-ca.pem --from-file=envoy.crt --from-file=envoy.key --dry-run -o yaml > envoy-secret.yaml
Название Secret и файлов изменять нельзя, так как mmt-proxy ищет их по заранее определенному пути.
Для Ingress и Kafka Logger используйте те же сертификаты (либо при необходимости создайте отдельные, которые будут расположены по другому пути и иметь другое название).
Скопируйте root-ca.pem в СА.crt:
cp root-ca.pem CA.crt

Создайте еще два secrets:

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

Пароли к базе данных необходимо хранить в файле Secret-nsi.yaml вида:

kind: secret
apiVersion:v1
metadata:
name:secret-nsi.unver
stringData:
    jdbc.nsi_postgres.password: <пароль к основной БД, в открытом виде>,
    jdbc.nsi_postgres.user: <прикладной  пользователь основной БД, в открытом виде>,
    jdbc.nsi_si_postgres.password: <пароль к БД Stand-in, в открытом виде>,
    jdbc.nsi_si_postgres.user: <прикладной пользователь БД StandIn, в открытом виде>,
    nsi_si.ssl_key_password: <ключ SSL>
    nsi_si.ssl_keystore_password: <пароль keystore>
    nsi_si.ssl_truststore_password: <пароль truststore>
type: Opaque

Установка#

Автоматизированная установка сервиса NSIC производится с использованием Deploy Tools (CDJE).

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

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

Наличие у пользователя, производящего установку NSIC, возможности создания репозиториев в GitLab СЕ, Nexus Public и получения прав на чтение/запись, включая права на чтение/запись в ветке master.
Наличие ТУЗ для работы с репозиториями.
Должны быть созданы следующие pipeline репозитории GitLab СЕ в проектной области, например:
- pipeline — репозиторий с кодовой базой релизов pipeline (на каждый стенд свой репозиторий);
- common — репозиторий с глобальными (одинаковыми для всех компонентов в рамках одного стенда) переменными среды (на каждый стенд свой репозиторий).
- nsi с параметрами конфигурациями подсистемы Фасад НСИ.
Должны быть прописаны доступы в репозитории по протоколам SSH + HTTP на чтение/запись во все ветки, включая ветку master.
В Nexus Public должны быть размещены дистрибутивы разворачиваемых сервисов, к данным репозиториям должен быть доступ с правами на чтение для ТУЗ.
В Nexus Public должны быть созданы следующие репозитории, в которые загружены дистрибутивы всех компонентов pipeline (Installer.Base, Installer.Migration, Installer.Common) (К перечисленным в данном пункте репозиториям должен быть доступ с правами на чтение для ТУЗ):
- AS_EFS_Installer.Base — глобальные настройки и утилиты для pipeline;
- AS_EFS_Installer.Migration — дистрибутив утилиты миграции;
- AS_EFS_Installer.Common — базовый дистрибутив common. Это глобальные параметры по умолчанию для pipeline.
В GitLab СЕ должны быть созданы репозитории, в которые загружены дистрибутивы всех компонентов pipeline.

Подготовка инструментов развертывания

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

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

Используя Service job, выполните миграцию актуальных данных для репозиториев common и pipeline.

pipelineVersion=<версия дистрибутива релиза>
commonVersion=<номер версии>

Настройка параметров конфигурации в common-репозитории#

После завершения миграции:

Добавьте подсистему NSIC в репозиторий common.
Заполните environment.json в блоке ENVIR: main.

Пример:

{
  "main": {
    "credentials": {
      "SshKeyCreds": "git_ssh_tech",
      "UserPassCreds": "user_pass_tech",
      "ansible_vault_id": "encrypt_secret",
      "ansible_vault_id_ops": "encrypt_secret",
      "jenkinsQAkitCred": "85618fbf-6aac-4c69-be1d-d1fd1895d189",
      "openshiftOpsPasswordsCred": "encrypt_pass",
      "gatewayClientCer": "gateway_client_cer",
      "gatewayClientKey": "gateway_client_key",
      "gatewayClientKeystore": "gateway_client_keystore"
    },
    "ticketID": "true",
    "addMarker": "false",
    "iag": "true",
    "efsReleaseRepo": "",
    "platformVersions": [
      "<номер версии>"
    ],
    "openshiftCluster": "https://api.stands-vdc01.solution.mycompany:<номер порта>",
    "openshiftAppsDomain": "domain.mycompany.ru",
    "openshiftRegistry": "mycompany/public_efs/v2/efs",
    "openshiftInnerRegistry": "mycompany",
    "openshiftInnerRegistryCommonNamespace": "devopsefs",
    "openshiftInnerRegistryAlias": "mycompany",
    "openshiftUseSkopeo": "true",
    "openshiftOuterRegistryTLSVerify": "false",
    "openshiftInnerRegistryTLSVerify": "false",
    "openshiftWaitForDeploySeconds": "600",
    "openShiftNewPasswords": "true",
    "openshiftMultiClusters": "true",
    "openshiftNginx": "true",
    "openshiftDeploySteps": {
      "deployProtocol": "true",
      "archiveConfigs": "true",
      "deployConfigMaps": "true",
      "deployApps": "true",
      "deployJKS": "true",
      "deployHPA": "false",
      "deployServices": "true",
      "deployRoutes": "true",
      "deploySecrets": "true"
    },
    "oseProjectMapping": {
      "config": {
        "sector": "conf"
      }
    },
    "sector": "true",
    "sectorFilter": [
      "config"
    ],
    "cleanupPattern": "**/conf/config/parameters/*.conf **/conf/data/**/parameters/*.conf"
  }
}

{
  "main": {
    "credentials": {
      "SshKeyCreds": "git_ssh_tech",
      "UserPassCreds": "user_pass_tech",
      "ansible_vault_id": "encrypt_secret",
      "ansible_vault_id_ops": "encrypt_secret",
      "jenkinsQAkitCred": "85618fbf-6aac-4c69-be1d-d1fd1895d189",
      "openshiftOpsPasswordsCred": "encrypt_pass",
      "gatewayClientCer": "gateway_client_cer",
      "gatewayClientKey": "gateway_client_key",
      "gatewayClientKeystore": "gateway_client_keystore"
    },
    "ticketID": "true",
    "addMarker": "false",
    "iag": "true",
    "efsReleaseRepo": "",
    "platformVersions": [
      "<номер версии>"
    ],
    "openshiftCluster": "https://api.stands-vdc01.solution.mycompany:<номер порта>",
    "openshiftAppsDomain": "domain.mycompany.ru",
    "openshiftRegistry": "mycompany/public_efs/v2/efs",
    "openshiftInnerRegistry": "mycompany",
    "openshiftInnerRegistryCommonNamespace": "devopsefs",
    "openshiftInnerRegistryAlias": "mycompany",
    "openshiftUseSkopeo": "true",
    "openshiftOuterRegistryTLSVerify": "false",
    "openshiftInnerRegistryTLSVerify": "false",
    "openshiftWaitForDeploySeconds": "600",
    "openShiftNewPasswords": "true",
    "openshiftMultiClusters": "true",
    "openshiftNginx": "true",
    "openshiftDeploySteps": {
      "deployProtocol": "true",
      "archiveConfigs": "true",
      "deployConfigMaps": "true",
      "deployApps": "true",
      "deployJKS": "true",
      "deployHPA": "false",
      "deployServices": "true",
      "deployRoutes": "true",
      "deploySecrets": "true"
    },
    "oseProjectMapping": {
      "config": {
        "sector": "conf"
      }
    },
    "sector": "true",
    "sectorFilter": [
      "config"
    ],
    "cleanupPattern": "**/conf/config/parameters/*.conf **/conf/data/**/parameters/*.conf"
  }
}

Пример subsystem.json:

{
  "__default": {
    "classifier": "distrib",
    "groupId": "Nexus_PROD",
    "packaging": "zip",
    "strict": "false",
    "sqlReport": "false",
    "limit": 200,
    "deployType": "manual",
    "fpType": "p69",
    "openshiftProject": "",
    "at": {
      "groupId": "Nexus_PROD",
      "branch": "master",
      "classifier": "distrib",
      "packaging": "zip"
    },
    "at_ui": {
      "groupId": "Nexus_PROD",
      "branch": "master",
      "classifier": "distrib",
      "packaging": "zip"
    }
  },
  "NSI_API": {
    "app_name": [
      "nsi-api"
    ],
    "groupId": "mycompany_PROD.CI90000122",
    "artifactId": "CI90000134_nsif_cloud",
    "nexus_repo": "mycompany_PROD",
    "fpType": "bts",
    "fpi_name": "nsi-cloud",
    "versionFilter": "<номер версии>"
  }
}

При добавлении нового сектора в subsystem.json добавьте запись о нем в environment.json.

openshiftProjectName — название проекта;
openshiftSATokenCred — credentials из Jenkins (Secret text c содержанием токена сервисного аккаунта с правами развертывания).

Пример multiclusters.json

{
  "datacenters": {
    "<путь до директории>": {
      "openshiftCluster": "https://api.stands-vdc01.solution.mycompany:<номер порта>",
      "openshiftSATokenCred": "dev-nsif-vdc20-01",
      "openshiftProjectName": "<название проекта в среде контейнеризации>",
      "openshiftNewRoute": "dummyNewRoute",
      "openshiftControlPlane": "sbt-devpub-controlplanev20",
      "openshiftControlPlaneIstiodService": "istiod-basic-install",
      "openshiftRoutersFQDN": [
        "dummyIp"
      ]
    }
  }
}

Использование глобальных переменных#

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

В \_global.jdbc.conf следует внести адрес БД, в случае использования ссылки на глобальную переменную из соответствующего параметра в репозитории, например:

# адрес БД продукта
global.jdbc.nsi_postgres.url=jdbc:postgresql://хост:порт/имя_бд?prepareThreshold=0

В \_global.resources.conf следует внести конечные хосты, в случае использования ссылки на них из соответствующих параметров в репозитории, например:

# Хосты ingress Продукта
global.platform.ingress.route.https=mdc-01.nsi-dev.apps.mycompanydomain
global.platform.ingress.route.http=mdc-http-01.nsi-dev.apps.mycompanydomain
global.platform.ingress.gateway.https=ingress-gw-mdc-unver
global.platform.ingress.gateway.http=ingress-gw-mdc-unver
global.platform.sgw.route.core.host=mdc-http-test-01.mdc-dev.apps.mycompanydomain

# Хосты Продукта
global.platform.baseurl.nsi-apis=nsi-api-01.apps.mycompanydomain

# Контрольная панель Istio
global.multiClusters.openshiftControlPlane=имя_контрольной_панели_istio
global.multiClusters.openshiftControlPlaneIstiodService=имя_сервис_контрольной_панели_istio

В _global.resources.conf следует добавить имя проектной области NAMESPACE, а также опционально список серверов для logger Kafka FluentBit, если в репозитории в соответствующем параметре будет идти к глобальной переменной:

# список серверов логирования kafka fluent bit. Формат <хост_logger_kafka_1>:<ip_logger_kafka_1>:<порт_logger_kafka>:<протокол>:<внутренний_порт_logger_kafka_1>:<внутренний протокол>;<хост_logger_kafka_2>:<ip_logger_kafka_2>:<порт_logger_kafka_2>:<протокол>:<внутренний_порт_logger_kafka_2>:<внутренний протокол>
global.platform.loga.kafka.servers=kafka-logger-host1.mycompanydomain:10.0.0.1:9093:TCP:8100:TCP;kafka-logger-host2.mycompanydomain:10.0.0.2:9093:TCP:8100:TCP
# Namespace
NAMESPACE=<название_проектной_области_в_среде_контейнеризации>

В ssl.conf закомментируйте значения параметров ssl.ose.keyStore.mq.keyStoreFromFile и ssl.ose.keyStore.mq.CertAlias, связанных с сертификатами mq, т.к. на данный момент в приложении они не используются:

#ssl.ose.keyStore.mq.keyStoreFromFile=ansible/files/ssl/ukoflssl.jks
#ssl.ose.keyStore.mq.CertAlias=${ssl.ose.istio.keyStore.egress.certAlias}

В openshift.conf:

# Параметры ОТТ
# Указать true, если используется ОТТ, и false в противном случае
global.ott.ose_deploy=true

# Параметры Secret Management System (SecMan)
# Указывается true, если используется хранилище паролей и сертификатов Secret Management System (SecMan) вместо обычных secrets
secman.secman_injector=true

Задайте значения параметров, связанных с сертификатами Istio egress/ingress, а также ОТТ (если используется):

##########################
# Параметры egress/ingress (в примере используется один общий сертификат)
##########################
ssl.ose.istio.keyStore.ingress.CertAlias=ingress
ssl.ose.istio.keyStore.ingress.KeyStoreFromFile=ansible/files/ssl/ingress.jks
ssl.ose.istio.keyStore.egress.CertAlias=egress
ssl.ose.istio.keyStore.egress.KeyStoreFromFile=ansible/files/ssl/ingress.jks
ssl.ose.istio.keyStore.kafka.CertAlias=kafka
ssl.ose.istio.keyStore.kafka.KeyStoreFromFile=ansible/files/ssl/kafka.jks
ssl.ose.istio.keyStore.RootCertAlias=root
ssl.ose.istio.keyStore.ingress.password=ssl.ose.istio.keyStore.ingress.password
ssl.ose.istio.keyStore.egress.password=ssl.ose.istio.keyStore.egress.password
ssl.ose.istio.keyStore.kafka.password=ssl.ose.istio.keyStore.kafka.password
##########################
# Параметры One-Time Password (OTP) / OTT (OTTS)
##########################
ssl.ose.istio.keyStore.ott.KeyStoreFromFile=ansible/files/ssl/ott_store.jks
ssl.ose.istio.trustStore.ott.TrustStoreFromFile=ansible/files/ssl/ott_trust.jks
ssl.ose.istio.keyStore.ott.password=ssl.ose.istio.keyStore.ott.password
ssl.ose.istio.trustStore.ott.password=ssl.ose.istio.trustStore.ott.password

Перейдите к созданию secrets и последующих параметров, касающихся сервиса.

Образы#

В \_global.resources.conf внесите образы, пример:

# Образ Istio
global.multiClusters.openshiftEnvoyImage=mycompany/registry_redhat_io/openshift-service-mesh/proxyv2-rhel8@sha256:320f5bd35c208e00005c01ce0e83c8f05276119f273e9f881da950fdfff59a13

# образ для flient-bit-sidecar
nsi-cloud.fluentbit-sidecar.image.path={{ registry }}/sbt/ci90000078_loga/loga/fluent-bit@sha256:8aff3ee8fae98679af05ce93cc0264eb06db3efcaa30f4360f2762a964a731bb

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

В репозитории nsi должны содержаться все значения стендовых параметров приложения. Создайте в репозитории корневую папку с именем как в репозитории common. В ней создайте папку conf, куда сохраните файл versions.conf, содержащий строку вида:

scriptsVersion=#0052f42faa7

Примечание

Версии скриптов могут меняться.

Также в новой папке conf создайте вложенную папку /config/parameters. Сохраните в нее conf-файлы, аналогичные тем, которые содержатся в дистрибутиве в папке parameters, и задайте нужные значения.

nsi-cloud.all.conf

registry=mycompany/docker # адрес Docker Registry
registry_path=/xxx/yyy_nsif_cloud  # относительный путь к образам в Docker Registry начиная с /, без учета имени образа nsi-api и папки nsi-cloud

# Параметры Deployment
nsi-cloud.configmap.db.url=<jdbc url> # адрес основной БД, например jdbc:postgresql://хост_БД:порт_БД/имя_БД?prepareThreshold=0
nsi-cloud.configmap.db.schema=<database> # название схемы основной БД
nsi-cloud.configmap.db.user=<jdbc main user> # адрес основной БД, например jdbc:postgresql://хост_БД:порт_БД/имя_БД?prepareThreshold=0
nsi-cloud.configmap.db_si.url=<jdbc url si> # адрес БД Stand-In, например jdbc:postgresql://хост_БД:порт_БД/имя_БД?prepareThreshold=0
nsi-cloud.configmap.db_si.user=<jdbc user> # пользователь БД
nsi-cloud.configmap.db_si.schema=<database standin schema> # название схемы БД Standin
nsi-cloud.configmap.db.hiber_fail_fetch_pagination='false' # raises an exception when in-memory pagination over collection fetch is about to be performed

# FluentBit
nsi-cloud.fluent-bit-forwarder-sidecar.deployment.image=sbt/ci90000078_loga/loga/fluent-bit@sha256:8aff3ee8fae98679af05ce93cc0264eb06db3efcaa30f4360f2762a964a731bb # относительный путь к образу fluent bit в вышеуказанном registry

nsi-cloud.configmap.fluentbit.kafka_loga.bootstrap_servers=<хост1>:9093,<хост2>:9093,<хост3>:9093 # Адрес серверов логгера Kafka LOGA
nsi-cloud.configmap.fluentbit.kafka_loga.topic=<имя топика> # Название топика logger Kafka LOGA
nsi-cloud.configmap.fluentbit.kafka_loga.protocol=PLAINTEXT # Протокол передачи данных из приложения (SSL или PLAINTEXT)

# Параметры для создания шаблона фильтра (значения не меняются)
nsi-cloud.configmap.fluentbit.filter.namespace={namespace}
nsi-cloud.configmap.fluentbit.filter.service={service}
nsi-cloud.configmap.fluentbit.filter.pod={pod}
nsi-cloud.configmap.fluentbit.filter.moduleId={moduleId}
nsi-cloud.configmap.fluentbit.filter.moduleVersion={moduleVersion}
nsi-cloud.configmap.fluentbit.filter.nodeId={nodeId}
nsi-cloud.configmap.fluentbit.filter.zoneId={zoneId}

# Пути к secrets Kafka для logger FluentBit в Secman. (Если он не используется, можно задать пустое значение)
nsi-cloud.common.fluentbit.secman.kafka_ca_cert_path=<Путь к secret SecMan для Kafka>
nsi-cloud.common.fluentbit.secman.kafka_cert_path=<Путь к secret SecMan для Kafka>
nsi-cloud-api.deployment.spec.replicas=1 # Кол-во pods для развертывания
nsi-cloud-api.deployment.metadata.annotations.sidecar.istio.io.inject='true' # Флаг использования istio-proxy в приложении nsi-api

# Лимиты CPU и памяти
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.resources.limits.cpu=2 # Лимит количества CPU на sidecar nsi-cloud-api
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.resources.limits.memory=4Gi # Лимит количества памяти на sidecar FLUENT BIT
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.resources.requests.cpu=2 # # Выделяемое sidecar istio количество CPU
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.resources.requests.memory=4Gi # Выделяемое sidecar FLUENT BIT количество памяти
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.livenessProbe.failureThreshold=15 # Количество попыток выполнения неуспешных проб до перезагрузки экземпляра исполняемого компонента

# NSI istio sidecar
nsi-cloud-api.deployment.metadata.annotations.sidecar.istio.io.proxyCPU=440m # Выделяемое sidecar istio количество CPU
nsi-cloud-api.deployment.metadata.annotations.sidecar.istio.io.proxyCPULimit=440m # Лимит количества CPU на sidecar с istio
nsi-cloud-api.deployment.metadata.annotations.sidecar.istio.io.proxyMemory=500Mi # Выделяемое sidecar istio количество памяти
nsi-cloud-api.deployment.metadata.annotations.sidecar.istio.io.proxyMemoryLimit=500Mi # Лимит количества памяти на sidecar с istio

nsi-cloud-api.configmap.si.kafka.bootstrap_server=<хост1>:9092,<хост2>:9092,<хост3>:9092 # Адрес сервера Kafka APLJ

nsi-cloud-api.configmap.si.zone_id=NSI-ZONE # Сущность APLJ (STANDIN), по которым переключаются БД
nsi-cloud-api.configmap.si.stub_mode='true' # Режим заглушки APLJ (true/false)
nsi-cloud-api.configmap.si.kafka.keystore=''# Хранилище приватных сертификатов для Kafka APLJ
nsi-cloud-api.configmap.si.kafka.truststore='' # Хранилище доверенных сертификатов для Kafka APLJ
nsi-cloud-api.configmap.si.security_protocol='' # Протокол взаимодействия с Stand-In

nsi-cloud-api.configmap.nsi_java_opts="-XX:MaxRAMPercentage=75.0 -XX:+AlwaysActAsServerClassMachine" # Параметры запуска JVM — Процент использования максимального размера heap для JVM / Параметр, указывающий запуск приложения как server
nsi-cloud-api.configmap.max_http_header_size=32KB # Максимальный допустимый размер HTTP-заголовка

# NSI SecMan sidecar
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.agent.inject='true' # Добавить sidecar с SecMan
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.agent-limits-cpu=100m # Лимит количества CPU на sidecar с SecMan
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.agent-limits-mem=128Mi # Лимит количества памяти на sidecar с SecMan
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.agent-requests-cpu=50m # Выделяемое sidecar SecMan количество CPU
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.agent-requests-mem=64Mi # Выделяемое sidecar Secman количество памяти
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.role=<Имя роли доступа к SecMan>
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.namespace=<Имя тенанта SecMan>
nsi-cloud-api.deployment.metadata.annotations.sidecar.secman.path=<Путь к хранилищу KV в SecMan>
nsi-cloud-api.deployment.spec.template.spec.containers.fluent-bit-forwarder-sidecar.resources.requests.cpu=250m # Выделяемое sidecar FLUENT BIT количество CPU
nsi-cloud-api.deployment.spec.template.spec.containers.fluent-bit-forwarder-sidecar.resources.limits.cpu=250m # Лимит количества CPU на sidecar FLUENT BIT
nsi-cloud-api.deployment.spec.template.spec.containers.fluent-bit-forwarder-sidecar.resources.requests.memory=260Mi # Выделяемое sidecar FLUENT BIT количество памяти
nsi-cloud-api.deployment.spec.template.spec.containers.fluent-bit-forwarder-sidecar.resources.limits.memory=260Mi # Лимит количества памяти на sidecar FLUENT BIT

nsi-cloud.common.fluentbit.secman.pki_engine.enabled=true
nsi-cloud.common.fluentbit.secman.pki_engine.fetch.role={stand_name}_{domain}/PKI/issue/role-ga-secman-nsix
nsi-cloud.common.fluentbit.secman.pki_engine.commonname=*.apps.mycompanydomain
nsi-cloud.common.fluentbit.secman.pki_engine.ttl=36000000

nsi-cloud.vault.uri=https://secman.solution.mycompany:8443 # URI для подключения к SecMan
nsi-cloud.kafka.ssl.enabled=true # Если требуется подключение fluent-controller к vault host по SSL
nsi-cloud.vault.client.method.namespace=DEV_DZO # Namespace в SecMan, в котором хранятся секреты fluent-bit
nsi-cloud.vault.client.method.authentication=kubernetes
nsi-cloud.vault.client.method.config.role=role-ga-secman-nsic # Роль для авторизации в SecMan, в котором хранятся секреты fluent-bit
nsi-cloud.vault.client.method.mount_path=os/mycompanydomain # Путь для авторизации в SecMan, в котором хранятся секреты fluent-bit (перед `/` указывается OS для среды контейнеризации, например - dropapp/stands.mycompany)
nsi-cloud.kafka.sslcert=$__vault{kv:имя_тенанта/путь_к_secret_егресса:istio-egressgateway-certs:tls.crt}
nsi-cloud.kafka.sslkey=$__vault{kv:имя_тенанта/путь_к_secret_егресса:istio-egressgateway-certs:tls.key}

nsi-cloud.fluentbit.sidecar.all.conf

# Аргументы запуска приложения через jvm переменную JAVA_OPTS
nsi-cloud.fluentbit-sidecar.configmap.javaArguments=-XX:+UseContainerSupport -Xmx50m

# Параметры fluent-controller

# Включить для fluent-bit SSL хранилище сертификатов и доступ к SecMan
nsi-cloud.fluentbit-sidecar.conf.vault.enabled=false

# Перечитать конфигурацию fluent-bit
nsi-cloud.fluentbit-sidecar.conf.reload.enabled=true

# Использовать механизм SecMan Hotreload
nsi-cloud.fluentbit-sidecar.vault.reload.enabled=true

nsi-cloud.istio.all.conf

nsi-cloud.istio.control_panel=<имя контрольной панели>
nsi-cloud.istio.proxy_image=registry.redhat.io/openshift-service-mesh/proxyv2-rhel8@sha256:03ba7a4bed6122c842ac0aeca626be7e6f3ec2106acee2ffda017c8cbf36e41b # Ссылка на образ Istio Proxy

#ISTIO
# имена secrets и пути к сертификатам
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.volumes.ingressgateway-certs.secret.secret_name=istio-ingressgateway-certs
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.volumes.ingressgateway-ca-certs.secret.secret_name=istio-ingressgateway-ca-certs
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.volumeMounts.ingressgateway-certs.mountPath=/etc/istio/ingressgateway-certs
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.volumeMounts.ingressgateway-ca-certs.mountPath=/etc/istio/ingressgateway-ca-certs
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.volumes.egressgateway-certs.secret.secret_name=egressgateway-certs
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.volumes.egressgateway-ca-certs.secret.secret_name=egressgateway-ca-certs
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.volumeMounts.egressgateway-certs.mountPath=/etc/istio/egressgateway-certs
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.volumeMounts.egressgateway-ca-certs.mountPath=/etc/istio/egressgateway-ca-certs

# имя secret Kafka в случае, если SecMan не используется
nsi-cloud.common.fluentbit.kafka_certs.secret_name=secret-nsi-kafka-certs.unver

# путь к сертификатам logger Kafka в pod
nsi-cloud.common.fluentbit.kafka_certs.mount_path=/etc/istio/kafka-certs

#HOSTS
# Имя хоста приложения
nsi-cloud.istio.ingress.common.host.nsi_api_host=nsi-dev-01.apps.mycompanydomain

# Имена хостов гео-routs через:
nsi-cloud.istio.ingress.common.host.nsi_api_geo_hosts=nsi-dev-geo01.dev-apps.ocp-geo.mycompanydomain;nsi-dev-geo02.dev-apps.ocp-geo.mycompanydomain;nsi-dev-geo03.dev-apps.ocp-geo.mycompanydomain;nsi-dev-geo04.dev-apps.ocp-geo.mycompanydomain;nsi-dev-geo05.dev-apps.ocp-geo.mycompanydomain

#PODS
nsi_cloud.istio.ingress.deployment.spec.replicas=1
nsi_cloud.istio.egress.deployment.spec.replicas=1
nsi_cloud.istio.egress_logger.deployment.spec.replicas=1
nsi-cloud.istio.egress.nsi_ef.spec.configPatches.patch.envoy.ext_authz.config.timeout=5s
nsi-cloud.istio.egress_logger.nsi_ef.spec.configPatches.patch.envoy.ext_authz.config.timeout=8s
nsi-cloud.istio.ingress.nsi_ef.spec.configPatches.patch.envoy.ext_authz.config.timeout=5s
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.readinessProbe.failureThreshold=5
nsi-cloud-api.deployment.spec.template.spec.containers.nsi-cloud-api.livenessProbe.failureThreshold=15

#LIMITS
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.resources.limits.cpu=400m
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.resources.limits.memory=512Mi
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.resources.requests.cpu=200m
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.istio-proxy.resources.requests.memory=256Mi
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.istio-proxy.resources.limits.cpu=400m
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.istio-proxy.resources.limits.memory=512Mi
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.istio-proxy.resources.requests.cpu=200m
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.istio-proxy.resources.requests.memory=256Mi
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.resources.limits.cpu=600m
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.resources.limits.memory=900Mi
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.resources.requests.cpu=400m
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.istio-proxy.resources.requests.memory=700Mi
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.ott.resources.limits.cpu=700m
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.ott.resources.limits.memory=900Mi
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.ott.resources.requests.cpu=500m
nsi-cloud.istio.egress.deployment.spec.template.spec.containers.ott.resources.requests.memory=700Mi
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.ott.resources.limits.cpu=700m
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.ott.resources.limits.memory=900Mi
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.ott.resources.requests.cpu=500m
nsi-cloud.istio.egress_logger.deployment.spec.template.spec.containers.ott.resources.requests.memory=700Mi
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.ott.resources.limits.cpu=700m
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.ott.resources.limits.memory=900Mi
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.ott.resources.requests.cpu=500m
nsi-cloud.istio.ingress.deployment.spec.template.spec.containers.ott.resources.requests.memory=700Mi
nsi-cloud.istio.common.ca_addr_discovery=istiod-common-install.sbt-devpub-controlplanev20.svc:15012
nsi-cloud.istio.configmap.discoveryAddress=istiod-common-install.sbt-devpub-controlplanev20.svc:15012

#DB
nsi-cloud.istio.egress.common.db1.ip=<ip_основной_БД>
nsi-cloud.istio.egress.common.db1.port=<порт_основной_БД>
nsi-cloud.istio.egress.common.db2.ip=<ip_резервной_БД>
nsi-cloud.istio.egress.common.db2.port=<порт_резервной_БД>
nsi-cloud.istio.egress.common.db_si1.ip=<ip_основной_БД_Standin>
nsi-cloud.istio.egress.common.db_si1.port=<порт_основной_БД_Standin>
nsi-cloud.istio.egress.common.db_si2.ip=<ip_резервной_БД_Standin>
nsi-cloud.istio.egress.common.db_si2.port=<порт_резервной_БД_Standin>

#OTT
nsi-cloud.istio.ott.deployment.ott_image=sbt/ci90000059_ottsc/otts/ott-sidecar:4.3.1-148 # относительный путь к образу отт в registry из all-файла
nsi-cloud.istio.ott.configmap.ott_service_url=http://<имя хоста OTT>:<порт OTT>/ott-service/rest/token # путь к сервису OTT
nsi-cloud.istio.ott.common.ott_hosts=["<имя хоста OTT>"]
nsi-cloud.istio.ott.configmap.ott_service_hosts=<имя хоста OTT>:<порт OTT>
nsi-cloud.istio.ott.common.ott_port=<порт OTT>

nsi-cloud.istio.ott.configmap.ott_certstore_type=PEM # тип сертификата OTT, PEM или PCKS12, рекомендуется использовать PEM
nsi-cloud.istio.ott.configmap.ott_service_crt=/mnt/secrets/ott-service.crt.pem # путь к серверному сертификату OTT в pod
nsi-cloud.istio.ott.configmap.ott_service_tls_crt=/mnt/secrets/root_ca.crt.pem # путь к корневому сертификату OTT в pod
nsi-cloud.istio.ott.configmap.ott_client_crt=/mnt/secrets/nsi-cloud.crt.pem # путь к клиентскому сертификату OTT в pod
nsi-cloud.istio.ott.configmap.ott_client_private_key=/mnt/secrets/nsi-cloud.key.pem # путь к файлу ключа клиентского сертификата OTT в pod

nsi-cloud.istio.ott.configmap.ott_anonymous_requests_enabled='true' # флаг разрешения анонимных запросов к OTT без авторизации

# FluentBit
nsi-cloud.istio.egress.common.fluent_bit.host=<имя хоста fluent bit>
nsi-cloud.istio.egress.common.fluent_bit.port=443 # порт fluent bit
nsi-cloud.istio.egress.common.fluentbit.kafka_loga.port=9093 # порт fluent bit logger

# список серверов Kafka logger fluent bit. Формат <хост_logger_kafka_1>:<ip_logger_kafka_1>:<порт_logger_kafka>:<протокол>:<внутренний_порт_logger_kafka_1>:<внутренний протокол>;<хост_logger_kafka_N>:<ip_logger_kafka_N>:<порт_logger_kafka_N>:<протокол>:<внутренний_порт_logger_kafka_N>:<внутренний протокол>
nsi-cloud.istio.egress.common.fluentbit.kafka.bootservers=${global.platform.loga.kafka.servers}
nsi-cloud.istio.egress.common.fluentbit.kafka_loga.bootservers=kafka-logger-host1.mycompanydomain:10.0.0.1:9093:TCP:8100:TCP;kafka-logger-host2.mycompanydomain:10.0.0.2:9093:TCP:8100:TCP
nsi-cloud.istio.egress.common.kafka_standin.hosts=["host1.mycompanydomain","host2.mycompanydomain"] # хосты Stand-In
nsi-cloud.istio.egress.common.kafka_standin.port=9092 #порт Kafka Stand-In

# список серверов Kafka APLJ. Формат <хост_aplj_kafka_1>:<ip_aplj_kafka_1>:<порт_aplj_kafka>:<протокол>:<внутренний_порт_aplj_kafka_1>;<хост_aplj_kafka_N>:<ip_logger_kafka_N>:<порт_logger_kafka_N>:<протокол>:<внутренний_порт_logger_kafka_N>
nsi-cloud.istio.egress.common.kafka.pj.bootservers=kafka-pj-host1.mycompanydomain:20.0.0.1:9092:TCP:9343;kafka-pj-host2.mycompanydomain:20.0.0.2:9344
nsi-cloud.istio.kubeapi.se.spec.addresses=<ip-адрес>
nsi-cloud.istio.egress.vs.spec.http.timeout=5s
nsi-cloud.istio.egress.vs.spec.http.retries.attempts=2
nsi-cloud.istio.egress.vs.spec.http.retries.timeout=2s
nsi-cloud.istio.egress_logger.vs.spec.http.timeout=5s
nsi-cloud.istio.egress_logger.vs.spec.http.retries.attempts=2
nsi-cloud.istio.egress_logger.vs.spec.http.retries.timeout=2s
nsi-cloud.istio.ingress.route.haproxy.router.openshift.io.timeout=120s

# SecMan
nsi-cloud.istio.egress.se.secman.spec.hosts=secman.mycompanydomain #хост SecMan
nsi-cloud.istio.egress.se.secman.spec.ports.https=8443 #порт SecMan

# Secman ingress
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.agent.inject='true' # Добавить sidecer с SecMan
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.agent-limits-cpu=100m # Лимит количества CPU на sidecar с SecMan
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.agent-limits-mem=128Mi # Лимит количества памяти на sidecar с SecMan
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.agent-requests-cpu=50m # Выделяемое sidecar SecMan количество CPU
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.agent-requests-mem=64Mi # Выделяемое sidecar SecMan количество памяти
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.role=<Имя роли доступа к SecMan>
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.namespace=<Имя тенанта SecMan>
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.path=<Путь к хранилищу KV в SecMan>

# Secman egress
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.agent.inject='true' # Добавить sidecer с SecMan
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.agent-limits-cpu=100m # Лимит количества CPU на sidecer с SecMan
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.agent-limits-mem=128Mi # Лимит количества памяти на sidecer с SecMan
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.agent-requests-cpu=50m # Выделяемое sidecer SecMan количество CPU
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.agent-requests-mem=64Mi # Выделяемое sidecer SecMan количество памяти
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.role=<Имя роли доступа к SecMan>
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.namespace=<Имя тенанта SecMan>
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.path=<Путь к хранилищу KV в SecMan>
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.agent.inject='true' # Добавить sidecer с SecMan
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.agent-limits-cpu=100m # Лимит количества CPU на sidecer с SecMan
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.agent-limits-mem=128Mi # Лимит количества памяти на sidecer с SecMan
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.agent-requests-cpu=50m # Выделяемое sidecer SecMan количество CPU
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.agent-requests-mem=64Mi # Выделяемое sidecer SecMan количество памяти
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.role=<Имя роли доступа к SecMan>
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.namespace=<Имя тенанта SecMan>
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.path=<Путь к хранилищу KV в SecMan>

# Secmman PKI
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.pki_engine.enabled='true' # Включение PKI-движка для Egress
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.pki_engine.fetch.role=<Имя тенанта SecMan>/PKI/issue/<Имя роли доступа к SecMan>
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.pki_engine.commonname=*.apps.mycompanydomain
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.pki_engine.fluentbit.commonname='*.apps.mycompanydomain'
nsi-cloud.istio.egress.deployment.metadata.annotations.sidecar.secman.pki_engine.ttl=36000000

nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.pki_engine.enabled='true' # Включение PKI-движка для Egress logger fluent-bit
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.pki_engine.fetch.role=<Имя тенанта SecMan>/PKI/issue/<Имя роли доступа к SecMan>
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.pki_engine.commonname=*.apps.mycompanydomain
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.pki_engine.fluentbit.commonname='*.apps.mycompanydomain'
nsi-cloud.istio.egress_logger.deployment.metadata.annotations.sidecar.secman.pki_engine.ttl=36000000

nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.pki_engine.enabled='true' # Включение PKI-движка для Ingress
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.pki_engine.fetch.role=<Имя тенанта SecMan>/PKI/issue/<Имя роли доступа к SecMan>
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.pki_engine.commonname=*.apps.mycompanydomain
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.pki_engine.fluentbit.commonname='*.apps.mycompanydomain'
nsi-cloud.istio.ingress.deployment.metadata.annotations.sidecar.secman.pki_engine.ttl=36000000

Кроме того, в папке /conf в репозитории необходимо создать либо смигрировать файл custom_property.conf.yml, в котором также указать параметры:

dbType: postgresql_1
logger_name: loga # Указывавется LOGA если планируется использовать logger Kafka LOGA, и любое другое значение, если нет
service_mesh_type: synapse3 # Тип SSM контрольной панели. Указывается synapse3, если используется контрольная панель с SSM версии Synapse 3.x, и другое значение в противном случае
securityContext_k8s: "false" # Тип SecurityContext для развертывания. Указывается "false" если используется Openshift, и "true" если чистый Kubernetes/DropApp
kind_route_deploy: "true" # Тип route. указывается "true" если требуется развертывать тип routs = Route вместо Ingress (Route совместим только с Openshift), и "false" если развертывать Ingress
secman_kv2: "false" "Версия KV-хранилища в SecMan. Указывается "true" если в SecMan используются хранилища типа KV-V2, по умолчанию "false"
apiVersion_vs: alpha3
apiVersion_gw: alpha3
apiVersion_se: alpha3
apiVersion_dr: alpha3

Настройка ключевых интеграций#

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

Настройка интеграции с PSQL (или PostgreSQL) производится в процессе Подготовки окружения, приведенной в настоящем документе.

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

Secret Management System (SecMan) — это инструмент, обеспечивающие безопасный способ хранения и распространения secrets, базируется на хранилище secrets Hashicorp Vault.

Secrets считаются:

логин и пароль доступа к БД;
сертификаты и ключи к ним;
доверенные цепочки сертификатов;
хранилища и пароли к ним.

SecMan предоставляет средства создания, отзыва (удаления) и ротации секретов, а также обеспечивает безопасную доставку secrets на ресурсы NSIC в процессе его функционирования без необходимости прерывания NSIC. Одними из основных компонентов SecMan являются движки secrets различных типов — компоненты, которые хранят, генерируют или шифруют данные. Некоторые движки secrets просто хранят и считывают данные, другие — подключаются к прочим сервисам и генерируют динамические учетные данные по требованию.

Для хранения secrets компонента NSIC рекомендуется использовать движок секретов kv — универсальное хранилище ключ-значение, используемое для хранения произвольных secrets в сконфигурированном физическом хранилище. Для интеграции NSIC с SecMan используются приложения vault-agent, которые размещаются в каждом из pods NSIC.

Чтобы установить SecMan в качестве места хранения secrets NSIC, необходимо в конфигурационном файле all.conf.yml дистрибутива конфигурации развертывания для параметра secman.secman_injector задать значение «true». Все secrets внутри контейнера будут находиться по пути /vault/secrets.

Все необходимые параметры для настройки интеграции с SecMan приведены в разделе Настройка параметров конфигурации

В качестве инструмента для управления secrets также может быть использован HashiCorp Vault. Настройка осуществляется аналогично.

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

В части аутентификации и авторизации межсервисных взаимодействий NSIC может быть интегрирован с компонентом One-Time Password/Token (OTTS). Для включения информационного обмена с OTTS в файле openShift.conf репозитория Сommon параметр global.ott.ose_deploy должен быть установлен в true.

OTTS предоставляет средства для удостоверения субъекта доступа и разграничения доступа к API NSIC на транспортном уровне, а также контроля целостности получаемого сообщения. Согласно требованиям безопасности, с помощью OTTS необходимо защищать взаимодействия, выходящие за границы пространства имен (namespace).

Для интеграции с OTTS используются sidecar-приложения ott-sidecar, которые размещаются в pods шлюзов Ingress и Egress NSIC.

Примечание

Взаимодействие с OTTS должно осуществляться с использованием шифрованного протокола обмена. Если для выпуска сертификатов предполагается использование PKI движка секретов SecMan, то в файле \conf\custom_property.conf.yml дистрибутива конфигурации развертывания NSIC параметр ott_cert_from_pki_enable должен быть установлен в true. Если же не предполагается выпуск сертификатов средствами SecMan, то параметр ott_cert_from_pki_enable должен быть установлен в false.

Параметры интеграции с OTTS устанавливаются путем определения их значений в файлах дистрибутива конфигурации развертывания NSIC. Все параметры приведены в разделе Настройка параметров конфигурации настоящего документа.

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

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

Определить глобальные переменные для стенда:

global.platform.aplj.kafka.security.protocol
global.platform.aplj.kafka.bootstrap.servers.mesh — список хостов и портов вида host1:mesh_port,host2:mesh_port,host3:mesh_port

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

ConfigMap	Параметры
ufs-policy-manager-config-cm	security.replication.aplj.policy.dataType = TYPE_POLICY
	security.replication.aplj.policy.plugin = PLGN_POLICY
ufs-security-manager-config-cm	security.replication.aplj.securityManager.dataType = TYPE_SEC_MAN
	security.replication.aplj.securityManager.plugin = PLGN_SEC_MAN
ufs-security-config-cm	security.replication.aplj.security.dataType = TYPE_SEC
	security.replication.aplj.security.plugin = PLGN_SEC

В компоненте APLJ создать зону REPLICATION и добавьте в нее:

Тип данных	Плагин
TYPE_SEC	PLGN_SEC
TYPE_POLICY	PLGN_POLICY
TYPE_SEC_MAN	PLGN_SEC_MAN

Параметры для настройки интеграции с APLJ приведены в разделе Настройка параметров конфигурации настоящего документа.

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

В части сбора и хранения данных о производительности, доступности и работоспособности NSIC может быть интегрирован с MONA. MONA обеспечивает сбор прикладных, инфраструктурных метрик и метрик по стандарту мониторинга Prometheus. В процессе сбора MONA обогащает метрики дополнительными служебными данными и сохраняет их в свое (локальное) хранилище.

Для интеграции с MONA — NSIC выставляет HTTP-endpoint c метриками по стандарту Prometheus. Файлы \conf\openshift.…\svc.yaml содержат аннотации и метки Prometheus для служб прикладных pods. Дополнительно в файлах \conf\openshift.…\svc.yaml и \conf\openshift.…\dc.yaml задаются настройки дополнительного порта.

!!! note: «Примечание» Настройка для программного обеспечения «Prometheus» (не путать со стандартом Prometheus) производится аналогичным образом.

Параметры интеграции с MONA устанавливаются путем определения их значений в файле \conf\config\parameters\dictionary.all.conf дистрибутива конфигурации развертывания NSIC.

Сбор метрик и публикацию их в хранилище должны обеспечивать клиентские приложения MONA (Unimon-agent — для сбора метрик и Unimon-sender — для отправки метрик в хранилище), которые рекомендуется размещать в namespace каждого из интегрированных с MONA компонентов. При отправке метрик в хранилище клиентские приложения MONA используют topic (Kafka). Рекомендованная стандартная частота сбора метрик клиентским приложением мониторинга — 15 сек (задается в клиентском приложении MONA).

Клиентские приложения MONA не входят в поставку NSIC. Детальное описание процесса установки и настройки MONA приведено в эксплуатационной документации компонента MONA.

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

Для интеграции c компонентом Журналирование (LOGA) используется sidecar-приложение fluent-bit-sidecar. В процессе функционирования fluent-bit-sidecar вычитывает события из лог-файлов и передает их в LOGA для дальнейшей обработки, используя topic (Kafka).

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

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

Параметры для настройки интеграции с компонентом SVPX задаются в файле dc.yaml для каждого модуля NSIC по пути: \package\conf\k8s\base<имя_модуля>, где <имя_модуля>:

nsi-cloud-facade;
nsi-cloud-client.

Параметры для настройки интеграции с компонентом IGEG задаются в манифестах по пути: \package\conf\k8s\base\istio. В папке config подготовлены манифесты объектов компонента IGEG для маршрутизации. В папке deployments описаны Envoy компонента IGEG.

!!! note: «Примечание» Настройка для Istio производится аналогичным образом.

Все параметры, необходимые для настройки интеграции с компонентами SSM (SVPX, IGEG), приведены в разделе Настройка параметров конфигурации настоящего документа.

Обновление#

Перед обновлением NSIC необходимо проверить, что образы с новой версией размещены в Docker-репозитории, и далее выполнить шаги:

В консоли среды контейнеризации открыть Workloads/Deployments/имя модуля/yaml.
Найти в yaml-файле строку image: и изменить значение хеш-кода на то, значение, хранящееся в конфигурационном релизе для нужного модуля.
Сохранить значение. Если перезапуск не начался автоматически, необходимо удалить Replication Controller у конфигурации развертывания. Новый Replication Controller запустит модуль.
В общем случае могут быть изменены значения переменных. В этом случае необходимо скорректировать их список на основе шаблонов в конфигурационном релизе (Parameters) и заполнить значения в Workloads/Config Maps/имя модуля/yaml, а также подставить в Deployments строки, где используются новые переменные (если они есть). Сделать перезапуск установки в соответствии с разделом Установка.

Примечание

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

Удаление#

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

ConfigMaps;
Secrets;
Deployments;
Deployment Configs (только в OpenShift);
Services;
PODs;
Routes (только в OpenShift) либо Ingresses.

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

kubectl -n <имя namespace> delete <тип компонента Kubernetes/DropApp/OpenShift> <имя компонента Kubernetes/DropApp/OpenShift>

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

При установке с помощью DeployTools задание в Jenkins должно завершиться без ошибок.

Примечание

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

Для проверки работоспособности NSIC необходимо убедиться что pod модуля nsi-api запущен (находится в статусе Running) и не содержит ошибок, а одноименный deploy-pod завершен. Успехом развертывания считается запуск всех pods. В случае, если не хватает какой-либо смежной системы, pods начнут писать внутри себя лог-файлы, либо перезагружаться, указывая на ошибку. Если такого поведения в процессе не наблюдается, то установка выполнена успешно.

Также для успешной проверки работоспособности (health-check) необходимо убедиться в работоспособности всех ключевых интеграций.

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

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

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

Проверить, что глобальная переменная global.ott.ose_deploy установлена в true.

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

Убедитесь, что адрес сервера Kafka APLJ (nsi-cloud-api.configmap.si.kafka.bootstrap_server) указан верно.

Также убедитесь, что при запросе к Kafka APLJ ответ приходит до завершения timeout, выставленного в параметрах APLJ (параметры приведены в разделе Настройка параметров конфигурации).

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

При успешной интеграции с MONA метрики NSIC появятся в сервисе мониторинга (MONA). Также следует проверить лог-файлы:

r.s.u.p.m.m.m.MarkerMetadataCollectorServiceImpl — сбор метрик мониторинга по маркерному интерфейсу запущен

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

При успешной интеграции с LOGA записи журнала NSIC можно найти в сервисе журналирования. Также следует проверить лог-файлы:

SLF4J: A number (129) of logging calls during the initialization phase have been intercepted and are
SLF4J: now being replayed. These are subject to the filtering rules of the underlying logging system.
SLF4J: See also http://www.slf4j.org/codes.html#replay

Проверка работоспособности интеграции с IGEG и SVPX#

Компоненты продукта SSM необходимы для обеспечения межсервисной аутентификации и авторизации. В начале проверки рекомендуется убедиться, что pods ingressgateway и egressgateway запущены (находятся в статусе Running):

kubectl get pod <имя pod> --namespace=<имя пространства имен>

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

kubectl logs -f <имя pod> --namespace=<имя пространства имен>

Если pods запущены и не содержат ошибок, то проверка выполнена успешно.

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

При успешной интеграции с Pangolin (PSQL) pods компонента NSIC успешно запущены (находятся в статусе Running).

!!! note: «Примечание» При использовании PostgreSQL проверка интеграции будет аналогичной.

Проверка интеграции с Secret Management System (SecMan)#

Если в качестве инструмента доставки секретов в среду функционирования компонента NSIC выбран SecMan, то в случае недоступности SecMan запуск новых экземпляров приложений NSIC невозможен.

Если pods NSIC запустились (находятся в статусе Running), то проверка выполнена успешно.

Откат#

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

Откат системного ПО#

Для отката системного ПО необходимо следующее:

Обновить настройки файла конфигурации (раздел Настройка параметров конфигурации);
Выполнить установку предыдущей версии модулей (раздел Установка).

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

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

Проблема	Возможная причина	Способ устранения
Ошибки при развертывании компонента	Не установлена	Следует собрать лог-файлы и обратиться к технической поддержке. Это могут быть ошибки в конфигурации, параметрах, сетевой маршрутизации, настройки баз данных, неверные сертификаты доступа
Pod модуля <имя модуля> содержит ошибку вида CrashLoppBackOff	Некорректная ссылка на Docker-образ image, ошибка JDBC-соединения, некорректная модель БД, отсутствие параметра конфигурации	1. Убедиться, что создана конфигурация развертывания (Workloads — Deployments), и в его настройках нажать кнопку Start Rollout. 2. Перейти в раздел Pods, проследить за появлением Pods имя-модуля-deploy и имя-модуля. 3. При появлении ошибки перейти в лог-файл в течение минуты (далее Pod удаляется) 4. Скопировать сообщение из лог-файла, проанализировать ошибку 5. Если Pods работают, нужно посмотреть логи pod соответствующего компонента на наличие сообщений об ошибках

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

Выполнены условия:

Имеется все необходимое ПО и платформенные компоненты в соответствии с разделом «Системные требования».
Подготовлено окружение в соответствии с разделом «Аппаратные требования».
Осуществлена подготовка требуемого окружения в соответствии с разделом «Подготовка окружения».
Произведена настройка необходимых интеграций в соответствии с разделом «Настройка интеграции» и проведена сверка с пунктами раздела «Чек-лист проверки работоспособности интеграций».
Поднялись все pods в соответствии с разделом «Проверка работоспособности».
Пришел успешный ответ от healthcheck (см. описание в разделе «Чек-лист проверки работоспособности интеграций»).