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

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

Необходимое окружение для разворачивания сервиса Пакетная обработка задач (Batch Tasks) — Kubernetes версии 1.0 и выше или OpenShift версии 4.2 и выше (далее — среда контейнеризации).

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

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

Программный продукт	Функция
Install_EIP	Инструмент для выполнения настройки параметров сервиса и автоматизированной установки на стенд
Helm	Инструмент для выполнения настройки параметров сервиса и автоматизированной установки на стенд
Компонент Аудит продукта Platform V Audit SE	Сервис для аудирования событий
Компонент Журналирование продукта Platform V Monitor	Сервис для хранения логов
Компонент Объединенный мониторинг Unimon продукта Platform V	Сервис для сбора прикладных и инфраструктурных метрик и отправки их в целевую систему хранения
Компонент Объединенный сервис авторизации продукта Platform V IAM SE	Сервис для управления доступом к информационным ресурсам
Компонент Прикладной журнал продукта Platform V Data Tools	Сервис для обеспечения отказоустойчивости приложения на уровне базы данных
Компонент IAM Proxy продукта Platform V IAM SE	Сервис для проксирования web-запросов и выполнения функций аутентификации вызывающей стороны (пользователя)
Компонент Планировщик заданий (Batch Scheduler) продукта Platform V Batch	Сервис для запуска вычислительных заданий по расписанию или по требованию
Продукт Platform V One-Time-Token	Сервис для аутентификации и авторизации межсервисных взаимодействий
Продукт Platform V Synapse Service Mesh	Сервис для обмена запросов через сложную топологию сервисов, созданное для работы в облаке, обеспечивает дополнительными средствами мониторинга и валидации сервиса и его конфигураций
Библиотека OpenSSL	Сервис для проверки подключения к базе данных по SSL/TLS
Компонент Управление политиками продукта Platform V Synapse Service Mesh	Панель управления с открытым исходным кодом, служащая для взаимодействия, мониторинга и обеспечения безопасности контейнеров в среде контейнеризации Kubernetes

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

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

ручная установка сервиса;
автоматизированная установка сервиса через Install_EIP;
автоматизированная установка сервиса через Helm.

Установка#

Обзор#

Установка сервиса Batch Tasks должна выполняться последовательно, в соответствии с общей схемой процесса развертывания:

