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

В данном руководстве приведены инструкции по установке компонента Сессионные данные (SUSD) продукта Platform V SessionsData (SUS).

Для клиентского модуля ССД из состава программного компонента данное руководство неприменимо. Подключение и конфигурирование клиентского модуля ССД осуществляется согласно сведениям, приведенным в документе «Руководство прикладного разработчика», раздел «Подключение и настройка клиентского модуля ССД».

Этот документ содержит названия переменных, которые одинаково применимы для различных сред контейнеризации, указанных в системных требованиях. Имя переменной не определяет конкретную среду контейнеризации.

Термины и сокращения#

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

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

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

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

Примечание:

*

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

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

**

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

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

*** — версия для приложений, запускаемых на VM (master-ССД).

**** — версия для приложений, запускаемых в контейнеризированной среде (slave-ССД, manager-ССД и servant-ССД).

Для проверки работоспособности компонента Сессионные данные после установки потребуется утилита curl.

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

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

Примечание:

***

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

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

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

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

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

Конфигурация VM для установки master-ССД:

• CPU: 4.

• RAM: 24 ГБ.

• HDD: 120 ГБ.

Квота на проект в среде контейнеризации для установки manager-ССД и servant-ССД: 12 CPU, 16 ГБ.

Количество pod на один элемент развертывания (deployment unit): 1 ufs-session-manager-unver, 1 ufs-session-servant-unver, 1 egressgateway-sds-management-unver, 1 ingressgateway-sds-management-unver.

Характеристики sidecar-контейнеров:

• sidecar-контейнеры для сервиса egressgateway-sds-management-unver: ott-sidecar;

• sidecar-контейнеры для сервиса ingressgateway-sds-management-unver: ott-sidecar;

• sidecar-контейнеры для сервиса ufs-session-manager-unver: istio-proxy, sds-slave;

• sidecar-контейнеры для сервиса ufs-session-servant-unver: istio-proxy.

Квота на pod c учетом sidecar-контейнеров:

• egressgateway-sds-management-unver: 0,2 CPU, 512Mi + ott-sidecar 0.8 CPU, 1Gi — итого 1 CPU, 1,5 ГБ;

• ingressgateway-sds-management-unver: 0,2 CPU, 512Mi + ott-sidecar 0.8 CPU, 1Gi — итого 1 CPU, 1,5 ГБ;

• ufs-session-manager-unver: 0,8 CPU, 2Gi + istio-proxy sidecar 0.3 CPU, 256Mi + sds-slave sidecar 0,8 CPU, 1Gi — итого 1,9 CPU, 3,25 ГБ;

• ufs-session-servant-unver: 1 CPU, 4Gi + istio-proxy sidecar 0,3 CPU, 256Mi — итого 1,3 CPU, 4,25 ГБ.

Механизмы безопасности#

Установка и настройка программных и программно-аппаратных средств, в том числе внешних (операционной системы, другого системного программного обеспечения) должна осуществляться в соответствии с документацией к этим средствам.

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

Компонент Сессионные данные поставляется в виде zip-архива, который называется дистрибутивом.

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

• binaries-{distrib-version}-distrib.zip — бинарные артефакты;

• <версия дистрибутива конфигов>_CFG_ALL-distrib.zip — архив конфигурационных артефактов.

Архив с бинарными артефактами включает в себя каталоги и файлы, описанные в таблице ниже.

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

Конфигурационные артефакты привязываются к бинарным через указание зависимости в pom.xml. Поэтому при установке необходимо выбирать версию конфигурационного архива, но в результате проверки environment/product должна вернуться версия бинарного.

Расположение конфигурационных файлов#

Перед тем как устанавливать ПО, подготовьте конфигурационные файлы. Конфигурационные файлы содержат в себе настройки и хранятся в 3-х местах:

• дистрибутиве;

• git-репозитории конфигурации компонента;

• git-репозитории конфигурации среды.

1. Конфигурационные файлы дистрибутива.

   Каталоги и файлы, которые содержит архив с конфигурационными артефактами, описаны в разделе «Состав дистрибутива».

