Руководство по установке для тестовых сред EVTA#

Описание ландшафта#

ВАЖНО! Для выполнения установки необходимо иметь доступ к узлу, с которого будет осуществляться установка – локально или по SSH под пользователем, имеющим на узле права администратора (находящимся в группе wheel), либо под пользователем root.

В случае, если для выполнения какой-либо команды ниже не хватает прав вашего пользователя - повторить команду, добавив к ней в начале «sudo». Например: «sudo yum -y install unzip».

ВАЖНО! Данная инструкция реализована для узла с узла с ALT 8 SP Server. Менеджеры пакетов на других версиях Linux и способы их установки в корпоративных сетях могут отличаться.

Проверка версии Linux:

cat /etc/*-release

Результат вывода покажет версию, например:

NAME=»ALT SPServer» VERSION=»8.4»

ВАЖНО! Описана установка EVTA в среде контейнеризации с вариантом передачи REST–Kafka. В качестве среды контейнеризации использовался Kubernetes 1.22.2.

ВАЖНО! Предполагается, что все упомянутые ниже произвольные текстовые метки содержат буквы только латинского алфавита. Использование алфавитов других языков не проверялось.

Для уcтановки используется версия EVTA 3.1.0.

В установке использовалась 1 ВМ с ОС ALT 8 SP Server - в качестве узла, с которого производилась установка и пространство кластера Kubernetes.

Целевое состояние тестового развертывания продукта - EVTA развернут в виде pod в K8s в варианте подключения «REST-Kafka». На тестовом контуре выполнена также связка развернутых EVTA и EVTD. Есть возможность обмена сообщениями через настроенные при развертывании топиков.

Предусловия подготовки окружения для развертывания EVTA#

С узла установки EVTA необходимо иметь доступ в интернет, либо при его отсутствии - обеспечить возможность установки следующих вспомогательных пакетов из другого доступного источника:

UnZip 6.00 of 20 April 2009, by ALT Linux Team. Original by Info-ZIP
Python 2.7.18
OpenJDK 11.0.19.1 2023-04-18
GNU Midnight Commander 4.8.27-alt1
Groovy Version: 2.4.8
Docker version 23.0.1, build e92dd87
kubectl Client Version: v1.26.6
helm version.BuildInfo{Version:»v3.10», GitCommit:»», GitTreeState:»», GoVersion:»go1.18.9»}

Предварительно необходимо иметь репозиторий, куда будет выложен образ EVTA для установки (например, Nexus):

До репозитория должен быть сетевой доступ с узла, с которого будет осуществляться установка;
В репозитории должен быть заранее создан пользователь с правами на чтение и запись, для которого известны логин и пароль;
В репозитории должен присутствовать собственный базовый образ для сборки контейнеров. Путь до него должен быть известен. Пример пути до базового образа: «./base/redhat/openjdk-11-rhel8:1.0-8»

Необходимо иметь готовый кластер Kubernetes.

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

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

получить метаданные кластера в виде файла kubeconfig;
создать пространство (namespace) с произвольным именем, где требуется развернуть EVTA. Namespace желательно создать заранее. Также его можно будет создать позже. (18 пункт данного Руководства)

ВАЖНО! После развертывания обращение к pod EVTA по REST будет доступно только изнутри namespace.

Подготовка узла, с которого будет осуществляться установка#

Подключиться к узлу, с которого будет осуществляться установка, по SSH или локально под пользователем, имеющим на узле права администратора (находящимся в группе wheel), либо под пользователем root.

Для входа по SSH с локальной машины - запустить локальный терминал (консоль) и ввести в командной строке:

"ssh <имя_пользователя>@<ip_адрес_узла>"

, где <имя_пользователя> – логин пользователя, под которым необходимо зайти на удаленный узел. Например, «ssh evta@IP_ADDRESS». После ввода в консоли будет запрошен пароль - ввести пароль пользователя, под которым необходимо зайти на удаленный узел (процесс ввода в консоли никак не будет отображаться) и нажать enter (для macOS - return).

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

Выбрать директорию, откуда будет осуществляться установка.

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

Рекомендуется создать в домашней директории специальную поддиректорию (например - «evta») и далее работать в ней. Далее по тексту данная директория будет упоминаться как «Основная рабочая директория».

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

mkdir ~/evta

Проверить успешность создания командой:

ls -la

В отобразившемся списке найти созданную директорию и перейти в нее, набрав команду:

cd evta

Проверить наличие Python и его версию командой:

python3 --version

При наличии: будет выведено сообщение вида «Python 3.6.8».

При отсутствии: будет выведено сообщение о неизвестной команде вида «-bash: python3: command not found».

Если python3 отсутствует - проверить наличие версий ниже:

python2 --version или python --version

Если никакая версия не обнаружена - установить Python версии 2.7.18.

Если при попытке установки системных программ через репозиторий yam появляется проблема похожая на:

CentOS-8 - AppStream 28 B/s | 38 B 00:01
Error: Failed to download metadata for repo 'AppStream': Cannot prepare internal mirrorlist: No URLs in mirrorlist

Выполните следующие команды под пользователем root:

cd /etc/yum.repos.d/

sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*

sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*

И далее выполните команду установки Python:

dnf module install python27

Проверить наличие пакета unzip.

Проверка – ввод в консоли «unzip» без аргументов.

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

При отсутствии: будет выведено сообщение о неизвестной команде.

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

sudo yum -y install unzip

Проверить наличие пакета Openjdk-11.

Для этого ввести в консоли команду:

java --version

При наличии: будет выведено сообщение вида:

openjdk version "11.0.19.1" 2023-04-18 LTS

OpenJDK Runtime Environment 18.9 (build 11.0.19.1+1)

OpenJDK 64-Bit Server VM 18.9 (build 11.0.19.1+1, mixed mode, sharing)

При отсутствии: будет выведено сообщение о неизвестной команде.

При отсутствии пакета выполнить:

yum -y install java-11-openjdk

Проверить наличие переменной JAVA HOME.

Для этого ввести в консоли команду:

set | grep JAVA_HOME

Если вывод пустой - переменная не установлена.

Вывод «JAVA_HOME=<какое-то_непустое_значение>» говорит о том, что переменная уже установлена. Например: «JAVA_HOME=/usr/lib/jvm/java-11-openjdk-11.0.16.1.1-1.el8_4.x86_64».

Если переменная не установлена, то выполнить команды:

sudo echo "export JAVA_HOME=\$(dirname \$(dirname \$(realpath \$(which java))))" > /etc/profile.d/java.sh

sudo source /etc/profile.d/java.sh

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

set | grep JAVA_HOME

Должен быть получен успешный вывод.

Проверить наличие оболочки Midnight Commander.

Для этого ввести в консоли команду:

mc

При наличии оболочки откроется окно Midnight Commander с отображением содержимого текущей директории. При отсутствии в консоли будет выведено сообщение о неизвестной команде.

При отсутствии Midnight Commander выполнить команду для установки:

sudo yum install -y mc

Проверить результат вводом в консоли «mc».

Для дальнейшей работы:

«control + o» – свернуть/показать окно Midnight Commander;
«F10» – закрыть Midnight Commander.

ВАЖНО! Одновременно может быть открыто только одно окно Midnight Commander. Ввод в консоли команды «mc» при свернутом окне запущенного Midnight Commander приведет к появлению окна с текстом «Warning! GNU Midnight Commander is already running on this terminal. Subshell support will be disabled». В этом окне необходимо нажать «ОК» и штатно работать дальше.

Установить groovy.

Для этого выполнить команду:

sudo apt-get install groovy

Из менеджера пакетов установился Groovy Version: 2.4.8. Рекомендованная версия Groovy Version: 3.0.х

Проверить наличие командой «groovy» – будет выведена справка по ключам утилиты.

Установить Docker.

Проверить наличие docker командой «docker –version».

Успешный вывод имеет вид, схожий с «Docker version 23.0.1, build e92dd87».

При отсутствии docker будет выведено сообщение о неизвестной команде.

В случае отсутствия docker для установки выполнить последовательность команд:

sudo yum install -y yum-utils

sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo

sudo yum install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

docker --version

После успешной установки выполнить вход в репозиторий образов (чтобы позже была возможность выкачать базовый образ):

docker login <имя_репозитория>

, где <имя_репозитория> имеет вид полного пути, например: «./dev/ci90000_synse_dev/evta».

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

Установить helm.

Для этого выполнить последовательность команд:

Скачать архив:

wget https://get.helm.sh/helm-v3.12.2-linux-386.tar.gz

Ссылка https://get.helm.sh/helm-v3.12.2-linux-386.tar.gz взята из инструкции с сайта https://helm.sh/docs/intro/install/ (переадресация на раздел github со ссылками под разные версии ОС https://github.com/helm/helm/releases, выбрана верcия для Linux i386).

Разархивировать полученный архив:

tar -zxf helm-v3.12.2-linux-386.tar.gz

Скопировать бинарный файл:

cp linux-386/helm /usr/local/bin/helm

Установить kubectl.

Для этого выполнить команды:

cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF

sudo yum install -y kubectl

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

Для этого ввести команду:

kubectl config view

Если вывод похож на:

apiVersion: v1
clusters: null
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null

Значит настройки отсутствуют.

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

Настройки устанавливаются в файле ~/.kube/config. Если директория .kube отсутствует, ее нужно предварительно создать:

mkdir -p ~/.kube

Для формирования файла config есть два способа:

а. Скачать со страницы обзора вашего кластера файл kubeconfig через графический интерфейс, что и будет являться необходимым файлом config, его остается только переименовать и подложить в директорию ~/.kube.

получить доступ к консоли управления;
выбрать Enterprise, далее Managed Kubernetes;
перейти на вкладку Кластеры;
найти нужный кластер и нажать b__choice;
выбрать Скачать Kubeconfig – файл будет загружен на локальную машину;
загрузить файл командой scp на целевой узел;

После этого для проверки выполнить команду «kubectl config view».

б. Если получение файла kubeconfig напрямую с кластера недоступно – файл config можно создать самостоятельно с помощью команд (подробно описаны https://kubernetes.io/docs/reference/generated/kubectl/kubectl-commands#config):

Для указания параметров кластера:

kubectl config set-cluster NAME [--server=server] [--certificate-authority=path/to/certficate/authority] [--insecure-skip-tls-verify=true]

Для указания контекста:

kubectl config set-context NAME [--cluster=cluster_nickname] [--user=user_nickname] [–namespace=namespace]

Для указания параметров пользователя:

kubectl config set-credentials NAME [--client-certificate=path/to/certfile] [--client-key=path/to/keyfile] [--token=bearer_token] [--username=basic_user] [–password=basic_password]

Создание namespace (опционально)#

При отсутствии в кластере Kubernetes целевого namespace для развертывания EVTA создать его командой:

kubectl create namespace <имя_пространства>

Например:

kubectl create namespace evta

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

Поместить в основную рабочую директорию полный дистрибутив продукта (архив с именем EM-*-distrib.zip).

Для отправки на сервер дистрибутива с локального компьютера в случае подключения по SSH можно использовать локальный SCP/SFTP-клиент (например, Far). Либо использовать команду:

scp <источник_передачи> <целевая_точка>

Формат команды:

scp [OPTION] [user@]SRC_HOST:]file1 [user@]DEST_HOST:]file2

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

scp /Users/yxz/EM-2.4.0-1-distrib.zip em@{ IP_ADDRESS }:/home/em/evta/EM-2.4.0-1-distrib.zip

Поэтапно разархивировать дистрибутив.

На сервере из директории, куда был помещен дистрибутив продукта EM, выполнить последовательность команд:

unzip EM-*-distrib.zip

unzip EM-*-owned-distrib.zip

unzip dependency-resolver-*-distrib.zip

В результате в данной директории помимо всего прочего появится директория src.

Произвести склейку дистрибутива.

Для этого выполнить команду:

groovy -cp ./src merge.groovy --report ./Report.json EM-*-vendor-distrib.zip EM-*-party-distrib.zip EM-*-owned-distrib.zip

ВАЖНО! Сохранять последовательность vendor-, party-, owned- архивов в команде выше.

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

unzip -o EM-*-owned-distrib.zip

Создание и заливка docker-образа EVTA#

Перейти в директорию, где лежит Dockerfile.

Для этого выполнить последовательность действий ниже:

а. Выполнить команду:

unzip -o EVTA-bin-*-distrib.zip

В результате в текущей директории появится директория package. Проверить можно командой:

ls -la

б. Далее перейти во вложенную директорию:

cd package/docker/reactivestreamadapter

в. В файле Dockerfile задать свой базовый образ:

Открыть Midnight Commander командой «mc». В файле в первой строке в параметре ARG BASE_IMAGE задать расположение базового образа для сборки образа EVTA (по умолчанию указано значение-пример). Наличие в репозитории базового образа является необходимым предусловием установки.

Строка с параметром должна выглядеть примерно так - «ARG BASE_IMAGE=/ci90000000_cloudspo/altlinux8sp/openjdk11:v0.5.15» (это только пример! нужно указать ваш конкретный базовый образ!).

г. Выполнить последовательность команд:

cp -r ../../bh

Дальнейшие команды данного пункта нужно выполнять с префиксом sudo:

docker build -t <имя_создаваемого_образа>:<версия_создаваемого_образа> .

Например:

docker build -t test-image:1.0

sudo docker tag <имя_создаваемого_образа> <имя_репозитория>/<имя_создаваемого_образа>

Например:

sudo docker tag test-image:1.0 sbc.space/dev/dev/evta/test-image:1.0

sudo docker push <имя_репозитория>/<имя_создаваемого_образа>

Например:

sudo docker push sbc.space/dev/dev/evta/test-image:1.0

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

д. Перейти обратно в основную рабочую директорию:

cd ~/<имя_основной_рабочей_директории>

Разархивировать cfg-дистрибутив EVTA.

Имя архива EVTA-cfg-*-distrib.zip, находится в выбранной ранее директории установки. В основной рабочей директории выполнить команду:

unzip -o EVTA-cfg-*-distrib.zip

Появится директория conf. Создать папку helm в основной рабочей директории. Скопировать содержимое директории conf/helm/application/reactivestreamadapter в директорию helm. Результат можно проверить командой «ls -la». В выводе команды визуально можно найти директорию helm.

Полную ссылку на сформированный образ прописать в файле helm/templates/deployment.yaml как значение параметра image.

Для этого запустить Midnight Commander командой «mc». Перейти в директорию helm/templates. Открыть файл deployment.yaml для редактирования. В файле по пути параметров spec – template – spec – containers – image полностью удалить строку:

"{{ .Values.registry }}/{{ .Values.registry_path}}/evta/reactivestreamadapter@sha256:<hash>"

Вместо нее указать полную ссылку на созданный в п.13 (раздел «Подготовка узла, с которого будет осуществляться установка») образ. Указывать без кавычек.

Например: «./sw.sbc.space/dev/evta/test-image:1.0».

Сохранить файл. Вернуться в основную рабочую директорию с помощью навигации Midnight Commander.

Подготовка настроек#

Создать secret для доступа к репозиторию, содержащему выложенный ранее образ EVTA.

Для этого выполнить команду:

kubectl create secret docker-registry <имя_секрета> --docker-server=<путь_до_репозитория> --docker-username=<имя_пользователя_docker> --docker-password=<пароль_пользователя_docker> --namespace=<имя_созданного_ранее_пространства>

Например:

kubectl create secret docker-registry evta-tuz --docker-server=https://sbc.space/dev --docker-username=em --docker-password=qwe123 --namespace=evta

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

Поместить необходимые для развертывания EVTA сертификаты в директорию ./helm/ssl.

Если директория отсутствует, ее надо создать командой:

mkdir ./helm/ssl

Файлы, находящиеся в данной директории, будут находится в secret Kubernetes и будут смонтированы в директорию /reactivestreamadapter/ssl контейнера EVTA.

Так как предполагается развертывание EVTA в режиме REST-Kafka, необходимо поместить в директорию helm/ssl сертификаты для запуска REST-endpoint и для подключения к топику Kafka.

Сертификаты подкладываются в виде JKS-хранилищ. Для обоих подключений может быть использовано одно и то же JKS-хранилище.

Для успешного последующего подключения к топику Kafka на этих топиках должны быть предварительно выданы права на запись для DN сертификата, лежащего в хранилище.

Подробнее о выпуске сертификатов в разделе «Создание JKS хранилища и сертификатов».

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

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

Для этого в директории <основная_рабочая_директория>/package/bh расположена утилита для шифрования encryptor-cli-2.4.0-fatjar.jar.

Формат использования утилиты из директории, в которой она располагается:

java -jar encryptor-cli-2.4.0-fatjar.jar -k KEY -p PASSWORD

«-p» – пароль, которым будет расшифровываться JKS-хранилище;
«-k» – значение, которым будет шифроваться значение параметра «-p».

Можно шифровать с указанием пути до файла, содержащего секрет, тогда значение параметра -k будет «file:<путь до файла с секретом>».

Значение секрета для шифрования нужно будет положить в файл secret.pass из пункта 26.

Общий формат команды (выполнение из любой директории, т.к. пути указаны полностью):

java -jar /home/<домашняя_директория_пользователя>/<основная_рабочая_директория>/package/bh/encryptor-cli-2.4.0-fatjar.jar -k file:/home/<домашняя_директория_пользователя>/<основная_рабочая_директория>/helm/ssl/secret.pass -p <строка_которую_нужно_зашифровать>

/home/<домашняя_директория_пользователя>/<основная_рабочая_директория>/package/bh/encryptor-cli-2.4.0-fatjar.jar – путь до jar-файла утилиты от корня файловой системы. Также в нашем случае может быть задан в виде «~/<основная_рабочая_директория>/package/bh/encryptor-cli-2.4.0-fatjar.jar».
file:/home/<домашняя_директория_пользователя>/<основная_рабочая_директория>/distr/helm/ssl/secret.pass – путь до файла secret.pass от корня файловой системы. В данном параметре нельзя использовать «~», т.к. java не распознает пути таким образом.
<строка_которую_нужно_зашифровать> – пароль, который нужно получить в шифрованном виде.

Пример:

java -jar /home/evta/test/package/bh/encryptor-cli-2.4.0-fatjar.jar -k file:/home/evta/test/helm/ssl/secret.pass -p test

Вывод команды будет иметь вид, похожий на:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Encrypted password: <password>

Последняя строка вывода содержит результат шифрования слова «test», указанного в команде.

В директории helm/ssl необходимо создать файл со списком DN сертификатов, разрешенных для подключения к REST-endpoint EVTA.

Файл представляет собой список DN, каждый из которых указывается с новой строки и без пробелов.

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

Для создания файла в консоли нужно сначала перейти в директорию helm/ssl. Если находились в основной рабочей директории, то для перехода выполнить команду:

cd helm/ssl

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

touch <имя_файла>

Например:

touch rest.certs

Далее запустить Midnight Commander командой «mc».

В директории helm/ssl необходимо создать файл со списком DN сертификатов разрешенных брокеров Kafka.

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

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

Если с прошлого пункта вы никуда не перемещались, то вы уже находитесь в директории helm/ssl. Если нет – необходимо в нее перейти. Проверить текущую директорию можно командой «pwd».

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

touch <имя_файла>

Например:

touch kafka.certs

Далее открыть Midnight Commander командой «mc» и сохранить файл.

В директории helm/ssl необходимо создать файл, которым будут шифроваться пароли.

Имя файла должно быть «secret.pass».

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

touch secret.pass

Далее открыть Midnight Commander командой «mc». Занести в файл произвольную последовательность латинских букв (любого регистра) и цифр. Рекомендуется не менее 20 символов. Сохранить файл.

Для выхода в основную рабочую директорию воспользоваться навигацией Midnight Commander или закрыть его, нажав F10 и выполнить в консоли команду «cd …/…».

В директории helm/conf создать конфигурационный файл urlConfig.json.

Проверить, что находитесь в основной рабочей директории, выполнив команду «pwd». Если нет – перейти в нее.

Далее создать директорию ./helm/conf, выполнив команду:

mkdir ./helm/conf

Перейти в созданную директорию командой:

cd helm/conf

Создать файл с именем «urlConfig.json»:

touch urlConfig.json

Далее запустить Midnight Commander командой «mc».

Установить курсор на созданный файл и нажать «control + F4». Файл откроется на редактирование.

Занести в файл взаимосвязь url-endpoint, по которым клиент будет обращаться к EVTA, и настроек транспорта.

Формат файла:

{
"fpss": {
    "<имя_домена>": {
        "<имя_федерации>": {
            "<имя_сегмента>": {
                "<имя_системы_источника>": {
                    "<имя_события>": { "1": { "type": "kafka", "topic": "<имя_топика>", "properties": "<файл_настроек_подключения>" } },
                    "<другое_имя_события>": { "1": { "type": "kafka", "topic": "<другое_имя_топика>", "properties": "<другой_файл_настроек_подключения>" } }
                    }
                }
            }
        }
    }
}

Пример содержимого файла:

{
"fpss": {
    "Domain": {
        "Federation": {
            "SegmentA": {
                "SystemName": {
                    "EventName": { "1": { "type": "kafka", "topic": "EventNameTopic", "properties": "producer.properties" } },
                    "OtherEventName": { "1": { "type": "kafka", "topic": "OtherEventNameTopic", "properties": "other_producer.properties" } }
                    }
                }
            }
        }
    }
}

При данной конфигурации EVTA обеспечит работу с двумя топиками: EventNameTopic и OtherEventNameTopic. Если настройки подключения одинаковые, то в параметрах properties может быть указан один и тот же файл. Подробнее в документации *Руководство пользователя в разделе «Использование приложения».

Сохранить файл.

В директории helm/conf создать файлы, содержащие настройки подключения к топикам Kafka, упомянутые в файле urlConfig.json.

Для указанного выше примера необходимо создать файлы producer.properties и other_producer.properties. Структура файлов однотипная.

Пример файла:

bootstrap.servers = "host1:9093,host2:9093"
enable.auto.commit = "false"
security.protocol = "SSL"
ssl.endpoint.identification.algorithm = ""
ssl.key.password="enc:<password>"
ssl.keystore.location=ssl/some-certstore.jks
ssl.keystore.password="enc:<password>"
ssl.truststore.location=ssl/some-certstore.jks
ssl.truststore.password="enc:<password>"
group.id="test-consumer"
auto.offset.reset="earliest"

Значения параметров:

bootstrap.servers = "host1:9093,host2:9093" - список брокеров кластера kafka
enable.auto.commit = "false" - коммит без подтверждения от получателя = false
security.protocol = "SSL" - признак использования шифрования данных
ssl.endpoint.identification.algorithm = "" - оставить пустую строку
ssl.key.password="enc:<подставляем_зашифрованный_пароль_из_п23_от_сертификата_лежащего_в_хранилище>"
ssl.keystore.location=ssl/<имя_хранилища_из_п2 раздела Подготовка настроек>.jks
ssl.keystore.password="enc:<подставляем_зашифрованный_пароль_из_п23_от_хранилища> "
ssl.truststore.location=ssl/<имя_хранилища_из_п2 раздела Подготовка настроек>.jks
ssl.truststore.password="enc:<подставляем_зашифрованный_пароль_из_п23_от_хранилища> "
group.id="test-consumer" - группа консьюмера, указать произвольную текстовую метку
auto.offset.reset="earliest" - начать вычитку топика с самого раннего сообщения

ВАЖНО! ssl.key.password, ssl.keystore.password, ssl.truststore.password – заполнять значениями, полученными с использованием утилиты из п.3 раздела «Подготовка настроек» с добавлением префикса «enc:».

ssl.keystore.location, ssl.truststore.location заполняем путями до JKS-хранилищ из п.2 раздела «Подготовка настроек», относительный путь до JKS-хранилища = «ssl/<имя_jks-хранилища>.jks»

Заполнить файл values.yaml, расположенный в директории helm.

Для этого запустить Midnight Commander командой «mc».

Перейти в директорию helm.

Установить курсор на файл values.yaml и нажать «control + F4». Файл откроется на редактирование.

В файле обязательно установить:

а. параметр pullImage – имя секрета для получения образа из репозитория (имя секрета, созданного в п.1 раздела «Подготовка настроек»).

б. блок config:

параметр egressType – должен быть равен rest;
параметры egressPublishPort и egressSubscribePort – отвечают за порты, на которых запущен REST-интерфейсы для публикации и подписки соответственно;
параметр needInfoAboutAcknowledge – отвечает за то, будет ли дожидаться адаптер успешной отправки сообщения в Kafka, прежде чем ответить клиенту, что сообщение опубликовано. Рекомендуемое значение true;
параметр brokerWhiteListPath – путь до файла со списком разрешенных DN сертификатов брокеров Kafka (из п.4 раздела «Подготовка настроек»). Путь до файла заполняется как «ssl/<имя_файла>». Например - «ssl/kafka.certs»; в. блок config – параметр ssl.

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

Формат блока:

  ssl:
    key:
      password: enc:<подставляем_зашифрованный_пароль_сертификата_лежащего_в_хранилище_из_п23>
    keystore:
      location: "ssl/<имя_хранилища_из_п2 раздела Подготовка настроек>.jks"
      password: enc:<подставляем_зашифрованный_пароль_сертификата_лежащего_в_хранилище_из_п23>
    truststore:
      location: "ssl/<имя_хранилища_из_п2 раздела Подготовка настроек>.jks"
      password: enc:<подставляем_зашифрованный_пароль_сертификата_лежащего_в_хранилище_из_п23>
    protocol: "TLSv1.2"
    white:
      list:
        path: ssl/<подставляем_имя_файла_из_п24>

Пример:

  ssl:
    key:
      password: enc:<password>
    keystore:
      location: "ssl/some-certstore.jks"
      password: enc:<password>
    truststore:
      location: "ssl/some-certstore.jks"
      password: enc:<password>
    protocol: "TLSv1.2"
    white:
      list:
        path: ssl/rest.certs

При этом необходимо сохранять корректное смещение – блок ssl должен находиться в том же смещении, что и предыдущие параметры блока config.

г. параметр config: urlConfigPath – путь до файла urlConfig.json из п.7 раздела «Подготовка настроек». В нашем случае путь должен иметь значение «conf/urlConfig.json».

Дополнительно можно установить:

д. блок resources – позволяет устанавливать лимиты на память и CPU пода (если блок оставить закомментированным, будут использоваться параметры по умолчанию, настроенные на кластере Kubernetes). По умолчанию блок закомментирован;

е. блок logging: logback – позволяет настроить логирование при необходимости (значение level – общий уровень логирования на пакеты, не указанные в loggers; массив loggers – настройка уровня логирования на конкретные пакеты);

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

Сохранить файл.

Запуск EVTA#

Установить EVTA в Kubernetes с подготовленными настройками. Для этого любым удобным способом убедиться, что вы находитесь в той же директории, что и файл values.yaml из п.9 раздела «Подготовка настроек».
Далее выполнить команду установки:

helm install <имя установки (произвольная текстовая метка)> . -n <имя пространства (namespace), созданного в разделе «Создание namespace (опционально)»>

В результате выполнения данной команды в Kubernetes в указанном namespace будет запущен pod EVTA с именем reactivestreamadapter-<имя установки>. Проверить успешность установки можно командой:

kubectl get deployment reactivestreamadapter-<имя установки>

В случае успеха вывод будет иметь вид, похожий на:

NAME                                                           READY   UP-TO-DATE   AVAILABLE   AGE
reactivestreamadapter-<имя установки>  3/3               3                      3            30m

Предусловия запуска непосредственной обработки сообщений:

Для передачи сообщений в направлении REST-kafka должен быть предварительно развернут кластер Kafka.

До кластера должен быть сетевой доступ от кластера Kubernetes.

На кластере должны быть созданы топики из п.7 раздела «Подготовка настроек» (топики, с которыми EVTA будет работать).

На данные топики должны быть выданы соответствующие права для DN сертификата из п.2 раздела «Подготовка настроек».