Руководство по установке для тестовых сред EVPT#
Предусловия подготовки окружения для развертывания EVPT#
ВАЖНО! Для выполнения установки необходимо иметь доступ к узлу, с которого будет осуществляться установка — локально или по SSH под пользователем, имеющим на узле права администратора (находящимся в группе wheel), либо под пользователем root.
Также необходимо уметь пользоваться консолью для выполнения команд.
В случае, если для выполнения какой-либо команды ниже не хватает прав Вашего пользователя — повторить команду, добавив к ней в начале sudo. Например:
sudo yum -y install unzip
Также желательно уметь пользоваться оболочками, подобными Far или Midnight Commander, для навигации и работы с файлами.
ВАЖНО! Данная инструкция реализована для узла с ОС Linux CentOS 8.0 и выше, имеющего доступ к сети Интернет. Менеджеры пакетов на других версиях Linux и способы их установки в корпоративных сетях могут отличаться.
Проверка версии Linux:
cat /etc/*-release
Первая строчка вывода покажет версию (например: «CentOS Linux release 8.1.1911 (Core)»).
ВАЖНО! Предполагается, что все упомянутые ниже произвольные текстовые метки содержат буквы только латинского алфавита. Использование алфавитов других языков не проверялось.
Предварительно должно быть создано пространство (namespace) в k8s, где требуется развернуть EVPT. При наличии доступа к кластеру его можно будет создать позже.
Также необходимо иметь репозиторий, куда можно будет выложить образ компонента EVPT для установки (например, в Nexus).
Предварительно необходимо иметь репозиторий, куда можно будет выложить образ EVPT для установки (например, Nexus).
До репозитория должен быть сетевой доступ с узла, с которого будет осуществляться установка.
В репозитории должен быть заранее создан пользователь с правами на чтение и запись, для которого известны логин и пароль.
В репозитории должен присутствовать Ваш собственный базовый образ для сборки контейнеров. Путь до него должен быть известен. Пример пути до базового образа: example.space/example-base/redhat/openjdk-11-rhel8:1.0-8.
Необходимо также иметь готовый кластер Kubernetes.
До кластера должен быть сетевой доступ с машины, с которой будет осуществляться установка.
Необходимо также иметь пользовательский доступ к управлению кластером, позволяющий:
получить метаданные кластера в виде файла kubeconfig;
создать пространство (namespace) с произвольным именем, где требуется развернуть EVPT. Namespace желательно создать заранее. Также его можно будет создать позже.
ВАЖНО! После развертывания, обращение к pod-у EVPT по REST будет доступно только изнутри namespace.
Перед установкой необходимо развернуть базу данных с настроенным TLS соединением (пример настроек подключения см. ниже в данной инструкции). При этом у разворачиваемой базы данных в схеме должны присутствовать определенные таблицы, требуемые для работы Quartz. Пример рабочей схемы можно посмотреть в документации EVPT.
Подготовка узла, с которого будет осуществляться установка#
ВАЖНО! Данная инструкция реализована для Linux CentOS 8.0 и выше, имеющего доступ к сети Интернет и предназначена для развертывания компонента EVPT в режиме работы c базой данных (В примере PostgreSQL). Менеджеры пакетов на других версиях Linux и способы их установки в корпоративных сетях могут отличаться.
Подключиться к узлу, с которого будет осуществляться установка, по SSH или локально под пользователем, имеющим на узле права администратора (находящимся в группе wheel), либо под пользователем root.
Для входа по SSH с локальной машины — запустить локальный терминал (консоль) и ввести в командной строке:
ssh <имя_пользователя>@<ip_адрес_узла>
где <имя_пользователя> — логин пользователя, под которым требуется зайти на удаленный узел. Например, «ssh example@{ IP_ADDRESS }». После ввода в консоли будет запрошен пароль — ввести пароль пользователя, под которым требуется зайти на удаленный узел (процесс ввода в консоли никак не будет отображаться) и нажать enter (для mac - return).
При подключении по SSH сразу после подключения произойдет переход в домашнюю директорию пользователя, под которым выполнено подключение.
Выбрать директорию, откуда будет осуществляться установка.
Это может быть домашняя директория пользователя, из под которого осуществляется установка.
Рекомендуем создать в домашней директории специальную поддиректорию, например — «evpt», и далее работать в ней. Далее по тексту данная директория будет упоминаться как «основная рабочая директория».
Для создания директории выполнить команду mkdir:
mkdir ~/evpt
Проверить успешность создания командой:
ls -la
В выведенном списке визуально найти созданную директорию. Перейти в нее по команде:
cd evpt
Проверить наличие Python и его версию.
Выполнить команду:
python3 --version
При наличии — будет выведено сообщение вида «Python 3.6.8».
При отсутствии — сообщение о неизвестной команде вида «-bash: python3: command not found».
Если python3 отсутствует, то необходимо проверить наличие версий ниже, выполнив команду:
python2 --version
или
python --version
Если не обнаружено никакой версии, то необходмо установить Python версии 2.7.18.
Установка производится в 2 этапа:
исправление проблемы с репозиториями пакетов в Linux CentOS 8.0 выполняется командами:
sudo sed -i 's/mirrorlist/#mirrorlist/g' /etc/yum.repos.d/CentOS-*
sudo sed -i 's|#baseurl=http://mirror.centos.org|baseurl=http://vault.centos.org|g' /etc/yum.repos.d/CentOS-*
установка Python выполняется командой:
sudo dnf module install python27
Проверить наличие пакета
unzip.
Для проверки выполнить команду:
unzip
При наличии пакета будет выведена справка об аргументах.
При отсутствии пакета будет выведено сообщение о неизвестной команде.
При отсутствии пакета выполнить команду:
sudo yum -y install unzip
Проверить наличие пакета
openjdk-17.
Для этого выполнить команду:
java -version
При наличии пакета будет выведено сообщение вида:
openjdk 17.0.8 2023-07-18 LTS
OpenJDK Runtime Environment (SBERTECH-17.0.8.0.7-1) (build 17.0.8+7-LTS)
OpenJDK 64-Bit Server VM (SBERTECH-17.0.8.0.7-1) (build 17.0.8+7-LTS, mixed mode, sharing)
При отсутствии пакета будет выведено сообщение о неизвестной команде.
При отсутствии пакета выполнить команду:
yum -y install java-11-openjdk
Проверить наличие переменной
JAVA HOME.
Для проверки выполнить команду:
set | grep JAVA_HOME
Если вывод пустой, значит переменная не установлена.
Вывод вида JAVA_HOME=<какое-то_непустое_значение> говорит о том, что переменная уже установлена (например, JAVA_HOME=/usr/lib/jvm/java-17-openjdk-17.0.8.0.7-2.sl8.2.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.
Для этого выполнить команду:
curl -O https://groovy.jfrog.io/artifactory/dist-release-local/groovy-zips/apache-groovy-binary-3.0.18.zip
В результате в текущей директории появится файл apache-groovy-binary-3.0.18.zip.
Далее его необходимо разархивировать, для этого выполнить команду:
unzip apache-groovy-binary-3.0.18.zip
В результате чего в текущей директории появится директория groovy-3.0.18.
Проверить можно командой:
./groovy-3.0.18/bin/groovy
В результате будет выведена справка по ключам утилиты.
Установить
Docker.
Проверить наличие docker командой:
docker --version
Успешный вывод имеет вид, схожий с «Docker version 24.0.5, build ced0996».
При отсутствии 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 <имя_репозитория>
где <имя_репозитория> имеет вид полного пути, например: «example.space/example_dev/ci90000050_synse_dev/evpt».
После выполнения команды будут запрошены последовательно логин и пароль для входа в подготовленный заранее репозиторий образов (подробнее описано в подразделе «Предусловия подготовки окружения»).
Получение и склейка дистрибутива#
Поместить в основную рабочую директорию полный дистрибутив продукта (архив с именем
EM-*-distrib.zip).
Для отправки на сервер дистрибутива с локального компьютера в случае подключения по SSH можно использовать локальный SCP/SFTP-клиент (например, Far).
Либо использовать команду:
scp <источник_передачи> <целевая_точка>
Формат команды:
scp [OPTION] [user@]SRC_HOST:]file1 [user@]DEST_HOST:]file2
При вводе команды с терминала локального компьютера для источника передачи не указывается имя пользователя и адрес host, указывается только полный путь до файла, который нужно передать.
Поэтапно разархивировать дистрибутив: На сервере из директории, куда был помещен дистрибутив продукта, выполнить последовательность команд:
unzip EM-*-distrib.zip
unzip EM-*-owned-distrib.zip
unzip dependency-resolver-*-distrib.zip
В результате в данной директории помимо всего прочего появится директория src.
Произвести склейку дистрибутива. Для этого выполнить команду:
./groovy-3.0.18/bin/groovy -cp ./src merge.groovy --report ./Report.json EM-*-party-distrib.zip EM-*-owned-distrib.zip
ВАЖНО! Сохранять последовательность party-, owned- архивов в команде выше.
ВАЖНО! Чтобы команда отработала «as is», директория groovy-3.0.18 и дистрибутив EM (п.1) должны располагаться в одной общей родительской директории (если все рекомендации выше соблюдены). Если это не так, то в начале команды нужно вместо «./groovy-3.0.18/bin/groovy» задать корректный полный путь до groovy от корня файловой системы.
Далее необходимо распаковать получившийся единый архив, выполнив команду:
unzip -o EM-*-owned-distrib.zip
Создание и заливка docker-образа EVPT#
Перейти в директорию, где лежит Dockerfile.
Для этого выполнить последовательность действий:
Выполнить команду:
unzip -o EVPT-bin-*-distrib.zip
В результате в текущей директории появится директория package. Для проверки можно выполнить команду:
ls -la
Далее перейти во вложенную директорию, выполнив команду:
cd package/docker/eventprocessflowakka
В файле Dockerfile задать свой базовый образ.
ВАЖНО! Требуется базовый образ на Linux CentOS 8.0, java 11.
Открыть Midnight Commander командой mc.
Далее в открывшемся окне установить курсор на файл Dockerfile. Нажать F4, после чего файл Dockerfile откроется на редактирование.
В файле в первой строке в параметре ARG BASE_IMAGE задать расположение базового образа для сборки образа EVPC (по умолчанию указано значение-пример). Наличие в репозитории базового образа является необходимым предусловием установки.
Строка с параметром должна выглядеть примерно так:
ARG BASE_IMAGE=example.space/example-base/redhat/openjdk-11-rhel8:1.0-8
Далее нажать F2 (сохранение файла), нажать esc (выход из файла).
выполнить последовательность команд (ВАЖНО! Точка в командах — это тоже часть команды. Она означает текущую директорию).
Команда:
cp -r ../../bh .
docker build -t <имя_создаваемого_образа>:<версия_создаваемого_образа> .
Пример:
docker build -t test-image:1.0 .
Команда:
docker tag <имя_создаваемого_образа> <имя_репозитория>/<имя_создаваемого_образа>
Пример:
docker tag test-image:1.0 example.space/example_dev/dev/evpt/test-image:1.0
Команда:
docker push <имя_репозитория>/<имя_создаваемого_образа:версия>
Пример:
docker push example.space/example_dev/dev/evpt/test-image:1.0
В результате, если все выполнилось без ошибок, то в репозитории должен появиться созданный образ. Опционально это можно проверить визуально, если есть доступ в графический интерфейс репозитория.
Полную ссылку на сформированный образ прописать в файле **cfg/package/conf/helm/application/scheduler/templates/deployment.yaml ** как значение параметра
image.
Для этого запустить Midnight Commander командой mc.
Перейти в директорию cfg/package/conf/helm/application/scheduler/templates.
Установить курсор на файл deployment.yaml и нажать control + F4. Файл откроется на редактирование.
В файле по пути параметров spec → template → spec → containers → image полностью удалить строку
{{ .Values.registry }}/{{ .Values.registry_path}}/evpt/eventprocess@test: <example_hash>. Вместо нее указать полную ссылку на созданный образ (п.1). Указывать без кавычек.
Пример:
example.space/example_dev/dev/evpt/test-image: 1.0
Сохранить файл, нажав control + F2. Нажать esc для выхода из файла. Вернуться в основную рабочую директорию с помощью навигации Midnight Commander.
Установка и настройка утилиты kubectl#
Проверить наличие утилиты
kubectl, выполнив команду:
kubectl version
Если данная утилита не установлена, то установить (подробные инструкции по установке на сайте: https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/#install-using-native-package-management).
Для установки выполнить:
команду:
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
Подсказка: копируем все и вставляем в командную строку, нажимаем «enter».
команду:
sudo yum install -y kubectl
Проверяем местоположение и учетные данные, о которых известно
kubectl, с помощью команды:
kubectl config view
Настройки отсутствуют если получен вывод:
apiVersion: v1
clusters: null
contexts: null
current-context: ""
kind: Config
preferences: {}
users: null
Подключение к кластеру
Kubernetes.
При отсутствии настроек есть 2 способа подключения:
При помощи файла config. Настройки устанавливаются в файле ~/.kube/config. Если директория
/.kubeотсутствует, ее нужно предварительно создать командой:
mkdir -p ~/.kube
Скачать со страницы вашего кластера файл kubeconfig через графический интерфейс. Это и есть нужный файл config, его остается только переименовать и подложить в директорию $HOME/.kube.
У нас:
получить доступ к консоли управления;
выбрать слева Enterprise, далее справа плитка Managed Kubernetes;
перейти на вкладку «Кластеры»;
найти нужный кластер и нажать «b__choice» справа от его названия;
выбрать «Скачать Kubeconfig» - файл будет загружен на локальную машину;
загрузить файл командой
scpна целевой узел.
После этого для проверки выполнить команду:
kubectl config view
Иначе можно добавлять параметры для подключения при помощи команд (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]
ВАЖНО! Для выполнения пункта 2 требуется повышенная квалификация по управлению кластером Kubernetes. Пункт приведен в данной инструкции информационно и не является исчерпывающим. Требуется подробное изучение оригинальных инструкций по ссылке. В случае невозможности получить самостоятельно файл config рекомендуем обратиться к администратору кластера Kubernetes.
Убедиться в корректности данных и в том, что они применились, можно, выполнив команду:
kubectl get nodes
При успешном подключении к кластеру Kubernetes будет выведен список кластера(ов) с их статусом.
Создание namespace (опционально)#
При отсутствии в кластере Kubernetes целевого namespace для развертывания адаптера, необходимо его создать командой:
kubectl create namespace <имя пространства>
Пример:
kubectl create namespace evpt
Установка Helm#
Проверить наличие инструмента Helm командой:
helm version
В случае отсутствия — установить, выполнив команду:
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
Полная оригинальная инструкция по установке Helm: https://helm.sh/docs/intro/install/.
Разархивировать cfg-дистрибутив EVPT (имя архива -
EVPT-cfg-[version]-distrib.zip, находится в выбранной ранее директории установки.../EM-*-distrib/EVP-*-owned-distrib) командой:
unzip EVPT-cfg-*-distrib.zip
Создать директорию helm. Переместить в нее содержимое package/conf/helm/application/scheduler.
Результат можно проверить командой ls -la helm. В выводе команды визуально можно увидеть содержимое директории helm.
Подготовка настроек#
Создать secret для доступа к репозиторию, содержащему выложенный ранее образ EVPT.
Для этого выполнить команду:
kubectl create secret docker-registry <имя_секрета> --docker-server=<путь_до_репозитория> --docker-username=<имя_пользователя_docker> --docker-password=<пароль_пользователя_docker> --namespace=<имя_созданного_ранее_пространства>
Пример:
kubectl create secret docker-registry evpt_tuz --docker-server=https://example.space/example_dev --docker-username=evpt --docker-password=<password> --namespace=evpt
В результате в целевом кластере Kubernetes появится созданный секрет.
Подробно создание секретов описано в оригинальной инструкции: https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/.
Поместить необходимые для развертывания EVPT сертификаты в директорию
./helm/ssl.
Если директория отсутствует, ее необходимо создать командой:
mkdir ./helm/ssl
Файлы, находящиеся в данной директории, будут находится в secret Kubernetes и будут смонтированы в директорию /scheduler/ssl контейнера EVPT.
В случае развертывания EVPT с БД будут необходимы сертификаты:
для настройки TLS соединения EVPT, необходимого при обращении к его REST-api;
для подключения к БД;
для настройки задач.
Сертификаты должны быть подписаны одним и тем же удостоверяющим центром. Сертификаты подкладываются в виде jks-хранилищ. Для всех подключений может быть использовано одно и то же jks-хранилище.
Все пароли в конфигурационных файлах принято указывать в зашифрованном виде.
Пароли от сертификатов и jks-хранилищ из п.2 необходимо зашифровать и сохранить в зашифрованном виде для последующего формирования конфигурационных файлов.
Для этого в директории <основная_рабочая_директория>/package/bh расположена утилита для шифрования encryptor-cli-2.4.0-fatjar.jar.
Формат использования утилиты из директории, в которой она располагается:
java -jar encryptor-cli-2.4.0-fatjar.jar -k KEY -p PASSWORD
где:
параметр
-p– шифруемое значение;параметр
-k– секрет, которым шифруется пароль (можно шифровать с указанием пути до файла, содержащего секрет, тогда значение параметра-kбудетfile:<путь до файла с секретом>).
Секрет должен совпадать с содержимым файла из пункта 4.
Общий формат команды (выполнение из любой директории, т.к. пути указаны полностью):
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/evpt/test/package/bh/encryptor-cli-2.4.0-fatjar.jar -k file:/home/evpt/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необходимо создать файл, которым будут шифроваться пароли.
Имя файла должно быть «secret.pass».
Для создания файла необходимо выполнить команду:
touch secret.pass
Далее открыть Midnight Commander командой mc.
Установить курсор на созданный файл и нажать «control + F4». Файл откроется на редактирование.
Занести в файл произвольную последовательность латинских букв (любого регистра) и цифр. Рекомендуется не менее 20 символов.
Сохранить файл, нажав «control + F2».
Нажать esc для выхода из файла.
Для выхода в основную рабочую директорию воспользоваться навигацией Midnight Commander или закрыть его нажав F10 и выполнить в консоли команду cd ../...
Настройка файла values.yaml#
Файл values.yaml располагается в директории helm. Для заполнения файла запустить Midnight Commander командой mc. Перейти в директорию helm. Установить курсор на файл values.yaml и нажать «control + F4». Файл откроется на редактирование.
В файле обязательно установить:
параметр
pullImage- имя секрета для получения образа из репозитория (имя секрета, созданного в п.1 подраздела Подготовка настроек);для настройки TLS соединения EVPT, необходимого при обращении к его REST-endpoint’ам, требуется добавить к уже имеющимся параметрам (в файле values.yml) в блоке
schedulerнеобходимые параметры.
Блок scheduler:#
ssl.protocol — версия TLS протокола;
ssl.truststore.location — путь к расположению truststore’а сертификата;
ssl.truststore.password — пароль от truststore“(в формате «enc: encoded_password»);
ssl.keystore.location — путь к расположению keystore’а сертификата;
ssl.keystore.password — пароль от keystore’а (в формате «enc:encoded_password»);
ssl.key.password — пароль для доступа к ключу от keystore’а (в формате «enc:encoded_password»);
secret — путь к файлу, содержащему секрет для шифрования паролей;
ssl.endpoint.identification.algorithm — алгоритм идентификации endpoint подключения для проверки имени host сервера с использованием сертификата сервера;
ssl.allowed.dn — DN используемого сертификата.
Пример:
ssl.protocol: "TLSv1.2"
ssl.truststore.location: ssl/kafka-dev-cluster-1.jks # Сертификат для scheduler
ssl.truststore.password: "enc:encoded_password"
ssl.keystore.location: ssl/kafka-dev-cluster-1.jks
ssl.keystore.password: "enc:encoded_password"
ssl.key.password: "enc:encoded_password"
secret: ssl/secret.pass
ssl.endpoint.identification.algorithm: "dn"
ssl.allowed.dn: "CN=KafkaDevCluster1, OU=FPSS, O=SBT, ST=Moscow, C=RU"
Блок quartz:#
Для запуска с БД, необходимо заполнить блок quartz.
Описание параметров:
org.quartz.threadPool.class - Класс ThreadPool, который будет использоваться. (Стандартно «org.quartz.simpl.SimpleThreadPool»);
org.quartz.threadPool.threadCount - Количество потоков;
org.quartz.jobStore.class - селектор JobStore;
org.quartz.jobStore.dataSource - значением этого свойства должно быть имя одного из источников данных, определенных в файле свойств конфигурации;
org.quartz.jobStore.tablePrefix - строка, равная префиксу, присвоенному таблицам Quartz, которые были созданы в вашей базе данных. У вас может быть несколько наборов таблиц Quartz в одной базе данных, если они используют разные префиксы таблиц;
org.quartz.jobStore.driverDelegateClass - конкретный «диалект» различных систем баз данных;
org.quartz.dataSource.NAME.driver (Вместо NAME указывается значение переданное в «org.quartz.jobStore.dataSource») - имя класса java драйвера JDBC для используемой базы данных;
org.quartz.dataSource.NAME.URL (Вместо NAME указывается значение переданное в «org.quartz.jobStore.dataSource») - URL-адрес подключения (хост, порт и т.д.) для подключения к используемой базе данных. При подключениии с использованием ssl возможна передача аргументов аналогичным образом, как и в блоке
batch. Для этого в url необходимо передать параметр sslfactory=ru.sbt.ss.batch.utils.DatabaseSslFactory;org.quartz.dataSource.NAME.user (Вместо NAME указывается значение переданное в «org.quartz.jobStore.dataSource») - имя пользователя для подключения к используемой базе данных;
org.quartz.dataSource.NAME.password (Вместо NAME указывается значение переданное в «org.quartz.jobStore.dataSource») - пароль для подключения к используемой базе данных;
secret - секрет для расшифровки паролей.
Особенности заполнения:
в значении параметра
org.quartz.dataSource.NAME.URL- указать настройки TLS соединения для подключения EVPT к БД в формате «jdbc:postgresql://db_hostname:db_port/schema_name?secret=file:path_to_secret&ssl.keystore.location=path_to_cert_keystore&ssl.keystore.password=enc:encoded_password&ssl.truststore.location=ssl/kafka-dev-cluster-1.jks&ssl.truststore.password=enc:encoded_password&ssl.key.password=enc:encoded_password&sslfactory=ru.sbt.ss.batch.utils.DatabaseSslFactory&sslmode=verify-ca»;параметры
ssl.key.password,ssl.keystore.password,ssl.truststore.password- заполняем значениями, полученными в п.3 подраздела Подготовка настроек с добавлением префикса «enc:». При этом, если в зашифрованном пароле присутствуют символы «=», «/»,«+», то для их последующего экранирования в url их необходимо представить в кодировке UTF-8 — это значения «%3d», «%2f» и «%2b» соответственно;параметры
ssl.keystore.location,ssl.truststore.location- заполняем путями до сертификатов из п.2 подраздела Подготовка настроек (относительный путь сертификата -ssl/<имя сертификата>).
Пример:
quartz:
properties:
org.quartz.threadPool.class: "org.quartz.simpl.SimpleThreadPool"
org.quartz.threadPool.threadCount: "1"
org.quartz.jobStore.class: "org.quartz.impl.jdbcjobstore.JobStoreTX"
org.quartz.jobStore.dataSource: "quartzDataSource"
org.quartz.jobStore.tablePrefix: "QRTZ_"
org.quartz.jobStore.driverDelegateClass: "org.quartz.impl.jdbcjobstore.PostgreSQLDelegate"
org.quartz.dataSource.quartzDataSource.driver: "org.postgresql.Driver"
org.quartz.dataSource.quartzDataSource.URL: "jdbc:postgresql://{ IP_ADDRESS }/scheduler?secret=file:ssl/secret.pass&ssl.keystore.location=ssl/kafka-dev-cluster-1.jks&ssl.keystore.password=enc:<encoded_password>.truststore.location=ssl/kafka-dev-cluster-1.jks&ssl.truststore.password=enc:<encoded_password>.key.password=enc:<encoded_password>factory=ru.sbt.ss.batch.utils.DatabaseSslFactory&sslmode=verify-ca"
org.quartz.dataSource.quartzDataSource.user: "scheduleruser"
org.quartz.dataSource.quartzDataSource.password: "<password>"
Блок task:#
Заполняем блок task. Значение блока ssl - настройка TLS соединения для REST подключения при выполнении задачи.
Параметры:
ssl.key.password,ssl.keystore.password,ssl.truststore.password- заполняем значениями, полученными в п.3 с добавлением префикса «enc:»;ssl.keystore.location,ssl.truststore.location- заполняем путями до сертификата из п.2 (относительный путь сертификата -ssl/<имя сертификата>);ssl.protocol- версия протокола.
Пример:
task:
ssl.protocol: "TLSv1.2"
ssl.keystore.location: ssl/kafka-dev-cluster-1.jks
ssl.keystore.password: enc:<encoded_password>
ssl.truststore.location: ssl/kafka-dev-cluster-1.jks
ssl.truststore.password: enc:<encoded_password>
ssl.key.password: <password>
secret: ssl/secret.pass
Дополнительные блоки#
Дополнительно можно установить:
блок
resources- позволяет устанавливать лимиты на память и CPU пода (если блок оставить закомментированным, будут использоваться параметры по умолчанию, настроенные на кластере Kubernetes). По умолчанию блок закомментирован.блок
logging → logback- позволяет настроить логирование при необходимости (значение level – общий уровень логирования на пакеты, не указанные в loggers; массив loggers – настройка уровня логирования на конкретные пакеты).
Сохранить файл, нажав control + F2. Нажать esc для выхода из файла.
Запуск EVPT#
Установить EVPT в Kubernetes с подготовленными настройками.
Для этого любым удобным способом убедиться, что вы находитесь в той же директории, что и файл values.yaml.
Далее в консоли выполнить команду установки:
helm install <имя установки (произвольная текстовая метка)> . -n <имя пространства (namespace)>
В результате выполнения данной команды в Kubernetes в указанном namespace будет запущен pod EVPT с именем XXX-<имя установки>.
Проверить успешность установки можно командой:
kubectl get deployment XXX-<имя установки>
В случае успеха вывод будет иметь вид, похожий на:
NAME READY UP-TO-DATE AVAILABLE AGE
XXX-<имя установки> 3/3 3 3 30m
Если появилась ошибка подобного рода «Error: the pod didn’t tolerate, n Insufficient cpu, n Insufficient memory» - это означает, что разворачиваемому продукту не хватает выделимся по умолчанию ресурсов, а именно: cpu и memory.
Тогда их необходимо явно задать, увеличив выделенные ранее значения. Для этого нужно в файле values.yaml явно указать требуемые значения в блоке resources и повторить снова предыдущий пункт.
Пример:
resources:
limits:
cpu: 0.5
memory: 512M
requests:
cpu: 0.3
memory: 256M