2. Конфигурационные файлы inventory.

   Репозиторий конфигурации компонента еще называют «репозиторием inventory». Он хранит в себе настройки, которые применяются только к устанавливаемому ПО в блоке или контуре. Сюда попадет часть конфигурационных файлов дистрибутива, этот процесс называется миграцией.

   Миграция позволяет перезаписывать значения настроек в конфигурационных файлах репозитория. Таким образом, для разных сегментов можно выставить свои значения настроек. Миграция применима только к некоторым файлам с расширением .conf и .yaml. Как выполнить миграцию, смотрите в пункте Миграция.

3. Конфигурационные файлы common-репозитория.

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

Теперь, после ознакомления с конфигурационными файлами, можно приступать к установке ПО. Как ее выполнить, смотрите в разделе «Установка».

Перед установкой master-ССД необходимо выполнить подготовку. Как ее выполнить, читайте в разделе «Подготовка».

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

Подготовка к установке master-ССД#

Подготовка VM#

Установка требуемого ПО

Установите необходимое программное обеспечение.

• ОС Альт 8 СП

apt-get install java-11-openjdk-devel=11.0.13*
apt-get install openssl=1.1.1*
apt-get install polkit=0.115*

• Red Hat Enterprise Linux

Важно! Строго не рекомендуется использовать версию Red Hat Enterprise Linux 7.9 и ниже! Рекомендуемая версия — Red Hat Enterprise Linux 8.4

yum install java-11-openjdk-devel-11.0.13*
yum install openssl-1.1.1*
yum install polkit-0.115*

Конкретные версии, проверенные на стендах тестирования:

• ОС Альт 8 СП

java-11-openjdk-devel-11.0.13.8-alt0.c9.1_1jpp11
openssl-1.1.1k-alt1
polkit-0.116-alt1

• Red Hat Enterprise Linux

java-11-openjdk-devel-11.0.13.0.8-4
openssl-1.1.1k-5.el8_5
polkit-0.115-13.el8_5.1

Пользователи

1. Создайте двух пользователей и задайте для них пароль в терминале ОС:

   adduser sds-master
   passwd **********
   adduser sds-read-only
   passwd *************
   

   Пользователь sds-master создается для работы Deploy tools и запуска приложения. У него есть права на чтение/запись всех подкаталогов. Пользователь sds-read-only создается для просмотра всех настроек приложения, его файловых логов и сброшенных дампов памяти JVM. У него есть права только на чтение подкаталогов config, logs, dumps.

   Убедитесь, что gid для sds-master равен sds-master:

   usermod -g sds-master sds-master
   id sds-master
   

   В выводе команды id sds-master должно содержаться gid=XXXX(sds-master).

2. Далее в группу sds-master добавьте пользователя sds-read-only, используя следующую команду:

   usermod -a -G sds-master sds-read-only

Директории

1. Создайте каталог /opt/sds-master.

2. Присвойте данный каталог пользователю sds-master:sds-master.

3. Дайте полные права пользователю и +x для группы (для того чтобы у пользователя sds-read-only появился доступ к каталогу /opt/sds-master/logs).

   mkdir /opt/sds-master
   chown sds-master:sds-master /opt/sds-master
   chmod 710 /opt/sds-master
   

Сервис systemd

Создайте файл /etc/systemd/system/sds-master.service.

[Unit]
Description=sds master
After=syslog.target
After=network.target

[Service]
User=sds-master
Group=sds-master
WorkingDirectory=/opt/sds-master
OOMScoreAdjust=-100
Type=forking
ExecStart=/usr/bin/java ./app/Run.java
ExecStop=/usr/bin/java ./app/Stop.java

Restart=on-failure
RestartSec=60

[Install]
WantedBy=multi-user.target

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

systemctl daemon-reload
systemctl enable sds-master.service

Права на запуск сервиса

Необходимо дать пользователю sds-master права на запуск/остановку сервиса sds-master.service, используя polkit.

Для этого создайте файл /etc/polkit-1/rules.d/57-manage-sds-master.rules

polkit.addRule(function(action, subject) {
    polkit.log("action=" + action);
    polkit.log("subject=" + subject);
    polkit.log("unit=" + action.lookup("unit"));
    polkit.log("unit=" + JSON.stringify(action, null, 4));

    if (action.id == "org.freedesktop.systemd1.manage-units" &&
        action.lookup("unit") == "sds-master.service" &&
        subject.user == "sds-master") {
        polkit.log("!!!!!!");
        return polkit.Result.YES;
    }
});