$@startuml skinparam shadowing false start -[#black]-> #white : Обеспечение выполнения пререквизитов; -[#black]-> #white : Обеспечение выполнения требований \n подготовки окружения; -[#black]-> #white : Выбор способа установки сервисов; -[#black]-> fork -[#black]-> #white :Ручная установка сервиса; -[#black]-> fork again -[#black]-> #white :Автоматизированная установка сервиса; -[#black]-> fork -[#black]-> #white :Установка сервиса \n через Install_EIP; -[#black]-> fork again -[#black]-> #white :Установка сервиса \n через Helm; -[#black]-> end fork -[#black]-> end fork -[#black]-> #white : Проверка развертывания сервиса; -[#black]-> stop @enduml$

Пререквизиты#

Для установки сервиса Batch Tasks должны быть:

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

Внимание

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

Требования к окружению#

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

наличие платформы среды контейнеризации;
наличие СУБД PostgreSQL (рекомендуется Platform V Pangolin SE, далее — PostgreSQL);
наличие в инфраструктуре продукта Platform V One-Time-Token (далее — OTT) (опционально).

Требования к КТС#

Требования к производительности#

Описание	Параметры
Рекомендуемый минимальный КТС для namespace	8 CPU / 32GB RAM

Требования к базе данных#

Описание	Параметры
Минимальные требования к КТС для разворачивания сервиса	2 Core CPU / 8GB RAM / 100GB HDD
Рекомендуемые требования к КТС для разворачивания сервиса	16 Core CPU / 128GB RAM / 1200GB HDD

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

Подключение namespace к компоненту Управлению политиками#

Подключение namespace к компоненту Управление политиками (POLM, версия 1.12 и выше) продукта Platform V Synapse Service Mеsh (SSM) осуществляется в соответствии с Руководством прикладного разработчика на компонент.

Выпуск и установка сертификатов для Ingress/Egress#

Необходимо выпустить и установить сертификаты Ingress/Egress, манифесты:

istio-egressgateway-ca-certs;
istio-egressgateway-certs;
istio-ingressgateway-ca-certs;
istio-ingressgateway-certs.

После чего будет создан набор необходимых артефактов, в том числе секреты с сертификатами cert, ca-cert.

Созданные секреты содержат, в том числе, наименования файлов tls.crt, tls.key, ca-chain.cert.pem (вся цепочка сертификатов):

istio-egressgateway-certs

  kind: Secret
  apiVersion: v1
  metadata:
    name: istio-egressgateway-certs

  ...

  data:
    tls.crt: >-
      LS0...<много символов>...0tLQ0K
    tls.key: >-
      LS0...<много символов>...0tLS0t
  type: Opaque

istio-egressgateway-ca-certs

  kind: Secret
  apiVersion: v1
  metadata:
    name: istio-egressgateway-ca-certs

  ...
  data:
    ca-chain.cert.pem: >-
      LS0...<много символов>...0tLQ==
  type: Opaque

istio-ingressgateway-certs

  kind: Secret
  apiVersion: v1
  metadata:
    name: istio-ingressgateway-certs

  ...

  data:
    tls.crt: >-
      LS0...<много символов>...0tLQ0K
    tls.key: >-
      LS0...<много символов>...0tLS0t
  type: Opaque

istio-ingressgateway-ca-certs

  kind: Secret
  apiVersion: v1
  metadata:
    name: istio-ingressgateway-ca-certs

  ...

  data:
    ca-chain.cert.pem: >-
      LS0...<много символов>...0tLQ==
  type: Opaque

В секретах istio-ingressgateway-ca-certs и istio-egressgateway-ca-certs должен присутствовать один файл ca-chain.cert.pem со всей цепочкой сертификатов. Если в секрете указаны два отдельных сертификата, то вызовы через Ingress по HTTPS не будут работать.

Возможен вариант, когда в секретах в файле ca-chain.cert.pem содержится вся цепочка сертификатов (т.е. добавлено содержимое из ca.pem), но сам файл ca.pem не удален. В этом случае все будет работать корректно.

Настройка OTT#

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

Получите сертификаты приложения, публичный ключ OTT Service и выполните их подключение.
Создайте ConfigMap для OTT-sidecar.

Дистрибутив сервиса Batch Tasks может быть развернут как с возможностью интеграции с сервисом OTT, так и без нее. Подробнее см. в Руководстве по системному администрированию сервиса Batch в разделе «Конфигурирование интеграции с сервисом OTT».

Если развертывание сервиса Batch Tasks производится без OTT, то в выполнении нижеприведенных действий нет необходимости.

Получение сертификатов приложения, публичного ключа OTT Service и их подключение#

Для получения сертификатов приложения, публичного ключа OTT Service и их подключения выполните следующие действия:

При помощи keytool сгенерируйте key-store c ключами (batch_cert.p12) по алгоритму SHA256withECDSA и длиной ключа 256 бит. В результате будет сформирован файл batch_cert_req.pem.

Примеры команд:

   keytool -genkey -keyalg EC -sigalg SHA256withECDSA -keystore batch.p12 -storetype PKCS12 -keysize 256 -dname "CN=batch" -alias batch

   keytool -certreq -keyalg EC -sigalg SHA256withECDSA -keystore batch.p12 -storetype PKCS12 -alias batch > batch_cert_req.pem

Отправьте файл batch_cert_req.pem администратору OTT в заявке на генерацию сертификата для модуля. Администратор OTT подписывает/генерирует ключи, высылает их обратно.
Импортируйте полученные от администратора OTT-ключи в key-store batch_cert.p12.

Примеры команд:

   keytool -import -keystore batch.p12 -storetype PKCS12 -file SberbankPlatformCA_EC.pem -alias SberbankPlatformCA_EC

   keytool -import -keystore batch.p12 -storetype PKCS12 -file batch.pem -alias batch

Создайте два секрета:
- batch-ott-certs — с сертификатами (batch.p12: >- , ott_service_truststore.p12: >- )
  
  Важно! Для корректного создания секрета конвертируйте содержимое файла с ключами в Base64. Далее — полученную строку вставьте в yml-файл. Либо выполните команду:
```
oc create secret generic batch-ott-certs --from-file=ott_service_truststore.p12=./sigma_ott_trust.p12 --from-file=batch.p12=./batch.p12
```
- batch-ott-passwords — c паролями к ключам:
  - OTT_CERTSTORE_PRIVATE_KEY_PWD — пароль для чтения ключа;
  - OTT_CERTSTORE_PWD — пароль для чтения сертификата;
  - OTT_TRUST_STORE_PWD — пароль для чтения ott_service_truststore.p12.

ConfigMap для OTT-sidecar#

Для работы OTT-sidecar необходимо наличие в дистрибутиве configMap с настройками сервиса. Создание configMap выполняется на этапе установки сервиса.

Ручное конфигурирование параметров ConfigMap для OTT-sidecar

Ручное конфигурирование параметров ConfigMap для OTT-sidecar выполняется в случае, если установка сервиса производится без помощи Jenkins Job Install_EIP.

Конфигурационные YML-файлы для OTT-sidecar находятся в дистрибутиве в папке /k8s/base. Список файлов конфигурации:

ott-ingress-logback;
batch-tasks-ott-ingress-settings;
ott-egress-logback;
batch-tasks-ott-egress-settings.

Перед загрузкой YML-файлов для OTT-sidecar в среде контейнеризации замените плейсхолдер на реальные значения параметров.

Для загрузки конфигураций в среду контейнеризации:

Выполните вход в консоль среды контейнеризации.
На панели слева выберите раздел Workloads → Config Maps.
Нажмите кнопку Create Config Map.
В открывшемся окне вставьте вместо имеющегося содержимое файла ott-ingress-logback.
Нажмите кнопку Create.
Повторите пункты 2–4 для файлов:
- batch-tasks-ott-ingress-settings;
- ott-egress-logback;
- batch-tasks-ott-egress-settings.

Автоматизированное конфигурирование параметров ConfigMap для OTT-sidecar

При автоматизированном развертывании сервиса конфигурирование параметров ConfigMap для OTT-sidecar выполняется в Install_EIP в файле os_props.

Подробнее см. в разделе «Редактирование файлов конфигурации Job Install_EIP».

Подготовка базы данных#

Подготовка БД для сред эксплуатации#

Для работы в средах эксплуатации для БД должны быть созданы схема (через заявку на подготовку БД для сред эксплуатации для администраторов стенда), пользователи (tasks_owner_user, tasks_appl_user) и включена поддержка SSL (при необходимости).

Подготовка БД для тестовых сред и сред разработки#

Чтобы подготовить основную (Main) и репликационную (Stand-In) базы данных для работы в тестовых и средах разработки, выполните следующие шаги:

Создайте пользователей:
- прикладного пользователя tasks_appl_user, от имени которого приложение будет соединяться с БД;
- пользователя-владельца схемы данных tasks_owner_user, от имени которого необходимо запускать скрипты.
Создайте БД.
Добавьте пользователей.
Перезагрузите БД.
Выполните SQL-скрипт создания схемы данных и предоставления прав.

Создание пользователей БД#

Если имеется SSH-доступ на КТС с БД и возможностью повысить привилегии до root, то для создания пользователей БД можно воспользоваться утилитой psql.

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

После авторизации на КТС повысьте привилегии до root. Для этого запустите оболочку (shell) с правами root: sudo -s.
Переключитесь для работы под пользователем postgres: su - postgres.
Запустите утилиту psql (или полный путь/usr/local/pgsql/bin/psql, если не запускается без указания полного пути).
Создайте пользователей:

   CREATE ROLE xxx_appl_user WITH LOGIN PASSWORD 'password';
   CREATE ROLE xxx_owner_user WITH LOGIN PASSWORD 'password';

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

Из утилиты psql список пользователей экземпляра можно получить, используя команду \du или

select * from pg_catalog.pg_user;

Поле valuntil указывает до какой даты-времени действителен пароль пользователя. Если поле пустое, то пароль пользователя не имеет срока действия (бессрочный).

Создание БД#

Для создания базы данных для среды разработки, выполните от имени пользователя postgres (суперпользователь БД) в утилите psql команду:

CREATE DATABASE database_name OWNER xxx_owner_user;

В зависимости от настроек в файле pg_hba.conf (аутентификации по имени узла) созданные пользователи не могут войти в систему, пока их не добавят в pg_hba.conf.

Аналогичная ситуация будет справедлива и для суперпользователя postgres при попытке подключения к созданной БД.

Добавление пользователей и перезагрузка БД#

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

Краткое описание

Файл конфигурации pg_hba.conf содержит:

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

Файл с настройками аутентификации по имени узла pg_hba.conf находится по пути /pgdata/11/data.

Примечание. Пути могут отличаться, в том числе в зависимости от версии базы.

Редактировать файл конфигурации pg_hba.conf нужно от имени системного (linux) пользователя postgres. В файле конфигурации pg_hba.conf добавьте 1 или 2 строки, в зависимости от того, может ли суперпользователь БД postgres подключаться к БД.

Нижеприведенные примеры исходят из того, что суперпользователь БД postgres не может подключаться к БД.

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

В файл конфигурации pg_hba.conf добавьте пользователя postgres:

host db_1, db_2, database_name postgres 127.0.0.1/32 trust

Данная строка должна идти впереди любой аналогичной строки, которая определяет способ подключения пользователя postgres c другого хоста (тип хоста), если они допускают подключение пользователя postgres с локального хоста.

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

Где:

host — показывает, что подключение выполняется с другого хоста (как правило, в файле pg_hba.conf присутствует строка local all all md5. Это означает, что при локальном логине к любой БД нужно вводить пароль);
db_1, db_2 — список баз, для которых уже прописана возможность локального подключения к ним суперпользователя БД postgres без ввода пароля;
database_name — наименование БД;
postgres — пользователь БД, от имени которого будет доступен данный вариант входа;
127.0.0.1/32 — показывает, что такой вход возможен только с того же самого хоста;
trust — метод аутентификации, не требующий ни ввода пароля, ни наличия сертификата.

Редактирование файла конфигурации для логина пользователей с произвольного хоста

Чтобы созданные пользователи могли подключиться к созданной БД данного экземпляра PostgreSQL, добавьте в файл конфигурации hb_pga.conf следующую строку:

# add users to pg_hba.conf
echo "host database_name xxx_owner_user, xxx_appl_user 0.0.0.0/0 md5" >> /pgdata/11/data/pg_hba.conf

Где:

host — показывает, что подключение выполняется с другого хоста;
database_name — наименование БД;
xxx_owner_user, xxx_appl_user — перечень имен созданных пользователи;
0.0.0.0/0 — разрешенный диапазон хостов (0.0.0.0/0 — показывает, что логин разрешен с любого хоста);
md5 — способ аутентификации по паролю.

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

Перезагрузка БД#

Подробную информацию о работе вы можете найти в документации на PostgreSQL.

Перечитывание конфигурационных файлов и перезагрузка базы запускается от linux-пользователя postgres. Аналогично от linux-пользователя postgres выполняется и проверка статуса, остановка или запуск экземпляра.

Перечитывание конфигурационных файлов и перезапуск экземпляра:

pg_ctl reload
pg_ctl restart

Создание схем БД#

После успешного перезапуска экземпляра БД создайте схему данных. Для этого запустите утилиту psql и под пользователем xxx_owner_user подключитесь к ранее созданной БД:

\c database_name xxx_owner_user
CREATE SCHEMA xxx_schema AUTHORIZATION xxx_owner_user;
GRANT USAGE ON SCHEMA xxx_schema to xxx_appl_user;

Для просмотра схемы в БД в psql выполните команду \dn или

SELECT schema_name FROM information_schema.schemata;

Варианты настройки SSL-подключения к БД#

Настройка подключения к БД по SSL#

Для конфигурации СУБД PostgreSQL на использование SSL/TLS создайте ключ и сертификат, а также настройте доступ.

Внимание

Конфигурацию СУБД PostgreSQL выполните для всех БД сервиса (основной и репликационной)!

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

Создание сертификата и закрытого ключа

Создание сертификата и закрытого ключа осуществляются на узле, где расположен экземпляр СУБД PostgreSQL, под пользователем-владельцем сервиса, например: postgres.

Закрытый ключ и сертификаты должны быть расположены в директории, доступной для пользователя-владельца сервиса СУБД PostgreSQL. По умолчанию для создания закрытого ключа и сертификата используется директория ${PGDATA}. Доступ к директории должен быть ограничен для всех, кроме пользователя-владельца сервиса.

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

Создайте запрос на подпись сертификата и закрытого ключа БД:

Значение Common Name (CN) для сертификата должно строго соответствовать FQDN (полному доменному имени) сервера.

   openssl req -new -nodes -text -out server.csr -keyout server.key -subj "/CN=some-dns-name.domen.xxxxx.ru"

Где some-dns-name.domen.xxxxx.ru — полное доменное имя сервера.

Ограничьте права доступа на файл закрытого ключа:

   chmod og-rwx server.key

Отправьте запрос на подпись сертификата (server.csr) в удостоверяющий центр.
Расположите подписанный сертификат с именем server.crt в директории сертификатов ($PGDATA/certs).

Если сертификат подписан промежуточным удостоверяющим центром, то файл сертификата (server.crt) должен также включать сертификаты всей цепочки промежуточных удостоверяющих центров.
Расположите корневой сертификат (root.crt) в директории сертификатов ($PGDATA/certs).

Настройка конфигурационных файлов БД

Настройка конфигурационных файлов БД состоит из следующих шагов.

Шаг 1. Включение поддержки SSL в postgresql.conf.

В postgresql.conf уберите комментирование следующих строк и заполните пути до сертификатов:

# - SSL -
ssl = on
ssl_cert_file = '/pgdata/certs/server.crt'
ssl_key_file = '/pgdata/certs/server.key'
ssl_ca_file = '/pgdata/certs/root.crt'
ssl_ciphers = 'HIGH:MEDIUM:+3DES:!aNULL' # allowed SSL ciphers

Если сертификаты и ключи расположены не в корне директории $PGDATA, укажите их полные пути.

Способ шифрования TLS v1.2 может быть указан следующим способом postgresql.conf:

# - SSL -
ssl_ciphers = 'TLSv1.2:!aNULL'

По умолчанию значение HIGH:MEDIUM:+3DES:!aNULL обеспечивает использование максимального уровня шифрования (версии протокола), поддерживаемого и клиентом, и сервером.

Шаг 2. Включение метода аутентификации посредством сертификата в pg_hba.conf.

В pg_hba.conf добавьте строку для подключения одного или нескольких серверов приложений по SSL/TLS:

# TYPE    DATABASE       USER LOGIN       ADDRESS         METHOD
hostssl   database_name  tasks_appl_user  10.11.12.1/24   cert

Где:

database_name — имя базы данных;
tasks_appl_user — имя пользователя;
10.11.12.1/24 — маска адресов серверов приложений, в формате IPv4.

После завершения настройки конфигурационных файлов выполните перезапуск сервиса СУБД PostgreSQL.

Шаг 3. Проверка подключения по SSL/TLS.

Для проверки подключения к СУБД PostgreSQL по SSL/TLS необходима версия клиента OpenSSL не ниже 1.1.1.

Выполните запрос сертификатов СУБД PostgreSQL:

   $ openssl s_client -starttls postgres -connect 10.11.12.13:5432 -showcerts

Где:

10.11.12.13 — адрес узла СУБД PostgreSQL;
5432 — порт подключения к БД по умолчанию.

Проверьте в полученном ответе наличие списка серверных сертификатов и отсутствие сообщения:

   ---
   no peer certificate available
   ---

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

Настройка подключения к БД без SSL#

Для конфигурации СУБД PostgreSQL на использование без SSL/TLS:

В os_props.conf укажите настройки:

   MAIN_DB_SSL_ON=false
   SI_DB_SSL_ON=false

   ### С помощью настройки MAIN_DB_TLS_FACTORY указываем фабрику, которая пропускает загрузку и использование сертификатов
   MAIN_DB_TLS_FACTORY=org.postgresql.ssl.NonValidatingFactory
   SI_DB_TLS_FACTORY=org.postgresql.ssl.NonValidatingFactory

В pg_hba.conf настройте доступ для пользователей по паролю к БД:

   host batch_demo_db batch_owner_user, batch_appl_user 0.0.0.0/0 md5

Перезагрузите PostgreSQL:

   pg_ctl reload
   pg_ctl restart

Добавьте недостающие секреты для режима без SSL в batch-tasks-db-certs-secret, добавив недействительные значения секретов:

   kind: Secret
   apiVersion: v1
   metadata:
     name: batch-tasks-db-certs-secret
   data:
     root-fake.crt: >-
       MTIz
     tasks_appl_user-fake.crt: >-
       MTIz
     tasks_appl_user-fake.pk8: >-
       MTIz
   type: Opaque

Внесение дополнительных изменений в postgresql.conf не требуется.

Обновление БД#

Обновление схемы данных БД может быть выполнено при условии выполненной первичной инициализации БД.

Для обновления схемы БД до текущей версии:

Заполните конфигурацию подключения к БД, под пользователем-владельцем (tasks_owner_user), в файле (расположен в дистрибутиве):
- основная БД: /db/postgresql/liquibase.properties;
- репликационная БД: /db/postgresql/liquibase-si.properties.
Выполните нужный скрипт (расположены в дистрибутиве):
- основная БД:
  - если установка производится на стенды с Linux: db/postgresql/win/db_update.sh;
  - если установка производится на стенды с Windows: db/postgresql/win/db_update.bat;
- репликационная БД:
  - если установка производится на стенды с Linux: db/postgresql/win/db_update-si.sh;
  - если установка производится на стенды с Windows: db/postgresql/win/db_update-si.bat.

Оформление доступа ТУЗ к репозиториям с Docker-образами#

Для оформления доступа ТУЗ к репозиториям с Docker-образами добавьте в default-аккаунт секрет для доступа к репозиторию с Docker-образами, например: name: docker-registry-sigma, type: kubernetes.io/dockerconfigjson:

$> oc create secret docker-registry <!- введите сюда выбранное наименование, например docker-registry-sigma -> --docker-server=registry.xxxxx.ru --docker-username=<!- введите логин, например AAA-BB-SERVICE1234 -> --docker-password=******
$> oc secrets link default docker-registry-sigma --for=pull

При установке сервиса с помощью Jenkins Job Install_EIP зарегистрируйте токен jenkins-аккаунта согласно инструкции, приведенной в следующем разделе.

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

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

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

cfg\conf\k8s\base\overrides\openshift\istio\config\egress\destination-rule-egress-audit.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\destination-rule-egress-logger.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\destination-rule-egress-monitoring.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\destination-rule-egress-spas.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\gateway-egress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\gateway-egress-journal.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-egress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-egress-journal.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-entry-egress-audit.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-entry-egress-journal.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-entry-egress-logger.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-entry-egress-monitoring.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\service-entry-egress-spas.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\virtual-service-egress-audit.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\virtual-service-egress-journal.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\virtual-service-egress-logger.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\virtual-service-egress-monitoring.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\virtual-service-egress-spas.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\config-ott\service-entry-ott-server-egress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\config-ott\configmap-ott-egress-logback.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\config-ott\configmap-ott-egress-settings.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\config-ott\envoy-filter-ott-egress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\db\service-entry-egress-standin-db.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\db\virtual-service-egress-main-db.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\db\virtual-service-egress-standin-db.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\db\service-entry-egress-main-db.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\virtual-service-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\destination-rule-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\envoy-filter-ott-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\gateway-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\service-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\egress\tenant\service-entry-egress-tenant.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\gateway-ingress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\gateway-ingress-api-v2.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\config-map-ingress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\destination-rule-ingress-gateway.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\envoy-filter-api-v2-cert.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\config-ott\envoy-filter-ott-ingress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\config-ott\configmap-ott-ingress-logback.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\config-ott\configmap-ott-ingress-settings.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\config-ott\envoy-filter-geobalancer-ingress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\virtual-service\virtual-service-ingress-api-v2.yml;
cfg\conf\k8s\base\overrides\openshift\istio\config\ingress\virtual-service\virtual-service-ingress.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\egress\deployment\dc.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\egress\deployment-ott\dc.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\ingress\service-ingress-gateway-api-v2.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\ingress\route-istio-ingress-gateway.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\ingress\service-ingress-gateway.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\ingress\deployment\dc.yml;
cfg\conf\k8s\base\overrides\openshift\istio\deployments\ingress\deployment-ott\dc.yml;
cfg\conf\k8s\base\overrides\openshift\istio\inner-mtls\destination-rule-enable-mtls.yml;
cfg\conf\k8s\base\overrides\openshift\istio\inner-mtls\peer-authentication-mtls-mode-strict.yml;
cfg\conf\k8s\base\overrides\openshift\istio\inner-mtls\authorization-policy-allow-all.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-gc\dc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-gc\service-tasks-gc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-gc\configmaps\configmap-tasks-gc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-gc\istio\destination-rule-tasks-gc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-journal-applier\dc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-journal-applier\service-tasks-journal-applier.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-journal-applier\configmaps\configmap-tasks-journal-applier.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-journal-applier\istio\destination-rule-tasks-journal-applier.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-server\dc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-server\service-tasks-server.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-server\configmaps\configmap-tasks-server.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-server\istio\destination-rule-tasks-server.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-worker\dc.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-worker\service-tasks-worker.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-worker\configmaps\configmap-tasks-worker.yml;
cfg\conf\k8s\base\overrides\openshift\tasks-worker\istio\destination-rule-tasks-worker.yml;
package\conf\k8s\tasks-database\configmap-batch-tasks-liquibase-properties.ym;
package\conf\k8s\tasks-database\configmap-batch-tasks-liquibase-si-properties.yml;
package\conf\k8s\tasks-database\job-batch-tasks-liquibase.yml;
package\conf\k8s\tasks-database\job-batch-tasks-liquibase-si.yml;
package\conf\k8s\tasks-database\secrets\secret-batch-tasks-liquibase-si.yml;
package\conf\k8s\tasks-database\secrets\secret-batch-tasks-liquibase.yml;
cfg\conf\k8s\base\overrides\openshift\gateway-ingress-health.yml;
cfg\conf\k8s\base\overrides\openshift\route-istio-ingress-gateway-health.yml;
cfg\conf\k8s\base\overrides\openshift\configmaps\configmap-fluentbit.yml.

Пример с заполненными плейсхолдерами приведен в файле os_props.conf.

После замены файлов конфигурации необходимо развернуть файлы конфигурации в среду контейнеризации:

В панели администратора в правом верхнем углу нажать на кнопку Import YAML;
в открывшейся окно вставить скопированный конфигурационный файл и нажать Create;
после создания отобразиться страница конфигурационного файла;
повторить действия 1-3 для всех файлов конфигурации.

Установка БД с Liquibase#

Установка БД с Liquibase происходит с помощью запуска Kubernetes Job. Предварительно на стенд должны быть установлены следующие манифесты:

configmap-batch-tasks-liquibase-properties.yml;
secret-batch-tasks-liquibase.yml;
configmap-batch-tasks-liquibase-si-properties.yml;
secret-batch-tasks-liquibase-si.yml.

Примечание

Устанавливать нужно только необходимый комплект БД. Например, если будут использоваться и основная и репликационная БД, то устанавливать нужно все манифесты, а если используется только основная БД, то только манифесты без постфикса -si.

Запуск Kubernetes Job происходит автоматически при добавлении на стенд соответствующих манифестов:

job-batch-tasks-liquibase-si.yml;
job-batch-tasks-liquibase.yml.

В состав дистрибутива Batch Tasks дополнительно включены:

configs/k8s/tasks-database/:
- secrets/:
  - secret-batch-tasks-liquibase-si.yml — секрет с УЗ/паролями для запуска Liquibase репликационной БД,
  - secret-batch-tasks-liquibase.yml — секрет с УЗ/паролями для запуска Liquibase основной БД;
    
    Предупреждение
    
    Содержимое-шаблон секрета должно быть заполнено реальными значениями.
  - configmap-batch-tasks-liquibase-properties.yml — параметры соединения Liquibase с основной БД:
    - MAIN_DB_CURRENT_SCHEMA — наименование схемы данных,
    - MAIN_DB_JDBC_URL — JDBC_URL для соединения с основной БД;
  - configmap-batch-tasks-liquibase-si-properties.yml — параметры соединения Liquibase с репликационной БД:
    - SI_DB_CURRENT_SCHEMA — наименование схемы данных,
    - SI_DB_JDBC_URL — JDBC_URL для соединения с репликационной БД;
  - job-batch-tasks-liquibase.yml, job-batch-tasks-liquibase-si.yml — манифесты создания Kubernetes Job на стенде:
    - image — должен содержать путь к собранному Docker-образу для Kubernetes Job.

Установка конфигурации Kubernetes#

Конфигурация Kubernetes для модулей server, worker и gc содержит следующие файлы:

deployment-tasks-{наименование модуля}.yml;
configmap-tasks-{наименование модуля}.yml;
service-tasks-{наименование модуля}.yml.

Данные файлы (конфигурации) попадают в директории итогового дистрибутива:

/configs/k8s/tasks-server;
/configs/k8s/tasks-worker;
/configs/k8s/tasks-gc;
/configs/k8s/tasks-ui.

Файлы с описанием дополнительных плейсхолдеров для Kubernetes k8s_props.conf.dev и k8s_props.conf.prod находятся в каталоге /install.

Автоматизированная установка сервиса через Helm#

Установка и настройка инсталлятора Helm осуществляется в соответствии с Руководством по установке на Helm.

Пререквизиты#

Для установки сервиса Batch Tasks с использованием инсталлятора Helm должны быть:

Helm v.3.8.0.
Кластер Kubernetes 1.8+ с включенным контролем доступа на основе ролей (RBAC).

Примечание. Kubernetes до версии 1.6 или не поддерживают управления доступом на основе ролей (или поддерживают ограниченно).

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

Обзор#

Chart — это пакет инсталлятора Helm, содержит описания ресурсов, необходимые для запуска приложения, инструмента или службы внутри кластера Kubernetes.

Репозиторий — это место для аккумулирования пакетов (charts).

Релиз — это пример пакетов, работающих в кластере Kubernetes. Один пакет может быть установлен много раз в одном и том же кластере.

Инсталлятор Helm устанавливает пакеты в Kubernetes, создавая новый релиз для каждой установки. А для поиска новых графиков можно воспользоваться поиском Helm chart repositories.

Поиск Charts#

Инсталлятор Helm содержит поисковую команду для поиска двух различных типов источников:

helm search hub ищет в репозитории «the Artifact Hub», который агрегирует списки из различных хранилищ;
helm search repo поиск в репозиториях, которые добавлены в локальный каталог helm client (используя helm repo add). Этот поиск выполняется по локальным данным, не используя подключение к публичной сети.

Вы можете найти общедоступные пакеты, запустив helm search hub:

$ helm search hub wordpress
URL                                                 CHART VERSION APP VERSION DESCRIPTION
https://hub.helm.sh/charts/bitnami/wordpress        7.6.7         5.2.4       Web publishing platform for building blogs and ...
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.6.3        v0.6.3      Presslabs WordPress Operator Helm Chart
https://hub.helm.sh/charts/presslabs/wordpress-...  v0.7.1        v0.7.1      A Helm chart for deploying a WordPress site on ...

Поиск показывает все доступные пакеты с определенным именем helm search hub.

Используя helm search repo, можно найти названия пакетов в уже добавленных репозиториях:

$ helm repo add brigade https://brigadecore.github.io/charts
"brigade" has been added to your repositories
$ helm search repo brigade
NAME                          CHART VERSION APP VERSION DESCRIPTION
brigade/brigade               1.3.2         v1.2.1      Brigade provides event-driven scripting of Kube...
brigade/brigade-github-app    0.4.1         v0.2.1      The Brigade GitHub App, an advanced gateway for...
brigade/brigade-github-oauth  0.2.0         v0.20.0     The legacy OAuth GitHub Gateway for Brigade
brigade/brigade-k8s-gateway   0.1.0                     A Helm chart for Kubernetes
brigade/brigade-project       1.0.0         v1.0.0      Create a Brigade project
brigade/kashti                0.4.0         v0.4.0      A Helm chart for Kubernetes

Helm search использует приближенный поиск подстроки (fuzzy string matching) по части слова или фразы:

$ helm search repo kash
NAME            CHART VERSION APP VERSION DESCRIPTION
brigade/kashti  0.4.0         v0.4.0      A Helm chart for Kubernetes

Установка пакета#

Для установки нового пакета используется команда helm install. В штатном режиме она ожидает два аргумента: имя выпуска _release_name_, и имя пакета, который необходимо установить. Пример:

$ helm install ххххх bitnami/wordpress
NAME: ххххх
LAST DEPLOYED: Tue Jan 31 10:27:17 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    ххххх-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w ххххх-wordpress'

export SERVICE_IP=$(kubectl get svc --namespace default ххххх-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo "WordPress URL: http://$SERVICE_IP/"
echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

echo Username: user
echo Password: $(kubectl get secret --namespace default ххххх-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

После установки пакета wordpress создается новый объект release.

Примечание. Инсталлятор Helm для завершения работы не требует запуск всех ресурсов.

Для отслеживания состояния релиза или считывания информации о конфигурации выполните команду helm status. Пример:

$ helm status ххххх
NAME: ххххх
LAST DEPLOYED: Tue Jan 31 10:27:17 2022
NAMESPACE: default
STATUS: deployed
REVISION: 1
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    ххххх-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

NOTE: It may take a few minutes for the LoadBalancer IP to be available.
Watch the status with: 'kubectl get svc --namespace default -w ххххх-wordpress'

export SERVICE_IP=$(kubectl get svc --namespace default ххххх-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
echo "WordPress URL: http://$SERVICE_IP/"
echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

echo Username: user
echo Password: $(kubectl get secret --namespace default ххххх-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

Настройка пакета перед установкой#

Для отображения параметров в пакете выполните команду helm show values. Пример:

$ helm show values bitnami/wordpress
## Global Docker image parameters
## Please, note that this will override the image parameters, including dependencies, configured to use the global value
## Current available global Docker image parameters: imageRegistry and imagePullSecrets
##
# global:
#   imageRegistry: myRegistryName
#   imagePullSecrets:
#     - myRegistryKeySecretName
#   storageClass: myStorageClass

## Bitnami WordPress image version
## ref: https://hub.docker.com/r/bitnami/wordpress/tags/
##
image:
registry: docker.io
repository: bitnami/wordpress
tag: 5.6.0-debian-10-r35
[..]

Для настройки параметров в файле формата YAML и передачи файла во время установки:

$ echo '{user.auth.database: user0db, mariadb.auth.username: user0}' > values.yaml
$ helm install -f values.yaml bitnami/wordpress --generate-name

Существует два способа передачи конфигурационных данных во время установки:

--values (или -f): передача YAML-файла с конфигурацией. Файл возможно передать несколько раз, но самый правый файл имеет больший приоритет;
--set: переопределения в командной строке. Если используются оба параметра, то значения --set объединяются в --values с более высоким приоритетом. Переопределения, указанные с помощью --set, сохраняются в ConfigMap. Значения просматриваются для данного выпуска с помощью helm get values <release-name>. Значения --set, можно очистить, выполнив команду helm upgrade с --reset-values.

Формат и ограничения#

Параметр --set используется следующим образом: --set name=value. Пример в YAML-формате:

name: value

Несколько значений разделяются символом ,. Пример --set a=b,c=d в YAML-формате:

a: b
c: d

Также поддерживаются более сложные выражения. Например, --set outer.inner=value.

outer:
inner: value

Обновление релиза и восстановление после сбоя#

Для выпуска новой версии пакета или изменения конфигурация релиза выполните команду helm upgrade.

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

$ helm upgrade -f panda.yaml ххххх bitnami/wordpress

Для контроля работы версии выполните команду helm get values. Пример:

$ helm get values ххххх
mariadb:
auth:
username: user1

Для возврата к предыдущему выпуску выполните команду helm rollback [RELEASE] [REVISION].

Удаление релиза#

Когда потребуется удалить релиз из кластера, используйте команду helm uninstall:

$ helm uninstall ххххх

Для просмотра текущих развернутых релизов выполните команду helm list:

$ helm list
NAME            VERSION UPDATED                         STATUS          CHART
inky-cat        1       Wed Sep 28 12:59:46 2016        DEPLOYED        alpine-0.1.0

Флаг helm list --all отображает все релизы, сохраненные Helm, включая записи для неудачных или удаленных элементов (если был указан параметр --keep-history):

$  helm list --all
NAME     VERSION UPDATED                      STATUS          CHART
ххххх    2       Wed Sep 28 12:47:54 2016     UNINSTALLED     wordpress-10.4.5.6.0
ххххх2   1       Wed Sep 28 12:59:46 2016     DEPLOYED        alpine-0.1.0
ххххх3   2       Tue Sep 27 16:16:10 2016     UNINSTALLED     alpine-0.1.0

Работа с репозиториями#

Для отображения настроенных репозиториев выполните команду helm repo list:

$ helm repo list
NAME            URL
stable          https://charts.helm.sh/stable
mumoshu         https://mumoshu.github.io/charts

Для добавления новых репозиториев выполните команду helm repo add:

$ helm repo add dev https://example.com/dev-charts

Для обновления информации о клиентах в инсталляторе Helm выполните команду helm repo update.

Для удаления репозиториев выполните команду helm repo remove.

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

Для быстрого начала работы с инсталляторов Helm выполните команду helm create:

$ helm create deis-workflow
Creating deis-workflow

В созданном пакете ./deis-workflow создайте и при необходимости отредактируйте шаблоны.

Для упаковки chart в пакет и дальнейшей его передачи выполните команду helm package:

$ helm package deis-workflow
deis-workflow-0.1.0.tgz

Для установки пакета chart в инсталлятор Helm выполните команду helm install:

$ helm install deis-workflow ./deis-workflow-0.1.0.tgz
...

Установка сервисов Batch на один namespace#

Для установки сервисов Batch Scheduler и Batch Tasks на один namespace с использованием инсталлятора Helm необходимо открыть, заполнить и вставить каждый манифест (пакет) командой helm install в определенном порядке и с параметрами, приведенными в разделе «Автоматизированная установка сервиса через Install_EIP».

Установка Batch Tasks в среде контейнеризации#

Для установки сервиса Batch Tasks в среде контейнеризации с использованием инсталлятора Helm необходимо открыть, заполнить и вставить каждый манифест (пакет) командой helm install в определенном порядке и с параметрами, приведенными в разделе «Автоматизированная установка сервиса через Install_EIP».

Автоматизированная установка сервиса через Install_EIP#

Общая схема процесса автоматизированного развертывания сервиса Batch с помощью Jenkins Job Install_EIP:

$@startuml skinparam shadowing false !pragma layout smetana start -[#black]-> #white : Обеспечение выполнения пререквизитов; -[#black]-> #white : Обеспечение выполнения требований подготовки окружения: \n 1. Настройка namespace в среде контейнеризации \n 2. Подготовка базы данных \n 3. Оформление доступа ТУЗ к репозиторию с Docker-образами \n 4. Настройка jenkins-токена для подключения Install_EIP к \n среде контейнеризации; -[#black]-> #white : Выполнить запуск автоматического развертывания сервиса \n с помощью Jenkins Job Install_EIP; -[#black]-> stop @enduml$

Шаги выполнения автоматизированной установки сервиса Batch Tasks#

Согласно вышеприведенной схеме процесса для автоматизированного развертывания сервиса Batch Tasks с помощью Jenkins Job Install_EIP выполните следующие действия:

Обеспечьте выполнение пререквизитов.
Подготовьте окружение:
1. Настройте namespace в среде контейнеризации.
2. Подготовьте базы данных.
3. Оформите доступ ТУЗ к репозиториям с Docker-образами.
4. Получите jenkins-токен для подключения Install_EIP к среде контейнеризации.
Запустите автоматизированную установку Batch Tasks с помощью Jenkins Job Install_EIP.

Настройка Jenkins Job Install_EIP#

Для развертывания сервиса Batch Tasks в среде контейнеризации выполните настройку Jenkins Job Install_EIP:

Получите доступ к репозиторию с конфигурацией и скриптами Install_EIP.
Настройте конфигурации приложения.
Создайте файловую подструктуры проекта.
Отредактируйте файлы конфигурации Job Install_EIP.
Передайте секретные данные (логины/пароли).
Настройте интеграцию со смежными сервисами.

Получение jenkins-токена для подключения Install_EIP к среде контейнеризации#

Внимание

Действия, указанные ниже, обязательны в случае развертывания сервиса с помощью Jenkins Job Install_EIP.

Для получения jenkins-токена для подключения Install_EIP к среде контейнеризации:

Выполните вход в выданную проектную область (проект) в среде контейнеризации под ролью Administrator.
Перейдите в раздел User Management → Service Accounts.
Выберите service account с именем jenkins.
Из списка Secrets внизу выберите секрет с именем jenkins-token.
В списке Data выберите token и нажмите справа кнопку Копировать.

Копирование из текста YAML дает другой результат, чем копирование по кнопке из UI. Проверить корректность копирования токена можно командой (на соответствующее пространство):

   #Команда:
   $> oc login api.dev-gen2.xxxxx.ru:6443 --token eyJhbG...2cJA --insecure-skip-tls-verify
   #Результат:
   Logged into "https://api.dev-gen2.xxxxx.ru:6443" as "system:serviceaccount:ci00641491-edevgen2-batch-scheduler-dev-ga:jenkins" using the token provided.
   You don't have any projects. Contact your system administrator to request a project.

Отправьте письмо команде Install_EIP с указанием данного токена, подсистемы и стенда.

Ответным письмом будет отправлен id токена, который укажите в файле os_namespaces.yml и в файле actions.xml, если в нем есть поле oc_token.

Настройка доступа к UI сервиса#

Сервис Batch Tasks предоставляет режим инсталляции с доступом к UI в режиме ReadOnly с помощью конфигурации развертывания.

Подробнее о режиме ReadOnly для Batch Tasks UI см. в Руководстве по системному администрированию в разделе «Использование режима ReadOnly для Batch Tasks UI».

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

Для настройки Jenkins Job Install_EIP получите доступ к GitLab-репозиторию с конфигурацией и скриптами для развертывания сервиса посредством Install_EIP.

Конфигурирование приложения#

Все действия выполните в репозитории конфигураций и скриптов Install_EIP.

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

Откройте файл configuration.xml в корневой директории репозитория.
Добавьте секцию Subsystem для ссылки на файл запуска скриптов:

   <?xml version="1.0" encoding="UTF-8"?>
   <Configuration>
        <Core>
            <Subsystem name="PPRB_BatchTasks">
                <InstallFiles/>
                <Actions>config/${env.Stand}/${env.Subsystem}/actions.xml</Actions>
            </Subsystem>
           ...
       </Core>
       ...
   </Configuration>

В секции Subsystems заполните параметры конфигурации для стендов:

   <?xml version="1.0" encoding="UTF-8"?>
   <Configuration>
       ...
       <Subsystems>
            <Subsystem name="PPRB_BatchTasks" description="BATCH Tasks">
                <MailList name="Users">
                    <file>config/${env.Stand}/${env.Subsystem}/mailto.txt</file>
                    <attachLog>true</attachLog>
                    <attachPattern>tableARM.html,log.zip</attachPattern>
                </MailList>
                <MailList name="Admins">
                    <file>config/${env.Stand}/${env.Subsystem}/mailto_admins.txt</file>
                    <attachLog>true</attachLog>
                    <attachPattern>tableARM.html,log.zip</attachPattern>
                </MailList>
                <Stand name="каталог стенда" description="Стенд разработки"/>
            </Subsystem>
            ...
       </Subsystems>
       ...
   </Configuration>

В теге <Stand name="каталог стенда" ...> укажите имя каталога, в котором расположены файлы конфигурации Install_EIP для автоматической установки сервиса.

Создание файловой подструктуры проекта#

Для создания файловой подструктуры проекта:

Создайте папку, соответствующую стенду, который указан при конфигурировании, например: Stand name="DEV_BatchTasks".
В созданной папке стенда создайте папку, соответствующую подсистеме, например: Subsystem name="PPRB_BatchTasks".
В созданной папке подсистемы создайте:
1. Файлы конфигурации Jenkins Job Install_EIP:
  - actions.xml — действия (шаги), которые будет выполнять Jenkins Job;
  - ansible.cfg — конфигурационный файл Ansible (конфигурирование Ansible);
  - mailto_admins.txt — список e-mail (или групповой e-mail) команды поддержки Install_EIP;
  - os_ignore.conf — список масок файлов, которые будут исключаться при развертывании сервиса;
  - os_namespaces.yml — информация о проекте в среде контейнеризации и ссылки на файлы с конфигурационными параметрами для этих проектов;
  - os_props.conf — конфигурационные параметры для установки (имя файла, используемое по умолчанию, которое можно переопределить в os_namespaces.yml);
  - os_yaml_dirs.conf — относительные пути yaml-файлов для развертывания в среде контейнеризации;
  - password.conf — файл для обратной совместимости (пустой);
  - system.conf — файл системных конфигураций;
  - liquibase.batch.scheduler.conf — настройка схемы данных с использованием Liquibase для основной БД;
  - liquibase.batch.scheduler.si.conf — настройка схемы данных с использованием Liquibase для реплицируемой БД.
2. Каталог openshift/certs с подкаталогами, которые соответствуют названиям секретов в среде контейнеризации.

Редактирование файлов конфигурации Jenkins Job Install_EIP#

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

Настройка action.xml:
- поставка политики авторизации;
- настройка установки схемы данных с использованием Liquibase.
Настройка mailto_admins.txt.
Настройка os_ignore.conf.
Настройка os_namespaces.yml.
Настройка os_yaml_dirs.conf.
Настройка system.conf.
Настройка os_props.conf.

Настройка action.xml#

В файл action.xml добавляются шаги для развертывания приложения.

Поставка политики авторизации (опционально)

Политика авторизации должна быть размещена на узлах компонента Объединенный сервис авторизации продукта Platform V IAM SE (далее — ОСА) в определенной папке, которая задается с помощью настройки policyBasePath. В дистрибутиве политика хранится в папке /other/abac.

При автоматизированной установке сервиса копирование политики из дистрибутива на узлы ОСА осуществляется с помощью отдельного шага Install_EIP. Этот шаг описывается следующим образом:

<Action name="spas_abac_copy" visible="true">
  <context />
  <mode>all</mode>
  <default>true</default>
  <Description>Раскладка политик spas</Description>
  <type>groovy</type>
  <Script>bin/run_with_password_tool26.groovy action_script=bin/copy_directory_data.yml hosts_group_WF=SPAS.Core key_id=vault_cred</Script>
</Action>

Для этого шага требуется задать необходимые параметры в system.conf.

Пример action.xml с настройкой политик компонента Объединенный сервис авторизации

Пример настройки action.xml с шагами:

Создайте/обновите схемы данных БД посредством Liquibase на основную (main) базу. Является обязательным шагом для установки сервиса.
Создайте/обновите схемы данных БД посредством Liquibase на реплицируемую (Stand-In) базу. Не является обязательным шагом для установки сервиса.
Настройте раскладки политик ОСА (Подсистема доступа). Не является обязательным шагом.
Разверните приложение в среде контейнеризации.

Пример actions.xml с настройкой политик ОСА (SPAS):

<?xml version="1.0" encoding="UTF-8"?>
<Actions>
  <Deploy>
    <!-- Данный блок говорит Job Install-EIP о том, что нужно выполнить шаг по установке на основную (main) базу схемы (таблицы) сервиса Batch.Tasks, необходимого для его работы. -->
    <Action name="liquibase_update_batch_tasks" visible="true">
      <context/>
      <default>true</default>
      <Description>Обновление liquibase(BATCH_TASKS)</Description>
      <type>groovy</type>
      <Script>bin/run_with_password_tool26.groovy action_script=bin/liquibase_migrate.yml system_conf_WF=liquibase.batch.tasks.conf key_id=vault_cred</Script>
    </Action>

    <!-- Данный блок говорит Job Install-EIP о том, что нужно выполнить шаг по установке на реплицируемую базу схемы (таблицы) сервиса Batch.Tasks.
         Наличие репликационной базы не является обязательным для работы сервиса, поэтому данный шаг может быть исключен из данной конфигурации. -->
    <Action name="liquibase_update_batch_tasks_si" visible="true">
      <context/>
      <default>true</default>
      <Dependency onFail="Skip">liquibase_update_batch_tasks</Dependency>
      <Description>Обновление liquibase(BATCH_TASKS SI)</Description>
      <type>groovy</type>
      <Script>bin/run_with_password_tool26.groovy action_script=bin/liquibase_migrate.yml system_conf_WF=liquibase.batch.tasks.si.conf key_id=vault_cred</Script>
    </Action>

    <!-- Данный блок говорит Job Install-EIP о том, что нужно выполнить шаг по установке политик SPAS (Подсистема доступа). -->
    <Action name="spas_abac_copy" visible="true">
      <context />
      <mode>all</mode>
      <default>true</default>
      <Dependency onFail="Skip">liquibase_update_batch_scheduler</Dependency>
      <Dependency onFail="Skip">liquibase_update_batch_scheduler_si</Dependency>
      <Description>Раскладка политик spas</Description>
      <type>groovy</type>
      <Script>bin/run_with_password_tool26.groovy action_script=bin/copy_directory_data.yml hosts_group_WF=SPAS.Core key_id=vault_cred</Script>
    </Action>

    <!-- Данный блок говорит Job Install-EIP о том, что нужно установить сервис Batch.Tasks в выделенном namespace среды контейнеризации -->
    <Action name="deploy_to" visible="true">
      <context/>
      <mode>all</mode>
      <default>true</default>
      <Dependency onFail="Skip">liquibase_update_batch_tasks</Dependency>
      <Dependency onFail="Skip">liquibase_update_batch_tasks_si</Dependency>
      <Dependency onFail="Skip">spas_abac_copy</Dependency>
      <Description>Установка приложения в среде контейнеризации</Description>
      <type>groovy</type>
      <Script>bin/deploy_to_multi.groovy</Script>
    </Action>
  </Deploy>
</Actions>

Настройка установки схемы данных с использованием Liquibase

Для указания пароля пользователя, под которым будет производиться выполнение скриптов, в репозитории install_eip в group_vars/main.yml задайте это имя и зашифрованное значение пароля (шифрование производите специальной Job ANSIBLE_VAULT_file).

Основная база данных

Создайте конфигурационный файл liquibase.batch.tasks.conf и укажите его для ключа system_conf_WF в соответствующем шаге.

Пример настройки файла с конфигурационными параметрами Liquibase для основной БД:

liquibase_log: changelog-main.xml
liquibase_basedir: "distrib/db/postgresql/xml"
liquibase_user: owner_schema_user_name
liquibase_pass: "{{batch_tasks_owner_user_pass}}"
liquibase_version: "3.7.0"
liquibase_params: "--url=jdbc:postgresql://IP:PORT/database_name?currentSchema=target_schema_name --changeLogFile={{ liquibase_log }} --logLevel=info update  -Dapp_user=tasks_appl_user"

В примере выше:

liquibase_log — имя файла с журналом выполнения установки с использованием скриптов Liquibase;
liquibase_basedir — путь до файла changelog.xml (исключая distrib/);
liquibase_user — пользователь, под которым будет производиться выполнение скриптов (владелец схемы);
liquibase_pass — зашифрованный пароль пользователя, под которым будет производиться выполнение скриптов;
liquibase_version — версия библиотеки Liquibase;
liquibase_params — набор параметров Liquibase, включая полный jdbc_url с указанием схемы, уровня журналирования и прикладного пользователя, которому необходимо предоставить права на созданные объекты.

Реплицируемая база данных

Создайте конфигурационный файл liquibase.batch.tasks.si.conf и укажите его для ключа system_conf_WF в соответствующем шаге.

Пример настройки файла с конфигурационными параметрами Liquibase для репликационной БД:

liquibase_log: changelog-si.xml
liquibase_basedir: "distrib/db/postgresql/xml"
liquibase_user: owner_schema_user_name
liquibase_pass: "{{TASKS_OWNER_PASSWORD_SI}}"
liquibase_version: "3.7.0"
liquibase_params: "--url=jdbc:postgresql://IP:PORT/database_name?currentSchema=target_schema_name --changeLogFile={{ liquibase_log }} --logLevel=info update  -Dapp_user=tasks_appl_user"

В примере выше:

liquibase_log — имя файла с журналом выполнения установки с использованием скриптов Liquibase;
liquibase_basedir — путь до файла changelog-si.xml (исключая distrib/);
liquibase_user — пользователь, под которым будет производиться выполнение скриптов (владелец схемы);
liquibase_pass — пароль пользователя, под которым будет производиться выполнение скриптов;
liquibase_version — версия библиотеки Liquibase;
liquibase_params — набор параметров Liquibase, включая полный jdbc_url с указанием схемы, уровня журналирования и прикладного пользователя, которому необходимо предоставить права на созданные объекты.

Пример action.xml

Пример настройки action.xml с шагами:

Создайте/обновите схемы данных БД посредством Liquibase на основную (main) базу. Является обязательным шагом для установки сервиса.
Создайте/обновите схемы данных БД посредством Liquibase на реплицируемую (Stand-In) базу. Не является обязательным шагом для установки сервиса.
Разверните приложение в среде контейнеризации.

Пример actions.xml без настройки политик ОСА (SPAS):

<?xml version="1.0" encoding="UTF-8"?>
<Actions>
  <Deploy>
    <!-- Данный блок говорит Job Install-EIP о том, что нужно выполнить шаг по установке на основную (main) базу схемы (таблицы) сервиса Batch.Tasks, необходимого для его работы. -->
    <Action name="liquibase_update_batch_tasks" visible="true">
      <context/>
      <default>true</default>
      <Description>Обновление liquibase(BATCH_TASKS)</Description>
      <type>groovy</type>
      <Script>bin/run_with_password_tool26.groovy action_script=bin/liquibase_migrate.yml system_conf_WF=liquibase.batch.tasks.conf key_id=vault_cred</Script>
    </Action>

    <!-- Данный блок говорит Job Install-EIP о том, что нужно выполнить шаг по установке на реплицируемую базу схемы (таблицы) сервиса Batch.Tasks.
         Наличие stand-in базы не является обязательным для работы сервиса, поэтому данный шаг может быть исключен из данной конфигурации. -->
    <Action name="liquibase_update_batch_tasks_si" visible="true">
      <context/>
      <default>true</default>
      <Dependency onFail="Skip">liquibase_update_batch_tasks</Dependency>
      <Description>Обновление liquibase(BATCH_TASKS SI)</Description>
      <type>groovy</type>
      <Script>bin/run_with_password_tool26.groovy action_script=bin/liquibase_migrate.yml system_conf_WF=liquibase.batch.tasks.si.conf key_id=vault_cred</Script>
    </Action>

    <!-- Данный блок говорит Job Install-EIP о том, что нужно установить сервис Batch.Tasks в выделенном namespace среды контейнеризации -->
    <Action name="deploy_to_openshift" visible="true">
      <context/>
      <mode>all</mode>
      <default>true</default>
      <Dependency onFail="Skip">liquibase_update_batch_tasks</Dependency>
      <Dependency onFail="Skip">liquibase_update_batch_tasks_si</Dependency>
      <Description>Установка приложения в среде контейнеризации</Description>
      <type>groovy</type>
      <Script>bin/deploy_to_openshift_multi.groovy</Script>
    </Action>
  </Deploy>
</Actions>

Запись вида:

<Dependency onFail="Skip">имя предыдущего шага</Dependency>

означает, что последующий шаг развертывания приложения зависит от предыдущего.

Настройка mailto_admins.txt#

Для настройки mailto_admins.txt требуется сконфигурировать список администраторов (или группу) для получения уведомлений об отработке Job Install_EIP.

Настройка os_ignore.conf#

В файле os_ignore.conf укажите маски файлов, которые необходимо исключить при развертывании дистрибутива. Если дистрибутив не содержит файлов, которые нужно исключить при развертывании, то данный шаг следует пропустить.

Настройка os_namespaces.yml#

В os_namespaces.yml укажите информацию о том, куда производить развертывание дистрибутива и откуда считывать конфигурационные параметры.

Пример os_namespace.yml:

projects:
- name: "Имя проекта"
  openShiftNamespace: "namespace среды контейнеризации"
  openShiftURL: api.openShiftUrl:6443
  oc_token: Jenkins service account Token name из ответного письма сопровождения Install_EIP
  os_props: "os_props.conf" # Путь до файла с конфигурационными параметрами
  uniqueParams:
    destination-rule-egress-tenant.yml: # Наименование файла, для которого задаются значения плейсхолдера
      TENANT_NAME: # Наименование плейсхолдера, для которого передаются нижеследующие значения
        - httptarget-http
        - httptarget-https
      ...
    ...

Пояснения:

В параметр запуска скрипта oc_token передается идентификатор учетных данных, содержащий токен сервисной учетной записи Jenkins из среды контейнеризации, который был получен в ответном письме от команды сопровождения Install_EIP. Подробнее в разделе «Репозиторий конфигураций и скриптов Install_EIP».
В параметр uniqueParams указываются наименования файлов с набором значений для передаваемых параметров.

В частности, в uniqueParams задаются значения для serviceEntry, destinationRule, которые необходимы для корректной работы Istio-proxy и выполнения запросов из namespace.

При выполнении Jenkins Job Install_EIP будет сгенерировано несколько файлов с префиксом-числом — номером версии файла: в один попадут первые значения всех плейсхолдеров, во второй — вторые и так далее.

Такой подход позволяет из одного шаблона сгенерировать несколько файлов с разными значениями, которые будут использоваться для вызовов на несколько разных HTTP-Target.

Например, для tenant/destination-rule-egress-tenant.yml с параметром name — batch-tasks-egress-dr-{{TENANT_NAME}} будут сгенерированы две версии файла: одна будет хранить описание сущности destinationRule с именем batch-tasks-egress-dr-httptarget-http, а другая — batch-tasks-egress-dr-httptarget-https.

Настройка os_yaml_dirs.conf#

В файл os_yaml_dirs.conf помещаются относительные пути до yaml-файлов для развертывания дистрибутива.

Пример os_yaml_dirs.conf:

# Список папок поставки, содержащих YAML-манифесты. Формат записи:
# /dir-1
# /dir-1/subdir-1
# /configs

/configs

# Ingress
## Общие файлы конфигурации Ingress
/configs/ingress
## Конфигурация virtualService
/configs/ingress/virtual-service

# Egress
## Общие файлы конфигурации Egress
/configs/egress
## Конфигурация под тенант
/configs/egress/tenant
## Конфигурация под основную и репликационную БД
/configs/egress/db

# Конфигурация OTT
## Для включения OTT в установку через Install_EIP включить /configs/ingress/deployment-ott, /configs/egress/deployment-ott и исключить /configs/ingress/deployment, /configs/egress/deployment.
## Для исключения OTT - включить /configs/ingress/deployment, /configs/egress/deployment и исключить /configs/ingress/deployment-ott, /configs/egress/deployment-ott
/configs/ingress/deployment-ott
/configs/egress/deployment-ott
# /configs/ingress/deployment
# /configs/egress/deployment

# Файлы конфигурации внутреннего mTLS
## Для отключения внутреннего mTLS на стенде - исключить
/configs/inner-mtls

# HTTP-routes (небезопасные маршруты)
# /configs/insecure

# Файлы конфигураций микросервисов Batch Tasks
/configs/tasks-server
/configs/tasks-worker
/configs/tasks-journal-applier
/configs/tasks-gc

# UI
## Общие файлы конфигурации UI
/configs/tasks-ui

## Конфигурация UI для одного сервиса
## Включить ui-per-one-service и исключить ui-unified при установке на стенд только Batch Tasks или при установке раздельных UI для каждого сервиса
# /configs/tasks-ui/ui-per-one-service

## Конфигурация единого UI
## Включить ui-unified и исключить ui-per-one-service при установке на стенд единого UI и при развертывании на один стенд двух сервисов: Batch Tasks и Batch Scheduler
/configs/tasks-ui/ui-unified

Настройка system.conf#

В файле системных конфигураций system.conf указываются, в том числе хост и namespace среды контейнеризации.

Пример system.conf:

openShiftURL: <!- заполните самостоятельно ->
openShiftNamespace: "<!- заполните самостоятельно ->"

resources_dir_path: "{{ hostvars[groups['SPAS.Core'][0]]['spas_abac_policy'] }}"
src_path: '/other/abac'
clear_old_data: 'false'

Где:

resources_dir_path — путь к папке, куда копировать файлы, берется из конфигуратора, из настроек самого SPAS. В данном случае предполагается, что группа узлов, на которых установлен SPAS, называется SPAS.Core. Если это не так, нужно заменить SPAS.Core на актуальное название в обоих файлах (actions.xml и system.conf);
src_path — путь к папке (/other/abac) в дистрибутиве модуля, откуда будут копироваться политики авторизации.

Настройка os_props.conf#

Файл os_props.conf используется непосредственно для передачи конфигурационных параметров в конфигурацию среды контейнеризации (configMap, deploymentConfig и другие).

В дистрибутиве в каталоге /installрасположены примеры файлов конфигурации os_props.conf, которые можно использовать при заполнении файла для целевого стенда. Значения из os_props.conf применяются к YAML-конфигурациям развертывания, представленным в дистрибутиве поставки.

Внимание

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

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

Полный список конфигурационных параметров os_props.conf расположен в директории дистрибутива по пути: batch-tasks/tasks-distrib/install/conf/os_props.conf.prod.yaml.

Список конфигурационных параметров os_props.conf#

Полный список конфигурационных параметров приведен в директории дистрибутива: batch-tasks/tasks-distrib/install/conf/os_props.conf.prod.yaml.

Передача и использование секретных данных#

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

Передача секретных данных в среду контейнеризации.
Использование секретных данных при выполнении шагов развертывания (например, для добавления скриптов с использованием библиотеки Liquibase).

В первом случае необходимо передать в среду контейнеризации секрет, во втором — просто хранить секретные данные, которые будут использоваться при работе Jenkins Job.

Перечень необходимых секретов#

В каталоге /install/secrets дистрибутива представлены шаблоны секретов для инсталляции.

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

Наименование секрета	Описание
`batch-tasks-app-secret.yml`	Секрет, содержащий в зашифрованном виде: ключ для интеграции со SPAS, пароль для доступа к основной БД, имя пользователя для доступа к основной БД, пароль для доступа к репликационной БД, имя пользователя для доступа к репликационной БД, пароль для доступа к ключу SSL, пароль для доступа к хранилищу ключей (keystore) SSL, пароль для доступа к хранилищу доверительных сертификатов (truststore) SSL
`batch-tasks-application-journal-certs.yml`	Секрет, определяющий сертификаты Journal Applier для подключения к компоненту Kafka SE продукта Platform V Corax
`batch-tasks-db-certs-secret.yml`	Секрет, определяющий сертификаты для подключения к БД по TLS: корневой сертификат, клиентский сертификат (публичный), клиентский ключ (закрытый)
`batch-tasks-ott-certs.yml`	Секрет, определяющий OTT-сертификаты
`batch-tasks-ott-passwords.yml`	Секрет с паролями к ключам OTT
`docker-registry-sigma.yml`	Секрет, содержащий в зашифрованном виде JSON с учетными данными ТУЗ для доступа в Docker-репозиторий
`istio-egressgateway-ca-certs.yml`	Секрет, содержащий объединенные корневой и промежуточный сертификаты egressgateway-ca
`istio-egressgateway-certs.yml`	Секрет, определяющий серверный сертификат и ключ от серверного сертификата egressgateway
`istio-ingressgateway-ca-certs.yml`	Секрет, содержащий объединенные корневой и промежуточный сертификаты ingressgateway-ca
`istio-ingressgateway-certs.yml`	Секрет, определяющий серверный сертификат и ключ от серверного сертификата ingressgateway

Передача секретных данных в среду контейнеризации#

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

Создайте папку подсистемы openshift/certs, если она не существует.
В папке /certs создайте вложенную папку, соответствующую названию секрета в среде контейнеризации. Например: batch-tasks-app-secret.
Создайте файлы, каждый из которых содержит секретную информацию, например, пароль. Названия файлов должны соответствовать именам ключей в создаваемом секрете.
Выполните шифрование файлов Jenkins Job ANSIBLE_VAULT_file. В результате шифрования секрет приходит инициатору запуска шифрования.

«Волтовка» — шифрование данных по Ansible-алгоритму. Подробнее о «волтовке» приведено по ссылке.
Поместите зашифрованные файлы в папку openshift/certs/{secret_name}, например: openshift/certs/batch-tasks-app-secret.

Пример database.main.password:

   $ANSIBLE_VAULT;1.1;AES256
   66..<!- много цифр ->...55

Соответствующие секреты в среде контейнеризации создаются автоматически при отработке Jenkins Job Install_EIP.

Использование секретных данных при выполнении шагов развертывания#

В файле конфигурации liquibase.batch.tasks.conf, созданном при выполнении шага установки скриптов Liquibase, присутствует обращение к переменной с зашифрованными данными:

liquibase_pass: "{{owner_schema_user_password}}"

Для подстановки этого параметра укажите его в зашифрованном виде в файле group_vars/all/main.yml стенда (например: DEV_BatchTasks/group_vars/all/main.yml). Если файла main.yml по указанному пути не существует, создайте его.

В файле main.yml заведите соответствующую переменную:

owner_schema_user_password: !vault |
  $ANSIBLE_VAULT;1.1;AES256
  35...<!- много цифр ->&..22

# Вместо owner_schema_user_password необходимо подставить конкретное название используемого параметра.

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

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

настройка интеграции с компонентом Аудит продукта Platform V Audit SE;
настройка интеграции c компонентом Объединенный сервис авторизации продукта Platform V IAM SE;
настройка интеграции с компонентом Объединенный мониторинг Unimon продукта Platform V Monitor;
настройка интеграции с компонентом Журналирование продукта Platform V Monitor;
настройка интеграции с продуктом Platform V One-Time-Token;
настройка интеграции с компонентом Прикладной журнал продукта Platform V Data Tools.
настройка интеграции с компонентом IAM Proxy продукта Platform V IAM SE.

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

Для настройки интеграции сервиса Batch Tasks с компонентом Аудит в os_props.conf сконфигурируйте следующие параметры:

# <!- заполните самостоятельно -> - значения параметров необходимо заполнить самостоятельно перед развертыванием сервиса

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

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

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

При необходимости внесения изменений в интеграцию сервиса Batch Tasks с внешними сервисами внесите соответствующие правки в os_props.conf, после чего выполните повторный запуск Jenkins Job Install_EIP сервиса Batch Tasks согласно соответствующей инструкции.

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

Примеры заполнения os_props.conf для интеграции с компонентом Аудит

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

HTTPS-endpoint https://audit2-client-proxy.apps.dev-gen.xxxxx.ru:

  TASKS_SERVER_AUDIT_ENABLED=true
  TASKS_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-gen.xxxxx.ru
  TASKS_SE_AUDIT_PORT=443
  TASKS_SE_AUDIT_PROTOCOL=tls
  TASKS_SE_AUDIT_TLS_MODE=MUTUAL

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

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

  TASKS_SERVER_AUDIT_ENABLED=true
  TASKS_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-gen.xxxxx.ru
  TASKS_SE_AUDIT_PORT=80
  TASKS_SE_AUDIT_PROTOCOL=http
  TASKS_SE_AUDIT_TLS_MODE=DISABLE

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

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

  TASKS_SERVER_AUDIT_ENABLED=true
   TASKS_SE_AUDIT_HOST=audit2-client-proxy.apps.dev-gen.xxxxx.ru
  # Обратите внимание, что в TASKS_SE_AUDIT_PORT указывается нужный endpoint port.
  TASKS_SE_AUDIT_PORT=9080
  TASKS_SE_AUDIT_PROTOCOL=http
  TASKS_SE_AUDIT_TLS_MODE=DISABLE

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

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

Для настройки сервиса Batch Tasks без интеграции компонента Аудит в os_props.conf сконфигурируйте следующие параметры:

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

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_AUDIT_HOST=tkled-pprb00001.vm.esrt.cloud.xxx.ru
# В TASKS_SE_AUDIT_PORT указывается нужный endpoint port.
TASKS_SE_AUDIT_PORT=443
## Используемый протокол: https/http
TASKS_SE_AUDIT_PROTOCOL=https

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

Настройка интеграции c компонентом Объединенный сервис авторизации продукта Platform V IAM SE#

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

Для корректной настройки интеграции сервиса Batch Tasks с ОСА обеспечьте выполнение следующих пререквизитов:

Подключите сервис Batch Tasks к ABAC (Attribute — Based Access Control) (подробнее см. в Руководстве по системному администрированию в разделе «Подключение сервиса к ABAC и загрузка справочника атрибутов»).
Загрузите справочник атрибутов.

Для настройки интеграции сервиса Batch Tasks с ОСА в os_props.conf сконфигурируйте следующие параметры:

# <!- заполните самостоятельно -> — значения параметров необходимо заполнить самостоятельно перед развертыванием сервиса

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_SPAS_HOST=<!- заполните самостоятельно ->
TASKS_SE_SPAS_PORT=<!- заполните самостоятельно ->
## Используемый протокол: tls/http
TASKS_SE_SPAS_PROTOCOL=<!- заполните самостоятельно: tls/http ->

# MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls, DISABLE для http
TASKS_SE_SPAS_TLS_MODE=<!- заполните самостоятельно: MUTUAL/DISABLE ->

При необходимости внесения изменений в интеграцию Batch Tasks с внешними сервисами внесите соответствующие правки в os_props.conf, после чего выполните повторный запуск Jenkins Job Install_EIP сервиса Batch Tasks согласно соответствующей инструкции.

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

Пример заполнения os_props.conf для интеграции с ОСА

os_props.conf:

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_SPAS_HOST=tkled-pprb00001.vm.esrt.cloud.xxxxx.ru
TASKS_SE_SPAS_PORT=443
TASKS_SE_SPAS_PROTOCOL=tls

# MUTUAL/DISABLE в зависимости от протокола
TASKS_SE_SPAS_TLS_MODE=MUTUAL

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

Настройка в случае интеграции без ОСА:

Для настройки сервиса Batch Tasks без интеграции с ОСА в os_props.conf сконфигурируйте следующие параметры:

## Настройки tasks-server для интеграции с ТС Доступ
# Включение интеграции с ТС Доступ: true - интеграция включена; false - интеграция выключена
TASKS_SERVER_ACCESS_ENABLED=false
# При выключенной интеграции (TASKS_SERVER_ACCESS_ENABLED=false) следующие 6 параметров необязательны:
TASKS_SERVER_ACCESS_KEYSTORE_CERT=
TASKS_SERVER_ACCESS_KEYSTORE_PKEY=
TASKS_SERVER_ACCESS_TRUSTSTED_CERT=
TASKS_SERVER_ACCESS_HTTP_CONNECTION_TIMEOUT=PT5S
TASKS_SERVER_ACCESS_HTTP_READ_TIMEOUT=PT10S
TASKS_SERVER_ACCESS_HTTP_CLIENT_MAX_POOL_SIZE=10
TASKS_SERVER_ACCESS_CACHE_SIZE=50
TASKS_SERVER_ACCESS_CACHE_AFTER_WRITE_TIMEOUT=PT60S

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

Пререквизиты интеграции с Platform V Monitor Объединенный мониторинг Unimon

Пререквизитами настройки интеграции Batch Tasks с компонентом Объединенный мониторинг Unimon (далее — Объединенный мониторинг) является создание в среде контейнеризации Service Account и Role Binding, необходимых для корректного развертывания deployment-config prometheus в среде контейнеризации.

Настройка интеграции с сервисом Объединенный мониторинг предполагает следующие действия:

создание Service Account Prometheus;
развертывание конфигурации Prometheus.

Создание Service Account

Создайте Service Account с именем <prometheus-user> и свяжите его с ролью Prometheus.

Если нет прав на создание Service Account, то можно сделать запрос в пространстве SIUOR на создание Service Account Prometheus в требуемом namespace.

Пример заявки на создание Service Account Prometheus

Домен: <кластер среды контейнеризации>

Проект: <наименование namespace>

Для проекта <наименование namespace> требуется создать Service Account с именем <prometheus-user> и связать его с ролью prometheus.

Для самостоятельного создания Service Account используйте следующие файлы:

service-account-prometheus-user.yaml

  kind: ServiceAccount
  apiVersion: v1
  metadata:
    name: "prometheus-user"
    labels:
      app: "prometheus"

role-binding-prometheus-view.yaml

  kind: RoleBinding
  apiVersion: authorization.openshift.io/v1
  metadata:
    name: "prometheus-view"
    labels:
      app: "prometheus"
  roleRef:
    name: "prometheus"
  subjects:
    - kind: ServiceAccount
      name: "prometheus-user"

Развертывание конфигурации Prometheus

Разместите шаблон Prometheus в папке openshift/templates проекта Install_EIP.

Если namespace настроен так, что трафик от Prometheus не проходит, то добавьте ServiceEntry:

  - apiVersion: networking.istio.io/v1alpha3
    kind: ServiceEntry
    metadata:
      name: prometheus-se
      labels:
        app: prometheus
    spec:
      exportTo:
      - .
      hosts:
      - ${APPMON_HOST}
      ports:
      - name: http
        number: 80
        protocol: HTTP
      - name: https
        number: 443
        protocol: TLS
      resolution: DNS

И параметр:

  - name: APPMON_HOST
    displayName: "Applied Monitoring host"
    description: "Хост для правила исходящего трафика. Обязательный."
    required: true

Пример значения параметра:

APPMON_HOST=appmon-ift.apps.dev-gen.ca.xxxxx.ru

Настройка интеграции с сервисом Объединенный мониторинг

Для настройки интеграции сервиса Batch Tasks с сервисом Объединенный мониторинг в os_props.conf сконфигурируйте следующие параметры:

# <!- заполните самостоятельно -> - значения параметров необходимо заполнить самостоятельно перед развертыванием сервиса

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_MONITORING_HOST=<!- заполните самостоятельно ->
TASKS_SE_MONITORING_PORT=<!- заполните самостоятельно ->
## Используемый протокол: tls/http
TASKS_SE_MONITORING_PROTOCOL=<!- заполните самостоятельно: tls/http ->
## MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls, DISABLE для http
TASKS_SE_MONITORING_TLS_MODE=<!- заполните самостоятельно: MUTUAL/DISABLE ->

# ----- PROMETHEUS ---------
IMAGE_PULL_SECRET=docker-registry-<>
APPMON_URL=http://<Обязательно к заполнению>/receive
APPMON_HOST=<заполните самостоятельно>
KUBERNETES_SERVICE_IP=<заполните самостоятельно>
PROMETHEUS_SERVICE_ACCOUNT=prometheus-user

## Значения параметров для сервиса Мониторинг
MONITORING_COLLECT_METRICS_ENABLED=<!- заполните самостоятельно: true/false ->
MONITORING_PUBLISH_ENDPOINTS_PATH=/actuator/prometheus
MONITORING_PUBLISH_ENDPOINTS_LIST=prometheus,health,info

Проверку успешности проведения интеграции Batch Tasks с сервисом Объединенный мониторинг выполняйте в UI Grafana.

Пример заполнения os_props.conf для интеграции с продуктом Прикладной мониторинг

os_props.conf:

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_MONITORING_HOST=tkled-pprb00001.vm.esrt.cloud.xxxxx.ru
TASKS_SE_MONITORING_PORT=443
## Используемый протокол: tls/http
TASKS_SE_MONITORING_PROTOCOL=tls
# MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls, DISABLE для http
TASKS_SE_MONITORING_TLS_MODE=MUTUAL

# ----- PROMETHEUS ---------
APPMON_URL=http://appmon-service.apps.dev-gen.sigma.xxxxx.ru/monitoring/v1/metrics/send
#### Значения параметров для сервиса Объединенный мониторинг
MONITORING_COLLECT_METRICS_ENABLED=true
MONITORING_PUBLISH_ENDPOINTS_PATH=/actuator/prometheus
MONITORING_PUBLISH_ENDPOINTS_LIST=prometheus,health,info

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

Настройка в случае интеграции без сервиса Объединенный мониторинг

Для настройки сервиса Batch Tasks без интеграции сервисом Объединенный мониторинг в os_props.conf сконфигурируйте параметры:

## Конфигурирование параметров Prometheus для интеграции с сервисом Объединенный мониторинг (значения параметров узнавать у администраторов стенда)
MONITORING_COLLECT_METRICS_ENABLED=false

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

При ручном развертывании сервиса Batch Tasks для интеграции с компонентом Журналирование:

В файле configmap-fluentbit.yml (openshift/configs/configmap-fluentbit.yml) для плейсхолдера {{LOGGER_SERVICE_HOST_NAME}}, {{LOGGER_SERVICE_PORT}} установите соответствующие значения для компонента Журналирование, развернутого в целевом окружении.
Загрузите в среду контейнеризации сконфигурированный файл configmap-fluentbit.yml.

В случае развертывания сервиса Batch Tasks с помощью Jenkins Job Install_EIP в выполнении указанных выше действий нет необходимости, так как все операции будут произведены в рамках работы Install_EIP Job.

Для настройки интеграции сервиса Batch Tasks с компонентом Журналирование в os_props.conf сконфигурируйте следующие параметры:

# <!- заполните самостоятельно -> - значения параметров необходимо заполнить самостоятельно перед развертыванием сервиса

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_LOGGER_HOST=<!- заполните самостоятельно ->
TASKS_SE_LOGGER_PORT=<!- заполните самостоятельно ->
## Используемый протокол: tls/http
TASKS_SE_LOGGER_PROTOCOL=<!- заполните самостоятельно: tls/http ->
## MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls, DISABLE для http
TASKS_SE_LOGGER_TLS_MODE=<!- заполните самостоятельно: MUTUAL/DISABLE ->

### ENDPOINT LOGGER_SERVICE
LOGGER_SERVICE_HOST_NAME=<!- заполните самостоятельно ->
## Для сервиса работающего по HTTP порт 80, для HTTPS порт 9999
LOGGER_SERVICE_PORT=80/9999

Пример заполнения os_props.conf для интеграции с компонентом Журналирование

os_props.conf:

# Хосты: порты внешних сервисов для ServiceEntry Egress
TASKS_SE_LOGGER_HOST=tkled-pprb00001.vm.esrt.cloud.xxxxx.ru
TASKS_SE_LOGGER_PORT=443
TASKS_SE_LOGGER_PROTOCOL=tls
# MUTUAL/DISABLE в зависимости от протокола
TASKS_SE_LOGGER_TLS_MODE=MUTUAL

# ----- PROMETHEUS ---------
### ENDPOINT LOGGER_SERVICE
LOGGER_SERVICE_HOST_NAME=tkled-pprb00001.vm.esrt.cloud.xxxxx.ru
LOGGER_SERVICE_PORT=9999

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

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

Для работы Batch Tasks без интеграции с компонентом Журналирование возможно заполнение параметров произвольными значениями:

# Настройки (HOST, PORT, PROTOCOL, MODE) внешних сервисов для ServiceEntry Egress
TASKS_SE_LOGGER_HOST=tkled-pprb00001.vm.esrt.cloud.xxx.ru
# В _PORT указывается нужный endpoint port
TASKS_SE_LOGGER_PORT=443
# Используемый протокол: https/http
TASKS_SE_LOGGER_PROTOCOL=https
# MUTUAL/DISABLE в зависимости от протокола: MUTUAL для tls, DISABLE для http
# Примечание: Для сервисов, обращение к которым выполняется через HTTPS, вызов от сервиса до Egress выполняется по HTTP, а от Egress до интегрируемого сервиса проксируется через HTTPS
TASKS_SE_LOGGER_TLS_MODE=MUTUAL
# Таймаут запроса на logger через istio
TASKS_SE_LOGGER_TIMEOUT=5s

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

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

Заведите заявку на администраторов компонента Прикладной журнал на стенде на подключение ZONE_ID в конфигураторе со значением TSK.
Обратитесь к администраторам компонента Прикладной журнал для выпуска сертификатов: server.keystore.jks и trust.jks.
Укажите значения вместо плейсхолдеров (плейсхолдеры заключены в двойные фигурные скобки ).

ZONE_ID сервиса регистрируемая в Configurator силами администраторов Прикладного Журнала
AJ_STAND_IN_ZONE_ID=SCHD

URL MMT. Пример значения: stub_url – если включен режим stub в параметре AJ_STAND_IN_STUB_MODE_FLAG=true, то любое значение, иначе необходимо указать корректный URL ПЖ, который установлен на стенде.
AJ_MMT_PROXY_URL=<Обязательно к заполнению>
 
Время для выполнения запроса на сервер ПЖ в секундах
AJ_MMT_CALL_TIMEOUT=30

Флаг использования заглушки вместо полноценного Stand-In. true – интеграция с ПЖ отключена, false – интеграция с ПЖ включена.
AJ_STAND_IN_STUB_MODE_FLAG=true
 
Сервер Kafka. Если включен режим stub в параметре AJ_STAND_IN_STUB_MODE_FLAG=true, то любое значение, иначе необходимо указать корректный сервер ПЖ, который установлен на стенде.
AJ_KAFKA_BOOTSTRAP_SERVERS=<Обязательно к заполнению>

Протокол взаимодействия с Kafka PLAINTEXT для http endpoint ПЖ, для https значение SSL
AJ_KAFKA_SECURITY_PROTOCOL=SSL

Пример заполненного файла configmap.yml

standin:
  cloud:
    client:
      zoneId: {{AJ_STAND_IN_ZONE_ID}}
      mmtProxyUrl: {{AJ_MMT_PROXY_URL}}
      mmtCallTimeout: {{AJ_MMT_CALL_TIMEOUT}}
      stub: {{AJ_STAND_IN_STUB_MODE_FLAG}}
      heartBeatPeriod: 1000
      kafka:
        bootstrapServers: {{AJ_KAFKA_BOOTSTRAP_SERVERS}}
        producerConfig:
          "[security.protocol]": {{AJ_KAFKA_SECURITY_PROTOCOL}}
          "[ssl.key.password]": ${AJ_SSL_KEY_PASSWORD}
          "[ssl.keystore.location]": /app/certs/journal/server.keystore.jks
          "[ssl.keystore.password]": ${AJ_SSL_KEYSTORE_PASSWORD}
          "[ssl.truststore.location]": /app/certs/journal/trust.jks
          "[ssl.truststore.password]": ${AJ_SSL_TRUSTSTORE_PASSWORD}
          "[ssl.keystore.type]": JKS
          "[ssl.truststore.type]": JKS
          "[ssl.protocol]": TLS
          "[ssl.enabled.protocols]": TLSv1.2
          "[ssl.endpoint.identification.algorithm]": ~
        consumerConfig:
          "[security.protocol]": {{AJ_KAFKA_SECURITY_PROTOCOL}}
          "[ssl.key.password]": ${AJ_SSL_KEY_PASSWORD}
          "[ssl.keystore.location]": /app/certs/journal/server.keystore.jks
          "[ssl.keystore.password]": ${AJ_SSL_KEYSTORE_PASSWORD}
          "[ssl.truststore.location]": /app/certs/journal/trust.jks
          "[ssl.truststore.password]": ${AJ_SSL_TRUSTSTORE_PASSWORD}
          "[ssl.keystore.type]": JKS
          "[ssl.truststore.type]": JKS
          "[ssl.protocol]": TLS
          "[ssl.enabled.protocols]": TLSv1.2
          "[ssl.endpoint.identification.algorithm]": ~
      concurrency: 10
      groupId: group_1

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

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

Настройка интеграции с продуктом Platform V One-Time-Token#

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

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

Подготовка дистрибутива к развертыванию сервиса с OTT

На этапе подготовки дистрибутива для развертывания сервиса Batch Tasks c сервисом OTT внесите в os_yaml_dirs.conf следующие правки:

# Добавить каталоги:
/configs/ingress/deployment-ott
/configs/egress/deployment-ott

# Исключить каталоги:
# /configs/ingress/deployment
# /configs/egress/deployment

Подготовка дистрибутива к развертыванию сервиса без OTT

На этапе подготовки дистрибутива для развертывания сервиса Batch Tasks без OTT при редактировании файлов конфигурации Install_EIP Job внесите следующие правки:

В os_yaml_dirs.conf:

# Добавить каталоги:
/configs/ingress/deployment
/configs/egress/deployment

# Исключить каталоги:
# /configs/ingress/deployment-ott
# /configs/egress/deployment-ott

В os_namespaces.yml удалите блок с envoy-filter-ott-egress-tenant.yml:

   projects:
   - name: "Имя проекта"
     openShiftNamespace: "namespace среды контейнеризации"
     openShiftURL: api.openShiftUrl:XXXX
     oc_token: Jenkins service account Token name из ответного письма сопровождения Install_EIP
     os_props: "os_props.conf" # Путь до файла с конфигурационными параметрами
     uniqueParams:
     ...
       envoy-filter-ott-egress-tenant.yml:
         TENANT_NAME:
           - httptarget-http
           - httptarget-https
         TENANT_EGRESS_PORT:
           - 21080
           - 21443
     ...

Блок uniqueParams может отсутствовать, если конфигурация настроена только на один тенант и он конфигурируется в os_props.conf. Отсутствие этого блока — не ошибка, и если его нет, данный шаг можно пропустить.

Подробнее см. в Руководстве по администрированию в разделе «Добавление нового тенанта».

В os_ignore.conf добавьте envoy-filter-ott-egress-tenant.

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

Для настройки интеграции сервиса Batch Tasks с OTT в os_props.conf сконфигурируйте следующие параметры:

## Конфигурирование параметров для интеграции с OTT

### Включение интеграции с OTT: true - интеграция включена; false - интеграция выключена
OTT_ENABLED=<!- заполните самостоятельно true/false ->

### Алиас сертификата клиента
OTT_CLIENT_CERT_ALIAS=batch-tasks

### Адрес OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOST=<!- заполните самостоятельно. Например: 10.53.99.178 ->

### Адреса OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOSTS=<!- заполните самостоятельно. Например: 10.53.99.178:8443,10.53.96.30:8443 ->

### URL OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_URL=https://<!- заполните самостоятельно. Например: 10.53.99.178: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

Для настройки сервиса Batch Tasks без интеграции с OTT в os_props.conf сконфигурируйте следующие параметры:

## Конфигурирование параметров для интеграции с OTT

### Включение интеграции с OTT: true - интеграция включена; false - интеграция выключена
OTT_ENABLED=false

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

### Алиас сертификата клиента
OTT_CLIENT_CERT_ALIAS=batch-tasks

### Адрес OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOST=<!- заполните самостоятельно. Например: 10.53.99.178 ->

### Адреса OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOSTS=<!- заполните самостоятельно. Например: 10.53.99.178:8443,10.53.96.30:8443 ->

### URL OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_URL=https://<!- заполните самостоятельно. Например: 10.53.99.178: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=<!- заполните самостоятельно ->

Пример заполнения os_props.conf для настройки интеграции с OTT

os_props.conf:

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

## Конфигурирование параметров для интеграции с сервисом OTT

### Включение интеграции с OTT: true - интеграция включена; false - интеграция выключена
OTT_ENABLED=true

### Алиас сертификата клиента
OTT_CLIENT_CERT_ALIAS=batch-tasks

### Адрес OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOST=10.53.99.178

### Адреса OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_HOSTS=10.53.99.178:8443,10.53.96.30:8443

### URL OTT-сервера (в целевом варианте - FQDN)
OTT_SERVICE_URL=https://10.53.99.178: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

Настройка интеграции с компонентом IAM Proxy#

Для настройки интеграции сервиса Batch Tasks с компонентом IAM Proxy:

заведите заявку на администраторов СУДИР на получение ответвления СУДИР согласно документации на IAM Proxy;
в os_props.conf сконфигурируйте следующие параметры:

## Значения для клиентского сертификата СУДИР (CN, Hash, path в URI ответвления СУДИР)
CN_CERT_SUDIR=<=заполните самостоятельно>
HASH_CERT_SUDIR=<=заполните самостоятельно>
CERT_PERMISSIONS_PATH_SUDIR=/batch-scheduler/

Примеры заполнения os_props.conf для интеграции с компонентом СУДИР

## Значения для клиентского сертификата СУДИР (CN, Hash, path в URI ответвления СУДИР)
CN_CERT_SUDIR=00CA0003CSUDIR_IFT
HASH_CERT_SUDIR=9d05c659a4345ffe0ac3b117bcfbe936d66b60cb3eaa5adcc06ce196187ce8b4
CERT_PERMISSIONS_PATH_SUDIR=/batch-scheduler/

Запуск автоматизированной установки Batch Tasks с помощью Jenkins Job Install_EIP#

Для запуска развертывания сервиса в Jenkins UI для Job Install_EIP:

В поле SubSystem укажите имя функциональной подсистемы.
В поле Stand укажите имя стенда.
В поле distrUrl укажите ссылку на дистрибутив приложения в Nexus.
Установите параметр defaultInst.
Нажмите кнопку Rebuild.

Установка сервисов Batch Tasks и Batch Scheduler на один namespace#

В подразделах содержится описание необходимых изменений конфигураций сервисов Batch Tasks и Batch Scheduler для их установки на один namespace.

Перед развертыванием сервисов Batch на один namespace должны быть выполнены соответствующие пререквизиты установки на разные namespace.

Подробнее см. в разделах:

«Подготовка окружения»;
«Автоматизированная установка сервиса Batch Tasks».

Общая схема процесса развертывания сервисов Batch на один namespace:

$@startuml skinparam shadowing false !pragma layout smetana start -[#black]-> #white : Обеспечение выполнения пререквизитов; -[#black]-> #white : Обеспечение выполнения требований \n подготовки окружения; -[#black]-> #white : Выбор способа установки сервисов Batch \n на один namespace; -[#black]-> fork -[#black]-> #white :Автоматизированная установка \n сервисов Batch на один namespace \n через Install_EIP; -[#black]-> fork again -[#black]-> #white :Ручная установка сервисов Batch \n на один namespace; -[#black]-> end fork -[#black]-> stop @enduml$

Требования к размещению и настройке сертификатов#

При установке сервисов Batch Tasks и Batch Scheduler на один namespace обеспечьте наличие следующих сертификатов (secrets) обоих сервисов на одном namespace:

Секреты обоих сервисов для доступа к репозиторию с Docker-образами.
Секреты для обоих сервисов для работы с БД через TLS.
Секреты для работы с БД (tasks_appl_user, scheduler_appl_user) для обоих сервисов.

Подробнее см. в подразделе «Автоматизированная установка сервиса Batch Task» → «Использование секретных данных при выполнении шагов развертывания».
Единый сертификат для работы с OTT.

Подробнее см. в разделе «Настройка OTT».
Единый сертификат для работы с Synapse Service Mesh (Ingress/Egress).

Подробнее см. в разделе «Выпуск и установка сертификатов Synapse Service Mesh для Ingress/Egress».

Набор секретов для работы сервисов в одном namespace не отличается от набора секретов при развертывании сервисов на разные namespace.

При автоматизированной установке через Install_EIP настройка сертификатов производится в каталоге /openshift/certs/ пользователем с необходимыми правами доступа.

Установка сервисов Batch на один namespace#

Установка сервисов на один namespace выполняется последовательно, при этом набор устанавливаемых манифестов для сервисов будет различаться. В данной инструкции приведен пример выполнения последовательной установки сервисов Batch Tasks и Batch Scheduler.

Соблюдение последовательности выполнения шагов подготовки и установки сервисов Batch обязательно.

Автоматизированная установка через Install_EIP#

Для развертывания сервисов Batch на один namespace с помощью Install_EIP выполните следующие шаги автоматизированной установки сервисов:

При подготовке дистрибутива Batch Tasks к автоматическому развертыванию выполните конфигурирование Install_EIP Batch Tasks.
При подготовке дистрибутива Batch Scheduler к автоматическому развертыванию выполните конфигурирование Install_EIP Batch Scheduler.
Выполните установку сервисов.

Общая схема процесса развертывания сервисов Batch на один namespace с помощью Install_EIP:

$@startuml skinparam shadowing false !pragma layout smetana start -[#black]-> #white : Подготовить дистрибутив сервиса \n Batch Tasks к автоматическому развертыванию; -[#black]-> #white : Выполнить конфигурирование Install_EIP Batch Tasks; -[#black]-> #white : Подготовить дистрибутив сервиса \n Batch Scheduler к автоматическому развертыванию; -[#black]-> #white : Выполнить конфигурирование Install_EIP Batch Scheduler; -[#black]-> #white : Выполнить установку сервиса Batch Tasks; -[#black]-> #white : Выполнить установку сервиса Batch Scheduler; -[#black]-> stop @enduml$

Конфигурирование Install_EIP Batch Tasks#

В репозитории Install_EIP в директорию настроек сервиса Batch Tasks внесите изменения в файлы os_props.conf, os_yaml_dirs.conf:

Так как сервисы Batch после развертывания в один namespace будут использовать общие Ingress и Egress, то в os_props.conf для Batch Tasks укажите наименования deployment для Ingress и Egress:

# Наименование Deployment Ingress, общее для обоих сервисов. Например:
INGRESS_NAME=ingressgateway-batch
# Наименование Deployment Egress, общее для обоих сервисов. Например:
EGRESS_NAME=egressgateway-batch

Сервис Batch Tasks при развертывании в один namespace с сервисом Batch Scheduler поставляет все основные манифесты, за некоторыми исключениями, специфичными для Batch Scheduler. Batch UI при таком типе развертывания сервиса устанавливается на втором этапе, поэтому для Batch Tasks в os_yaml_dirs.conf исключите соответствующие каталоги поставки:

   # Список папок поставки, содержащих YAML-манифесты.
   /configs
   /configs/ingress
   /configs/ingress/virtual-service
   /configs/egress
   /configs/egress/tenant
   /configs/egress/db
   /configs/tasks-server
   /configs/tasks-worker
   /configs/tasks-journal-applier
   /configs/tasks-gc
   /configs/inner-mtls

   # UI сервисов, при установке сервисов Batch Tasks и Batch Scheduler в один namespace, устанавливается вторым этапом (после установки первого сервиса).
   # UI
   # /configs/scheduler-ui
   # /configs/scheduler-ui/ui-per-one-service

   # В случае единого UI на два сервиса (ui-per-one-service исключить)
   # /configs/scheduler-ui/ui-unified

Конфигурирование Install_EIP Batch Scheduler#

После настройки Batch Tasks настройте Batch Scheduler.

В репозитории Install_EIP в директории настроек сервиса Batch Scheduler сконфигурируйте следующие файлы (подробнее см. в разделе «Редактирование файлов конфигурации Job Install_EIP»):

system.conf — значения параметров должны совпадать с system.conf сервиса Batch Tasks.
password.conf — файл конфигурации необходим для поддержания обратной совместимости, поэтому формальное содержание может совпадать с password.conf сервиса Batch Tasks.
os_ignore.conf — установите необходимые значения параметров. Значения могут совпадать os_ignore.conf сервиса Batch Tasks.
mailto_admins.txt — установите необходимые значения параметров. Значения параметров могут совпадать с mailto_admins.txt сервиса Batch Tasks.
ansible.cfg — значения параметров должны совпадать с ansible.cfg сервиса Batch Tasks.
actions.xml — настройте события (Actions) для сервиса Batch Scheduler.
liquibase.batch.scheduler.conf — настройте библиотеку Liquibase основной БД, так как для Batch Scheduler используются свои БД и схема.
liquibase.batch.scheduler.si.conf — настройте библиотеку Liquibase репликационной БД, так как для Batch Scheduler используются свои БД и схема.
os_namespaces.yml — значения параметров настроек name, openShiftNamespace, openShiftURL, oc_token должны совпадать с os_namespaces.yml сервиса Batch Tasks.
os_yaml_dirs.conf — так как сервис Batch Tasks при развертывании в один namespace с сервисом Batch Scheduler поставляет все основные манифесты, то в os_yaml_dirs.conf для Batch Scheduler укажите пути до специфичных папок, а также до Batch UI:

    # Список папок поставки, содержащих YAML-манифесты:
    /configs
    #/configs/ingress
    /configs/ingress/virtual-service
    #/configs/egress
    #/configs/egress/tenant
    /configs/egress/db
    /configs/scheduler-dispatcher
    /configs/scheduler-journal-applier
    /configs/scheduler-server
    #/configs/inner-mtls

    # UI сервисов, при установке сервисов Batch Tasks и Batch Scheduler в один namespace, устанавливается вторым этапом (после установки первого сервиса).
    # UI
    /configs/scheduler-ui
    #/configs/scheduler-ui/ui-per-one-service

    # В случае единого UI на два сервиса (ui-per-one-service исключить)
    /configs/scheduler-ui/ui-unified

os_props.conf — значения параметров настроек:

    # Путь до репозитория Docker-образов сервисов scheduler
        Указать путь до репозитория Docker-образов. Обычно пути до репозиториев Batch.Tasks и Batch.Scheduler совпадают.

    # Параметры настроек FluentBit
        Указать путь до образа FluentBit и STAND_ID. При установке сервисов Batch.Tasks и Batch.Scheduler обычно пути до образов и STAND_ID совпадают.

    # SCHD_SERVER
        Указать значения параметров, необходимые для работы scheduler-server. Параметры, значения которых совпадают (но не обязательно):
        // хост прокси-приложения аудита
        SCHD_SERVER_AUDIT_HOST=<Обязательно к заполнению>
        // хост прокси-приложения SPAS. При выключенной интеграции остальные параметры необязательны
        SCHD_SERVER_ACCESS_AUTHORIZE_ENDPOINT=<Обязательно к заполнению>

    # SCHD_DISPATCHER
        Указать значения параметров, необходимые для работы scheduler-dispatcher.

    # SCHD_JOURNAL_APPLIER
        Указать значения параметров, необходимые для работы scheduler-journal-applier.

    # Параметры, у которых имя начинается с MAIN_DB_..., например, JDBC URL соединения с основной БД — MAIN_DB_JDBC_URL.
        Указать значения параметров (сервисы Batch Scheduler и Batch Tasks используют разные БД и схемы).

    # Параметры, у которых имя начинается с SI_DB_..., например, JDBC URL соединения с Stand-In БД — SI_DB_JDBC_URL.
        Указать значения параметров (сервисы Batch Scheduler и Batch Tasks используют разные БД и схемы).

    # Настройка параметров для работы с сервисом ПЖ. Параметры, у которых имя начинается с AJ_, например, AJ_STAND_IN_STUB_MODE_FLAG
        Имеют настройки, идентичные для обоих сервисов, так как работа с обоими сервисами будет выполняться из одного сервиса ПЖ. Но при необходимости сервисы ПЖ для обоих сервисов можно использовать разные, т. е. настройки будут отличаться.

    # Значения параметров для INGRESS/EGRESS
        Все необходимые манифесты будут установлены при развертывании сервиса Batch Tasks, т. е. для Batch.Scheduler данные манифесты устанавливаться не будут (соответствующие каталоги отключены в файле os_yaml_dirs.conf). Поэтому не важно, какие значения будут установлены в данных плейсхолдерах.

    # Параметры для конфигурации HTTP endpoint потребителя
        Значения параметров должны совпадать с аналогичными настройками сервиса Batch Tasks.

    # Хост основной БД
        Указать значения параметров (сервисы Batch Scheduler и Batch Tasks используют разные БД и схемы).

    # Хост репликационной БД
        Указать значения параметров (сервисы Batch Scheduler и Batch Tasks используют разные БД и схемы).

    # Значения параметров для OTT
        Значения параметров должны совпадать с аналогичными настройками сервиса Batch Tasks.

    # Хосты:порты внешних сервисов для ServiceEntry Egress

    # Параметры SCHD_SE_AUDIT_... для интеграции с сервисом АУДИТ.
        Значения параметров могут совпадать с аналогичными настройками сервиса Batch Tasks, но возможно и использование разных сервисов Аудит для Batch Tasks и Batch Scheduler.

    # Параметры SCHD_SE_MONITORING... для интеграции с сервисом Мониторинг.
        Значения параметров могут совпадать с аналогичными настройками сервиса Batch Tasks, но возможно и использование разных сервисов Мониторинг для Batch Tasks и Batch Scheduler.

    # Параметры SCHD_SE_SPAS... для интеграции с SPAS.
        Значения параметров могут совпадать с аналогичными настройками сервиса Batch Tasks, но возможно и использование разных сервисов SPAS для Batch Tasks и Batch Scheduler.

    # Параметры SCHD_SE_LOGGER... для интеграции с сервисом Журналирование.
        Значения параметров могут совпадать с аналогичными настройками сервиса Batch Tasks, но возможно и использование разных сервисов Журналирование для Batch Tasks и Batch Scheduler.

    # PROMETHEUS
        Значения параметров должны совпадать с аналогичными настройками сервиса Batch Tasks.

    # ENDPOINT LOGGER_SERVICE
        Значения параметров должны совпадать с аналогичными настройками сервиса Batch Tasks.

    # SCHEDULER_UI
        Указать значения параметров для Batch Scheduler.

Установка Batch Tasks в среде контейнеризации#

Требования к окружению#

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

наличие среды контейнеризации;
наличие базы данных PostgreSQL.

Требования к КТС#

Требования к производительности#

Описание	Параметры
Рекомендуемый минимальный КТС	8 CPU / 32 Гбайт RAM

Требования к базе данных#

Описание	Параметры
Минимальные требования к КТС для разворачивания сервиса	2 Core CPU / 8 Гбайт RAM / 100 Гбайт HDD
Рекомендуемые требования к КТС для разворачивания сервиса	16 Core CPU / 128 Гбайт RAM / 1200 Гбайт HDD

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

Требования к namespace#

Учитывайте, что различные частные случаи развертывания сервиса могут иметь свои требования к окружению.

Данный способ развертывания — частный случай для ЦПО/ШЦП со своими особенностями, например, отсутствием: OTT, Ingress, Egress, Stand-In, интеграции с сервисом Аудит.

Подготовка базы данных#

Для подготовки основной и репликационной БД для работы в тестовых и средах разработки:

Создайте БД.
Создайте:
- прикладного пользователя tasks_appl_user, от имени которого приложение будет соединяться с БД;
- пользователя-владельца схемы данных tasks_owner_user, от имени которого необходимо запустить скрипты.
Выполните SQL-скрипт создания схемы данных и предоставления прав.
Добавьте пользователей и перезагрузите БД.

Создание БД#

Для создания базы данных выполните от имени пользователя postgres (суперпользователь БД) следующие команды в утилите psql:

Создайте базу данных:

   CREATE DATABASE database_name OWNER xxx_owner_user;

Чтобы создать схему данных, подключитесь к созданной БД с помощью команды:

   \c database_name

или (для подключения под другим пользователем):

   \c database_name user_name

При смене пользователя введите пароль.

Предупреждение

В зависимости от настроек в файле pg_hba.conf (аутентификации по имени узла) созданные пользователи не могут авторизоваться, пока их не добавят в pg_hba.conf. Аналогичная ситуация будет справедлива и для суперпользователя postgres при попытке соединения c вновь созданной БД.

Создание пользователей БД#

Примечание

Если имеется SSH-доступ на КТС с БД и возможностью повысить привилегии до root, то для создания пользователей БД можно воспользоваться утилитой psql.

Для создания пользователей базы данных:

После авторизации на КТС повысьте привилегии до root. Для этого запустите оболочку (shell) с правами root: sudo -s.
Переключитесь для работы под пользователем postgres: su - postgres.
Запустите psql: psql (или полный путь /usr/local/pgsql/bin/psql, если не запускается без указания полного пути).

Создайте пользователей:

CREATE ROLE xxx_appl_user WITH LOGIN PASSWORD 'password';
CREATE ROLE xxx_owner_user WITH LOGIN PASSWORD 'password';

Информация

Пользователи в PostgreSQL не привязаны к базе и схеме.

Из утилиты psql список пользователей экземпляра можно получить, используя команду:

\du

или:

select * from pg_catalog.pg_user;

Информация

Поле valuntil указывает, до какой даты-времени действителен пароль пользователя. Если поле пустое, то пароль пользователя не имеет срока действия (бессрочный).

Создание схем БД#

После успешного перезапуска экземпляра БД создайте схему данных. Для этого запустите утилиту psql под пользователем postgres и присоединитесь к ранее созданной БД:

\c database_name
CREATE SCHEMA xxx_schema AUTHORIZATION xxx_owner_user;
GRANT USAGE ON SCHEMA xxx_schema to xxx_appl_user;

Для просмотра схемы в БД в psql выполните команду:

\dn

или:

SELECT schema_name FROM information_schema.schemata;

Добавление пользователей и перезагрузка БД#

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

Файл конфигурации pg_hba.conf содержит:

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

Файл с настройками аутентификации по имени узла pg_hba.conf находится по пути /pgdata/11/data.

Примечание

Пути могут отличаться, в том числе в зависимости от версии базы.

Редактировать файл конфигурации pg_hba.conf нужно от имени системного (linux) пользователя postgres. В файле конфигурации pg_hba.conf добавьте 1 или 2 строки, в зависимости от того, может ли суперпользователь БД postgres присоединиться к созданной БД.

Информация

Нижеприведенные примеры исходят из того, что суперпользователь БД postgres не может подключаться к созданной БД.

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

В файл конфигурации pg_hba.conf добавьте пользователя postgres:

host db_1, db_2, database_name postgres 127.0.0.1/32 trust

Предупреждение

Данная строка должна идти впереди любой аналогичной строки, которая определяет способ подключения пользователя postgres c другого хоста (тип хоста), если они допускают подключение пользователя postgres с локального хоста. Записи в файле pg_hba.conf не должны быть противоречивы, в противном случае экземпляр PostgreSql может не загрузиться при перезагрузке.

Где:

host — показывает, что подключение выполняется с другого хоста (как правило, в файле pg_hba.conf присутствует строка local all all md5, которая показывает, что при локальном логине к любой БД нужно вводить пароль, однако пароль пользователя БД postgres, как правило, не известен).
db_1, db_2 — список баз, для которых уже прописана возможность локального подключения к ним суперпользователя БД postgres без ввода пароля.
database_name— вновь созданная БД.
postgres — пользователь БД, под которым будет доступен данный вариант входа.
127.0.0.1/32— показывает, что такой вход возможен только с того же самого хоста.
trust — метод аутентификации, не требующий ни ввода пароля, ни наличия сертификата.

Редактирование файла конфигурации для логина вновь созданных пользователей с произвольного хоста

Чтобы вновь созданные пользователи могли подключиться к созданной БД данного экземпляра PostgreSql, добавьте в файл конфигурации hb_pga.conf следующую строку:

host database_name xxx_owner_user, xxx_appl_user 0.0.0.0/0 md5

Где:

host — показывает, что подключение выполняется с другого хоста;
database_name — вновь созданная БД;
xxx_owner_user, xxx_appl_user — вновь созданные пользователи;
0.0.0.0/0 — разрешенный диапазон хостов (0.0.0.0/0 — показывает, что логин разрешен с любого хоста);
md5 — способ аутентификации по паролю.

Примечание

После изменений, внесенных в файл конфигурации pg_hba.conf, выполните перезагрузку базы данных, так как файл конфигурации не будет перечитан динамически.

Перезагрузка экземпляра PostgreSql

Подробную информацию о работе можно найти в документации на PostgreSQL.

Примечание

Перечитывание конфигурационных файлов и перезапуск базы выполняются от имени linux-пользователя postgres. Аналогично от linux пользователя postgres выполняется и проверка статуса, остановка или старт экземпляра.

Перечитывание конфигурационных файлов и перезапуск экземпляра:

pg_ctl reload
pg_ctl restart

Добавление секретов#

При установке сервиса Batch Tasks в Kubernetes обязательно наличие следующего секрета: batch-tasks-liquibase-passwords. Обязательные ключи:

TASKS_OWNER_USER;
TASKS_OWNER_USER_PASSWD;
TASKS_APPL_USER.

Обновление#

Обновление сервиса Batch Tasks происходит с помощью механизма Rolling Update.

Подробная информация размещена в Руководстве по системному администрированию в разделе «Реализация Graceful Shutdown и конфигурирование Rolling Update сервиса Batch Tasks».

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

Удаление#

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

Для удаления сервиса в среде контейнеризации удалите следующие объекты:

ConfigMap:
- batch-tasks-ott-egress-logback,
- batch-tasks-ott-egress-settings,
- batch-tasks-ott-ingress-logback,
- batch-tasks-ott-ingress-settings,
- batch-ui-app-config,
- tasks-server-app-config,
- tasks-journal-applier-app-config,
- tasks-worker-app-config,
- tasks-gc-app-config;
Deployment:
- ,
- ;
DeploymentConfig:
- batch-ui,
- tasks-server,
- tasks-journal-applier,
- tasks-worker,
- tasks-gc;
ServiceEntry:
- batch-tasks-egress-main-db-se,
- batch-tasks-egress-standin-db-se,
- batch-tasks-egress-ott-server-se-*,
- batch-tasks-dispatcher,
- batch-tasks-egress-se-*,
- batch-tasks-egress-audit-se,
- batch-tasks-egress-logger-se,
- batch-tasks-egress-monitoring-se,
- batch-tasks-egress-spas-se,
- batch-tasks-journal-kafka-*;
VirtualService:
- batch-tasks-egress-main-db-vs,
- batch-tasks-egress-standin-db-vs,
- batch-tasks-egress-vs-*,
- batch-tasks-egress-audit-vs,
- batch-tasks-egress-logger-vs,
- batch-tasks-egress-monitoring-vs,
- batch-tasks-egress-spas-vs,
- batch-tasks-ingress-vs;
EnvoyFilter:
- batch-tasks-egress-ott-auth-filter,
- batch-tasks-egress-ott-auth-filter-*,
- batch-tasks-ingress-ott-auth-filter,
- batch-tasks-ingress-sudir-auth-filter;
DestinationRule: -batch-tasks-egress-dr-*,
- batch-tasks-egress-audit-dr,
- batch-tasks-egress-logger-dr,
- batch-tasks-egress-monitoring-dr,
- batch-tasks-egress-authorize-dr,
- -dr,
- enable-mtls-dr,
- tasks-server-dr,
- tasks-journal-applier-dr,
- tasks-worker-dr,
- tasks-gc-dr;
Gateway:
- batch-egress-gw-*,
- batch-egress-gw,
- batch-ingress-gw;
Service:
- batch-tasks-egress-svc-*,
- batch-tasks-egress-svc,
- batch-tasks-ingress-svc,
- batch-ui,
- tasks-server,
- tasks-journal-applier,
- tasks-worker,
- tasks-gc;
Route:
- batch-tasks-istio-ingressgateway-http,
- batch-istio-ingressgateway-ui-http,
- batch-tasks-istio-ingressgateway,
- batch-istio-ingressgateway-ui,
- batch-ui,
- tasks-server;
AuthorizationPolicy:
- allow-all-ap;
Policy:
- default.

Если название объекта заканчивается символом "*", это означает, что данных объектов несколько, и они имеют разное окончание наименования. Удалите все объекты. Для объектов типа {{INGRESS_NAME}}, {{EGRESS_NAME}}, задаваемых при установке, удалите типичные значения: istio-ingressgateway-<namespace>, istio-egressgateway-<namespace>.

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

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

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

В общем виде процесс выполнения проверки успешности развертывания сервиса Batch Tasks состоит из следующих этапов:

Проверка статусов всех Pods развернутого в среде контейнеризации сервиса Batch Tasks.
Проверка базовой функциональности сервиса Batch Tasks через:
- Batch UI;
- Batch API.

Проверка статусов Pods#

Чтобы проверить статусы всех Pods развернутого в среде контейнеризации сервиса Batch Tasks, выполните следующие действия:

Зайдите в консоль среды контейнеризации проекта, в котором выполнено развертывание проверяемого сервиса Batch Tasks.
Перейдите в раздел Workloads → Pods.
В открывшейся таблице по значениям столбцов Status и Ready проверьте , что все Pods запущены (имеют статус Running) и готовы к работе (n/n, например: 2/2 ).

Проверка базовой функциональности#

Чтобы проверить базовую функциональность сервиса Batch Tasks, через Batch UI или Batch API выполните следующие действия:

Создайте Очередь.
Создайте Задачу для Очереди.
Проверьте, что Задача запустилась: статус Задачи изменился и не равен Готова к запуску.

В случае прохождения вышеописанной проверки можно сделать вывод об успешном выполнении развертывания сервиса Batch Tasks.

Откат#

Откат к начальным настройкам сервиса не предусмотрен.

Откат сервиса Batch Tasks на предыдущую версию в целевом виде состоит из следующих шагов:

Удалите все развернутые в окружении артефакты сервиса, кроме БД (и информации в БД).
Выполните установку сервиса по соответствующей инструкции.

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

Ошибка подключения сервиса Batch к PgBouncer#

При развертывании сервиса Batch в окружении с обязательным подключением к PgBouncer может возникать следующая ошибка:

Caused by: org.postgresql.util.PSQLException: ERROR: unsupported startup parameter: search_path
at org.postgresql.core.v3.ConnectionFactoryImpl.doAuthentication(ConnectionFactoryImpl.java:514)
at org.postgresql.core.v3.ConnectionFactoryImpl.tryConnect(ConnectionFactoryImpl.java:141)
at org.postgresql.core.v3.ConnectionFactoryImpl.openConnectionImpl(ConnectionFactoryImpl.java:192)
at org.postgresql.core.ConnectionFactory.openConnection(ConnectionFactory.java:49)
at org.postgresql.jdbc.PgConnection.<init>(PgConnection.java:195)
at org.postgresql.Driver.makeConnection(Driver.java:454)
at org.postgresql.Driver.connect(Driver.java:256)
at com.zaxxer.hikari.util.DriverDataSource.getConnection(DriverDataSource.java:138)
at com.zaxxer.hikari.pool.PoolBase.newConnection(PoolBase.java:358)
at com.zaxxer.hikari.pool.PoolBase.newPoolEntry(PoolBase.java:206)
at com.zaxxer.hikari.pool.HikariPool.createPoolEntry(HikariPool.java:477)
at com.zaxxer.hikari.pool.HikariPool.access$100(HikariPool.java:71)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:725)
at com.zaxxer.hikari.pool.HikariPool$PoolEntryCreator.call(HikariPool.java:711)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
... 3 common frames omitted

Чтобы исправить ошибки и выполнить корректное подключение сервиса, в PgBouncer в файле /etc/pgbouncer/postgres.yum к значению параметра ignore_startup_parameters добавьте search_path:

ignore_startup_parameters = extra_float_digits, search_path

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

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

№	Тип	Блок	Шаг
1	Пререквизит	Подготовка БД	Проверить, кто является администратором имеющейся БД. Администратор БД обязательно должен быть администратор ПСИ
2	Пререквизит	Подготовка БД	Выполнить подключение к БД. Если ошибки при подключении к БД / Невозможность подключиться к БД со старым паролем — заводятся заявки на СУБД PostgreSQL с описанием проблемы
3	Пререквизит	Подготовка БД	Выполнить подготовку базы данных (используя SQL-запросы) по инструкции
4	Пререквизит	Подготовка namespace среды контейнеризации	Получить доступ в namespace среды контейнеризации
5	Пререквизит	Подготовка namespace среды контейнеризации	Выполнить подготовку namespace (настроить Istio) по инструкции
6	Пререквизит	Репозиторий	Создать репозиторий для хранения проекта
7	Пререквизит	Репозиторий	Получить доступ к созданному на шаге 1 репозиторию
8	Пререквизит	Jenkins Job	Создать свой экземпляр Jenkins Job Install_EIP
9	Пререквизит	Jenkins Job	Проверить доступ от Jenkins Job до Nexus, БД, namespace
10	Пререквизит	Jenkins Job	Настроить доступ Install_EIP к namespace среды контейнеризации
11	Пререквизит	Подготовка конфигурации развертывания	Выполнить подготовку файловой структуры конфигурации Install_EIP по инструкции
12	Пререквизит	Подготовка конфигурации развертывания	Заполнить файлы конфигурации Install_EIP по инструкции
13	Пререквизит	Подготовка конфигурации развертывания	Создать секреты в репозитории конфигурации по инструкции
14	Пререквизит	Подготовка развертывания	Создать ServiceAccount для ТУЗ, который скачивает Docker-образа в namespace среды контейнеризации: Для оформления доступа ТУЗ к репозиториям с Docker-образами необходимо добавить в defаult-аккаунт секрет для доступа к репозиторию с Docker-образами
15	Основные работы	Развертывание продукта	Выполнить запуск Jenkins Job Install_EIP. Jenkins Job выполнит следующие действия: 1) Запуск Liquibase для создания структуры таблиц. 2) Заполнение файлов конфигурации среды контейнеризации на основе конфигурации в репозитории. 3) Создание секретов в среде контейнеризации. 4) Загрузка файлов конфигурации среде контейнеризации, отвечающих за старт приложения
16	Пререквизит	Актуализация настроек интеграции с внешними сервисами	Выпуск/загрузка сертификатов доступа к смежным сервисам в случае использования HTTPS
17	Основные работы	Актуализация настроек интеграции с внешними сервисами	Настроить интеграцию с используемыми смежным сервисами по инструкциям

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

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

В ConfigMap scheduler-server (tasks-server-app-config) вручную установите флаг allow-local-hosts: true под свойством server для выполнения запросов на localhost через терминал.
Перезагрузите pod task-server, выполнив команду Start rollout, чтобы внесенные изменения вступили в силу.
Последовательно перейдите по вкладкам Pod tasks-server → Terminal и выполните запрос на создание Очереди.

curl --request POST \
  --url http://localhost:8080/batch/v1/queues \
  --header 'content-type: application/json' \
  --header 'ott-subject: test' \
  --data '{
  "jsonrpc": "2.0",
  "method": "create",
  "params": {
    "name": "test",
    "description": "test",
    "maxRunningTasks": 100,
    "retryPolicy": null
  },
  "label": "T",
  "id": 555
}'

Создайте Задачу для этой Очереди, выполнив запрос:

curl --request POST \
  --url http://localhost:8080/batch/v1/tasks \
  --header 'content-type: application/json' \
  --header 'ott-subject: test' \
  --data '{
  "jsonrpc": "2.0",
  "method": "create",
  "params": {
    "queue": "test",
    "dependsOn": "",
    "description": "",
    "scheduleTime": "",
    "httpTarget": {
      "url": "http://localhost:8081/actuator/health",
      "method": "GET",
      "headers": {
        "key1": "value1",
        "key2": "value2"
      },
      "body": 56
    }
  },
  "id": 555
}'

Проверьте выполнение объекта httpTarget с помощью метода get для задачи, полученной в п.4 (поле lastAttempt).

curl --request POST \
  --url http://localhost:8080/batch/v1/tasks \
  --header 'content-type: application/json' \
  --header 'ott-subject: test' \
  --data '{
    "jsonrpc": "2.0",
    "method": "get",
    "params": {
        "name": "21493"
    },
    "id": 555
}'

