Настройка интеграции со смежными сервисами#

Настройка интеграции со смежными сервисами происходит путем конфигурации параметров для конкретного внешнего сервиса в определенных ConfigMaps. Каждый смежный сервис имеет свой набор параметров:

настройка интеграции с компонентом Аудит продукта Platform V Audit SE;
настройка интеграции с компонентом Объединенный мониторинг Unimon продукта Platform V Monitor;
настройка интеграции с компонентом Журналирование продукта Platform V Monitor;
настройка интеграции с компонентом One-Time Password (OTP) / OTT;
настройка интеграции с компонентом Прикладной журнал продукта Platform V Data Tools;
настройка интеграции с продуктом Secret Management System;
настройка интеграции с продуктом Synapse Rate Limiter Service.

Настройка интеграции с компонентом Аудит продукта Platform V Audit SE#

Для настройки интеграции сервиса Batch Scheduler с компонентом Аудит продукта Platform V Audit SE (далее — Аудит):

в scheduler-server.conf сконфигурируйте параметр:

# Включение интеграции с сервисом Аудит: true/false
SCHD_SERVER_AUDIT_ENABLED=true

в batch-scheduler.istio.all.conf сконфигурируйте следующие параметры:

# Хосты: порты внешних сервисов для ServiceEntry Egress
SCHD_SE_AUDIT_HOST=<!- заполните самостоятельно ->
# В SCHD_SE_AUDIT_PORT указывается нужный endpoint port.
SCHD_SE_AUDIT_PORT=<!- заполните самостоятельно ->
## Используемый протокол: tls/http
SCHD_SE_AUDIT_PROTOCOL=<!- заполните самостоятельно: tls/http ->

# MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls (для сервисов, обращение к которым выполняется через HTTPS (вызов от сервиса до egress выполняется по HTTP, а от egress до интегрируемого сервиса проксируется через HTTPS)), DISABLE для http 
SCHD_SE_AUDIT_TLS_MODE=<!- заполните самостоятельно: MUTUAL/DISABLE ->

При необходимости внесения изменений в интеграции Batch Scheduler с внешними сервисами внесите соответствующие правки в batch-scheduler.istio.all.conf, после чего выполните повторный запуск Jenkins Job Deploy Tools сервиса Batch Scheduler согласно соответствующей инструкции.

Проверку успешности проведения интеграции Batch Scheduler с внешними сервисами выполняйте в консоли сервиса, с которым выполняется интеграция.

Инструкция по включению/отключению работы health-check приведена в Руководстве системного администратора в разделе «Включение/отключение health-check для сервиса Аудит».

Примеры заполнения файла batch-scheduler.istio.all.conf для интеграции с компонентом Аудит#

Пример конфигурации параметров в файле batch-scheduler.istio.all.conf для внешнего компонента Аудит с различными endpoint:

HTTPS-endpoint https://audit2-client-proxy.apps.dev-<URL-сайта>:

SCHD_SERVER_AUDIT_ENABLED=true
SCHD_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-<URL-сайта>
SCHD_SE_AUDIT_PORT=443
SCHD_SE_AUDIT_PROTOCOL=tls
SCHD_SE_AUDIT_TLS_MODE=MUTUAL

# Общие для всех смежных сервисов параметры (указываются однократно)
SCHD_OTT_ENVOY_FILTER_PORT=8888
SCHD_EXT_SERVICE_EGRESS_PORT=9999

HTTP-endpoint http://audit2-client-proxy.apps.dev-<URL-сайта>:

SCHD_SERVER_AUDIT_ENABLED=true
SCHD_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-<URL-сайта>
SCHD_SE_AUDIT_PORT=80
SCHD_SE_AUDIT_PROTOCOL=http
SCHD_SE_AUDIT_TLS_MODE=DISABLE

# Общие для всех смежных сервисов параметры (указываются однократно)
SCHD_OTT_ENVOY_FILTER_PORT=8888
SCHD_EXT_SERVICE_EGRESS_PORT=9999

HTTP-endpoint http://audit2-client-proxy.apps.dev-gen.xxxxx.xxxx.ru:9080:

