Установка#

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

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

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

• ручная установка сервиса;

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

Обзор#

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

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

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

• обеспечены соответствующие требования и настройка окружения;

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

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

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

• наличие платформы системы оркестрации контейнерами;

• наличие СУБД PostgreSQL (рекомендуется Platform V Pangolin SE, далее — PostgreSQL);

• наличие в инфраструктуре One-Time Password (OTP) / OTT (далее — OTT) (опционально).

Настройка окружения#

Подключение 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 выполните следующие действия:

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

2. Создайте ConfigMap для OTT-sidecar.

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

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

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

1. При помощи 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

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

3. Импортируйте полученные от администратора 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

4. Создайте два секрета:

   • 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 — с паролями к ключам:

     • 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 выполняется в случае, если установка сервиса производится без помощи Deploy Tools.

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

• ott-ingress-logback;

• batch-tasks-ott-ingress-settings;

• ott-egress-logback;

• batch-tasks-ott-egress-settings.

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

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

1. Выполните вход в консоль системы оркестрации контейнерами.

2. На панели слева выберите раздел Workloads → Config Maps.

3. Нажмите кнопку Create Config Map.

4. В открывшемся окне вставьте вместо имеющегося содержимое файла ott-ingress-logback.

5. Нажмите кнопку Create.

6. Повторите пункты 2–4 для файлов:

   • batch-tasks-ott-ingress-settings;

   • ott-egress-logback;

   • batch-tasks-ott-egress-settings.

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

При автоматизированном развертывании сервиса конфигурирование параметров ConfigMap для OTT-sidecar выполняется в Deploy Tools в файле batch-tasks.ott-sidecar.all.conf.

Подробнее см. в разделе «Автоматизированная установка сервиса с использованием Deploy Tools».

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

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

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

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

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

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

   • прикладного пользователя tasks_appl_user, от имени которого приложение будет соединяться с БД;

   • пользователя-владельца схемы данных tasks_owner_user, от имени которого необходимо запускать скрипты.

2. Создайте БД.

3. Добавьте пользователей.

4. Перезагрузите БД.

5. Выполните SQL-скрипт создания схемы данных и предоставления прав.

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

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

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

1. После авторизации на КТС повысьте привилегии до root. Для этого запустите оболочку (shell) с правами root: sudo -s.

2. Переключитесь для работы под пользователем postgres: su — postgres.

3. Запустите утилиту psql (или полный путь/usr/local/pgsql/bin/psql, если не запускается без указания полного пути).

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

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

Для выполнения скриптов Liquibase необходимо хотя бы для одной роли указать наименование: tasks_appl_user.

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

select * from pg_catalog.pg_user;

Создание БД#

Для создания базы данных для среды разработки выполните от имени пользователя 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

Где:

• 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.

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

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, под пользователем-владельцем сервиса, например: postgres.

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

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

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

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 — полное доменное имя сервера.

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

chmod og-rwx server.key

3. Отправьте запрос на подпись сертификата (server.csr) в удостоверяющий центр.

4. Расположите подписанный сертификат с именем server.crt в директории сертификатов ($PGDATA/certs).

5. Расположите корневой сертификат (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

Способ шифрования 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.xx.xx.x/xx   cert

Где:

• database_name — имя базы данных;

• tasks_appl_user — имя пользователя;

• 10.xx.xx.x/xx — маска адресов серверов приложений, в формате IPv4.

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

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

$ openssl s_client -starttls postgres -connect 10.xx.xx.xx:5432 -showcerts

Где:

• 10.xx.xx.xx — адрес узла СУБД PostgreSQL;

• 5432 — порт подключения к БД по умолчанию.

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

no peer certificate available

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

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

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

1. В файле batch-tasks.istio.all.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

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

host batch_demo_db batch_owner_user, batch_appl_user 0.0.0.0/0 md5

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

pg_ctl reload
pg_ctl restart

4. Добавьте недостающие секреты для режима без 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

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

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

1. Заполните конфигурацию подключения к БД под пользователем-владельцем (tasks_owner_user) в файле (расположен в дистрибутиве):

   • основная БД: /db/postgresql/liquibase.properties;

   • репликационная БД: /db/postgresql/liquibase-si.properties.

2. Выполните нужный скрипт (расположены в дистрибутиве):

   • основная БД:

     • если установка производится на стенды с 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, type:

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

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

Установка БД с 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.

Запуск 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.

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