При успешном ответе удалите созданную в Очередь методом delete.

curl --request POST \
  --url http://localhost:8080/batch/v1/queues \
  --header 'content-type: application/json' \
  --header 'ott-subject: test' \
  --data '{
  "jsonrpc": "2.0",
  "method": "delete",
  "params": {
    "name": "test"
  },
  "id": 555
}'

Пример успешного ответа:

{
  "jsonrpc": "2.0",
  "id": 555,
  "result": {
    "name": "21497",
    "queue": "test",
    "description": "",
    "httpTarget": {
      "url": "http://localhost:8081/actuator/health",
      "method": "GET",
      "body": "56",
      "headers": {
        "key1": "value1",
        "key2": "value2"
      }
    },
    "createTime": "2022-03-22T04:30:21.925Z",
    "updateTime": "2022-03-22T04:30:22.744Z",
    "scheduleTime": null,
    "state": "DONE",
    "firstAttempt": {
      "scheduleTime": "2022-03-22T04:30:21.925Z",
      "dispatchTime": "2022-03-22T04:30:22.665Z",
      "responseTime": "2022-03-22T04:30:22.744Z",
      "responseStatus": {
        "code": 200,
        "message": "{\"status\":\"UP\",\"components\":{\"livenessState\":{\"status\":\"UP\"},\"readinessState\":{\"status\":\"UP\"},\"tasksReadiness\":{\"status\":\"UP\",\"details\":{\"Active БД\":{\"status\":\"UP\"}}}},\"groups\":[\"liveness\",\"readiness\"]}"
      }
    },
    "lastAttempt": {
      "scheduleTime": "2022-03-22T04:30:21.925Z",
      "dispatchTime": "2022-03-22T04:30:22.665Z",
      "responseTime": "2022-03-22T04:30:22.744Z",
      "responseStatus": {
        "code": 200,
        "message": "{\"status\":\"UP\",\"components\":{\"livenessState\":{\"status\":\"UP\"},\"readinessState\":{\"status\":\"UP\"},\"tasksReadiness\":{\"status\":\"UP\",\"details\":{\"Active БД\":{\"status\":\"UP\"}}}},\"groups\":[\"liveness\",\"readiness\"]}"
      }
    },
    "retryState": {
      "numAttempts": 1,
      "nextAttemptTime": "2022-03-22T04:30:21.925Z",
      "intervalSeconds": 1
    },
    "dependsOn": null
  }
}

