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

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

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

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

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

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

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

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

Сценарий 1. Запуск EVTA#

Данный раздел применим для роли Администратор.

Запуск EVTA на ВМ#

С помощью ansible#

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

systemctl status <имя сервиса>.service

, где имя сервиса — имя, соответствующее имени адаптера из документа «Руководство по установке», раздел «Подготовка окружения EVTA» (подраздел «Создание системных и пользовательских сервисов обслуживания для EVTA»).

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

1. При наличии сервиса необходимо:

• Запустить сервис: sudo systemctl start <имя сервиса>.service

2. При отсутствии сервиса необходимо:

• Запустить EVTA. Из директории установки запустить команду: ./bin/<имя адаптера> start

С помощью Jenkins#

Для запуска компонентов необходимо запустить Jenkins job установки EVTA (название может быть произвольным, задается в процессе установки) с выбором playbook reactive_stream_adapter_vm.yml с тегом start.

Для проведения операции над конкретными адаптерами добавляются теги run_only,<имя адаптера1>,<имя адаптера2>.

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

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

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

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

• nexusDistribUrl — ссылка на дистрибутив reactive_stream_adapter;

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

  • reactive_stream_adapter_vm.yml — запуск EVTA на ВМ;

  • reactive_stream_adapter_vm_system_service.yml — создание системных сервисов EVTA;

  • reactive_stream_adapter_vm_user_service.yml — создание пользовательских сервисов EVTA;

  • reencrypt_password.yml — перешифрование паролей.

• tags — список тегов. При пустом значении выполняется полная установка компонента:

  • run_only — при указании появляется выбор адаптеров (для дальнейших действий) без указания — на все адаптеры;

  • adapter_already_installed — выполняется установка и запуск EVTA из конфигурационного дистрибутива без выкачивания дистрибутива EVTA из nexusDistribUrl;

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

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

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

  • distribute — распаковка дистрибутива nexusDistribUrl;

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

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

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

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

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

  • uninstall — удаление сервиса.

• adapterList — выбор адаптера (при наличии тега run_only);

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

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

• jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

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

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

  • SecManKeys — имена полей для ssh_username, ssh_key, ssh_key_passphrase в HashiCorp Vault (через запятую). Ssh_key_passphrase не указывается, если у ssh ключа нет пароля. В секрете, в значении ssh_key обязательно оставить перенос строки после текста с приватным ключом;

  • 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 доверенными (по умолчанию включен, true);

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

• inventories_repo — репозиторий с inventory;

• inventories_branch — ветка репозитория;

• inventories_path — путь до inventories от корня репозитория;

• cleanws — параметр очистки Jenkins workspace (по умолчанию включен, true).

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

Запуск EVTA, установленного в облачной среде#

Запуск EVTA в облачной среде не производится. Существуют только операции установки и удаления. Подробнее в документе «Руководство по установке».

Сценарий 2. Остановка EVTA#

Данный раздел применим для роли Администратор.

Остановка EVTA на ВМ#

С помощью ansible#

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

systemctl status <имя сервиса>.service

, где имя сервиса — имя, соответствующее имени адаптера из документа «Руководство по установке», раздел «Подготовка окружения EVTA» (подраздел «Создание системных и пользовательских сервисов обслуживания для EVTA»).

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

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

sudo systemctl stop <имя сервиса>.service

2. При отсутствии сервиса необходимо остановить EVTA, из директории установки запустить команду:

./bin/<имя адаптера> stop

С помощью Jenkins#

Для остановки компонентов необходимо запустить Jenkins job установки EVTA (название может быть произвольным, задается в процессе установки) с выбором playbook reactive_stream_adapter_vm.yml с тегом stop.

Для проведения операции над конкретными адаптерами добавляются теги run_only,<имя адаптера1>,<имя адаптера2>.

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

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

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

• nexusDistribUrl — ссылка на дистрибутив reactive_stream_adapter;

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

  • reactive_stream_adapter_vm.yml — запуск EVTA на ВМ;

  • reactive_stream_adapter_vm_system_service.yml — создание системных сервисов EVTA;

  • reactive_stream_adapter_vm_user_service.yml — создание пользовательских сервисов EVTA;

  • reencrypt_password.yml — перешифрование паролей.