После создания файла завершите все сессии пользователя sds-master и зайдите заново, чтобы правило применилось.

Важно! Строго не рекомендуется использовать версию Red Hat Enterprise Linux 7.9 и ниже! Рекомендуемая версия — Red Hat Enterprise Linux 8.4

Подготовка стенда для первичной установки#

1. Добавьте в secret.yml user и pass для выполнения установки master-ССД (например, SSD_SSH_USER (sds-master) и SSD_SSH_PASS).

   Пользователь sds-master и пароль должны быть созданы, как указано в пункте «Подготовка VM для развертывания master-ССД».

2. Добавьте в passwords.conf параметры для расшифровки секретов master-ССД.

   ufs-session-master.secrets.decryption.password
   ufs-session-master.secrets.decryption.salt
   ufs-session-master.secrets.decryption.iterationCount
   

   Пример значений:

   ufs-session-master.secrets.decryption.password=vm_secrets_pass
   ufs-session-master.secrets.decryption.salt=0123456789abcdef
   ufs-session-master.secrets.decryption.iterationCount=1000
   

   Примечание: salt должен быть длиной строго 16 hex-символов, т.к. это бинарный параметр длиной 64 бита.

   $ openssl rand -hex 8
   

3. Добавьте в passwords.conf ключи для шифрования/расшифровки маршрутизирующей информации.

   jaas.ufs_session_master_key_01.password
   jaas.ufs_session_master_key_02.password
   jaas.ufs_session_master_key_03.password
   

   В пункте «Генерация ключей шифрования» подробно описан процесс создания нового ключа.

4. Настройте inventory.

   Примечание: репозиторий inventory доступен только после выполнения этапа «Миграция» (запуска MIGRATION_FP_CONF). Подробнее о миграции читайте в разделе «Установка».

   Сервера, на которые необходимо выполнить установку master-ССД, должны быть указаны в файле inventory или globalInventory. Могут быть указаны группы серверов. Ниже приведен пример:

   [vm_sds_master:children]
   vm_blue
   vm_green
   
   [vm_blue]
   server1 ansible_user="{{ SSD_SSH_USER }}" ansible_ssh_pass="{{ SSD_SSH_PASS }}"
   
   [vm_green]
   server1 ansible_user="{{ SSD_SSH_USER }}" ansible_ssh_pass="{{ SSD_SSH_PASS }}"
   
   [nginx_node_mm]
   server1
   server2
   
   [hosts:children]
   local
   vm_sds_master
   

Настройка ключей шифрования#

Данные о местонахождении master-ССД, отвечающего за сессию, шифруются в идентификаторе сессии с помощью симметричного алгоритма шифрования с использованием ключа шифрования. Название (alias) данного ключа указано в настройке ufs.sds.keys.ids.for.session.id.encryption. По умолчанию настройка ufs.sds.keys.ids.for.session.id.encryption содержит ровно одно значение alias ключа — ufs_session_master_key_01 Для корректной работы шифрования необходимо, чтобы на всех VM, на которых развернут master-ССД, присутствовал ключ с соответствующим alias.

Генерация ключей шифрования#

Cгенерируйте ключ, используя функцию Security Job компонента Deploy tools. При запуске в качестве параметров укажите список идентификаторов ключей, которые должны быть перегенерированы. В результате в файл _password.conf common-репозитория добавится сгенерированный контейнер pcks#12 с ключами, а также пароль к контейнеру.

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

После генерации ключа и добавления в _password.conf установите его. В файле custom_property.conf.yml заполните имена секретов jasypt_secret_keys, заданных на стенде в _passwords.conf.

Примечание. В целях обеспечения непрерывности работы при обновлении ключей шифрования (например, при возникновении ошибок шифрования или в случае компрометации ключей) рекомендуется сгенерировать три ключа. Как выполнить обновление ключей, читайте в разделе «Обновление».

Установка ключей шифрования#

Установка ключей шифрования произойдет во время развертывания приложения. Как выполняется установка, смотрите в пункте «Установка master-ССД». В результате ключи, указанные в jasypt_secret_keys, будут доставлены на master-ССД.