В ConfigMap tasks-server удалите флаг allow-local-hosts: true.
Перезагрузите pod scheduler-server, выполнив команду Start rollout, чтобы внесенные изменения вступили в силу.

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

Проверка работоспособности компонента Объединенный Мониторинг#

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

В среде контейнеризации перейдите на вкладку Pods и выберете отсек (pod) tasks-server.
Перейдите в Terminal и введите команду:

curl localhost:8081/actuator/prometheus

Если получено сообщение следующего вида, то проверка выполнена успешно:

Проверка работоспособности компонента Аудит#

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

Перейти в АРМ Аудит по ссылке: https://sudpprb-ift.xxxxx.ru/pprb-audit/business-audit/#/
Выберите поле Поиск событий аудита и на открывшейся странице заполните:
- поля Период — необходимым временным периодом (текущая дата);
- поле Исходный текст — «batch.tasks-server».
Нажмите кнопку Найти.
Если в результатах поиска присутствуют записи, созданные по времени после запуска сервиса, то проверка выполнена успешно.

Проверка работоспособности компонента Журналирование#

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

Перейти в АРМ Журналирование по ссылке: https://sudpprb-ift.xxxxx.ru/react_izm/logger-srch-backend/
Перейти на вкладку Системный журнал ППРБ и на открывшейся странице заполните:
- поля: Начальная дата, Начальное время, Конечная дата, Конечное время;
- поле Модуль — «tasks_server».
Нажмите кнопку Поиск.
Если в результатах поиска присутствуют записи, созданные по времени после запуска сервиса, то проверка выполнена успешно.

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

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