• tags — список тегов. При пустом значении выполняется полная установка компонента:

  • run_only — при указании появляется выбор адаптеров (для дальнейших действий) без указания — на все адаптеры;

  • adapter_already_installed — выполняется установка и запуск EVTA из конфигурационного дистрибутива без выкачивания дистрибутива EVTA из nexusDistribUrl;

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

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

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

  • distribute — распаковка дистрибутива nexusDistribUrl;

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

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

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

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

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

  • uninstall — удаление сервиса.

• adapterList — выбор адаптера (при наличии тега run_only);

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

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

• jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

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

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

  • SecManKeys — имена полей для ssh_username, ssh_key, ssh_key_passphrase в HashiCorp Vault (через запятую). Ssh_key_passphrase не указывается, если у ssh ключа нет пароля. В секрете, в значении ssh_key обязательно оставить перенос строки после текста с приватным ключом;

  • 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 доверенными (по умолчанию включен, true);

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

• inventories_repo — репозиторий с inventory;

• inventories_branch — ветка репозитория;

• inventories_path — путь до inventories от корня репозитория;

• cleanws — параметр очистки Jenkins workspace (по умолчанию включен, true).

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

Перезапуск EVTA, установленного в облачной среде#

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

Сценарий 3. Перезапуск EVTA#

Данный раздел применим для роли Администратор.

Перезапуск EVTA на ВМ#

С помощью ansible#

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

systemctl status <имя сервиса>.service

, где имя сервиса – имя, соответствующее имени адаптера из документа «Руководство по установке», раздел «Подготовка окружения EVTA» (подраздел «Создание системных и пользовательских сервисов обслуживания для EVTA»).

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

1. При наличии сервиса необходимо:

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

  sudo systemctl stop <имя сервиса>.service
  

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

  sudo systemctl start <имя сервиса>.service
  

2. При отсутствии сервиса необходимо:

• Остановить EVTA. Из директории установки запустить команду:

  ./bin/<имя адаптера> stop
  

• Запустить EVTA. Из директории установки запустить команду:

  ./bin/<имя адаптера> start
  

С помощью Jenkins#

Для перезапуска компонентов необходимо запустить Jenkins job установки EVTA (название может быть произвольным, задается в процессе установки) с выбором playbook reactive_stream_adapter_vm.yml с тегами start и stop.

Для проведения операции над конкретными адаптерами добавляются теги run_only,<имя адаптера1>,<имя адаптера2>.

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

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

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

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

• nexusDistribUrl — ссылка на дистрибутив reactive_stream_adapter;

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

  • reactive_stream_adapter_vm.yml — запуск EVTA на ВМ;

  • reactive_stream_adapter_vm_system_service.yml — создание системных сервисов EVTA;

  • reactive_stream_adapter_vm_user_service.yml — создание пользовательских сервисов EVTA;

  • reencrypt_password.yml — перешифрование паролей.

• tags — список тегов. При пустом значении выполняется полная установка компонента:

  • run_only — при указании появляется выбор адаптеров (для дальнейших действий) без указания — на все адаптеры;

  • adapter_already_installed — выполняется установка и запуск EVTA из конфигурационного дистрибутива без выкачивания дистрибутива EVTA из nexusDistribUrl;

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

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

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

  • distribute — распаковка дистрибутива nexusDistribUrl;

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

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

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

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

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

  • uninstall — удаление сервиса.

• adapterList — выбор адаптера (при наличии тега run_only);

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

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

• jenkins_slave — выбор Jenkins Slave;

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

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

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

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

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

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

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

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

  • SecManKeys — имена полей для ssh_username, ssh_key, ssh_key_passphrase в HashiCorp Vault (через запятую). Ssh_key_passphrase не указывается, если у ssh ключа нет пароля. В секрете, в значении ssh_key обязательно оставить перенос строки после текста с приватным ключом;

  • 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 доверенными (по умолчанию включен, true);

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

• inventories_repo — репозиторий с inventory;

• inventories_branch — ветка репозитория;

• inventories_path — путь до inventories от корня репозитория;

• cleanws — параметр очистки Jenkins workspace (по умолчанию включен, true).

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

Перезапуск EVTA, установленного в облачной среде#

Перезапуск EVTA в облачной среде не производится. Существуют только операции установки и удаления. Подробнее в документе «Руководство по установке».

Сценарий 4. Создание конфигурационного дистрибутива для EVTA#

Данный раздел применим для роли Администратор.