Подготовка БД#

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

1. Создайте:

   • схему «susd_<суффикс>»;

   • табличные пространства: «susd_ts_data» и «susd_ts_idx»;

   • пользователя «susd_<суффикс>».

2. Добавьте переменные:

   • в secret.yml: SUSD_POSTGRES_DB_ADMIN и SUSD_POSTGRES_DB_PASS;

   • в passwords.conf: jdbc.susd.postgres.user и jdbc.susd.postgres.password.

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

Предусмотрена только автоматизированная установка сервиса, которая выполняется с помощью компонента Deploy tools (CDJE) продукта Platform V DevOps Tools (DOT). Доступ к Deploy tools осуществляется с помощью интерфейса Jenkins.

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

Если установка производится в блок/контур, на котором ПО ранее не устанавливалось, необходимо выполнить установку (смотрите раздел «Установка»).

Если установка производится в блок/контур, на который установлена ранняя версия ПО, необходимо выполнить обновление (смотрите раздел «Обновление»).

Установка#

Установка компонента Сессионные данные включает в себя следующие этапы:

1. Миграция конфигурационных файлов.

2. Импорт параметров.

3. Развертывание приложений.

Миграция#

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

Важно! Перед запуском миграции SESSION_REGISTRY_MASTER и SESSION_REGISTRY_SERVANT проверьте, что в репозитории inventory в файле /conf/limits/nginx-iag-limits.fact версия схемы соответствует текущей – {"schema_version": "4.1"}. Если версия другая, то на этапе генерации конфигурационных файлов для маршрутизации запросов произойдет ошибка. Чтобы этого избежать, измените версию на 4.1.

Запуск миграции:

1. Перейдите в интерфейс Jenkins.

2. Откройте параметры сборки, нажав на опцию слева «Собрать с параметрами».

3. На открывшейся странице введите параметры:

   • SUBSYSTEM: для slave-ССД значение UFS_SESSION, для master-ССД — SESSION_REGISTRY_MASTER, для manager-ССД и servant-ССД — SESSION_REGISTRY_SERVANT;

   • DISTRIB_VERSION: версия дистрибутива;

   • PARAMS: репозиторий\ветка с настройками компонента — branch <текущий релиз>.

4. Выберите следующие сценарии для запуска (playbook), поставив галочку напротив:

   • MIGRATION_FP_CONF

   • CLEANUP_FP_CONFIG

5. Нажмите кнопку «Собрать».

Импорт параметров#

Компонент Сессионные данные зависит от других сервисов. Подробную информацию о таких сервисах смотрите в таблице в разделе «Системные требования», пункт «Платформенные зависимости».

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

Настройки других сервисов содержатся в конфигурационной составляющей дистрибутивов приложений в каталоге ./conf/data.

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

Для работы в АРМ ССД в компонент Объединенный сервис авторизации (ОСА) импортируется модель авторизации. Модель авторизации описывает набор привилегий пользователей АРМ ССД. Для доступа пользователя к АРМ ССД необходимо, чтобы:

1. К группе суперпользователя был привязан набор привилегий «Администратор Сервиса сессионных данных» (войдите в АРМ Сервиса авторизации -> Страница «Группы» -> Найдите группу «Прикладной администратор платформенного сектора» -> На странице просмотра информации о группе добавьте набор «Администратор Сервиса сессионных данных»).

2. В условиях группы был добавлен логин пользователя (войдите в АРМ Сервиса авторизации -> Страница «Группы» — Найдите группу «Прикладной администратор платформенного сектора» -> На вкладке «Условия» добавьте в «ATTR_USERNAME» свой логин).

Примечание. Предполагается, что данные действия будут выполнены сопровождением Platform V IAM SE.

Запуск импорта:

1. Перейдите в интерфейс Jenkins.

2. Откройте параметры сборки, нажав на кнопку «Собрать с параметрами».

3. На открывшейся странице заполните параметры:

   • SUBSYSTEM: для slave-ССД значение UFS_SESSION, для master-ССД — SESSION_REGISTRY_MASTER, для manager-ССД и servant-ССД — SESSION_REGISTRY_SERVANT;

   • DISTRIB_VERSION: версия дистрибутива;

   • PARAMS: репозиторий\ветка с настройками компонента — branch <текущий релиз>.