SCHD_SERVER_AUDIT_ENABLED=true
SCHD_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-gen.xxxxx.xxxx.ru
# Обратите внимание, что в SCHD_SE_AUDIT_PORT указывается нужный endpoint port.
SCHD_SE_AUDIT_PORT=9080
SCHD_SE_AUDIT_PROTOCOL=http
SCHD_SE_AUDIT_TLS_MODE=DISABLE

# Общие для всех смежных сервисов параметры (указываются однократно)
SCHD_OTT_ENVOY_FILTER_PORT=8888
SCHD_EXT_SERVICE_EGRESS_PORT=9999

Настройка в случае развертывания без компонента Аудит#

Для настройки Batch Scheduler без интеграции компонента Аудит в batch-scheduler.istio.all.conf сконфигурируйте следующие параметры:

# Включение интеграции с сервисом Аудит: true/false
SCHD_SERVER_AUDIT_ENABLED=false

# Хосты: порты внешних сервисов для ServiceEntry Egress
SCHD_SE_AUDIT_HOST=xxx.xxx.xxx
# В SCHD_SE_AUDIT_PORT указывается нужный endpoint port.
SCHD_SE_AUDIT_PORT=443
## Используемый протокол: https/http
SCHD_SE_AUDIT_PROTOCOL=https

# MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls (для сервисов, обращение к которым выполняется через HTTPS (вызов от сервиса до Egress выполняется по HTTP, а от Egress до интегрируемого сервиса проксируется через HTTPS)), DISABLE для http
SCHD_SE_AUDIT_TLS_MODE=MUTUAL

Настройка интеграции с компонентом Объединенный мониторинг Unimon продукта Platform V Monitor#

Для настройки интеграции с компонентом Объединенный мониторинг Unimon установите сервис Объединенный мониторинг Unimon в соответствии с Руководством по установке на него.

Настройка интеграции с компонентом Журналирование продукта Platform V Monitor#

Выполнение настроек перед разворачиванием сервиса с новым типом интеграции (отправка трафика с лог-записями напрямую в Kafka logger вместо endpoint logger):

В репозитории с настройками Deploy Tools в файле fluent-bit.conf по пути: ansible/files/fluent-bit/<каталог сервиса>/ замените весь блок [OUTPUT] со строки Name http на новый блок:

[OUTPUT]
  Name kafka
  Match *
  timestamp_key timestamp
  Brokers <Хосты kafka logger>
  Topics  <Топик kafka logger>
  rdkafka.sticky.partitioning.linger.ms 4000
  rdkafka.queue.buffering.max.kbytes 5120
  rdkafka.ssl.key.location /app/certs/logger/logger_private-key.pem
  rdkafka.ssl.certificate.location /app/certs/logger/logger_cert.pem
  rdkafka.ssl.ca.location /app/certs/logger/logger_cacerts.cer
  rdkafka.security.protocol SSL

Note

В ConfigMap fluent-bit значение параметра rdkafka.security.protocol PLAINTEXT, так как трафик из sidecar прикладного pod выходит без шифрования (не считая шифрования внутри namespace) через Egress и оборачивается сертификатами на выходе. Подключение к брокерам Kafka происходит по SSL.

Укажите значения параметров hosts и топик Kafka Logger:

# Заполнить значениями <DNS kafka logger с указанием портов>, пример: stend-kafka-01.opsmon.xxx:ххх,stend-kafka-02.opsmon.xxx:ххх,stend-kafka-03.opsmon.xxx:ххх
Brokers <Хосты Kafka Logger>
# Топик Kafka Logger
Topics <Топик Kafka Logger>

В репозитории с настройками параметров сервиса в файле custom_property.yaml после блока хостов Kafka ПЖ добавьте новый блок hosts Kafka Logger. Пример:

# Блок хостов Kafka Logger
logger_kafka_hosts:
- host: stend-kafka-01.opsmon.xxx
  ip: xx.xx.xx.xx
  egress_port: xxx
  out_port: xxx
- host: stend-kafka-02.opsmon.xxx
  ip: xx.xx.xx.xx
  egress_port: xxx
  out_port: xxx
- host: stend-kafka-03.opsmon.xxx
  ip: xx.xx.xx.xx
  egress_port: xxx
  out_port: xx