Для создания конфигурационных дистрибутивов с настройками компонента EVTA существует две Jenkins job:

• evta_config_create – создает конфигурационный дистрибутив и публикует его в Nexus;

• evta_image_create – создает новый cfg-дистрибутив и пересобирает образ адаптера вместо конфигурационного дистрибутива, подкладывая схемы валидации прямо внутрь контейнера.

Параметры evta_config_create#

С помощью job evta_config_create можно создать конфигурационный дистрибутив и опубликовать его в Nexus. Если конфигурационный дистрибутив уже существует, можно указать путь до него в параметре nexusUrl в Jenkins job установки компонента (не путать с job для конфигурационных дистрибутивов).

Задание конфигурационного дистрибутива EVTA через Git

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

1. Параметры issueID, gitPath, gitUrl, gitCred, gitBranch задаются только в случае если признак configManualUpload отключен. При этом параметры evtaConfig и configs_upload обязательно должны быть не заданы (в том числе параметр configs_upload должен быть в отключенном состоянии). Если configManualUpload — включен, то параметры issueID, gitPath, gitUrl, gitCred, gitBranch должны быть пустыми, но при этом обязательно заданы параметры replicatorConfig и configs_upload.

2. В корне директории конфигурации в Git обязательно должен быть файл release.yml, который содержит конфигурацию адаптера в формате vars.yml. В корне директории конфигурации также может находиться папка conf – конфигурация интерсепторов адаптера (при необходимости).

Пример файла release.yml (без папки conf):

reactive_stream_adapter_vm:
  adapter_list:
  - name: example-kafka # наименование адаптера
    producer: # Пример продюсера типа kafka
    preset_name: kafka_output # Обязательный параметр, название пресета
    topic: "output" # Обязательный параметр для продюсера типа kafka, имя топика
    consumer: # Пример консюмера типа kafka
    preset_name: kafka_input # Обязательный параметр, название пресета
    topic: "input" # Обязательный параметр для консьюмера типа kafka, имя топика
    props:
    group.id: kafka-example-consumer # имя консьюмера группы

Примеры конфигурации EVTA для установки на ВМ (указывается в параметре evtaConfig), вариант без использования Git репозитория

reactive_stream_adapter_vm:
  adapter_list:
  - name: example-kafka # наименование адаптера
    producer: # Пример продюсера типа kafka
    preset_name: kafka_output # Обязательный параметр, название пресета
    topic: "output" # Обязательный параметр для продюсера типа kafka, имя топика
    consumer: # Пример консюмера типа kafka
    preset_name: kafka_input # Обязательный параметр, название пресета
    topic: "input" # Обязательный параметр для консьюмера типа kafka, имя топика
    props:
    group.id: kafka-example-consumer # имя консьюмера группы
  - name: example-artemis # наименование адаптера
    consumer: # Пример консюмера типа artemis
    preset_name: artemis_input # Обязательный параметр, название пресета
    queue: "input" # Обязательный параметр для консюмера типа artemis, имя очереди
    deadLetter: "deadLetter" # Необязательный параметр для консюмера типа artemis, очередь ошибочных сообщений
    producer: # Пример продюсера типа artemis
    preset_name: artemis_output # Обязательный параметр, название пресета
    queue: "output" # Обязательный параметр для producer типа artemis, имя очереди

reactive_stream_adapter_vm:
  logging:
    kafka:
      enabled: false
  adapter_list:
  - name: evta-night-install-vm-2-1 # наименование адаптера
    processors:
      log:
        format: auto
        level: info
  - name: aft-21-vm-grpc-rabbit # наименование адаптера
    log:
      deadLetterLogEnabled: "false"
    endpoints:
    - name: "fpss://K2_IAZCommon.Common.ALPHA/System/TESTA/1"
      preset_name: rabbit
      exchange: some_exchange
      routingKey: routing_key_night_2
      queue: night.test.1

Пример конфигурации EVTA для установки в облачной среде (указывается в параметре evtaConfig)

reactive_stream_adapter:
   name: example # наименование деплоя. Результат: reactivestreamadapter-example
   type: grpc
   endpoints:
      - name: "fpss://Domain.Federation.SEGMENT/System/TESTA/1"
        topic: "input"
        preset_name: kafka_input # имя пресета из reactive_stream_adapter_preset
      - name: "fpss://Domain.Federation.SEGMENT/System/TESTB/1"
        topic: "output"
        preset_name: kafka_output # имя пресета из reactive_stream_adapter_preset

Все доступные параметры для конфигурации находятся в vars.yml (можно ознакомиться в «Руководство по установке» в разделе «Подготовка окружения EVTA» (подраздел «Пример заполненного файла vars.yml»)).

Параметры evta_image_create#

Job evta_image_create используется только для создания облачных конфигурационных дистрибутивов – создает новый cfg-дистрибутив и пересобирает образ адаптера вместо конфигурационного дистрибутива, подкладывая схемы валидации прямо внутрь контейнера. Далее новый облачный конфигурационный дистрибутив с вшитыми схемами валидации можно указать в поле nexusHelmUrl при установке компонента с помощью job reactive_stream_adapter.

Задание конфигурационного дистрибутива EVTA через Git для облачного варианта установки

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

1. Параметры issueID, gitPath, gitUrl, gitCred, gitBranch задаются только в случае если признак configManualUpload отключен. При этом парамтры evtaConfig и configs_upload обязательно должны быть не заданы (в том числе параметр configs_upload должен быть в отключенном состоянии). Если configManualUpload — включен, то параметры issueID, gitPath, gitUrl, gitCred, gitBranch должны быть пустыми, но при этом обязательно заданы параметры replicatorConfig и configs_upload.

2. В корне директории конфигурации в Git обязательно должен быть файл release.yml, который содержит конфигурацию адаптера в формате vars.yml. В корне директории конфигурации также может находиться папка conf – конфигурация интерсепторов адаптера (при необходимости).

Пример файла release.yml:

reactive_stream_adapter:
  name: example # наименование деплоя. Результат: reactivestreamadapter-example
  type: grpc
  endpoints:
    - name: "fpss://Domain.Federation.SEGMENT/System/TESTA/1"
      topic: "input"
      preset_name: kafka_input # имя пресета из reactive_stream_adapter_preset
    - name: "fpss://Domain.Federation.SEGMENT/System/TESTB/1"
      topic: "output"
      preset_name: kafka_output # имя пресета из reactive_stream_adapter_preset

Пример конфигурации EVTA для установки в облачной среде (указывается в параметре evtaConfig), вариант без использования Git репозитория

reactive_stream_adapter:
  name: example # наименование деплоя. Результат: reactivestreamadapter-example
  type: grpc
  endpoints:
    - name: "fpss://Domain.Federation.SEGMENT/System/TESTA/1"
      topic: "input"
      preset_name: kafka_input # имя пресета из reactive_stream_adapter_preset
    - name: "fpss://Domain.Federation.SEGMENT/System/TESTB/1"
      topic: "output"
      preset_name: kafka_output # имя пресета из reactive_stream_adapter_preset

Все доступные параметры для конфигурации находятся в vars.yml (можно ознакомиться в «Руководство по установке» в разделе «Подготовка окружения EVTA» (подраздел «Пример заполненного файла vars.yml»)).

Загрузка дополнительной конфигурации#

1. Для загрузки необходимо выставить параметр configs_upload в значение true и запустить Jenkins job (процесс загрузки архива происходит после запуска job):

2. Появится этап загрузки zip-архива дополнительной конфигурации:

3. Далее необходимо загрузить нужную конфигурацию и продолжить выполнение job (кнопка Proceed):

Загружаемый файл конфигурации должен быть в виде плоского zip-архива с относительными путями до файлов внутри его конфигураций (если есть). Загрузка распакованных файлов будет произведена в директорию установки в папку conf/ (или conf/<имя адаптера>/ для ВМ).

Сценарий 5. Перешифрование паролей в конфигурационных файлах для EVTA#

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

Данный раздел применим для роли Администратор.

Необходимо добавить в файл vars.yml блок настроек:

reencrypt_passwords:
  new_algorithm: PBEWithHmacSHA512AndAES_256 # алгоритм, на который перешифровываем (допускается PBEWithHmacSHA512AndAES_256)
  change_key: false # удалить старый ключ encrypt.pass и создать новый

С помощью ansible#

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

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

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

С помощью Jenkins#

Для перешифрования необходимо запустить Jenkins job по установке EVTA (название может быть произвольным, задается в процессе установки) с выбором playbook reencrypt_password.yml.

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

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

Данный раздел применим для роли Администратор.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат#

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