4. Выберите следующие сценарии для запуска (playbook), поставив галочку напротив:

   • IMPORT_SECURITY_PARAMS — импорт в Объединенный сервис авторизации (ОСА)

   • IMPORT_ALL_PARAMS — импорт всех настроек других сервисов (если все платформенные зависимости представлены на стенде)

5. Нажмите на кнопку «Собрать».

Установка slave-ССД#

Установка выполняется вместе с прикладным сервисом, использующим функциональность slave-ССД. Сервис-потребитель подключает sidecar slave-ССД в прикладном проекте. Как выполняется подключение slave-ССД, смотрите в документе «Руководство прикладного разработчика», раздел «Подключение и конфигурирование sidecar slave-ССД».

Шаги установки:

1. Обновите сервисы, используемые приложением ССД, до актуальных версий, которые указаны в разделе «Системные требования», пункт «Платформенные зависимости».

2. Выполните установку прикладного проекта, подключившего sidecar slave-ССД, согласно инструкции сервиса-потребителя.

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

В общем случае миграция и импорт выполняются инструментами Deploy tools сектора, в который производится установка. Если в каком-то сегменте есть исключение из общего случая, выполните миграцию и импорт в соответствии с действующим в сегменте порядком (например, возможен вариант, когда в common-репозитории добавляется запись в subsystem.json с другим id сектора).

В результате выполнения указанных выше действий slave-ССД будет установлен в виде sidecar-контейнера в pod прикладного проекта.

Если после установки возникли проблемы, выполните откат к предыдущей версии. Для этого обратитесь к разделу «Откат».

Установка master-ССД#

Примечание. Перед установкой master-ССД выполните подготовку, как указано в разделе «Подготовка к установке master-ССД», сгенерируйте ключи шифрования, как указано в разделе «Настройка ключей шифрования», а также убедитесь, что выполнены миграция и импорт параметров.

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

1. Перейдите в интерфейс Jenkins.

2. Откройте параметры сборки, нажав на кнопку «Собрать с параметрами».

3. На открывшейся странице заполните параметры:

   • SUBSYSTEM: SESSION_REGISTRY_MASTER;

   • DISTRIB_VERSION: версия дистрибутива;

   • PARAMS: репозиторий\ветка с настройками компонента — branch <текущий релиз>.

4. Выберите следующие сценарии для запуска (playbook), поставив галочку напротив:

   • VM_START

   • VM_STOP

   • VM_DEPLOY

   • VM_SMOKE

   • NGINX_MM_DEPLOY

   • API_MANAGER_UPLOAD

5. Нажмите кнопку «Собрать».

Важно! Если эта инструкция используется для отката к предыдущей версии, то параметры «DISTRIB_VERSION» и «PARAMS» => «Репозиторий\ветка с настройками компонента» должны быть заполнены соответствующими значениями.

После успешного завершения сборки на серверы, описанные в файле inventory, будут установлены приложения master-ССД, а также будет создана конфигурация для маршрутизации запросов (playbook NGINX_MM_DEPLOY).

Редактирование java-опций запуска master-ССД#

При возможных проблемах с загрузкой java-опций из переменной ufs_session_master_java_opts (файл /opt/sds-master/config/session_registry_master.conf) необходимо это исправить следующим образом:

1. В файле /opt/sds-master/app/Run.java в методе startExecutableJarBy() добавьте нужную опцию, используя метод append() объекта startCommand:

   startCommand.append( " -D<java-option1> -D<java-option2>" )
   

2. Перезапустите master-ССД.

Важно! Опции должны добавляться в строку через 1 пробел!

Например, для переключения на ParallelGC нужно добавить опцию -XX:+UseParallelGC, ниже добавляемая опция выделена //+:

private void startExecutableJarBy( ProcessBuilder builder ) throws IOException {
    LOGGER.info( "Запуск Spring Boot приложения" );
    StringBuilder startCommand = new StringBuilder()
        .append( "java -Dufsparams.config.directory=" ).append( RUNTIME_PARAMS_PATH )
        .append( " -XX:+UseParallelGC") //+
        .append( " -Dspring.profiles.active=PROM,COMMON -Dhealthcheck.offline=true" );
...
}

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

