Поузловое обновление сертификатов на кластере без недоступности#

В данном сценарии описана возможность последовательной замены сертификатов на брокерах кластера.

При запуске понодной замены сертификатов на кластере необходимо предварительно проверить значение параметра ignore_dn_mismatch в файле vars.yml.

ssl_rolling_update:
  ignore_dn_mismatch: false # Продолжаем ли работу при несовпадении старого и нового DN. Доступные значения: true or false. Значение по умолчанию: false.

В случае, если значение параметра при установке было задано true — в случае обновления сертификатов при несовпадении старого и нового сертификатов происходит продолжение работы Jenkins job или продолжает выполняться playbook при ручном способе. Если значение параметра false — происходит прерывание работы Jenkins job или прерывается выполнение playbook при ручном способе.

Для обновления сертификатов обязательно заполнение параметра artemis.super_user, в котором содержится DN нового сертификата. При отсутствии этого параметра обновление завершится с соответствующей ошибкой.

Ручной способ#

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

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

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

С помощью Jenkins#

Наименование задания Jenkins: artemis_custom.

Параметры запуска:

  • job_config_renew — параметр, использующийся для перенастройки задания Jenkins. Его необходимо включить, если был добавлен новый inventory или изменен файл jenkins_defaults.groovy. Меняет значения по умолчанию всех параметров. Сохраняет предыдущее состояние параметров inventories_repo, inventories_branch, inventories_path. Обновляет список тегов для всех playbooks. По умолчанию не указывается;

  • inventory — выбрать inventory, для которого необходимо произвести последовательное обновление;

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

  • playbook — указать значение ssl_rolling_update.yml;

  • emailTo — список адресов электронной почты для отправки технических писем с логами;

  • custom_vault_password — указывается, если нужен ручной ввод пароля для Ansible Vault;

  • jenkins_slave — выбор Slave Jenkins;

  • jdk_tool — указать Jenkins Tool с нужной версией JDK;

  • ansible_branch — ветка скриптов развертывания (в настройках Jenkins Job указать ${ansible_branch});

  • ansible_version — версия используемого ansible, например ansible29;

  • nexus_user_cred — ID credential типа username with password для выкачивания дистрибутива. При задании параметра secman_url - полный путь в HashiCorp Vault до имени пользователя и пароля, например {ID credential типа vault app role для получение секретов из HashiCorp Vault}|/<путь до>/nexus:{user},{password};

  • vault_cred — ID credential типа secret file со строкой для расшифровки паролей (ansible vault) (можно указывать несколько через запятую). При задании параметра secman_url - полный путь в HashiCorp Vault до пароля, например {ID credential }|/<путь до>/vault:{password_1},{ID credential _2}|/<путь до>/vault:{password_2} (в качестве пароля можно использовать не строку, а файл в base64 формате с ключом секрета, заканчивающимся на Base64, например myVaultBase64);

  • server_ssh_cred — ID credential типа ssh key для подключения к серверам. При задании параметра secman_url - полный путь в HashiCorp Vault, например {ID credential типа vault app role для получение секретов из HashiCorp Vault}|/<путь до>/ssh:{юзер},{ключ},{passphrase} (в качестве ключа можно использовать не строку, а файл в base64 формате с ключом секрета, заканчивающимся на Base64, например myPrivateKeyBase64);

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

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

  • inventories_repo — репозиторий с inventory (ssh://);

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

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