Добавьте параметр с указанием пути до образа. Пример:

## Путь до образа fluent-bit
fluent_bit_registry_path: <путь до образа>

В репозитории с настройками в файле batch-scheduler.all.conf по пути config/parameters установите флаг включения сервиса Журналирование:

# Флаг включения/отключения интеграции с сервисом Журналирование
LOGGER_ENABLED=true

В зависимости от интеграции с сервисом SecMan:

При интеграции с SecMan добавьте сертификаты и ключи в хранилище SecMan (подробнее о сертификатах приведено в разделе «Настройка интеграции с продуктом Secret Management System»).
При отсутствии интеграции с SecMan добавьте пути до сертификатов и ключей в файл ssl.conf.

Настройка в случае интеграции без компонента Журналирование

Для работы Batch Tasks без интеграции с компонентом Журналирование в репозитории с настройками в файле batch-scheduler.all.conf по пути config/parameters установите флаг отключения интеграции:

# Флаг включения/отключения интеграции с сервисом Журналирование
LOGGER_ENABLED=false

Настройка интеграции с компонентом One-Time Password (OTP) / OTT#

Сервис Batch Scheduler может быть развернут как с возможностью интеграции с продуктом OTT, так и без него.

В случае, если сервис Batch будет развертываться с OTT, то должны быть произведены соответствующие настройки OTT в рамках работ по настройке namespace в системе оркестрации контейнерами. Подробнее см. в разделе «Настройка окружения».

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

Для настройки интеграции сервиса Batch Scheduler с OTT:

Добавьте настройки host и путь до образа OTT в файл custom_property.yml в репозитории сервиса по пути: /conf/inventory/custom_property.yml в блок:

ott_registry_path: <путь до образа OTT>

ott_hosts:
  - host: <host сервера OTT>
    port: <порт сервера OTT>
    inner_port: <внутренний порт для маршрутизации Istio, выбирается самостоятельно>

В зависимости от количества hosts серверов OTT необходимо растиражировать блок. Пример приведен в файле.

В файле batch-scheduler.ott-sidecar.all.conf сконфигурируйте адрес OTT сервера:

### Адрес OTT-сервера (в целевом варианте — FQDN). При заполнении в файле custom_property.yml нескольких блоков серверов OTT заполнение параметра должно быть в формате: host:inner_port. Пример: host1:inner_port1,host2:inner_port2,host3:inner_port3
OTT_SERVICE_HOSTS=<!- заполните самостоятельно, обязательно к заполнению ->
SCHD_SE_OTT_TLS_MODE=<!- заполните самостоятельно, обязательно к заполнению, например: MUTUAL ->

При необходимости внесения изменений в интеграции Batch Scheduler с внешними сервисами внесите соответствующие правки в batch-scheduler.ott-sidecar.all.conf, после чего выполните повторный запуск Jenkins Job Deploy Tools сервиса Batch Scheduler согласно соответствующей инструкции.

Файлы сертификатов OTT должны быть прописаны в ssl.conf:

# OTT
ssl.schd.ott.client.crt=ansible/files/ssl/ott/batch-scheduler.crt
ssl.schd.ott.client.key=ansible/files/ssl/ott/batch-scheduler.key
ssl.schd.ott.ott-service=ansible/files/ssl/ott/ott-service.crt
ssl.schd.ott.trustCa=ansible/files/ssl/ott/trustCa.crt

Настройка в случае развертывания без OTT#

Для настройки сервиса Batch Scheduler с выключенной интеграцией с OTT в batch-scheduler.ott-sidecar.all.conf сконфигурируйте следующие параметры:

## Конфигурирование параметров для интеграции с сервисом OTT
 
### Включение интеграции с OTT: true — интеграция включена; false - интеграция выключена
OTT_ENABLED=false

### Внимание! При выключенной интеграции с OTT нижеперечисленные параметры могут быть закомментированы или удалены, но даже если они останутся, значения placeholder все равно не будут применены.

### Алиас (псевдоним) сертификата клиента
OTT_CLIENT_CERT_ALIAS=batch-scheduler
 
### Адрес OTT-сервера (в целевом варианте — FQDN)
OTT_SERVICE_HOST=<!- заполните самостоятельно ->
 
