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

Получение скриптов развертывания Ansible#

Скачайте и разархивируйте дистрибутив, содержащий ansible роли (директория Ansible) и Jenkins скрипты развертывания (директория Pipeline): ./EVTD-scripts-[version]-distrib.zip.

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

При установке с помощью Jenkins: поместить директории Ansible и Pipeline из развернутого архива в корень Git-репозитория.

Общие предусловия установки EVTD#

Общие настройки#

1. Для увеличения отказоусточивости кластера брокеров Platform V Corax / Apache Kafka рекомендуется изменить сетевые настройки ядра Linux на следующие значения:

net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3
net.ipv4.tcp_keepalive_time = 60
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_keepalive_intvl = 1
net.ipv4.tcp_retries2 = 3

Где:

• tcp_syn_retries — количество попыток передачи SYN-пакета при установлении нового соединения;

• tcp_synack_retries — количество попыток передачи SYN, ACK-пакета в ответ на SYN-запрос. Максимальное число попыток установить пассивное TCP-соединение, инициированное другим сервером;

• tcp_keepalive_time — частота проверки соединения, если оно давно не используется (в секундах);

• tcp_keepalive_probes — количество попыток проверки жизнеспособности прежде, чем будет принято решении о разрыве соединения;

• tcp_keepalive_intvl — интервал проверки жизнеспособность сокета. Значение учитывается при подсчете времени, которое должно пройти перед тем, как соединение будет разорвано (в секундах);

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

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

echo "3"  > /proc/sys/net/ipv4/tcp_syn_retries
echo "3"  > /proc/sys/net/ipv4/tcp_synack_retries
echo "60" > /proc/sys/net/ipv4/tcp_keepalive_time
echo "5"  > /proc/sys/net/ipv4/tcp_keepalive_probes
echo "1"  > /proc/sys/net/ipv4/tcp_keepalive_intvl
echo "3"  > /proc/sys/net/ipv4/tcp_retries2

2. Для уменьшения использования системного диска рекомендуется отключить SWAP. Для этого необходимо под пользователем root на сервере установки кластера брокеров Platform V Corax / Apache Kafka выполнить команду:

swapoff -a

3. Установить пакеты: java, unzip, ansible (необходимо установить на сервер, с которого будет производиться установка).

4. Создать пользователя установки (например, kafka).

5. Увеличить лимит дескрипторов для пользователя kafka. Для этого в файле /etc/security/limits.conf для пользователя kafka прописать:

kafka   soft  nproc    512000
kafka   hard  nproc    512000
kafka   soft  nofile   512000
kafka   hard  nofile   512000

6. Создать системные или пользовательские сервисы обслуживания. Создавать необходимо согласно инструкции в подразделе «Создание системных и пользовательских сервисов обслуживания для EVTD».

7. Дополнительно проверить:

• доступность порта 9093 на серверах брокеров для подключения клиентов;

• доступность порта 2181 на серверах Zookeeper для подключения брокеров;

• доступность портов 2888 и 3888 на серверах Zookeeper для создания кластера;

• разрешение имен серверов по IP в рамках всех серверов (с использованием DNS или записи в /etc/hosts).

все указанные порты при необходимости можно изменить через параметры ansible.

При использовании Jenkins#

Необходимо проверить:

• наличие доступа в Jenkins. Должны быть выданы права на запуск Jenkins job для пользователя, запускающего установку компонента;

• сетевую доступность узлов для вызова со стороны Jenkins;

• наличие доступа в Git, в котором создан проект для ролей ansible и скриптов развертывания, а также выданы права на чтение для учетных данных, указанных в настройках Jenkins job;

• наличие доступа в Nexus, где размещен дистрибутив компонента, а также выданы права на чтение для учетных данных, указанных в настройках Jenkins job.

Настройка серверов Apache Kafka#

1. Создать разделы на диске:

/opt/Apache/ — 10 ГБ, владелец kafka:kafka;

/KAFKADATA/ — от 150 ГБ, владелец kafka:kafka (объем зависит от нагрузки, рассчитывается предварительно).

2. Создать JKS хранилище с сертификатом, подписанным УЦ, доверенным для всех клиентов.

Настройка серверов Zookeeper#

1. Создать разделы на диске:

/opt/Apache/ — 10 ГБ, владелец kafka:kafka;

/zookeeper/ — 50 ГБ, владелец kafka:kafka.

2. Создать JKS хранилище с сертификатом, подписанным УЦ, доверенным для брокеров Kafka.

Создание системных и пользовательских сервисов обслуживания для EVTD#

Для автоматического перезапуска брокеров Platform V Corax / Apache Kafka и Zookeeper в случае перезагрузки сервера и корректной работы скриптов Ansible необходимо перед установкой создать системные или пользовательские сервисы обслуживания.

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

Необходимо выдать права пользователю (например, kafka) на запуск, остановку и редактирование сервиса. Для этого под пользователем root добавить строки в файл /etc/sudoers:

Для Kafka:

kafka ALL= NOPASSWD: /bin/systemctl start kafka
kafka ALL= NOPASSWD: /bin/systemctl stop kafka
kafka ALL= NOPASSWD: /bin/systemctl status kafka
kafka ALL= NOPASSWD: /bin/systemctl restart kafka
kafka ALL= NOPASSWD: /bin/systemctl enable kafka
kafka ALL= NOPASSWD: /bin/systemctl disable kafka
kafka ALL= NOPASSWD: /bin/systemctl daemon-reload
kafka ALL= NOPASSWD: /bin/sudoedit /etc/systemd/system/kafka.service

Для Zookeeper:

kafka ALL= NOPASSWD: /bin/systemctl start zookeeper
kafka ALL= NOPASSWD: /bin/systemctl stop zookeeper
kafka ALL= NOPASSWD: /bin/systemctl status zookeeper
kafka ALL= NOPASSWD: /bin/systemctl restart zookeeper
kafka ALL= NOPASSWD: /bin/systemctl enable zookeeper
kafka ALL= NOPASSWD: /bin/systemctl disable zookeeper
kafka ALL= NOPASSWD: /bin/systemctl daemon-reload
kafka ALL= NOPASSWD: /bin/sudoedit /etc/systemd/system/zookeeper.service