Примечание. Перед установкой БД выполните подготовку, как указано в разделе «Подготовка БД».

Шаги установки:

1. Перейдите в интерфейс Jenkins.

2. Откройте параметры сборки, нажав на кнопку «Собрать с параметрами».

3. На открывшейся странице заполните параметры:

   • SUBSYSTEM: SESSION_REGISTRY_SERVANT;

   • DISTRIB_VERSION: версия дистрибутива;

   • PARAMS: репозиторий\ветка с настройками компонента — branch <текущий релиз>.

4. Выберите следующие сценарии для запуска (playbook), поставив галочку напротив: DB_UPDATE.

5. Нажмите кнопку «Собрать».

Установка схемы выполняется Deploy tools с помощью Liquibase. В результате в БД контура\блока установится схема ССД из дистрибутива.

Если после установки в блоке\контуре возникли проблемы, выполните откат к предыдущей версии. Для этого обратитесь к разделу «Откат».

Установка UI ССД, manager-ССД и servant-ССД#

Шаги установки:

1. Перейдите в интерфейс Jenkins.

2. Откройте параметры сборки, нажав на кнопку «Собрать с параметрами».

3. На открывшейся странице заполните параметры:

   • SUBSYSTEM: SESSION_REGISTRY_SERVANT;

   • DISTRIB_VERSION: версия дистрибутива;

   • PARAMS: репозиторий\ветка с настройками компонента — branch <текущий релиз>.

4. Выберите следующие сценарии для запуска (playbook), поставив галочку напротив:

   • OPENSHIFT_DEPLOY

   • OPENSHIFT_INGRESS_EGRESS_DEPLOY

   • NGINX_DEPLOY

   • API_MANAGER_UPLOAD

5. Нажмите кнопку «Собрать».

Важно! Если эта инструкция используется для отката к предыдущей версии, то параметры «DISTRIB_VERSION» и «PARAMS» => «Репозиторий\ветка с настройками компонента» должны быть заполнены соответствующими значениями.

После установки убедитесь, что:

• На сервере nginx_ui {{nginx_iag_home_path}} (глобальная переменная, указывающая на путь для статики сервера nginx) разархивировалась статика из папки package/pl дистрибутива.

• Сервер nginx_ui содержит файлы locations, upstreams и routing в папке /opt/nginx-iag/conf в соответствии с файлами конфигурации:

  • nginx-iag-routing.json.j2

  • nginx-iag-services.json.j2

  • nginx-iag-nodes.json.j2

• В результате выполнения OPENSHIFT_DEPLOY manager-ССД и servant-ССД успешно стартовали (Status pod — Running).

Если после установки в блоке/контуре возникли проблемы, выполните откат к предыдущей версии. Для этого обратитесь к разделу «Откат».

Обновление#

Обновление представляет собой установку новой версии релиза.

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

1. Обновите сервисы, используемые приложениями ССД, до актуальных версий, которые указаны в разделе «Системные требования», пункт «Платформенные зависимости».

2. Выполните обновление компонента Сессионные данные. Для выполнения обновления воспользуетесь инструкциями в разделе «Установка».

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

1. Установка новой версии slave-ССД возможна только после обновления всех master-ССД в блоке/контуре.

2. Slave-ССД обновляется вместе с прикладным проектом, использующим функциональность новой версии ССД, согласно инструкции сервиса-потребителя.

3. Новая версия master-ССД совместима со всеми версиями slave-ССД блока/контура.

4. Новая версия БД совместима с предыдущей версией релиза master-ССД и servant-ССД.

5. Новая версия servant-ССД совместима со старыми версиями master-ССД и manager-ССД, но только с одним прошлым релизом.

6. К обновлению manager-ССД нет особых указаний, так как для него не требуется поддержка обратной совместимости, но обновление manager-ССД, включая расположенный рядом с ним slave-ССД, следует выполнять после обновления servant-ССД.

7. При обновлении БД блок/контур выводятся из нагрузки, устанавливается БД ССД, как у казано в разделе «Установка», и блок/контур снова вводится под нагрузку.

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

1. Сгенерируйте ключ, как указано в пункте «Генерация ключей шифрования».