### Адреса OTT-сервера (в целевом варианте — FQDN)
OTT_SERVICE_HOSTS=<!- заполните самостоятельно ->
 
### URL OTT-сервера (в целевом варианте — FQDN)
OTT_SERVICE_URL=https://<!- заполните самостоятельно. Например: 10.xx.xx.xxx:8443/ott-service/rest/token ->
OTT_SERVICE_CERT_ALIAS=ott-service
OTT_REALM=mmt
 
### HTTP-заголовки, которые будут переданы в сервис
ACCEPT_HEADERS=ott-subject, Authorization, iv-user, iv-remote-address, X-Forwarded-For, X-Batch-Tenant
 
### Лимиты ресурсов для контейнера
OTT_SIDECAR_CPU_LIMIT=300m
OTT_SIDECAR_MEMORY_LIMIT=500Mi
OTT_SIDECAR_CPU_REQUEST=200m
OTT_SIDECAR_MEMORY_REQUEST=300Mi
 
### Для версии образа 4.1.3
#### OTT Sidecar Port для readiness probe
OTT_HTTP_PORT=<!- заполните самостоятельно. Например: 8086 ->
#### Анонимный режим: true - влючен; false - выключен
OTT_ANONYMOUS_REQUESTS_ENABLED=<!- заполните самостоятельно true/false ->
#### Сопоставление claim токена на соответствующие HTTP-заголовки
OTT_CLIENT_HEADERS='ott-subject#sub'
OTT_CLIENT_DEFAULT_REALM=mmt

### Ссылки на образы контейнеров
OTT_CLIENT_SIDECAR_IMAGE_REGISTRY_PATH=<!- заполните самостоятельно ->

### Параметры подключения к OTT
OTT_SE_SERVICE_IP=<!- заполните самостоятельно ->
OTT_SE_SERVICE_HOST=<!- заполните самостоятельно ->

Примеры заполнения batch-scheduler.ott-sidecar.all.conf для настройки интеграции с OTT#

OTT_CLIENT_SIDECAR_IMAGE_REGISTRY_PATH=registry.xxxxx.xxxx.ru/pprb/ci00641491/ci01125613_ott

## Конфигурирование параметров для интеграции с сервисом OTT
 
### Включение интеграции с OTT: true – интеграция включена; false – интеграция выключена
OTT_ENABLED=true
 
### Алиас сертификата клиента
OTT_CLIENT_CERT_ALIAS=batch-scheduler
 
### Адрес OTT-сервера (в целевом варианте – FQDN)
OTT_SERVICE_HOST=10.xx.xx.xxx
 
### Адреса OTT-сервера (в целевом варианте – FQDN)
OTT_SERVICE_HOSTS=10.xx.xx.xxx:8443,10.xx.xx.xx:8443
 
### URL OTT-сервера (в целевом варианте – FQDN)
OTT_SERVICE_URL=https://10.xx.xx.xxx:8443/ott-service/rest/token
OTT_SERVICE_CERT_ALIAS=ott-service
OTT_REALM=mmt
 
### HTTP-заголовки, которые будут переданы в сервис
ACCEPT_HEADERS=ott-subject, Authorization, iv-user, iv-remote-address, X-Forwarded-For, X-Batch-Tenant
 
### Лимиты ресурсов для контейнера
OTT_SIDECAR_CPU_LIMIT=300m
OTT_SIDECAR_MEMORY_LIMIT=500Mi
OTT_SIDECAR_CPU_REQUEST=200m
OTT_SIDECAR_MEMORY_REQUEST=300Mi
 
### Для версии образа 4.1.3
#### OTT Sidecar Port для readiness probe
OTT_HTTP_PORT=8086
#### Анонимный режим: true - влючен; false - выключен
OTT_ANONYMOUS_REQUESTS_ENABLED=false
#### Сопоставление claim токена на соответствующие HTTP-заголовки
OTT_CLIENT_HEADERS='ott-subject#sub'
OTT_CLIENT_DEFAULT_REALM=mmt

### Параметры подключения к OTT
OTT_SE_SERVICE_IP=10.xxx.xxx.xxx
OTT_SE_SERVICE_HOST=xxx.xxx.ru

Настройка интеграции с компонентом Прикладной журнал продукта Platform V Data Tools#

Для настройки интеграции сервиса Batch Scheduler с компонентом Прикладной журнал:

Заведите заявку на администраторов компонента Прикладной журнал на стенде на подключение ZONE_ID в конфигураторе со значением SCHD.
Обратитесь к администраторам компонента Прикладной журнал для выпуска сертификатов: server.keystore.jks и trust.jks.
Укажите значения вместо placeholders (placeholders заключены в двойные фигурные скобки {{ }} ).
Добавьте настройки host в файл custom_property.yml в репозитории сервиса по пути: /conf/inventory/custom_property.yml в блок:

ja_kafka_hosts:
  - host: <host сервера Kafka>
    ip: xxx.xxx.xxx.xxx
    inner_port: <внутренний порт для маршрутизации Istio, выбирается самостоятельно>
    egress_port: <промежуточный порт для маршрутизации Istio, выбирается самостоятельно>
    out_port: <порт сервера Kafka>

В зависимости от количества hosts серверов Kafka необходимо растиражировать блок. Пример приведен в файле.

Заполните в файле конфигурирования batch-scheduler.all.conf параметры прикладного ПЖ:

# Флаг включения заглушки ПЖ
AJ_STAND_IN_STUB_MODE_FLAG=<обязательно к заполнению, false - для интеграции с ПЖ, true - без интеграции с ПЖ>

# Сервер Kafka. При заполнении в файле custom_property.yml нескольких блоков серверов Kafka заполнение параметра должно быть в формате: host:inner_port. Пример: host1:inner_port1,host2:inner_port2,host3:inner_port3
AJ_KAFKA_BOOTSTRAP_SERVERS=<обязательно к заполнению>

# Зона ПЖ
AJ_STAND_IN_ZONE_ID=<обязательно к заполнению, например: SCHD>

Настройка в случае развертывания без компонента Прикладной журнал#

Для настройки сервиса Batch Scheduler без интеграции с компонентом Прикладной журнал в конфигурационном файле установите флаг AJ_STAND_IN_STUB_MODE_FLAG=true.

Настройка загрузки и сверки данных БД PostgreSQL#

Для загрузки и сверки данных в БД:

Убедитесь, что на стендах сервиса ПЖ установлен BSSI.
В основной БД (Main) создайте и предоставьте права на чтение пользователю bssi_link с использованием скрипта create_bssi_link.sql (данный и последующие скрипты расположены в дистрибутиве по пути: BAT-x.x.x-xxx-owned-distrib.zip/schd-bin-x.x.x-xxx-distrib.zip/db/db-scripts-db/users).
В репликационной БД (Stand-In):

создайте пользователя и схему bssi с использованием скрипта create_bssi.sql;
в схеме bssi создайте процедуру truncateTables с использованием скрипта TruncateAllTablesInSchema.sql;
предоставьте права пользователю bssi на схему сервиса с использованием скрипта create_bssi.sql;
предоставьте права пользователю bssi на схему bssi с использованием скрипта create_bssi.sql;

На сервере, где установлен BSSI, установите утилиты PostgreSQL: pg_dump, psql. Версии утилит должны быть равны или выше версии PostgreSQL.
Передайте администраторам ПЖ три системные пути относительно корня системы:

к bash, например: /usr/bin/bash;
к pg_dump, например: /usr/bin/pg_dump;
к psql, например: /usr/bin/psql.

Сконфигурируйте файл валидации с таблицами для сверки. Файл конфигурации создается для одной из БД: Main или Stand-In (структура БД одинакова). Для этого:
- заполните актуальными параметрами БД файл generate-validate.env в папке bssi (расположена по пути: BAT-x.x.x-xxx-owned-distrib.zip/schd-bin-x.x.x-xxx-distrib.zip/db/db-scripts-db/bssi);
- запустите утилиту генерации generate-validate-config.sh в папке bssi.
Для генерации файла сверки данных используется файл generate-validate-config-template.sql в папке bssi (файл в конфигурации не нуждается).
Дождитесь генерации файла сверки. Пример файла: bssi-oracle-validate-dbscheduler-1609136739.properties.
Передайте администраторам ПЖ пути к БД, а также логин и пароль пользователя БД.

Далее пункты выполняются администраторами ПЖ.

Откройте в Конфигураторе ПЖ артефакт БС SI ORACLE.
В конфигураторе BSSI заполните пути к системным утилитам.
В конфигураторе BSSI добавьте новую схему.

Примечание. Тип подключения — POSTGRES.

Перезапустите BSSI и АРМ ПЖ.

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

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

Принцип работы обновления секретов#

Период настройки задается на каждый секрет в vault-agent по формуле:

Math.max(minRenewal.getSeconds(),
lease.getLeaseDuration().getSeconds() - expiryThreshold.getSeconds())

где:

expiryThreshold (порог истечения срока действия) — 1 мин.
LeaseDuration — значение из vault для секрета, значение по умолчанию — для vault-engine-kv 200 ч; для TTL — 10 с (10s).
minRenewal — минимальное время опроса клиента, значение по умолчанию — 10 с.

Для установки времени опроса хранилища SecMan на наличие изменений в каждом хранилище SecMan добавьте пару "key-value". Например, для установки жизни токена равным 1 мин, введите: ttl=1m.

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

Для интеграции с Secret Management System (далее — SecMan):

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

Наименование секрета в системе оркестрации контейнерами	Наименование секрета в SecMan	Содержимое	Примечание
batch-scheduler-application-journal-certs	journal-certs	certstore.jks truststore.jks	—
batch-scheduler-db-certs-secret	db-certs	postgresql.pk8 postgresql.crt root.crt	—
secret-{{ fpConfig.fpi_name }}.4	db-secrets	scheduler.db.main.user, scheduler.db.main.password, scheduler.db.si.user, scheduler.db.si.password	В системе оркестрации контейнерами данный секрет генерируется Jenkins Job Deploy Tools на основе файла distrib.yml
istio-ingressgateway-ca-certs	ingressgateway-ca-certs	ca-chain.cert.pem	—
istio-ingressgateway-certs	ingressgateway-certs	tls.crt, tls.key	—
istio-egressgateway-ca-certs	egressgateway-ca-certs	ca-chain.cert.pem	—
istio-egressgateway-certs	egressgateway-certs	tls.crt, tls.key	—
batch-scheduler-ott-certs	ott-certs	batch-scheduler.crt, batch-scheduler.key, ott-service.crt, trustCa.crt	—
batch-scheduler-logger-certs	logging-certs	logger_cacerts.cer, logger_cert.pem, logger_private-key.pem	—

Заведите роль для доступа (роль vault по наименованию проекта системы оркестрации контейнерами) и предоставьте права на хранилище для доступа к секретам.
Настройте параметры для управления подключением в файле batch-scheduler.secman.all.conf.

Параметр SECMAN_ENABLED позволяет управлять включением/выключением интеграции с Secret Management System. При задании параметра в false — все относящиеся к SecMan аннотации, лейблы и т.д. не будут включены в манифесты. При SECMAN_ENABLED=false секреты будут включены в установку, монтироваться секреты будут средствами системы оркестрации контейнерами.

Возможные сценарии использования SecMan:

Использование SecMan в конфигурации KV-engine.
Использование SecMan в конфигурации KV-engine+DB-engine.

Для интеграции с Secret Management System для pods Istio выполняется с использованием sidecar vault-agent, для прикладных pods — без sidecar vault-agent.

Использование SecMan в конфигурации KV-engine#

Предусловия:

в файле batch-scheduler.secman.all.conf заполнен блок с уровнем доступа;
в файле batch-scheduler.secman.all.conf введено значение параметра SECMAN_URL.

Для использования SecMan в конфигурации KV-engine в файле batch-scheduler.secman.all.conf установите значение переменных:

SECMAN_KV_CERTS_ISTIO=true;
SECMAN_PKI_CERTS=false;
SECMAN_KV_APP=true;
SECMAN_DB_ENGINE_ENABLED=false.

Использование SecMan в конфигурации KV-engine+DB-engine#

Предусловия:

в файле batch-scheduler.secman.all.conf заполнен блок с уровнем доступа;
в файле batch-scheduler.secman.all.conf введено значение параметра SECMAN_URL.