Для создания пользовательских сервисов обслуживания:

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

Для этого под пользователем root:

1. Добавить строки с логином пользователей в файл /etc/systemd/logind.conf:

KillExcludeUsers=kafka

2. Дать возможность пользовательским сервисам работать как долговременные, выполнив команды:

systemctl restart systemd-logind
loginctl enable-linger kafka

Создание системных и пользовательских сервисов обслуживания с помощью Jenkins Job#

1. Необходимо заполнить настройки inventory из подраздела «Настройка inventory для EVTD».

2. Выбрать соответствующий playbook в Jenkins Job в параметре playbook:

   • zk_kafka_system_service.yml — создание системного сервиса обслуживания EVTD;

   • zk_kafka_user_service.yml — создание пользовательского сервиса обслуживания EVTD.

Создание системного сервиса обслуживания Zookeeper с помощью ansible#

Под пользователем kafka выполните действия:

1. Создайте файл сервиса zookeeper.service:

sudo /bin/sudoedit /etc/systemd/system/zookeeper.service

2. Заполните созданный файл:

[Unit]
Description=Zookeeper service
After=local-fs.target network.service

[Service]
WorkingDirectory={{ zookeeper.installdir }}
Type=simple
User=kafka
ExecStart={{ zookeeper.installdir }}/bin/zookeeper-server-start.sh {{ zookeeper.installdir }}/config/zookeeper.properties
ExecStop={{ zookeeper.installdir }}/bin/zookeeper-server-stop.sh
LimitNOFILE=512000
LimitNPROC=512000
Restart=on-failure
RestartSec=10

[Install]
WantedBy=default.target

, где zookeeper.installdir — абсолютный путь до директории установки Zookeeper.

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

sudo systemctl daemon-reload

Создание пользовательского сервиса обслуживания Zookeeper с помощью ansible#

Под пользователем kafka выполните следующие действия:

1. Создайте файл сервиса ~/.config/systemd/user/zookeeper.service со следующим содержимым:

[Unit]
Description=Zookeeper service

[Service]
WorkingDirectory={{ zookeeper.installdir }}
Type=simple
ExecStart={{ zookeeper.installdir }}/bin/zookeeper-server-start.sh {{ zookeeper.installdir }}/config/zookeeper.properties
ExecStop={{ zookeeper.installdir }}/bin/zookeeper-server-stop.sh
LimitNOFILE=512000
LimitNPROC=512000
Restart=on-failure
RestartSec=30

[Install]
WantedBy=default.target

, где zookeeper.installdir — абсолютный путь до директории установки Zookeeper.

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

sudo systemctl --user daemon-reload

Создание системного сервиса обслуживания Kafka с помощью ansible#

Под пользователем kafka выполните следующие действия:

1. Создайте файл сервиса:

sudo /bin/sudoedit /etc/systemd/system/kafka.service

2. Заполните созданный файл:

[Unit]
Description=Apache Kafka service
After=local-fs.target network.service

[Service]
WorkingDirectory={{ kafka.installdir }}
Type=simple
User=kafka
ExecStartPre=/bin/sleep 10
ExecStart={{ kafka.installdir }}/bin/kafka-server-start.sh {{ kafka.installdir }}/config/server.properties
ExecStop={{ kafka.installdir }}/bin/kafka-server-stop.sh
LimitNOFILE=512000
LimitNPROC=512000
Restart=on-failure
RestartSec=30

[Install]
WantedBy=default.target

, где kafka.installdir — абсолютный путь до директории установки Kafka.

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

sudo systemctl daemon-reload

Создание пользовательского сервиса обслуживания Kafka с помощью ansible#

Под пользователем kafka выполните следующие действия:

1. Создайте файл сервиса ~/.config/systemd/user/kafka.service со следующим содержимым:

[Unit]
Description=Apache Kafka service

[Service]
WorkingDirectory={{ kafka.installdir }}
Type=simple
ExecStartPre=/bin/sleep 10
ExecStart={{ kafka.installdir }}/bin/kafka-server-start.sh {{ kafka.installdir }}/config/server.properties
ExecStop={{ kafka.installdir }}/bin/kafka-server-stop.sh
LimitNOFILE=512000
LimitNPROC=512000
Restart=on-failure
RestartSec=30

[Install]
WantedBy=default.target

, где kafka.installdir — абсолютный путь до директории установки Kafka.

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

sudo systemctl --user daemon-reload

Процесс удаления системных и пользовательских сервисов обслуживания описан в документе: «Руководство администратора» в разделе «Удаление системных и пользовательских сервисов обслуживания на ВМ для EVTD».

Настройка inventory для EVTD#

1. Создайте в директории inventories свою директорию (с вашим названием) с параметрами. Пример настроек находится в директории !EXAMPLE! (внутри директории inventories).

2. В созданной директории должны содержаться следующие элементы:

group_vars/all - директория, в которой находятся файл vars.yml и файл vault.yml;

ssl - директория с сертификатами;

ssl_admin - директория, в которой лежат сертификаты администраторов;

inventory - файл, где прописываются группы серверов, на которых будут выполняться playbook.

Пример структуры репозитория:

├── ...
├── files
├── inventories
│   ├── !EXAMPLE!
│   │   ├── group_vars
│   │   │   └── all
│   │   │       ├── vars.yml
│   │   │       └── vault.yml
│   │   ├── inventory
│   │   ├── ssl
│   │   │   └── kafka-server.jks
│   │   └── ssl_admin
│   │       └── admin.jks
│   ├── [новая директория]
│   │   ├── group_vars
│   │   │   └── all
│   │   │       ├── vars.yml
│   │   │       └── vault.yml
│   │   ├── inventory
│   │   ├── ssl
│   │   │   └── kafka-server.jks
│   │   └── ssl_admin
│   │       └── admin.jks
├── roles
│   │   ...
├── zk_and_kafka.yml
├── ***.yml
├──...

3. В файл inventory добавьте список серверов, на которые будет производиться установка:

Пример:

localhost ansible_connection=local ansible_become=0

[zookeeper]
host1.domen
host2.domen
host3.domen

[kafka]
host10.domen
host11.domen
host12.domen

4. Перейдите к заполнению файлов в директории group_vars/all.

Файл vars.yml заполните по аналогии с имеющимися примерами файла vars.yml в директории !EXAMPLE!. Ознакомиться с примером заполненного файла vars.yml можно в подразделе «Пример заполненного файла vars.yml для EVTD».

При этом необходимо задать пароли в зашифрованном виде (описано далее в п.5), а также учесть все настройки безопасности (подробно описано в подразделе «Настройки безопасности для установки EVTD»).

5. Продолжите заполнение файлов в директории group_vars/all. Файл vault.yml содержит пароли в зашифрованном виде.

При заполнении файла vars.yml необходимо зашифровать указываемые в нем пароли с помощью утилиты ansible-vault и занести их в файл vault.yml. Подробно данная процедура описана в разделе Использование утилиты «ansible-vault» для шифрования паролей.

6. Поместите используемые сертификаты в директорию ssl.

Используемые сертификаты необходимо зашифровать с помощью утилиты «ansible-vault». Подробно данная процедура описана в разделе Использование утилиты «ansible-vault» для шифрования паролей.

7. Подложить используемые сертификаты администраторов в директорию ssl_admin.

Используемые сертификаты необходимо зашифровать с помощью утилиты «ansible-vault».

Пример заполненного файла vars.yml для EVTD#

Получение значений параметров из HashiCorp Vault#

При интеграции с HashiCorp Vault возможно получение значений параметров ansible из него. Для этого при указании параметров в файле vars.yml вместо значений параметров используется синтаксис:

ansible_password: "{{ lookup('hashi_vault', 'url=*** auth_method=approle role_id=*** secret_id=*** secret=*** validate_certs=0') }}"

, где:

• url – URL для подключения к HashiCorp Vault. Например: https://my.vault.address;

• auth_method – метод аутентификации. Например: approle;

• role_id – используемый role.id;

• secret_id – используемый secret.id;

• secret – путь:ключ для получаемого секрета. Например: kv1/company/secret_keys:jks_password;

• validate_certs – проверка доверия сертификата HashiCorp Vault.

Параметры подключения и аутентификации запрашиваются у администраторов HashiCorp Vault.

В результате значение переменной ansible_password будет получено из HashiCorp Vault при запуске установки.

Базовый файл#

Базовый файл — это файл Ansible/inventories/!EXAMPLE!/group_vars/all/vars.yml, содержащий минимальное количество настроек для корректной установки приложения.

Пример заполненного базового файла vars.yml:

ansible_user: kafka # пользователь, под которым производится установка
ansible_password: "{{ kafka_password }}" # ssh пароль от пользователя

kafka: # блок настроек для Kafka
  keyStorePath: path/to/kafka-server.jks # путь от inventories/_стенд_/ до файла с хранилищем сертификатов, при установке загружается на сервер
  keyStorePassword: "{{ jks_password }}" # пароль от хранилища сертификатов
  keyPassword: "{{ jks_password }}" # пароль от ключа в хранилище
  trustStorePath:  path/to/kafka-server.jks # путь от inventories/_стенд_/ до файла с хранилищем доверенных сертификатов, при установке загружается на сервер
  trustStorePassword: "{{ jks_password }}" # пароль от хранилища доверенных сертификатов
  audit: # настройки аудита
    rest: false # отключена отправка событий аудита в rest интерфейс

Расширенный файл настроек#

Расширенный файл — файл Ansible/roles/kafka/defaults/main.yml, представляет из себя пример всех изменяемых настроек со значениями «по умолчанию». Любую из указанных настроек можно перенести в свой vars.yml для переопределения ее значения.

tmp_dir:  path/to/installer # путь до временной директории на конечных серверах
wait_for_start: 120 # время (в секундах) на корректный старт приложения (падает с ошибкой при превышении)
check_correct_start: true # проверка корректности запуска приложения по наличию строки в логе
ansible_no_log: true # отключить вывод паролей в лог/output
password_encoder_cli_path: # путь до утилиты для шифрования паролей (helper/encode_passwords.yml)
#inventory_for_acl: IFT # ограничение списка ACL по инвентори (для установки в инвентори, не совпадающем с inventory в релизе)

ansible_user: kafka # пользователь, под которым производится установка
ansible_password: "{{ kafka_password }}" # ssh пароль от пользователя

# авторизация под другим пользователем и его паролем
#ansible_become: 1
#ansible_become_method: su
#ansible_become_user: new_user
#ansible_become_pass: "{{ new_user_password }}"

# авторизация под другим пользователем с использованием sudo (при добавлении в sudoers: kafka ALL=(new_user) NOPASSWD:ALL)
#ansible_become: 1
#ansible_become_user: new_user

kafka:
  distr: kafka_2.13-2.7.2.tgz # путь до приложения относительно /files (tar.gz или tgz архив)
  installdir:  path/to/Apache/kafka # абсолютный путь на конечном сервере до приложения
  logdir:  path/to/Apache/kafka/logs # абсолютный путь на конечном сервере до логов приложения
  datadir:  path/to/KAFKADATA # абсолютный путь на конечном сервере до данных приложения (через запятую, если путей несколько)
  #backup_installdir_to: path/to/installer # если параметр задан, то создаваемый папки installdir попадает в эту директорию. Не должно совпадать с installdir
  service_name: kafka # имя сервиса
  cleanLog: true # очистить путь до логов при установке
  cleanData: false # очистить путь до данных при установке
  xms: 256m # начальный heap size
  xmx: 7G # максимальный heap size
  use_KRaft: true # использование механизма KRaft для кластеризации (при false используется zookeeper)
  #cluster_uuid: # используемый UUID для KRaft кластера (по умолчанию генерируется автоматически через ./bin/kafka-storage.sh random-uuid)
  port: 9093 # используемый порт
  controller_port: 9094 # порт контроллера при использовании KRaft
  jmxport: 7010 # порт для подключения по JMX
  jmx_security_enable: true # включение авторизации для JMX
  jmx_access_roles: # переменные для генерации доступов. Если переменная не определена, то текущие доступы не меняются
    - user: <user_name>
      access: readonly
      password: <user_password>
  #id: 3 # уникальный broker.id для брокера в кластере (по умолчанию: порядковый номер хоста в inventory)
  #superUser: CN=00000000.KafkaCluster1,OU=00CA,O=SBRF,L=Moscow,C=RU # DN суперпользователя, иначе берется DN сертификата
  autoCreateTopics: false # автосоздание топиков
  trustStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с trustStore (или абсолютный на сервере при needUploadJks: false)
  trustStorePassword: PLACEHOLDER # пароль от trustStore
  keyStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с keyStore (или абсолютный на сервере при needUploadJks: false)
  keyStorePassword: PLACEHOLDER # пароль от keyStore
  keyPassword: PLACEHOLDER # пароль от ключа в хранилище
  cipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 # список шифров для TLS соединения
  #admin_rights: # список DN администраторов доступа
  #  - CN=custom_admin,ST=Moscow,C=RU
  #iniChange: # изменить или добавить значение в файле формата ini/properties
  #  - fileName: path/to/server.properties # полный путь до файла или относительно installdir
  #    changeList:
  #      - key: log.segment.bytes
  #        value: 1073741824
  #        section: Defaults # необязательное поле с именем [секции] для изменения
  #        state: absent # необязательное поле, при пустом value удаляет строчку с указанным key, при пустом section - удаляет секцию
  ## Допустимые параметры для additionalJavaOpts:
  #  #  - "-XX:MetaspaceSize"
  #  #  - "-XX:MaxMetaspaceSize"
  #  #  - "-XX:MinMetaspaceFreeRatio"
  #  #  - "-XX:MaxMetaspaceFreeRatio"
  #  #  - "-XX:MinHeapFreeRatio"
  #  #  - "-XX:MaxHeapFreeRatio"
  #  #  - "-XX:+AlwaysPreTouch"
  #  #  - "-noverify"
  #  #  - "-XX:+AlwaysActAsServerClassMachine"
  #  #  - "-XX:MaxRAMPercentage"
  #  additionalJavaOpts: "-XX:+AlwaysPreTouch" # дополнительные опции для KAFKA_HEAP_OPTS в kafka-server-start.sh

zookeeper:
  distr: kafka_2.13-2.7.2.tgz # путь до приложения относительно /files (tar.gz или tgz архив)
  installdir: path/to/Apache/kafka # абсолютный путь на конечном сервере до приложения
  logdir: path/to/Apache/kafka/logs # абсолютный путь на конечном сервере до логов приложения
  datadir: path/to/zookeeper/ # абсолютный путь на конечном сервере до данных приложения
  #backup_installdir_to: path/to/installer # если параметр задан, то создается архив installdir в эту директорию. Не должно совпадать с installdir
  service_name: zookeeper # имя сервиса
  cleanLog: true # очистить путь до логов при установке
  cleanData: false # очистить путь до данных при установке
  xms: 128m # начальный heap size
  xmx: 1G # максимальный heap size
  port: 2181 # используемый порт
  jmxport: 7000 # порт для подключения по JMX
  jmx_security_enable: true # включение авторизации для JMX
  jmx_access_roles: # переменные для генерации доступов. Если переменная не определена, то текущие доступы не меняются
    - user: <user_name>
      access: readonly
      password: <user_password>
  #id: 3 # уникальный zookeeper id для quorum (по умолчанию: порядковый номер хоста в inventory)
  #superUser: CN=00000000.KafkaCluster1,OU=00CA,O=SBRF,L=Moscow,C=RU # DN суперпользователя, иначе берется DN сертификата
  quorumPorts: 2888:3888 # порты для quorum (первый - для лидера, второй - на всех хостах, включая лидера)
  trustStorePath: path/to/zookeeper.jks # путь от inventories/_стенд_/ до файла с trustStore
  trustStorePassword: PLACEHOLDER # пароль от trustStore
  keyStorePath: path/to/zookeeper.jks # путь от inventories/_стенд_/ до файла с keyStore
  keyStorePassword: PLACEHOLDER # пароль от keyStore
  cipherSuites: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256,TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 # список шифров для TLS соединения
  #iniChange: # изменить или добавить значение в файле формата ini/properties
  #  - fileName: path/to/zookeeper.properties # полный путь до файла или относительно installdir
  #    changeList:
  #      - key: tickTime
  #        value: 5000
  #        section: Defaults # необязательное поле с именем [секции] для изменения
  #        state: absent # необязательное поле, при пустом value удаляет строчку с указанным key, при пустом section - удаляет секцию
  #additionalJavaOpts: "-XX:+AlwaysPreTouch" # дополнительные опции для KAFKA_HEAP_OPTS в zookeeper-server-start.sh

Настройки безопасности для установки EVTD#

Настройки безопасности задаются в файле vars.yml перед запуском установки и находятся в разделах:

1. Настройки SSL-сертификатов и их хранилища для Platform V Corax / Apache Kafka, с которыми будет запускаться брокер:

kafka:
  trustStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с trustStore (или абсолютный на сервере при needUploadJks: false)
  trustStorePassword: PLACEHOLDER # пароль от trustStore
  keyStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с keyStore (или абсолютный на сервере при needUploadJks: false)
  keyStorePassword: PLACEHOLDER # пароль от keyStore
  keyPassword: PLACEHOLDER # пароль от ключа в хранилище

2. Настройки подключения системы мониторинга к Platform V Corax / Apache Kafka:

kafka:
  jmx_access_roles: # переменные для генерации доступов. Если переменная не определена, то текущие доступы не меняются
    - user: <user_name>
      access: readonly
      password: <user_password>

3. Настройка аудита для Platform V Corax / Apache Kafka:

kafka:
  audit: # настройки аудита
    log: true # запись событий аудита в лог
    rest: true # запись событий аудита в rest endpoint
    trustStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с trustStore
    trustStorePassword: PLACEHOLDER # пароль от trustStore
    keyStorePath: path/to/kafka.jks # путь от inventories/_стенд_/ до файла с keyStore
    keyStorePassword: PLACEHOLDER # пароль от keyStore
    keyPassword: PLACEHOLDER # пароль от ключа в хранилище
    url: https://localhost:8084 # префикс url для отправки событий аудита
    metamodel: path/to/metamodel # суффикс для метамодели
    event: path/to/event # суффикс для событий
    system_id: <Event_ID> # идентификатор событий аудита

4. Настройки SSL-сертификата и хранилища для Zookeeper:

zookeeper:
  trustStorePath: path/to/zookeeper.jks # путь от inventories/_стенд_/ до файла с trustStore
  trustStorePassword: PLACEHOLDER # пароль от trustStore
  keyStorePath: path/to/zookeeper.jks # путь от inventories/_стенд_/ до файла с keyStore
  keyStorePassword: PLACEHOLDER # пароль от keyStore

5. Настройки SSL-подключения системы мониторинга к Zookeeper:

zookeeper:
  jmx_access_roles: # переменные для генерации доступов. Если переменная не определена, то текущие доступы не меняются
    - user: myuser
      access: readonly
      password: mypassword

Пример заполненного файла vars.yml приведен в подразделе «Пример заполненного файла vars.yml для EVTD».

В процессе установки все настройки безопасности, заданные первично в файле vars.yml, попадают в конфигурационные файлы ssl_adm.properties (данные о сертификатах), server.properties (настройки общих параметров безопасности, настройки аудита), zookeeper.properties (настройки для Zookeeper), config/encrypt.pass (ключ для шифрования паролей), где могут быть изменены вручную. Для того, чтобы новые настройки безопасности применились, необходимо перезапустить брокеры Platform V Corax / Apache Kafka.

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

Создание Jenkins Job для автоматической установки EVTD#

Данный подраздел подготовки окружения относится только к разделу Установка EVTD, подраздел «Автоматическая установка EVTD с использованием Jenkins».

Настройка credentials для Ansible-Vault#

1. Необходимо создать файл с паролем, с помощью которого при автоматической установке будут расшифровываться пароли, зашифрованные через ansible-vault в параметрах vars выбранного inventory.

Пароль требуется задать согласно следующим рекомендациям:

• Длина пароля должна быть не менее 12 символов;

• Пароль должен содержать в себе символы как минимум трех категорий из четырех: буквы нижнего регистра (от a до z), буквы верхнего регистра (от A до Z), цифры (от 0 до 9) и спецсимволы (например: $, #, %);

• Рекомендуется избегать простых последовательностей. Например, «12345», «qwerty», «password1» и т.д.;

• Пароль не должен повторять предыдущие 4 пароля для данной УЗ;

• Пароль должен изменяться не реже, чем 1 раз в 80 дней с момента последнего изменения;

• В случае разглашения или компрометации пароль должен быть незамедлительно изменен;

• Рекомендаций по заданию и смене паролей следует придерживаться в случае, если они не противоречат корпоративной парольной этике. чы Приведенные рекомендации не должны противоречить требованиям внутренних документов Заказчика, отраслевых и национальных стандартов, требований уполномоченных регуляторов и законодательства РФ.

2. Далее зайти в Jenkins в свой проект, перейти во вкладку Credentials и выбрать нужный проект:

- prerequirements.yml — playbook для автоматической настройки пререквизитов: устанавливает необходимые пакеты, модифицирует лимиты, настройки сети, включает linger для использования пользовательских сервисов и создает директории установки/логов.

3. Откроется страница, где необходимо выбрать «Global credentials (unrestricted)»:

4. Перейти во вкладку Add Credentials:

5. После перехода будут доступны поля для заполнения:

• «Kind» — в выпадающем списке выбрать параметр Secret file;

• «File» — загрузить созданный файл с паролем;

• «ID» — указать наименование, которое придумываете самостоятельно (данный ID необходимо будет указать в job SYN_custom_kafka в параметре vault_cred);

• «Description» — необязательное поле, в котором можно добавить описание.

6. Нажать кнопку Create — Credentials для Vault создаются после нажатия кнопки «Create»:

Создание Jenkins Job SYN_custom_kafka#

1. Содержимое дистрибутива ./EVTD-scripts-[version]-distrib.zip поместить в Git-репозиторий.

2. Выбрать New Item для создания нового Jenkins Job:

2.1. Добавить название создаваемого Jenkins Job. Нельзя использовать в названии русские буквы, спецсимволы.

2.2. Выбрать Pipeline и нажать кнопку «ОК»:

2.3. Заполнить поля на появившейся странице в блоке Pipeline:

• Изменить значение параметра «Definition» на Pipeline script from SCM;

• Изменить значение параметра «SCM» на Git;

• Заполнить параметр «Repository URL», в параметре указать путь до вашего Git-репозитория;

• Заполнить параметр «Credentials», в параметре указать ваши сredentials с правами на чтение;

• В параметре «Branches to build» выбрать ветку, в которой находятся скрипты;

• В параметре «Script Path» указать путь до groovy-скрипта Pipeline/SYN_custom.groovy;

• Убедиться, что НЕ стоит галочка Lightweight checkout.

Пример заполнения параметров:

3. Сохранить получившийся Jenkins Pipeline.

4. На появившейся странице в меню боковой панели выбрать «Собрать сейчас» — запустится первоначальная сборка:

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

6. Выбрать в меню боковой панели «Собрать с параметрами»:

7. Заполнить следующие параметры на появившейся странице:

• jenkins_slave — имя агента Jenkins для сборки;

• ansible_version — указание Jenkins Tool с необходимой версией Ansible. Конкретное значение необходимо получить у администратора Jenkins.

8. Нажать кнопку «Собрать».

9. Обновить страницу и после окончания работы Jenkins Job снова нажать «Собрать с параметрами».

10. Появится страница со всем списком настраиваемых параметров, отвечающих за установку компонента EVTD:

• job_config_renew — обновление Jenkins Job. При установке приложения должен быть выключен (false). Для обновления текущих параметров и сохранения значений по умолчанию должен быть включен (true);

• inventory — имя inventory для установки;

• nexusUrlKafka — полный путь до дистрибутива KFKA или дистрибутива Apache Kafka;

• playbook— необходимый сценарий установки, где:

  • admin_rights.yml — предоставление прав для сертификатов администратора при использовании Jenkins job kafka_config_deploy; (параметр kafka.admin_rights в файле vars.yml);

  • kafka.yml — установка брокеров Platform V Corax / Apache Kafka;

  • kafka_acls.yml — создание и удаление ACL для брокеров Platform V Corax / Apache Kafka;

  • kafka_get_info.yml — получение информации о версии кластера Platform V Corax / Apache Kafka, к которому предполагается подключение;

  • kafka_limits.yml — создание и удаление лимитов на чтение/запись для клиентов брокеров Platform V Corax / Apache Kafka;

  • kafka_topics.yml — создание топиков для брокеров Platform V Corax / Apache Kafka;

  • kafka_topics_acls.yml — создание и удаление топиков/ACL для брокеров Platform V Corax / Apache Kafka;

  • zk_and_kafka.yml — установка компонентов Zookeeper и брокеров Platform V Corax / Apache Kafka;

  • zk_kafka_system_service.yml — создание системных сервисов обслуживания для Zookeeper и брокеров Platform V Corax / Apache Kafkaa;

  • zk_kafka_user_service.yml — создание пользовательских сервисов обслуживания для Zookeeper и брокеров Platform V Corax / Apache Kafka;

  • zk_kafka_system_service_delete.yml — удаление системного сервиса обслуживания EVTD;

  • zk_kafka_user_service_delete.yml — удаление пользовательского сервиса обслуживания EVTD;

  • zookeeper.yml — установка компонента Zookeeper.

• tags — список тегов. Первая установка приложения выполняется без выбора тегов. Это позволит полностью выполниться playbook. В случае, если необходима частичная установка, то можно выбрать определенные теги:

  • backup — создание backup;

  • backup_remove — удаление backup;

  • backup_restore — восстановление из backup;

  • distribute — распаковка переданного дистрибутива EVTD;

  • ini_change — используется для изменения настроек в конфигурации брокеров Platform V Corax / Apache Kafka и Zookeper (параметры kafka.iniChange и zookeper.iniChange соответственно в файле vars.yml);

  • install — запуск блока установки;

  • start — запуск сервиса;

  • status — статус установки сервиса; также используется для вывода результата обращения к endpoint дискаверинга (информация в логах);

  • restart — перезапуск сервиса;

  • stop — остановка сервиса;

  • unistall — удаление сервиса;

  • update_audit — обновление настроек аудита.

• select_all_hosts — выполнение playbook на всех серверах из выбранного inventory;

• only_on_host — выполнение playbook на выбранных серверах;

• emailto — список адресов электронной почты для отправки результатов (письмо исполнителю упадет автоматически);

• custom_vault_password — ручной ввод пароля для Ansible Vault;

• jenkins_slave — выбор Jenkins Slave;

• jdk_tool — наименование Jenkins Tool с необходимой версией JDK. Конкретное значение необходимо получить у администратора Jenkins;

• ansible_branch — ветка скриптов развертывания;

• ansible_version — указание Jenkins Tool с необходимой версией Ansible. Конкретное значение необходимо получить у администратора Jenkins;

• nexus_user_cred — Jenkins Username with Password credential ID для выкачивания дистрибутива. При задании secman_url — полный путь в HashiCorp Vault до имени пользователя и пароля. Например: {Jenkins *Vault App Role credential* ID для получения секретов из HashiCorp Vault}|path/to/nexus:{user},{password};

• vault_cred — Jenkins secret file credential ID со строкой для расшифровки паролей (ansible vault). При задании secman_url — полный путь в HashiCorp Vault до пароля. Например: {Jenkins *Vault App Role credential* ID_1}|/path/to/vault:{password_1}, {Jenkins *Vault App Role credential* ID_2}|/path/to/vault:{password_2} В качестве пароля можно использовать не строку, а файл в base64 формате с ключом секрета, заканчивающимся на Base64. Например myVaultBase64;

• server_ssh_cred — Jenkins ssh key Credential ID с ssh ключом для подключения к конечным серверам. Чтобы получить ssh_username, ssh_key, ssh_key_passsphrase для подключения к серверам из HashiCorp Vault, необходимо заполнить параметр secman_url в формате: JenkinsCredID|SecManPath:SecManKeys|SecManParams, где:

  • JenkinsСredID — Jenkins Vault App Role Credential ID, содержащий реквизиты для подключения к HashiCorp Vault;

  • SecManPath — путь к секретам в HashiCorp Vault;

  • SecManKeys — имена полей для JKS администратора в HashiCorp Vault и пароля от него через запятую.

    • Окончание имени поля для JKS администратора должно быть Base64;

    • JKS администратора в HashiCorp Vault должен храниться в KV хранилище в Base64 формате;

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

  • SecManParams — параметры подключения к HashiCorp Vault (через точку с запятой). Если данные параметры по умолчанию, то пропускаются вместе с «|» (в качестве ключа можно использовать не строку, а файл в base64 формате и секрет в HashiCorp Vault с именем, оканчивающимся на «Base64», например: myPrivateKeyBase64). Примеры:

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key,ssh_key_passphrase

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key,ssh_key_passphrase|engineVersion:2.

• secman_url — URL для подключения к HashiCorp Vault;

• ssl_verify — проверка, являются ли сертификаты HashiCorp Vault/Nexus доверенными;

• second_hand_approve — подтверждение запуска другим администратором (контроль «второй рукой»; по умолчанию включен, true). При активации параметра одному администратору будет недоступна возможность запуска Jenkins Job без подтверждения со стороны другого администратора. При выключении параметра в логах появится информация об отключении данной проверки;

• inventories_repo — репозиторий с inventory. Данный пункт применим, если inventory были созданы в другом репозитории, отличным от того, где лежат скрипты;

• inventories_branch — ветка репозитория, где находятся inventory. Данный пункт применим, если inventory были созданы в другом репозитории, отличным от того, где лежат скрипты;

• inventories_path — путь до inventories от корня репозитория (значение Ansible/inventories).

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

Для продолжения установки вернитесь к разделу Установка EVTD, подраздел «Автоматическая установка EVTD с использованием Jenkins».

Jenkins Job для создания конфигурационного дистрибутива для EVTD#

Данный подраздел подготовки окружения относится только к разделу Установка EVTD, подраздел «Автоматическая установка EVTD с использованием Jenkins».

Создание Jenkins job kafka_config_create#

1. Содержимое дистрибутива ./EVTD-scripts-[version]-distrib.zip поместить в свой Git-репозиторий.

2. Выбрать New Item для создания нового Jenkins Job:

2.1. Добавить название создаваемого Jenkins Job. Нельзя использовать в названии русские буквы, спецсимволы.

2.2. Выбрать Pipeline и нажать кнопку «ОК»:

2.3. Заполнить поля на появившейся странице в блоке Pipeline:

• Изменить значение параметра «Definition» на Pipeline script from SCM;

• Изменить значение параметра «SCM» на Git;

• Заполнить параметр «Repository URL», в параметре указать путь до вашего Git-репозитория, содержащего скрипты;

• Заполнить параметр «Credentials», в параметре указать ваши сredentials с правами на чтение;

• В параметре «Branches to build» выбрать ветку, в которой находятся скрипты;

• В параметре «Script Path» указать путь до groovy-скрипта Pipeline/kafka_config_create.groovy;

• Убедиться, что НЕ стоит галочка Lightweight checkout.

Пример заполнения параметров:

3. Сохранить получившийся Jenkins Pipeline.

4. На появившейся странице в меню боковой панели выбрать «Собрать сейчас» — запустится первоначальная сборка:

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

6. Выбрать в меню боковой панели «Собрать с параметрами»:

7. Заполнить следующие параметры на появившейся странице:

• jenkins_slave — имя агента Jenkins для сборки;

• ansible_version — указание Jenkins Tool с необходимой версией Ansible. Конкретное значение необходимо получить у администратора Jenkins.

8. Нажать кнопку «Собрать».

9. Обновить страницу и после окончания работы job снова нажать «Собрать с параметрами».

10. Появится страница нужного Jenkins job для создания конфигурационных дистрибутивов со всем списком настраиваемых параметров.

Настраиваемые параметры Jenkins job kafka_config_create#

• majorVersion — мажорная версия создаваемого конфигурационного дистрибутива. Пример полный версии дистрибутива — ${majorVersion}.001.00-00;

• nexusUrl — ссылка на пространство в Nexus, куда будет опубликован созданный конфигурационный дистрибутив после выполнения Jenkins job;

• nexusReleaseUrl — ссылка на релизное пространство в Nexus для определения актуальной версии дистрибутива. Можно оставить пустым, если уже определена версия и номер сборки из пространства, в которое идет публикация

• nexusCred — Jenkins Username with Password credential ID для выкачивания дистрибутива. При задании параметра secman_url — полный путь в HashiCorp Vault до имени пользователя и пароля. Например: {Jenkins *Vault App Role credential* ID для получения секретов из HashiCorp Vault}|path/to/nexus:{user},{password};

• secman_url — URL для подключения к HashiCorp Vault;

• ssl_verify — проверка, являются ли сертификаты HashiCorp Vault/Nexus доверенными. Значение по умолчанию true;

• rebuildVersion — версия конфигурационного дистрибутива для пересборки, например D-10.123.00 (пусто, если выпускается новый релиз);

• jenkinsSlaveNode — выбор Jenkins Slave для сборки;

• emailTo — список адресов электронной почты для отправки результатов работы job (письмо исполнителю Jenkins job упадет автоматически, здесь можно указать дополнительные адреса);

• kafkaConfig — необходимая конфигурация топиков и ACL.

Пример конфигурации EVTD для установки (указывается в параметре kafkaConfig)

kafka_topics:
  list:
    - name: test1 # с дефолтными параметрами
    - name: test2 # с указанием настроек
      replicationFactor: 3
      partitions: 5
      configs: # изменение конфигурации на уровне топика
        - cleanup.policy=compact
        - max.message.bytes=10485760

kafka_acls:
  - principal: CN=fqdn.foohost.summer,C=RU
    producer: true # операции Write и Describe на топиках и Create на кластер
    topics: singleTopic
  - principal: CN=fqdn.foohost.west,C=RU
    consumer: true # операции Read и Describe на топиках и Read на группу
    topics: monitoringOutput,orphanOutput
    groups: filters # имена групп для подключения (обязательно для консьюмера, можно указать '*')

Со всеми изменяемыми настройками компонента можно ознакомиться в подразделе «Пример заполненного файла vars.yml для EVTD».

Jenkins Job для установки конфигурационного дистрибутива для EVTD#

Данный подраздел подготовки окружения относится только к разделу Установка EVTD, подраздел «Автоматическая установка EVTD с использованием Jenkins».

Ниже описан процесс создания и настройки Jenkins job для установки конфигурационных дистрибутивов, созданных согласно подраздела «Jenkins Job для создания конфигурационного дистрибутива для EVTD».

Создание Jenkins job kafka_config_deploy#

1. Содержимое дистрибутива ./EVTD-scripts-[version]-distrib.zip поместить в Git-репозиторий.

2. Выбрать New Item для создания нового Jenkins Job:

2.1. Добавить название создаваемого Jenkins Job. Нельзя использовать в названии русские буквы, спецсимволы.

2.2. Выбрать Pipeline и нажать кнопку «ОК»:

2.3. Заполнить поля на появившейся странице в блоке Pipeline:

• Изменить значение параметра «Definition» на Pipeline script from SCM;

• Изменить значение параметра «SCM» на Git;

• Заполнить параметр «Repository URL», в параметре указать путь до вашего Git-репозитория, содержащего скрипты развертывания;

• Заполнить параметр «Credentials», в параметре указать ваши сredentials с правами на чтение;

• В параметре «Branches to build» выбрать ветку, в которой находятся скрипты;

• В параметре «Script Path» указать путь до groovy-скрипта Pipeline/kafka_utils.groovy;

• Убедиться, что НЕ стоит галочка Lightweight checkout.

Пример заполнения параметров:

3. Сохранить получившийся Jenkins Pipeline.

4. На появившейся странице в меню боковой панели выбрать «Собрать сейчас» — запустится первоначальная сборка:

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

6. Выбрать в меню боковой панели «Собрать с параметрами»:

7. Заполнить следующие параметры на появившейся странице:

• jenkins_slave — имя агента Jenkins для сборки;

• ansible_version — указание Jenkins Tool с необходимой версией Ansible. Конкретное значение необходимо получить у администратора Jenkins.

8. Нажать кнопку «Собрать».

9. Обновить страницу и после окончания работы job снова нажать «Собрать с параметрами».

10. Появится страница нужного Jenkins job для установки конфигурационных дистрибутивов со всем списком настраиваемых параметров.

Настраиваемые параметры Jenkins job kafka_config_deploy#

• job_config_renew — отвечает за обновление Jenkins Job. При установке приложения должен быть выключен (false). Для обновления текущих параметров и сохранения значений по умолчанию должен быть включен (true);

• inventory — имя inventory;

• nexusUrl — полный путь до конфигурационного дистрибутива в пространстве Nexus (можно указать несколько через запятую);

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

  • check_consumer_groups — проверка списка ConsumerGroup;

  • erase_acls — удаление ACLs;

  • print_acls — просмотр списка ACLs на кластере ;

  • print_topics — просмотр списка топиков на кластере;

  • print_topics_with_configs — просмотр конфигурации топиков на кластере.

• admin_jks_file — сертификат администратора;

• admin_jks_cred — Jenkins secret file Credential ID хранящий сертификат администратора в HashiCorp Vault. Чтобы получить сертификат администратора из HashiCorp Vault, необходимо заполнить параметр secman_url в формате: JenkinsCredID|SecManPath:SecManKey|SecManParams, где:

  • JenkinsСredID — Jenkins Vault App Role Credential ID c реквизитами для подключения к HashiCorp Vault;

  • SecManPath — путь к секретам в HashiCorp Vault;

  • SecManKeys — имена полей для JKS администратора в HashiCorp Vault и пароля от него через запятую.

    • Окончание имени поля для JKS администратора должно быть Base64;

    • JKS администратора в HashiCorp Vault должен храниться в KV хранилище в Base64 формате;

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

  • SecManParams — параметры для подключения к HashiCorp Vault (через точку с запятой). Если данные параметры по умолчанию, то пропускаются вместе с «|». Примеры:

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/kafka:admin_jks;

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/kafka:admin_jks|engineVersion:2.

• emailto — список адресов электронной почты для отправки результатов работы jenkins job (письмо исполнителю Jenkins job упадет автоматически);

• jenkins_slave — выбор Slave Jenkins;

• jdk_tool — наименование Jenkins Tool с необходимой версией JDK. Конкретное значение необходимо получить у администратора Jenkins;

• ansible_branch — ветка скриптов развертывания;

• ansible_version — указание Jenkins Tool с необходимой версией Ansible. Конкретное значение необходимо получить у администратора Jenkins;

• nexus_user_cred — Jenkins Username with Password credential ID для выкачивания дистрибутива. При задании параметра secman_url — полный путь в HashiCorp Vault до имени пользователя и пароля. Например: {Jenkins *Vault App Role* credential ID для получения секретов из HashiCorp Vault}|path/to/nexus:{user},{password};

• vault_cred — Jenkins secret file credential ID со строкой для расшифровки паролей (ansible vault) (можно указывать несколько через запятую). При задании параметра secman_url — полный путь в HashiCorp Vault до пароля. Например: {Jenkins *Vault App Role* credential ID_1}|/path/to/vault:{password_1}, {Jenkins *Vault App Role* credential ID_2}|/path/to/vault:{password_2}. В качестве пароля можно использовать не строку, а файл в base64 формате с ключом секрета, заканчивающимся на Base64, например myVaultBase64;

• server_ssh_cred — Jenkins ssh key Credential ID с ssh ключом для подключения к конечным серверам. Чтобы получить ssh_username, ssh_key, ssh_key_passsphrase для подключения к серверам из HashiCorp Vault, необходимо заполнить параметр secman_url в формате: JenkinsCredID|SecManPath:SecManKeys|SecManParams, где:

  • JenkinsСredID — Jenkins Vault App Role Credential ID, содержащий реквизиты для подключения к HashiCorp Vault;

  • SecManPath — путь к секретам в HashiCorp Vault;

  • SecManKeys — имена полей для JKS администратора в HashiCorp Vault и пароля от него через запятую.

    • Окончание имени поля для JKS администратора должно быть Base64;

    • JKS администратора в HashiCorp Vault должен храниться в KV хранилище в Base64 формате;

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

  • SecManParams — параметры подключения к HashiCorp Vault (через точку с запятой). Если данные параметры по умолчанию, то пропускаются вместе с «|» (в качестве ключа можно использовать не строку, а файл в base64 формате и секрет в HashiCorp Vault с именем, оканчивающимся на «Base64», например: myPrivateKeyBase64). Примеры:

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key,ssh_key_passphrase

    • SecManAppRoleCred|/CI01994970_CI02618129_ES/A/DEV/APP/JEN/KV/vault:ssh_username,ssh_key,ssh_key_passphrase|engineVersion:2.

• secman_url — URL для подключения к HashiCorp Vault;

• ssl_verify — проверка, являются ли сертификаты HashiCorp Vault/Nexus доверенными;

• second_hand_approve — подтверждение запуска другим администратором (контроль «второй рукой»; по умолчанию включен, true). При активации параметра одному администратору будет недоступна возможность запуска Jenkins Job без подтверждения со стороны другого администратора. При выключении параметра в логах появится информация об отключении данной проверки;

• inventories_repo — репозиторий с inventory. Данный пункт позволяет указать сторонний репозиторий для inventory, не совпадающий с репозиторием скриптов развертывания;

• inventories_branch — ветка стороннего репозитория, где находятся inventory. Данный пункт применим, если указан сторонний репозиторий;

• inventories_path — путь до каталога, содержащего каталоги с inventory от корня стороннего репозитория; Данный пункт применим, если указан сторонний репозиторий.