2. В файле custom_property.conf.yml задайте имена секретов jasypt_secret_keys.

3. Запустите развертывание master-ССД на VM, чтобы ключи, указанные в jasypt_secret_keys, были доставлены на master-ССД.

4. Добавьте новый идентификатор в список ключей в параметре ufs.sds.keys.ids.for.session.id.encryption первым.

5. Подождите время, равное как минимум 2 * (среднее время жизни сессии).

6. Уберите из списка ключей старый идентификатор (ufs_session_master_key_01).

В момент, когда в списке идентификаторов ключей находится более одного ключа, master-ССД придерживается следующего поведения:

• маршрутизирующая информация новых сессий шифруется самым новым ключом (указанным в настройке ufs.sds.keys.ids.for.session.id.encryption первым);

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

Удаление#

Удаление slave-ССД выполняется вместе с прикладным проектом, подключившим sidecar, согласно инструкции сервиса-потребителя.

Для удаления UI ССД, manager-ССД и servant-ССД необходимо:

1. Удалить конфигурационные файлы из репозитория inventory.

2. Удалить PL-компоненты и настройки с группы серверов nginx_ui.

3. Удалить все ресурсы в среде контейнеризации.

Для удаления master-ССД необходимо:

1. Добавить в environment.json сценарий для запуска VM_DEL_RES для функции Security Job компонента Deploy tools.

2. Заполнить в inventory в ansible/UTIL_SECURE/inventory параметры:

   app.delete=true
   config.delete=true
   logs.delete=true
   ssl.delete=true
   secrets.delete=true
   dumps.delete=true
   

3. Запустить playbook VM_DEL_RES.

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

Для проверки правильности функционирования slave-ССД в pod прикладного проекта выполните следующие действия:

1. Проверьте, что проходит readiness-probe. В консоли зайдите в конкретный pod каждого приложения: Pods -> Pod Details, перейдите на закладку Events. Если ошибок нет, то pod стартовал.

2. Проверьте Status pod. В консоли откройте вкладку Pods. Нажмите на нужный pod, перейдите во вкладку YAML, containerStatuses -> name: sds-slave. Должно быть указано: started:true, ready:true.

Для проверки правильности функционирования приложений master-ССД, manager-ССД и servant-ССД выполните специальные запросы:

• http://<хост:порт>/<context-root>/environment/product. В ответе обратите внимание на параметры: success: true, в body «distribVersion» — текущая версия дистрибутива {distrib-version}.

• http://<хост:порт>/<context-root>/healthcheck. В ответе обратите внимание на параметры: success: true, body: OK.

• http://<хост:порт>/<context-root>/v1/info/getSDSInfo?needExtendedInfo=true

В ответе должны быть поля:

{
    "success": true,
    "body": {
        …
        "threadPoolInJNDI": true,
        …
        "supParametersReadOK": true,
         …
        "httpclientSupParameters": { "ufs.baseurl.sds.* ": [прописан правильный адрес]}
        "appSpecificParameters": { "masterKeys": [не пустой] – только для master-ССД}
    }
}

Запросы можно выполнить как в браузере, так и при помощи утилиты curl: curl -X GET <запрос>.

Вместо context-root в запросах подставьте соответствующее значение Context root из таблицы ниже:

Для проверки работы АРМ ССД войдите в UI АРМ ССД по ссылке https://<хост_IAM>/ufs-session-manager/, включите переключатель «Расширенный поиск», нажмите кнопку «Поиск». Ожидаемый результат: нет сообщений об ошибке.

Откат#

БД обратно совместима с предыдущей версией и в откате не нуждается.

Если при установке master-ССД, UI ССД, manager-ССД и servant-ССД произошли ошибки, и установка завершилась неуспешно, произведите откат к предыдущей версии, успешно установленной. Для отката выполните установку дистрибутива предпоследней версии согласно разделу Установка. В завершение проверьте правильность функционирования приложений.

Если при установке slave-ССД, подключенного в прикладном проекте, произошли ошибки, и установка завершилась неуспешно, произведите откат согласно инструкции сервиса-потребителя. Откат предполагает установку предыдущей версии и сервиса-потребителя, и расположенного рядом с ним slave-ССД.

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

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