Перейти в АРМ Прикладной журнал по ссылке: https://sudpprb-ift.xxxxx.ru/pprb_aj/journal-arm/version3/journal
На открывшейся странице Журнал выберите в поле Зона — «TSK», уберите галочку с чекбокса С ошибками репликации и нажмите кнопку Найти.
Если в результатах поиска присутствуют записи, созданные по времени после запуска сервиса, то проверка выполнена успешно.

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

Термин/аббревиатура	Определение
АС	Автоматизированная система
БД	База данных
Задание	Сущность Job — вычисление, оформленное в виде вызова произвольных запросов HTTP(S)
Задача	Сущность Task — вычисление, предназначенное для одноразового запуска из Очереди
КТС	Комплекс технических средств
Очередь	Сущность Queue — контейнер для Задач, предназначенный для управления запуском одноразовых вычислений в определенном порядке, может ограничивать количество одновременно выполняемых Задач для регулирования нагрузки на вычислительные средства
ПЖ	Прикладной журнал
СУБД	Система управления базами данных
ТУЗ	Технологическая учетная запись
ШЦП	Школьная цифровая платформа
ЦПО	Цифровая платформа образования
ABAC	Attribute-Based Access Control, разграничение доступа на основе атрибутов
API	Application Programming Interface, программный интерфейс приложения
FQDN	Fully Qualified Domain Name, имя домена, не имеющее неоднозначностей в определении
Graceful Shutdown	Механизм плавного завершения работы приложения, с минимизацией потерь данных и ошибок
HTTP	HyperText Transfer Protocol, протокол передачи гипертекста
HTTPS	Расширение протокола HTTP для поддержки шифрования в целях повышения безопасности
IDE	Integrated Development Environment, интегрированная среда разработки
IP-адрес	Internet Protocol Address, уникальный числовой идентификатор устройства в компьютерной сети
JDBC	Java DataBase Connectivity, платформенно независимый промышленный стандарт взаимодействия Java-приложений с различными СУБД
JSON	JavaScript Object Notation, текстовый формат обмена данными, основанный на JavaScript
OTT	One-Time Token, сервис для получения JWS-ключей
REST	Representational State Transfer, архитектурный стиль взаимодействия компонентов распределенного приложения
Rolling Update	Метод обновления без прерывания работы сервиса с постепенным отключением экземпляров старой версии и вводом экземпляров новой версии
RPC	Remote Procedure Call, система удаленного вызова процедур
SPAS	Server Part Access System, компонент Объединенный сервис авторизации, продукт Platform V IAM SE
SQL	Structured Query Language, язык структурированных запросов — декларативный язык программирования, применяемый для создания, модификации и управления данными в реляционной базе данных, управляемой соответствующей системой управления базами данных
SSH	Secure Shell, безопасная оболочка, сетевой протокол прикладного уровня, позволяющий производить удаленное управление операционной системой и туннелирование TCP-соединений
SSL	Secure Sockets Layer, криптографический протокол, обеспечивающий защищенную передачу данных в компьютерной сети
TLS	Transport Layer Security, протокол защиты транспортного уровня
UI	User interface
URL	Uniform Resource Locator, унифицированный адрес ресурса
UTF-8	Unicode Transformation Format, 8-bit, формат преобразования Юникода, 8-битный
YAML	Yet Another Markup Language, «дружественный» формат сериализации данных — концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования