Сценарии администрирования EVTD#

Предусловия#

Параметры установки компонента EVTD описаны в документе «Руководство по установке» в разделе «Установка EVTD». При необходимости параметры могут быть изменены.

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

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

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

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

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

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

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

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

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

  1. Наличие сертификатов TLS для администратора доступа. Процесс создания сертификатов описан в разделе Создание JKS хранилища и сертификатов. Перед началом действий поместить сертификаты в домашнюю директорию на сервере, где расположены брокеры Platform V Corax / Apache Kafka.

  2. На сервере, где расположены брокеры Platform V Corax / Apache Kafka, в домашней директории создать файл ssl_adm.properties. Наполнить следующими значениями:

security.protocol = SSL
ssl.keystore.location = <полный путь до хранилища ключа.jks>
ssl.truststore.location = <полный путь до хранилища ключа.jks>
ssl.keystore.password = пароль хранилища ключа
ssl.truststore.password = пароль хранилища сертификата ЦС
ssl.key.password = пароль закрытого ключа
ssl.endpoint.identification.algorithm =

Параметр ssl.endpoint.identification.algorithm должен остаться пустым.

  1. Необходимо удостовериться, что все задания Jenkins, необходимые для администрирования продукта, были созданы на этапе установки. Подробнее этот процесс описан в документе «Руководство по установке» в разделе «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

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

Правила эксплуатации#

Не применимо.

Описание механизмов безопасности#

Не применимо.

Последовательность выполнения#

Сценарий 1. Создание архивных копий компонентов EVTD#

Необходимо заполнить параметры в конфигурационном файле vars.yml.

  • в разделе kafka:

    • backup_installdir_to:— директория создания архивных копий для директории установки брокеров Platform V Corax / Apache Kafka;

  • в разделе zookeeper:

    • backup_installdir_to:— директория создания архивных копий для директории установки Zookeeper.

Результатом выполнения данного сценария любым из нижеприведенных способов (с помощью ansible или Jenkins) будет(ут) архив(ы) с названием kafka_backup.tar.gz и/или zookeeper_backup.tar.gz, расположенный(е) в директории, указанной в параметрах конфигурационного файла vars.yml с правами 600 (чтение и запись разрешены пользователю, под которым работает приложение).

С помощью ansible#

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

ansible-playbook -i inventories/<ID>/inventory <playbook> --ask-vault-pass -t backup -l <host>

, где:

  • ID — имя созданного inventory;

  • playbook — используемый playbook;

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

Необходимый playbook:

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

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

  • zookeeper.yml — восстановление только Zookeeper.

С помощью Jenkins#

  1. Для создания архивной копии директории установки брокеров Platform V Corax / Apache Kafka необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook kafka.yml c тегом backup.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

  1. Для создания архивной копии Zookeeper необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook zookeeper.yml c тегом backup.

  2. Для создания архивных копий всех компонентов (и брокеров Platform V Corax / Apache Kafka и Zookeeper) необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook zk_and_kafka.yml c тегом backup.

Созданные архивные копии хранятся в директориях в единичном экземпляре для предотвращения переполнения директории хранения архивов. При попытке создания архивных копий компонентов повторно выполнение Jenkins job будет прерываться, если в указанной директории присутствует ранее созданный архив. Поэтому необходимо перед созданием нового архива предварительно удалить существующие архивные копии из данных директорий. Для этого необходимо запустить Jenkins job с выбором соответствующего playbook с тегом backup_remove.

Теги backup_remove и backup можно совмещать в одном запуске Jenkins job для экономии времени.

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов;

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts, выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 2. Восстановление из архивных копий компонентов EVTD#

Необходимо заполнить параметры в конфигурационном файле vars.yml.

  • в разделе kafka:

    • backup_installdir_to: — директория создания архивных копий для директории установки брокеров Platform V Corax / Apache Kafka;

  • в разделе zookeeper:

    • backup_installdir_to: — директория создания архивных копий для директории установки Zookeeper.

С помощью ansible#

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

ansible-playbook -i inventories/<ID>/inventory <playbook> --ask-vault-pass -t backup_restore -l <host>

, где:

  • ID — имя созданного inventory;

  • playbook — используемый playbook;

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

Необходимый playbook:

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

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

  • zookeeper.yml — восстаноления только Zookeeper.

С помощью Jenkins#

  1. Для восстановления брокеров Platform V Corax / Apache Kafka из архивной копии необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook kafka.yml c тегом backup_restore. Результатом будет являться восстановление директории установки из архива, помещенного в указанную в файле vars.yml директорию.

  2. Для восстановления Zookeeper из архивной копии необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook zookeeper.yml c тегом backup_restore. Результатом будет являться восстановление директории установки Zookeeper из архива, помещенного в указанную в файле vars.yml директорию.

  3. Для восстановления из архивных копий всех компонентов (и брокеров Platform V Corax / Apache Kafka и Zookeeper) необходимо запустить Jenkins job SYN_custom_kafka с выбором playbook zk_and_kafka.yml c тегом backup_restore. Результатом будет являться восстановление данных из архива, помещенного в указанную в файле vars.yml директорию.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов:

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

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

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

    • distribute — распаковка переданного дистрибутива ./EVTD-kafka-[version]-distrib.zip;

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

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

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

    • status — статус сервиса;

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

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

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

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

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts, выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 3. Получение списка топиков на кластере для EVTD#

С помощью ansible#

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

bin/kafka-topics.sh --bootstrap-server `hostname -f`:<порт> --list --command-config ~/ssl_adm.properties

Более подробную информацию по конкретному топику можно получить используя команду:

bin/kafka-topics.sh --bootstrap-server `hostname -f`:<порт> --topic <наименование топика> --describe --command-config ~/ssl_adm.properties

С помощью Jenkins#

Получить список топиков на кластере можно с помощью Jenkins job kafka_config_deploy с тегом print_topics (чтобы получить список топиков) или print_topics_with_configs (чтобы получить список топиков и их конфигурацию) с выбором сертификата администратора в поле admin_jks_file.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для установки конфигурационного дистрибутива для EVTD»).

Настраиваемые параметры:

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

  • inventory — имя inventory;

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

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

    • 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_slave — выбор Slave Jenkins;

  • custom_vault_password — запрашивать ли дополнительный ansible vault пароль в интерактивном режиме?

  • 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 доверенными;

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

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

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

Сценарий 4. Просмотр конфигурации топика для EVTD#

С помощью ansible#

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

bin/kafka-configs.sh --bootstrap-server `hostname -f`:<порт> --entity-type topics --entity-name <наименование топика> --describe --command-config ~/ssl_adm.properties

С помощью Jenkins#

Просмотреть конфигурацию топиков на кластере можно с помощью Jenkins job kafka_config_deploy с тегом print_topics_with_configs с выбором сертификата администратора в поле admin_jks_file.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для установки конфигурационного дистрибутива для EVTD»).

Настраиваемые параметры:

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

  • inventory — имя inventory;

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

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

    • 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_slave — выбор Slave Jenkins;

  • custom_vault_password — запрашивать ли дополнительный ansible vault пароль в интерактивном режиме?

  • 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 доверенными;

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

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

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

Сценарий 5. Проверка списка прав на топик для EVTD#

С помощью ansible#

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

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:<порт> --list --topic <наименование топика> --command-config ~/ssl_adm.properties

С помощью Jenkins#

Проверка списка прав на топике осуществляется с помощью Jenkins job kafka_config_deploy.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для установки конфигурационного дистрибутива для EVTD»).

Для этого:

  1. При настройке Jenkins job kafka_config_deploy укажите:

  • в параметре nexusUrl – полный путь до необходимого конфигурационного дистрибутива (или нескольких);

  • в параметре tags – тег print_topics;

  • в параметре admin_jks_file – сертификат администратора.

Настраиваемые параметры kafka_config_deploy:

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

  • inventory — имя inventory;

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

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

    • 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_slave — выбор Slave Jenkins;

  • custom_vault_password — запрашивать ли дополнительный ansible vault пароль в интерактивном режиме?

  • 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 доверенными;

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

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

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

Сценарий 6. Проверка лага на топике (отставание consumerGroup по топикам) для EVTD#

С помощью ansible#

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

bin/kafka-consumer-groups.sh --bootstrap-server `hostname -f`:<порт> --group <наименование группы> --topic <наименование топика> --reset-offsets --to-current --command-config ~/ssl_adm.properties

С помощью Jenkins#

Проверить лаг на топике можно с помощью Jenkins job kafka_config_deploy с тегом check_consumer_groups (покажет список ConsumerGroup с лагом) с выбором сертификата администратора в поле admin_jks_file.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для установки конфигурационного дистрибутива для EVTD»).

Настраиваемые параметры kafka_config_deploy:

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

  • inventory — имя inventory;

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

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

    • 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_slave — выбор Slave Jenkins;

  • custom_vault_password — запрашивать ли дополнительный ansible vault пароль в интерактивном режиме?

  • 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 доверенными;

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

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

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

Сценарий 7. Проверка списка consumerGroup для EVTD#

С помощью ansible#

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

bin/kafka-consumer-groups.sh --bootstrap-server `hostname -f`:<порт> --all-groups --list --command-config ~/ssl_adm.properties

С помощью Jenkins#

Проверить список ConsumerGroup можно с помощью Jenkins job kafka_config_deploy с тегом check_consumer_groups (покажет список ConsumerGroup) с выбором сертификата администратора в поле admin_jks_file.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для установки конфигурационного дистрибутива для EVTD»).

Настраиваемые параметры kafka_config_deploy:

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

  • inventory — имя inventory;

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

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

    • 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_slave — выбор Slave Jenkins;

  • custom_vault_password — запрашивать ли дополнительный ansible vault пароль в интерактивном режиме?

  • 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 доверенными;

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

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

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

Сценарий 8. Сброс текущей позиции для consumerGroup по топику для EVTD#

Используется в случае, если необходимо прочитать предыдущие сообщения.

С помощью ansible#

Сбрасывает текущую позицию для consumerGroup по топику на последнюю запись. На сервере, с которого производилась установка, выполнить команду:

bin/kafka-consumer-groups.sh --bootstrap-server `hostname -f`:<порт> --group <наименование группы> --topic <наименование топика> --reset-offsets --to-latest --command-config ~/ssl_adm.properties

Варианты использования:

  • для операции по всем топикам к которым подключалась данная consumerGroup: --all-topics

  • для операции по определенному топику: --topic <наименование topic>

  • для операции по определенной партиции топика: --topic <наименование topic>:<partition>

Варианты перемещения текущей позиции:

  • на запись в указанный момент времени: --to-datetime <YYYY-MM-DDTHH:mm:SS.sss>

  • сдвиг на указанный промежуток времени от текущего: --by-period <PnDTnHnMnS>

  • на самую раннюю из доступных записей: --to-earliest

  • на последнюю запись: --to-latest

  • сдвиг на указанное число позиций: --shift-by

Сценарий 9. Перезапуск компонентов EVTD#

С помощью ansible#

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

Если требуется перезапустить брокер Platform V Corax / Apache Kafka:

  • Остановить сервис:

    sudo systemctl stop kafka.service

  • Остановить брокер Platform V Corax / Apache Kafka:

    opt/Apache/kafka/bin/kafka-server-stop.sh

  • Запустить брокер Platform V Corax / Apache Kafka:

    opt/Apache/bin/kafka-server-start.sh -daemon opt/Apache/config/server.properties

  • Запустить сервис:

    sudo systemctl start kafka.service

Если требуется перезапустить Zookeeper:

  • Остановить сервис:

    sudo systemctl stop zookeeper.service

  • Остановить Zookeeper:

    opt/Apache/kafka/bin/zookeeper-server-stop.sh

  • Запустить Zookeeper:

    opt/Apache/bin/zookeeper-server-start.sh -daemon opt/Apache/config/zookeeper.properties

  • Запустить сервис:

    sudo systemctl start zookeeper.service

С помощью Jenkins#

Перезапуск осуществляется с помощью Jenkins job SYN_custom_kafka.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

Перезапуск компонентов Zookeper и брокеров Platform V Corax / Apache Kafka одновременно:

При настройке Jenkins job SYN_custom_kafka укажите:

  • в параметре playbook – zk_and_kafka.yml;

  • в параметре tags – теги start и stop.

**Перезапуск брокеров Platform V Corax / Apache Kafka:

При настройке Jenkins job SYN_custom_kafka укажите:

  • в параметре playbook – kafka.yml;

  • в параметре tags – теги start и stop.

Перезапуск компонента Zookeper:

При настройке Jenkins job SYN_custom_kafka укажите:

  • в параметре playbook – zookeeper.yml;

  • в параметре tags – теги start и stop.

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов для playbooks zk_and_kafka.yml, kafka.yml и zookeeper.yml:

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

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

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

    • distribute — распаковка переданного дистрибутива ./EVTD-kafka-[version]-distrib.zip;

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

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

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

    • status — статус сервиса;

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

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

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

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

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts, выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 10. Использование скриптов автоматизации для EVTD#

Перезапуск компонентов техсервиса#

С помощью ansible#

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

ansible-playbook -i inventories/<ID>/<playbook> --ask-vault-pass -t start,stop

, где:

  • ID — имя созданного inventory;

  • playbook — используемый playbook.

Необходимый playbook:

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

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

  • zookeeper.yml — для перезапуска только Zookeeper;

  • -l <fqdn узла> — для указания конкретных узлов.

С помощью Jenkins#

Перезапуск компонентов техсервиса осуществляется с помощью Jenkins job SYN_custom_kafka с выбором нужного playbook, тегами start и stop и узлами, на которых будет производиться операция. Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

Необходимый playbook:

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

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

  • zookeeper.yml — для перезапуска только Zookeeper.

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов;

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 11. Работа с сущностями (топики и ACL) для EVTD#

С помощью ansible#

Создание сущностей

Для создания топиков и ACLs необходимо заполнить в соответствующем inventory файл vars.yml:

kafka_topics:
  list:
    - name: <имя создаваемого топика>
      partitions: <количество партиций>
      configs: # дополнительные конфигурации топика
        - retention.ms=<очистка топиков по времени в мс>

kafka_acls:
  - principal: <DN сертификата клиента>
    producer: true # в данном случае клиент выступает поставщиком. В случае потребителя указывается «consumer: true»
    topics: <имя топика, к которому подключается клиент>

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

ansible-playbook -i inventories/<ID>/inventory kafka_topics_acls.yml --ask-vault-pass

, где ID — имя созданного inventory.

Удаление ACLs

Для удаления ACLs необходимо изменить файл vars.yml:

  1. Добавить флаг erase: true к удаляемой сущности:

kafka_acls:
  - principal: <DN сертификата клиента>
    producer: true # в данном случае клиент выступает поставщиком. В случае потребителя указывается «consumer: true»
    topics: <имя топика, к которому подключается клиент>
    erase: true # флаг удаления ACL

  1. На сервере, с которого производилась установка, выполнить команду:

ansible-playbook -i inventories/<ID>/inventory kafka_topics_acls.yml --ask-vault-pass -t erase_acls

, где ID — имя созданного inventory.

С помощью Jenkins#

Работа с сущностями ведется посредством конфигурационных дистрибутивов. Для их создания используется Jenkins job kafka_config_create. Подробнее в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для создания конфигурационного дистрибутива для EVTD»).

Создание сущностей

Для создания топиков и ACLs используется Jenkins job kafka_config_deploy.

Процесс создания Jenkins job kafka_config_deploy описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Jenkins Job для создания конфигурационного дистрибутива для EVTD»).

  1. При настройке Jenkins job kafka_config_deploy необходимо указать следующие параметры:

  • nexusUrl – полный путь до необходимого конфигурационного дистрибутива (или нескольких);

  • tags – оставить поле пустым;

  • admin_jks_file – сертификат администратора.

  1. Запустите Jenkins job, дождитесь окончания выполнения работы.

  2. Убедитесь, что Jenkins job завершена без ошибок, просмотрев лог консоли Jenkins и проверив код завершения (статус «Finished: SUCCESS»).

Удаление ACLs

Для удаления сущностей используется Jenkins job kafka_config_deploy:

  1. При настройке Jenkins job kafka_config_deploy необходимо указать следующие параметры:

  • nexusUrl – полный путь до необходимого конфигурационного дистрибутива (или нескольких);

  • tags – erase_acls;

  • admin_jks_file – сертификат администратора.

  1. Запустите Jenkins job, дождитесь окончания выполнения работы.

  2. Убедитесь, что Jenkins job завершена без ошибок, просмотрев лог консоли Jenkins и проверив код завершения (статус «Finished: SUCCESS»).

Сценарий 12. Автоматизированная замена TLS-сертификатов для EVTD#

TLS-сертификаты для сетевого взаимодействия между компонентами программного компонента EVTD могут быть автоматически обновлены на новые в случае окончания их срока действия.

Предварительно перед обновлением сертификатов необходимо выполнить следующие действия:

  1. Выпустить новые сертификаты. DN новых сертификатов для конкретных компонентов (брокеры Platform V Corax / Apache Kafka, Zookeeper) должны совпадать с DN старых сертификатов этих компонентов.

  2. Скопировать новые сертификаты в директорию хранения сертификатов согласно настройке, указанной в конфигурационном файле vars.yml:

kafka:
    trustStorePath: <путь до сертификата truststore>
    trustStorePassword: <пароль truststore>
    keyStorePath: <путь до сертификата keystore>
    keyStorePassword: <пароль keystore>
    keyPassword: <пароль от ключа в хранилище>
...
zookeeper:
    trustStorePath: <путь до сертификата truststore>
    trustStorePassword: <пароль truststore>
    keyStorePath: <путь до сертификата keystore>
    keyStorePassword: <пароль keystore>
    keyPassword: <пароль от ключа в хранилище>

  1. Заполнить в конфигурационном файле vars.yml список DN сертификатов УЦ, которые являются доверенными:

ssl_rolling_update:
  trusted_dn_list: # список DN доверенных центров сертификации
    - <DN доверенного центра сертификации>

  1. В случае изменения настроек для SSL-сертификатов (директория хранения, имя сертификата, пароли, новые центры сертификации) необходимо изменить соответствующие настройки в конфигурационном файле vars.yml и сохранить эти изменения.

Для автоматической замены сертификатов необходимо запустить Jenkins job SYN_custom_kafka с выбором параметра playbook ssl_rolling_update.yml.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

После запуска поочередно на каждом сервере кластера будет произведена замена сертификатов, обновятся настройки сертификатов на серверах в файлах .properties, а также перезапустятся компоненты (брокеры Platform V Corax / Apache KafkaKafka, Zookeeper) с новыми сертификатами на каждом сервере кластера поочередно. В рамках работы Jenkins job осуществляется проверка корректного запуска задействованных компонент.

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов;

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Если список DN доверенных УЦ окажется пустым, работа Jenkins job SYN_custom_kafka с выбором playbook ssl_rolling_update.yml завершится с ошибкой: DN <DN заменяемого сертификата> didn't found in trusted_dn_list!.

Сценарий 13. Установка ограничений на клиенты и пользователей для EVTD#

С помощью ansible#

  1. Чтобы получить список ограничений на клиентах/пользователях, необходимо на сервере, с которого производилась установка, выполнить команду:

  • только для определенных client.id:

/bin/kafka-configs.sh  --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --describe --entity-type clients

  • только для определенных пользователей (идентификация пользователя осуществляется по DN сертификата):

/bin/kafka-configs.sh  --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --describe --entity-type users

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

/bin/kafka-configs.sh  --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --describe --entity-type users --entity-type clients

  1. Для добавления ограничения на клиентах/пользователях необходимо на сервере, с которого производилась установка, выполнить команду:

  • для клиентов и пользователей одновременно:

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --add-config 'producer_byte_rate=1024000,consumer_byte_rate=1024000' --entity-type users --entity-name "CN=XXX.YYYY,OU=XXX,O=XXXX,L=Moscow,C=RU" --entity-type clients --entity-name <client.id>

  • только для определенных пользователей:

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --add-config 'producer_byte_rate=1024000,consumer_byte_rate=1024000' --entity-type users --entity-name "CN=XXX.YYYY,OU=XXX,O=XXXX,L=Moscow,C=RU"

  • только для определенных client.id:

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --add-config 'producer_byte_rate=1024000,consumer_byte_rate=1024000' --entity-type clients --entity-name <client.id>

  1. Для удаления ограничений на клиентах/пользователях необходимо на сервере, с которого производилась установка, выполнить команду:

  • только для определенных client.id:

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --delete-config 'producer_byte_rate, consumer_byte_rate' --entity-type clients --entity-name <client.id>

  • только для определенных пользователей (идентификация пользователя осуществляется по DN сертификата):

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --delete-config 'producer_byte_rate, consumer_byte_rate' --entity-type users --entity-name "CN=XXX.YYYY,OU=XXX,O=XXXX,L=Moscow,C=RU"

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

./bin/kafka-configs.sh --command-config config/producer.properties --bootstrap-server host1:port1,host2:port2,host3:port3 --alter --delete-config 'producer_byte_rate, consumer_byte_rate' --entity-type users --entity-name "CN=XXX.YYYY,OU=XXX,O=XXXX,L=Moscow,C=RU" --entity-type clients --entity-name <client.id>

С помощью Jenkins#

Работа с ограничениями на клиенты и/или пользователей осуществляется с помощью Jenkins job SYN_custom_kafka с использованием playbook kafka_limits.yml.

Предварительно в конфигурационном файле vars.yml необходимо заполнить блок:

kafka_limits:
#  - producer_byte_rate: "1024000" # ограничения для продюсера, в байтах
#    consumer_byte_rate: "1024000" # ограничения для консьюмера, в байтах
#    dn_name: <имя сертификата, например user2>   # dn сертификата пользователя
#    client_id: <имя клиента, например client2>  # client.id из настроек продюсера/консьюмер
#    erase: false # параметр для удаления ограничения. Допустимые значения: false и true. В случае необходимости удаления лимитов перед запуском задания Jenkins необходимо устанавливить значение true.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

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

  • tags — список тегов для playbook kafka_limits.yml:

    • erase_limits — удаление ограничений;

    • get_limits — получить запрос текущих ограничений;

    • set_limits — установка ограничений;

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts, выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 14. Получение информации о версии кластера Kafka для EVTD#

С помощью Jenkins#

Получение информации о версии кластера брокеров Platform V Corax / Apache Kafka, к которому предполагается подключение, с помощью Jenkins job SYN_custom_kafka с выбором playbook kafka_get_info.yml без тегов.

Процесс создания Jenkins job SYN_custom_kafka описан в документе «Руководство по установке», раздел «Подготовка окружения EVTD» (подраздел «Создание Jenkins Job для автоматической установки EVTD»).

Настраиваемые параметры SYN_custom_kafka:

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

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

  • nexusUrl — ссылка на переданный дистрибутив ./EVTD-kafka-[version]-distrib.zip;

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

  • playbook— необходимый сценарий установки (kafka_get_info.yml);

  • tags — список тегов;

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

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

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

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

  • jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

Если не выбран ни один из параметров only_on_host, select_all_hosts выполнение Jenkins job прервется с ошибкой Не выбраны сервера.

Сценарий 15. Контроль работоспособности EVTD#

Для получения данных по установленным компонентам можно воспользоваться утилитой discovery_component.py.

На стороне компонента, если соответствующий порт для компонента уже занят, будет открыт следующий первый свободный порт. Утилита discovery_component.py принимает на вход название компонента и опционально IP-адрес, маску подсети, discovery-порт, значение тайм-аута и флаг расширенного логирования.

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

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

discovery_component.py [-h] --component COMPONENT [--discovery-port DISCOVERY_PORT] [--mask MASK] [--ip IP] [--closed-port-threshold CLOSED_PORT_THRESHOLD] [--timeout TIMEOUT] [--verbose]

Аргументы:

Параметр

Назначение

-h, –help

show this help message and exit

–component COMPONENT

Четырехсимвольный код компонента для поиска. Возможное значение: „EVTD“

–discovery-port DISCOVERY_PORT

Discovery-порт компонента, который будет опрашиваться на хостах подсети. По умолчанию берется discovery-порт в зависимости от компонента: {„EVTD“: 20000}

–mask MASK

Маска подсети для поиска компонент в нотации CIDR. По умолчанию: /24

–ip IP

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

–closed-port-threshold CLOSED_PORT_THRESHOLD

Порог количества закрытых подряд портов для перехода проверки на следующий хост. По умолчанию 5

–timeout TIMEOUT

Тайм-аут на ожидание подключения к порту сканируемого хоста в секундах. По умолчанию 0.1 секунды

–verbose

Расширенное логирование сканирования

Пример возвращаемых данных компонента EVTD при обращении на discovery-порт:

{
    'product': 'EM',
    'component': 'EVTD',
    'version': '<версия>',
    'cpuCount': '4'
    }

Подробнее с параметрами утилиты можно ознакомиться в файле README.txt, размещенном в папке discovery архива EM-*-metadata-distrib.zip в пакете продукта EM-*-distrib.zip.

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

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

Выдайте требуемому пользователю (далее в примере - пользователю 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
kafka ALL= NOPASSWD: /bin/rm /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 ALL= NOPASSWD: /bin/rm /etc/systemd/system/zookeeper.service

Ручное удаления системного сервиса обслуживания EVTD для Kafka#

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

  1. Остановите и выключите системный сервис. Для этого выполните команду sudo systemctl stop kafka.service && sudo systemctl disable kafka.service.

  2. Удалите unit файл системного сервиса. Для этого выполните команду sudo rm /etc/systemd/system/kafka.service.

  3. Для применения изменений выполните команду sudo systemctl daemon-reload.

Ручное удаления системного сервиса обслуживания EVTD для Zookeeper#

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

  1. Остановите и выключите системный сервис. Для этого выполните команду sudo systemctl stop zookeeper.service && sudo systemctl disable zookeeper.service.

  2. Удалите unit файл системного сервиса. Для этого выполните команду sudo rm /etc/systemd/system/zookeeper.service.

  3. Для применения изменений выполните команду sudo systemctl daemon-reload.

Ручное удаление пользовательского сервиса обслуживания EVTD для Kafka#

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

  1. Остановите и выключите пользовательский сервис. Для этого выполните команду systemctl stop kafka.service --user && systemctl disable kafka.service --user.

  2. Удалите unit файл пользовательского сервиса. Для этого выполните команду rm ~/.config/systemd/user/kafka.service

  3. Для применения изменений выполните команду systemctl daemon-reload --user.

Ручное удаление пользовательского сервиса обслуживания EVTD для для Zookeeper#

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

  1. Остановите и выключите пользовательский сервис. Для этого выполните команду systemctl stop zookeeper.service --user && systemctl disable zookeeper.service --user.

  2. Удалите unit файл пользовательского сервиса. Для этого выполните команду rm ~/.config/systemd/user/zookeeper.service

  3. Для применения изменений выполните команду systemctl daemon-reload --user.

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

  1. Выберите соответствующий playbook в Jenkins job, в параметре «playbook»:

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

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

  1. Выберите сервер (хост), параметр «only_on_host» или «select_all_hosts» для установки на всех хостах.

  2. Запустите работу Jenkins Job.

  3. Проверьте статус Jenkins Job, для успешной работы должно быть - Finished: SUCCESS.

Сценарий 17. Предоставление прав для сертификатов администратора для EVTD#

Необходимо заполнить параметр kafka.admin_rights в файле vars.yml.

  • в разделе kafka:

    • backup_installdir_to:— директория создания архивных копий для директории установки брокеров Platform V Corax / Apache Kafka;

  • в разделе zookeeper:

    • backup_installdir_to:— директория создания архивных копий для директории установки Zookeeper.

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

По завершению установки под пользователем kafka на сервере Kafka создать УЗ администратора доступа, который в дальнейшем будет отвечать за выдачу прав пользователям:

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:9093 --allow-principal User:"<DN сертификата администратора доступа из папки ssl_admin>" --operation CREATE --cluster --add --command-config /opt/Apache/kafka/config/producer.properties

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:9093 --allow-principal User:"<DN сертификата администратора доступа из папки ssl_admin>" --operation ALTER --cluster --topic "*" --add --command-config /opt/Apache/kafka/config/producer.properties

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:9093 --allow-principal User:"<DN сертификата администратора доступа из папки ssl_admin>" --operation DESCRIBE --cluster --group "*" --topic "*" --add --command-config /opt/Apache/kafka/config/producer.properties

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:9093 --allow-principal User:"<DN сертификата администратора доступа из папки ssl_admin>" --operation DESCRIBECONFIGS  --topic "*" --add --command-config /opt/Apache/kafka/config/producer.properties

/opt/Apache/kafka/bin/kafka-acls.sh --bootstrap-server `hostname -f`:9093 --allow-principal User:"<DN сертификата администратора доступа из папки ssl_admin>" --operation ALTERCONFIGS  --topic "*" --add --command-config /opt/Apache/kafka/config/producer.properties

Просмотреть DN в JKS-файле хранилища сертификатов можно командой:

 keytool  -v -list -keystore <имя хранилища>.jks  | sed -n -E '/PrivateKeyEntry/{N;N;N;N;N;s/.*Owner: (.*)\nIssuer.*/\1/p}'

Результат#

Сценарии администрирования выполнены.