Для использования SecMan в конфигурации KV-engine+DB-engine:

В файле batch-scheduler.secman.all.conf установите значение переменных:

SECMAN_KV_CERTS_ISTIO=true;
SECMAN_PKI_CERTS=false;
SECMAN_KV_APP=true;
SECMAN_DB_ENGINE_ENABLED=true;
SECMAN_DB_ENGINE_ROLE_MAIN=<роль для основной БД>;
SECMAN_DB_ENGINE_ROLE_SI=<роль для репликационной БД>;
SECMAN_DB_ENGINE_BACKEND=<путь до DB-engine>.

Из переменной SECMAN_CONFIG_IMPORT удалите контекст optional:vault://{{SECMAN_NAMESPACE}}{{SECMAN_SECRETADDRESS}}/db-secrets.

Настройка приоритизации источников секретов#

Для организации поведения "fail-safe" существуют два источника получения секретов: kind: Secret и SecMan.

Для настройки приоритизации в файле batch-scheduler.secman.all.conf укажите приоритет, где 0 — максимальный приоритет.

# Флаг включения завершения запуска сервиса, если выявлены ошибки при запуске: true/false
SECMAN_FAIL_FAST=false

# Приоритет получения секретов из kind: Secret (0/1)
SECMAN_SPRING_PRIORITY=1

# Приоритет получения секретов из Vault (0/1)
SECMAN_VAULT_PRIORITY=0

Принудительное применение секретов сервиса Batch Scheduler#

Для принудительного применения секретов в терминале любого pod, например, scheduler-server, выполните команду:

curl -X POST localhost:8080/actuator/secrets-refresh

Настройка PKI для сервиса Pangolin#

Для настройки PKI для сервиса Pangolin:

В файле batch-scheduler.secman.all.conf заполните значения параметров:

# Флаг включение/отключение PKI для прикладных Pods (true/false)
PKI_APP_ENABLED=false
# Путь до PKI
PKI_PATH=<Обязательно к заполнению, например: PKI/pki>
# Роль для получения клиентского сертификата БД
PKI_ROLE_POSTGRESQL_CRT=<Обязательно к заполнению>
# CN для клиентского сертификата БД
PKI_CN_POSTGRESQL_CRT=<Обязательно к заполнению>
# Время жизни сертификата
PKI_TTL_POSTGRESQL_CRT=<Обязательно к заполнению>
# Роль для получения корневого сертификата БД
PKI_ROLE_ROOT_CRT=<Обязательно к заполнению>
# CN для корневого сертификата БД
PKI_CN_ROOT_CRT=<Обязательно к заполнению>
# Время жизни сертификата
PKI_TTL_ROOT_CRT=<Обязательно к заполнению>
# Роль для получения клиентского ключа БД
PKI_ROLE_POSTGRESQL_KEY=<Обязательно к заполнению>
# CN для клиентского ключа БД
PKI_CN_POSTGRESQL_KEY=<Обязательно к заполнению>
# Время жизни ключа
PKI_TTL_POSTGRESQL_KEY=<Обязательно к заполнению>

Из переменной SECMAN_CONFIG_IMPORT удалите контекст optional:vault://{{SECMAN_NAMESPACE}}{{SECMAN_SECRETADDRESS}}/db-certs.

Настройка интеграции с продуктом Synapse Rate Limiter Service#

Для настройки интеграции с компонентом Synapse Rate Limiter Service (далее — SRLS):

Настройте файл конфигурации srls.all.conf (все параметры обязательны к заполнению), расположенный в дистрибутиве по пути: package/conf/k8s/base/customresources. Пример заполнения приведен в файле.
При необходимости квотирования для каждого потребителя в конфигурационном файле custom_property.yml в блоке добавления заголовков заполните:

srls_headers:
  - header: <Уникальный заголовок потребителя, например - batch-scheduler>
    name: <Метаданные для заголовка потребителя, например - simple>
    unit: <Единица измерения лимитов, например - second>
    value: <Величина квоты для запросов потребителя, например - 10>

Note

Для использования файла custom_property.conf.yml необходимо перенести содержимое файла inventory/custom_property.yml вручную, а файл inventory/custom_property.yml удалить вместе с каталогом.