Сценарии администрирования продуктов | Ansible_Cartridge

Версия:

latest
Уважаемые пользователи! Мы приняли решение перенести документацию по Ansible Tarantool Enterprise на новый портал. Это позволит нам сделать её ещё более удобной и полезной. Будем рады обратной связи от Вас.
Использование Docker-образа Сценарии администрирования продуктов

Сценарии администрирования продуктов

Далее по документации будут встречаться следующие переменные окружения:

  • SUPER_USER_NAME — имя пользователя для SSH-подключения.

  • PATH_TO_PRIVATE_KEY — полный путь к приватному ключу.

  • PATH_TO_INVENTORY — полный путь к файлу инвентаря.

  • PATH_TO_PACKAGE — полный путь к архиву с приложением.

  • PACKAGE_NAME — имя архива с приложением.

  • DEPLOY_TOOL_VERSION_TAG — версия инсталлятора.

  • LIMIT — указание для Ansible, на каких хостах или группах хостов производить действия.

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

Пример инвентаря для продукта Tarantool Cartridge можно найти в разделе Подготовка к использованию.

Часть переменных используется внутри контейнера во время запуска сценария. Значения переменных передаются в контейнер с помощью опции -e.

Переменная LIMIT — обычный параметр limit для Ansible. Указывать limit можно для любого сценария. В некоторых случаях – обязательно. Можно использовать специальное значение лимита all, чтобы запустить сценарий на всех экземплярах Tarantool.

Tarantool 3.x

Добавлено в версии 1.10.0: Переменные для подключения к централизованному хранилищу на базе Tarantool вместо etcd:

  • tarantool_config_storage (string) - тип централизованного хранилища конфигурации (etcd или Tarantool Config Storage). Если вы хотите использовать Tarantool Config Storage, предварительно установите его (см. файл инвентаря в примерах). Если переменная установлена в значение tarantool, конфигурационный файл будет сгенерирован и сохранён в Tarantool Config Storage с помощью утилиты tt.

    • etcd ← (default)

    • tarantool

  • is_config_storage (boolean) - используется для поднятия кластера Tarantool без централизованого хранилища конфигурации, с указанием пути до файла конфигурации. Как правило, необходимо только при установке кластера Tarantool в качестве Config Storage.

    • true

    • undefined ← (default)

  • tarantool_config_storage_endpoints (list) - аналог tarantool_config_etcd_endpoints. Указывается в соответствии с документацией Tarantool 3.x как значение переменной TT_CONFIG_STORAGE_ENDPOINTS.

    • [{uri: «http://127.0.0.1:4242», login: «user», password: «pass»}]

  • tarantool_config_storage_prefix (path) - префикс, по которому будет сохранена конфигурация кластера Tarantool.

    • /myapp

Важно

Переменная is_config_storage со значением true может быть использована только если переменная tarantool_config_storage задана со значением tarantool.

Сценарии используются для развертывания, обновления, а также администрирования приложений и продуктов на основе Tarantool 3.x Enterprise Edition (например, TDB 2.x, TCS и т.д.). Смотрите также: Примеры инвентарей Tarantool 3.x.

Tarantool 3.x: Управление конфигурацией

Добавлено в версии 1.0.0.

Изменено в версии 1.2.0: Изменена работа с конфигурацией. Уровень global задается в переменной tarantool_config_global, а group – с помощью tarantool_config_group соответственно.

Добавлено управление секциями на уровне replicaset с помощью переменной tarantool_config_replicaset.

Конфигурация Tarantool 3.x генерируется из инвентаря.

Вы можете изменить значения секций конфигурации на любом из уровней окружения. За каждый уровень отвечают собственные переменные:

  • global – общая переменная tarantool_config_global.

  • grouptarantool_config_group на уровне Ansible-групп.

  • replicasettarantool_config_replicaset на том же уровне Ansible-групп, где определена переменная replicaset_alias.

  • instance – собственные переменные у хоста.

Во время запуска Tarantool отдает приоритет уровням в указанном порядке, где самый приоритетный – уровень instance.

Переменная replicaset_alias обязательна, так как экземпляры объединяются в наборы реплик на основе её значения.

Tarantool 3.x: Установка приложения

Добавлено в версии 1.0.0.

Изменено в версии 1.7.0: Добавлена возможность развертывания от имени пользователя root.

Добавлено в версии 1.10.0: Добавлена возможность разворачивать Tarantool Config Storage и приложения с централизованным хранением конфигурации в Tarantool Config Storage.

Основной сценарий для развертывания приложений и продуктов на основе Tarantool 3.x Enterprise Edition (например, TDB 2.x).

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}/${PACKAGE_NAME}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'"
    }' \
    playbooks/install_3_0.yml

Для выполнения развертывания в system space (под пользователем root) убедитесь, что переменная tarantool_shared_become_user установлена в root и добавьте переменную systemd_scope со значением system.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}/${PACKAGE_NAME}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"root",
        "systemd_scope":"system"
    }' \
    playbooks/install_3_0.yml

Tarantool 3.x: Отправка конфигурации в etcd

Добавлено в версии 1.0.0.

Изменено в версии 1.4.1: Изменен способ отправки конфигурации Tarantool в ETCD. Теперь отправка происходит по HTTP с сервера Tarantool.

Важно

Начиная с версии ATE 1.4.1 сценарий работает только с версиями ETCD 3.4 и выше, т.к. используется v3 HTTP API.

Текущий подход к хранению конфигурации – отказоустойчивый кластер ETCD. Данный сценарий сохраняет сгенерированный из инвентаря файл конфигурации в ETCD по ключу /tarantool/{{ cartridge_app_name }}/config/all.

Обязательно укажите адрес сервера ETCD в переменной tarantool_etcd_host. Адрес должен быть доступен с сервера, на котором разворачиваются экземпляры Tarantool.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'"
    }' \
    playbooks/etcd_3_0.yml --limit ${HOSTS}

Внимание

${HOSTS} - группа хостов Tarantool 3.x.

Указание лимита может понадобиться в случае, если в инвентаре присутствуют другие компоненты. Например, coordinators для supervised failover или экземпляры GRPC API продукта TQE. Они не должны попасть в конфигурацию в ETCD, так как это приведет к ошибкам. Учитывайте эту особенность в своих инсталляциях.

Дополнительные переменные:

  • etcd_schema_definition (string) — Протокол используемый для передачи данных в etcd.

    • http ← (default)

  • etcd_validate_certs (string) — Наличие проверки серверного сертификата etcd.

  • etcd_client_cert (string) — Путь к ssl-сертификату используемому для установки соединения с etcd.

  • etcd_client_key (string) — Путь к ssl-ключу используемому для установки соединения с etcd.

  • etcd_ca_path (string) — Путь к ca-сертификату используемому для установки соединения с etcd.

  • etcd_tarantool_username (string) — Имя пользователя для логина в etcd.

  • etcd_tarantool_password (string) — Пароль пользователя для логина в etcd.

Tarantool 3.x: Обновление приложения без простоя

В этом сценарии с минимальным временем простоя выполняется последовательное (rolling) обновление кластера Tarantool 3.x с роутерами и stateless-экземплярами (координаторы, scheduler, grpc-сервисы).

Во время данного сценария не все экземпляры Tarantool обновляются одновременно. Процесс постепенно перезапускает экземпляры, переключая при этом роль лидера в наборах реплик. Таким образом кластер всегда остается доступен на запись. В сценарии также предусмотрено обновление экземпляров, не принадлежащих кластеру Tarantool 3.x (экземпляры scheduler, grpc-сервисы) и stateless-узлов.

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

docker run --network host -it --rm \
  -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
  -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
  -e SUPER_USER_NAME=${SUPER_USER_NAME} \
  -e STORAGE_GROUP_NAME=${STORAGE_GROUP_NAME} \
  -e PATH_TO_BACKUP_DIRECTORY=${PATH_TO_BACKUP_DIRECTORY} \
  ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
  ansible-playbook -i /ansible/inventories/hosts.yml \
  --extra-vars '{
      "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
      "super_user":"'${SUPER_USER_NAME}'",
      "tarantool_shared_become_user":"tarantool",
      "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
      "storage_group":"${STORAGE_GROUP_NAME}"
  }' \
  playbooks/continuous_update.yml

Обязательные переменные:

  • tarantool_3_0_version_support (boolean) — поддержка Tarantool 3.x. Обязательное значение – true.

    • true

    • undefined ← (default)

  • tarantool_group (string) — группа экземпляров, на которых будет проходить обновление. Если переменная не указана, обновление пройдет на всех экземплярах из файла инвентаря.

    • all ← (default)

  • storage_group (string) — группа экземпляров хранилища, которые нужно обновить. Если переменная не указана, узлы хранилища будут определены автоматически. Обновление экземпляров хранилища происходит отдельно, и эта переменная позволяет отделить такие экземпляры от остальных типов узлов в кластере.

Дополнительные переменные:

  • update_batch_size (string) — количество параллельно обновляемых узлов хранилища.

    • 1 ← (default)

  • tt_failover_status_retries (number) — количество повторных попыток для проверки статуса восстановления после отказа (failover).

    • 5 ← (default)

  • tt_failover_status_delay (number) — задержка в секундах для проверки статуса восстановления после отказа.

    • 50 ← (default)

  • schedulers_name_list (string) — список экземпляров scheduler. Данная переменная необходима, если в inventory-файле для экземпляров scheduler задана переменная replicaset_alias.

Внутри этого плейбука используются переменные из других плейбуков:

  • check_3_0

    • tarantool_wait_alive_retries (integer) — количество повторных проверок доступности экземпляра Tarantool после рестарта.

    • tarantool_wait_alive_delay (integer) — время ожидания (в секундах) между проверками доступности экземпляра.

  • tt_failower_switch

    • tt_failover_status_timeout (integer) — время ожидания в секундах выполнения команды failover switch.

    • tt_failover_status_retries (integer) — количество ретраев для запроса статуса выполнения команды failover switch.

    • tt_failover_status_delay (integer) — время ожидания в секундах выполнения команды failover status.

  • promote_leader

    • promote_timeout (integer) — время ожидания в секундах выполнения promote на инстансе.

Примечание

Данный сценарий нельзя выполнять с лимитами.

Если для scheduler в inventory-файле указан replicaset_alias, то необходимо указать переменную schedulers_name_list.

Сценарий можно применять только на кластерах с восстановлением после отказа (failover), включенным в режиме supervised или election. Подробнее про эти режимы можно прочитать в документации Tarantool.

Этапы выполнения плейбука

  1. Сбор информации о кластере и проверка его работоспособности:

    • определение порядка обновления экземпляров хранилища (storage);

    • проверка режима работы восстановления после отказа;

    • определение списка мастер-узлов, экземпляров хранилища и stateless-экземпляров.

    • проверка работоспособности всех узлов кластера Tarantool перед обновлением;

  2. Переключение мастер-узла:

    • передача роли мастера списку выбранных хостов под названием replicaset_masters_list;

    • проверка здоровья кластера после передачи роли мастера.

  3. Обновление реплик:

    • параллельное обновление списка реплик replicaset_upgrade_targets с шагом update_batch_size;

    • проверка здоровья кластера после обновления.

  4. Переключение мастера и обновление хостов предыдущих мастер-узлов. На этом этапе происходит передача роли мастера списку хостов new_masters_list, чтобы обновить хосты мастер-узлов в списке replicaset_masters_list.

  5. Параллельное обновление stateless-сервисов кроме роутеров с шагом update_batch_size.

  6. Обновление схемы данных:

    • обновление схемы данных на replicaset_masters_list и routers_list;

    • проверка здоровья кластера после обновления.

  7. Обновление списка scheduler-хостов.

  8. Финальная проверка здоровья кластера после обновления. На этом этапе идет проверка здоровья всех экземпляров Tarantool.

Tarantool 3.x: Добавление параметров SSL в динамический инвентарь

Добавлено в версии 1.13.0.

Настройте параметр iproto.listen.[0].params в соответствии с документацией Tarantool с помощью переменной tarantool_iproto_ssl_params:

---
plugin: tarantool.enterprise.generator
cluster_name: tarantool
product: tarantool

constants:
  tarantool_iproto_ssl_params:
    transport: 'ssl'
    ssl_cert_file: 'certs/server.crt'
    ssl_key_file: 'certs/server.key'
  ...

Всё, что задано в переменной tarantool_iproto_ssl_params, будет указано в конфигурации Tarantool в каждой секции <instance>.iproto.listen.[0].params «как есть». Например, указанные выше настройки будут преобразованы в следующую секцию конфигурации для всех экземпляров:

"storage-r01-i01": {
  "iproto": {
      "advertise": {
          "client": "127.0.0.1:3301"
      },
      "listen": [
          {
              "params": {
                  "ssl_cert_file": "certs/server.crt",
                  "ssl_key_file": "certs/server.key",
                  "transport": "ssl"
              },
              "uri": "127.0.0.1:3301"
          }
      ]

Задать параметр в глобальной секции конфигурации Tarantool можно аналогично другим глобальным настройкам Tarantool:

tarantool_config_global:
  iproto:
    advertise:
      peer:
        login: replicator
      sharding:
        login: storage
      client: unix/:{{ cartridge_run_dir }}/{% raw %}{{ instance_name }}{% endraw %}.iproto
    listen:
      - uri: unix/:/app/tarantool/kvee/run/{% raw %}{{ instance_name }}{% endraw %}.iproto
        params:
          ssl_cert_file: certs/server.crt
          ssl_key_file: certs/server.key
          transport: ssl

Tarantool 3.x: Включение supervised failover

Добавлено в версии 1.4.0.

Настройка failover с внешним координатором потребует изменений в инвентаре.

  1. Установите параметр replication.failover в значение supervised на одном из уровней конфигурации: tarantool_config_replicaset, tarantool_config_group, tarantool_config_global.

tarantool_config_replicaset:
  replication:
    failover: supervised
  1. Добавьте новые экземпляры и укажите для них переменную tarantool_coordinator: true.

  2. Добавьте пользователю с ролью replication привилегии для выполнения функции failover.execute.

tarantool_config_global:
  credentials:
    users:
      replicator:
        password: 'i-changed-a-password-here'
        roles: ['replication']
        privileges:
          - permissions: [execute]
            lua_call: [failover.execute]

Важно

В версиях Tarantool 3.0 и Tarantool 3.1 настройка supervised failover требует создания отдельной роли для добавления привилегий на исполнение failover.execute.

Подробности можно найти в документации.

Tarantool 3.x: Контролируемое переключение лидера для supervised failover

Добавлено в версии 1.10.0.

Важно

Может быть использован только в режиме supervised failover.

Подробнее про этот режим можно прочитать в документации Tarantool.

Примечание

Параметр LIMIT указывает, какие экземпляры Tarantool должны стать мастерами.

docker run --network host -it --rm \
  -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
  -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
  -e SUPER_USER_NAME=${SUPER_USER_NAME} \
  ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
  ansible-playbook -i /ansible/inventories/hosts.yml \
  --extra-vars '{
      "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
      "super_user":"'${SUPER_USER_NAME}'",
      "tarantool_shared_become_user":"tarantool",
      "tt_failover_status_timeout": 30,
      "tt_failover_status_retries": 3,
      "tt_failover_status_delay": 5
  }' \
  playbooks/tt_failover_switch.yml --limit ${LIMIT}

Дополнительные переменные:

  • tt_failover_status_timeout (integer) — время ожидания в секундах выполнения команды failover switch. Например: '{"tt_failover_status_timeout": 30}'.

  • tt_failover_status_retries (integer) — количество повторных попыток для запроса статуса выполнения команды failover switch. Например: '{"tt_failover_status_retries": 3}'.

  • tt_failover_status_delay (integer) — время ожидания в секундах выполнения команды failover status. Например: '{"tt_failover_status_delay": 5}'.

  • tt_ssl_key_file_path (string) — путь к клиентскому ssl-ключу. Например: '{"tt_ssl_key_file_path": "/certs/client.key"}'.

  • tt_ssl_cert_file_path (string) — путь к клиентскому ssl-сертификату. Например: '{"tt_ssl_cert_file_path": "/certs/client.crt"}'.

  • tt_ssl_ca_file_path (string) — путь к доверенному ca-сертификату. Например: '{"tt_ssl_ca_file_path": "/certs/rootCA.crt"}'.

  • tt_etcd_schema_definition (string) — Протокол используемый для передачи данных в etcd. Например: '{"tt_etcd_schema_definition": "http"}'.

  • tt_ssl_verify_host (string) — Наличие проверки серверного сертификата etcd. Например: '{"tt_ssl_verify_host": "False"}'.

  • tt_etcd_username (string) — Имя пользователя для логина в etcd.

  • tt_etcd_password (string) — Пароль пользователя для логина в etcd.

Tarantool Cartridge

Сценарии используются для развертывания, обновления, а также администрирования приложений и продуктов на основе Tarantool Cartridge (например, TDG, TDB 1.x и т.д.). Смотрите также: Примеры инвентарей Tarantool Cartridge.

Tarantool Cartridge: Первичное развертывание

Изменено в версии 1.7.0: Добавлена возможность развертывания от имени пользователя root.

Внимание

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

  • Нельзя изменять названия наборов реплик, групп и самих экземпляров.

  • Для исключения экземпляров Tarantool из кластера используйте соответствующий сценарий.

  • Добавление новых экземпляров возможно только на свободные порты и с уникальными именами.

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

Основной сценарий для развертывания приложений и продуктов на основе Tarantool Cartridge (например, TDG, TDB 1.x и т.д.). Используйте после подготовки серверов к развертыванию.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/deploy.yml

Для выполнения развертывания в system space (под пользователем root) убедитесь, что переменная tarantool_shared_become_user установлена в root и добавьте переменную systemd_scope со значением system.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"root",
        "systemd_scope":"system"
    }' \
    playbooks/deploy.yml

Дополнительные переменные:

  • tarantool_configure_logrotate (boolean) — настраивает ротацию журналов с помощью утилиты logrotate. Имеет смысл только при записи журналов или журналов аудита в файл.

    • true

    • undefined ← (default)

Tarantool Cartridge: Обновление приложения

Сценарий для обновления Tarantool Data Grid, а также приложений и продуктов на основе Tarantool Cartridge. Производит одновременный перезапуск всех экземпляров Tarantool на всех серверах. Рекомендуется использовать на тестовых контурах, если необходимо ускорить развертывание.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/update.yml

Tarantool Cartridge: Обновление приложения без простоя

Типичная топология кластеров Tarantool подразумевает наличие двух дата-центров: Активного и Резервного. Каждый набор реплик хранилища имеет одну или несколько реплик в обоих дата-центрах.

Во время данного сценария не все экземпляры Tarantool обновляются одновременно. Процесс постепенно перезапускает экземпляры в каждом из дата-центров, переключая при этом роль лидера в наборах реплик. Таким образом кластер всегда остается доступен на запись.

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

Обязательными являются переменные tarantool_active_hosts, tarantool_passive_hosts и tarantool_stateless_hosts.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e PACKAGE_NAME=${PACKAGE_NAME} \
    -e CLUSTER_IS_HEALTHY_RETRIES=100 \
    -e CLUSTER_IS_HEALTHY_DELAY=10 \
    -e UPDATE_BATCH_SIZE=2 \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "wait_members_alive_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",
        "wait_members_alive_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",
        "wait_cluster_has_no_issues_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",
        "wait_cluster_has_no_issues_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",
        "update_batch_size":"'${UPDATE_BATCH_SIZE}'",
        "tarantool_active_hosts":"'${TARANTOOL_ACTIVE}'",
        "tarantool_reserve_hosts":"'${TARANTOOL_RESERVE}'",
        "tarantool_stateless_hosts":"'${TARANTOOL_STATELESS}'"
    }' \
    playbooks/update_2x.yml

Обязательные переменные:

  • tarantool_active_hosts (string) — группа хостов, которая состоит из экземпляров Tarantool в активном дата-центре. Активным является дата-центр, который принимает пользовательские запросы и включает в себя всех лидеров наборов реплик.

  • tarantool_passive_hosts (string) — хосты, не попавшие в tarantool_active_hosts. По своей сути является группой хостов, состоящей из всех экземпляров Tarantool в резервном дата-центре.

  • tarantool_stateless_hosts (string) - все остальные экземпляры Tarantool, которые не требуют обязательного обновления по плечам, например роутеры.

  • update_batch_size (number) — количество экземпляров, которые будут обновляться одновременно.

  • wait_members_alive_retries (number) — количество проверок доступности экземпляров.

  • wait_members_alive_delay (number) — время ожидания между проверками доступности экземпляров.

  • wait_cluster_has_no_issues_retries (number) — количество проверок консистентности кластера.

  • wait_cluster_has_no_issues_delay (number) — время ожидания между проверками консистентности кластера.

Tarantool Cartridge: Доставка поставки приложения

Сценарий доставки новой версии продукта без перезапуска экземпляров.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool"
    }' \
    playbooks/update_bundle.yml

Tarantool Cartridge: Запуск модуля миграций

Сценарий запускает процесс обновления схемы данных. Аналогичен сценарию миграции для Tarantool DB.

См. подробнее про миграции в документации по Tarantool.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/migrations.yml

Tarantool Cartridge: Перезагрузка ролей

Важно

Сценарий можно применять только на подготовленных Enterprise-приложениях Tarantool Cartridge, построенных по принципу hot-reload.

Сценарий используется для обновления поставки приложения и последующей перезагрузки ролей Tarantool Cartridge для обновления без перезапуска.

Предусмотрено два вида данного сценария:

  1. reload_roles.yml – для кластера без избыточности.

    docker run --network host -it --rm \
        -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
        -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
        -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
        -e SUPER_USER_NAME=${SUPER_USER_NAME} \
        -e PACKAGE_NAME=${PACKAGE_NAME} \
        ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
        ansible-playbook -i /ansible/inventories/hosts.yml \
        --extra-vars '{
            "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
            "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
            "super_user":"'${SUPER_USER_NAME}'",
            "tarantool_shared_become_user":"tarantool",
        }' \
        playbooks/reload_roles.yml
    
  2. reload_roles_2x.yml – для кластера с избыточностью «2».

    docker run --network host -it --rm \
        -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
        -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
        -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
        -e CLUSTER_IS_HEALTHY_RETRIES=100 \
        -e CLUSTER_IS_HEALTHY_DELAY=10 \
        -e UPDATE_BATCH_SIZE=2 \
        -e SUPER_USER_NAME=${SUPER_USER_NAME} \
        -e PACKAGE_NAME=${PACKAGE_NAME} \
        ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
        ansible-playbook -i /ansible/inventories/hosts.yml \
        --extra-vars '{
            "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
            "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
            "super_user":"'${SUPER_USER_NAME}'",
            "tarantool_shared_become_user":"tarantool",
            "wait_members_alive_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",
            "wait_members_alive_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",
            "wait_cluster_has_no_issues_retries":"'${CLUSTER_IS_HEALTHY_RETRIES}'",
            "wait_cluster_has_no_issues_delay":"'${CLUSTER_IS_HEALTHY_DELAY}'",
            "update_batch_size":"'${UPDATE_BATCH_SIZE}'",
            "tarantool_active_hosts":"'${TARANTOOL_ACTIVE}'",
            "tarantool_reserve_hosts":"'${TARANTOOL_RESERVE}'",
            "tarantool_stateless_hosts":"'${TARANTOOL_STATELESS}'"
        }' \
        playbooks/reload_roles_2x.yml
    

Обязательные переменные:

  • tarantool_active_hosts (string) — группа хостов, которая состоит из экземпляров Tarantool в активном дата-центре. Активным является дата-центр, который принимает пользовательские запросы и включает в себя всех лидеров наборов реплик.

  • tarantool_passive_hosts (string) — хосты, не попавшие в tarantool_active_hosts. По своей сути является группой хостов, состоящей из всех экземпляров Tarantool в резервном дата-центре.

  • tarantool_stateless_hosts (string) - все остальные экземпляры Tarantool, которые не требуют обязательного обновления по плечам, например роутеры.

  • update_batch_size (number) — количество экземпляров, которые будут обновляются одновременно.

  • wait_members_alive_retries (number) — количество проверок доступности экземпляров.

  • wait_members_alive_delay (number) — время ожидания между проверками доступности экземпляров.

  • wait_cluster_has_no_issues_retries (number) — количество проверок консистентности кластера.

  • wait_cluster_has_no_issues_delay (number) — время ожидания между проверками консистентности кластера.

Tarantool Cluster Manager

Смотрите также: Примеры инвентарей TCM.

Tarantool Cluster Manager: Установка и запуск

Добавлено в версии 1.1.0.

Сценарий предназначен для развертывания, настройки и запуска продукта Tarantool Cluster Manager.

Команда для запуска сценария с помощью Docker-образа:

  • PATH_TO_PACKAGE - путь до директории с архивами.

  • TCM_PACKAGE_NAME — имя архива с поставкой Tarantool Cluster Manager.

  • HOSTS - указание группы хостов TCM, например clusters-manager из примера инвентаря.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/tcm.yml:Z \
    -v ${PATH_TO_PACKAGE}/${TCM_PACKAGE_NAME}:/ansible/packages/${TCM_PACKAGE_NAME}:Z \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/tcm.yml \
    --extra-vars '{
        "tcm_package_path":"/ansible/packages/'${TCM_PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tcm/install.yml

Tarantool Cluster Manager: Перезапуск

Добавлено в версии 1.1.0.

Команда для запуска сценария с помощью Docker-образа:

  • HOSTS - указание группы хостов TCM, например clusters-manager из примера инвентаря.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/tcm.yml:Z \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/tcm.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tcm/restart.yml

Tarantool Data Grid

Для развертывания, обновления и администрирования TDG используются сценарии из разделов Tarantool Cartridge и Общие сценарии администрирования. Смотрите также: Примеры инвентарей TDG.

Tarantool Data Grid: Обновление конфигурации

В продукте Tarantool Data Grid бизнес-логика поставляется в виде архива с конфигурацией. Этот сценарий загружает конфигурацию в кластер TDG.

  • TDG_CONFIG_DIR — полный путь к директории с конфигурациями TDG.

  • TDG_CONFIG_NAME — имя архива с конфигурацией, например my-app-config-1.0.0.zip.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${TDG_CONFIG_DIR}/${TDG_CONFIG_NAME}:/ansible/packages/${TDG_CONFIG_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e TDG_CONFIG_NAME=${TDG_CONFIG_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_app_config_path":"/ansible/packages/'${TDG_CONFIG_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/tdg_config.yml

Tarantool Data Grid: Включение режима разработчика

Добавлено в версии 1.4.0.

Сценарий используется для включения (и отключения) режима разработчика в Tarantool Data Grid.

Сценарий может запускаться без лимита.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tdg_dev_mode":"true"
    }' \
    playbooks/switch_tdg_mode.yml

Обязательные переменные:

  • tdg_dev_mode (string) - флаг управления режимом разработчика: false (по умолчанию) - выключить DEV_MODE, true - включить DEV_MODE;

Важно

Для того что бы изменения вступили в силу, необходимо перезапустить экземпляр(ы) после вызова сценария switch_tdg_mode.yml.

Tarantool DB

Для развертывания, обновления и администрирования Tarantool DB используются следующие сценарии:

Смотрите также: Примеры инвентарей TDB.

Tarantool DB 1.x: Запуск модуля миграций

Сценарий предназначен исключительно для продукта Tarantool DB 1.x. Сценарий запускает процесс обновления схемы данных. Аналогичен сценарию миграции для Tarantool Enterprise Edition.

Подробная информация о миграциях приведена в документации по Tarantool и Tarantool DB.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/migrations.yml

Tarantool DB 1.x: Загрузка кода миграций через конфигурацию

Сценарий предназначен исключительно для продукта Tarantool DB 1.x. Сценарий загружает код миграций на Lua через конфигурацию кластера.

Важно

После выполнения данного сценария необходимо запустить миграции. См. сценарий Tarantool DB: Запуск модуля миграций.

  • PATH_TO_MIGRATIONS — путь до директории с миграциями на Lua.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_MIGRATIONS}:/ansible/migrations \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_migrations_directory":"/ansible/migrations/"
    }' \
    playbooks/upload_migrations.yml --limit ${LIMIT}

Обязательные переменные:

  • tarantool_migrations_directory (string) — директория c DDL-миграциями.

Tarantool Queue Enterprise (MQ)

Для развертывания Tarantool Queue Enterprise используются следующие сценарии:

Для обновления и администрирования TQE используются следующие сценарии:

Смотрите также: Примеры инвентарей TQE.

Tarantool Queue Enterprise (MQ): Установка кластерного приложения Tarantool 3.x с модулем API

Добавлено в версии 1.5.0.

  • Для установки кластерного приложения TQE на Tarantool 3.x используйте сценарий install_tqe_3_0.yml.

  • Для установки API TQE на Tarantool 3.x используйте сценарий install_api_3_0.yml.

Сценарий для установки и настройки продукта TQE (версия 1.10 и выше) и модуля Message Queue install_3_0.yml.

  • PATH_TO_INVENTORY — путь до файла.

  • PATH_TO_TQE_PACKAGE - путь до артефакта.

  • TQE_PACKAGE_NAME — имя архива с поставкой Tarantool Queue Enterprise.

  • HOSTS - группа хостов хранилищ очереди и API модуля.

Важно

В инвентаре задайте хостам API модуля переменную tarantool_grpc в значение true.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_TQE_PACKAGE}:/ansible/packages/${TQE_PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e TQE_PACKAGE_NAME=${TQE_PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${TQE_PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tqe/install_3_0.yml

Tarantool Queue Enterprise (MQ): Установка кластерного приложения Tarantool Cartridge

Добавлено в версии 1.0.0.

Изменено в версии 1.1.0: Добавлен пример инвентаря.

Изменено в версии 1.5.0: Сценарии install_tqe.yml и install_tqe_api.yml функционируют до версии TQE 1.10 на Tarantool Cartridge.

Сценарий для установки и настройки продукта TQE и модуля Message Queue.

  • PATH_TO_INVENTORY — путь до файла.

  • PATH_TO_TQE_PACKAGE - путь до артефакта.

  • TQE_PACKAGE_NAME — имя архива с поставкой Tarantool Queue Enterprise.

  • HOSTS - группа хостов хранилищ очереди.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_TQE_PACKAGE}:/ansible/packages/${TQE_PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e TQE_PACKAGE_NAME=${TQE_PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${TQE_PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tqe/install_tqe.yml

Tarantool Queue Enterprise (MQ): Установка модуля API для Tarantool Cartridge

Добавлено в версии 1.0.0.

Изменено в версии 1.5.0: Добавлена переменная tqe_binary_name.

  • tqe_binary_name - путь до исполняемого файла модуля API. Значение по умолчанию: bin/message-queue-ee.

({{ cartridge_app_instances_dir }}/{{ cartridge_app_name }}.{{ inventory_hostname }}/{{ tqe_binary_name }})

Сценарий для установки и настройки API части продукта Tarantool Queue Enterprise.

  • PATH_TO_INVENTORY — путь до файла инвентаря.

  • PATH_TO_TQE_PACKAGE - путь до артефакта.

  • TQE_PACKAGE_NAME — имя архива с поставкой Tarantool Queue Enterprise.

  • HOSTS - группа API-хостов.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_TQE_PACKAGE}:/ansible/packages/${TQE_PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e TQE_PACKAGE_NAME=${TQE_PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "cartridge_package_path":"/ansible/packages/'${TQE_PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tqe/install_tqe_api.yml

Tarantool Clusters Federation

Смотрите также: Примеры инвентарей TCF.

Tarantool Clusters Federation: Установка и запуск

Изменено в версии 1.1.0: Сценарий переименован в tarantool.enterprise.tcf.install.

Изменено в версии 1.2.0: Изменено имя параметра конфигурации prometheus для Destination на http_server. Добавлена настройка logrotate для логов TCF.

Добавлено в версии 1.10.0: Добавлена возможность указать SSL-сертификаты для компонентов Destination и Gateway.

Добавлено в версии 1.11.0: Добавлена возможность указать alias для метрик компонентов Destination и Gateway (доступно с TCF 0.8.0). Добавлена возможность указать параметры truncate_collect_timeout и truncate_buffer_size в Destination для настройки выполнения операции TRUNCATE (доступно с TCF 0.9.0).

Добавлено в версии 1.11.0: Добавлена возможность включить метрики для компонента Gateway.

Добавлено в версии 1.11.0: Добавлены переменные tcf_authorization_provider и tcf_authorization_provider_params.

Сценарий предназначен для развертывания и настройки продукта Tarantool Clusters Federation. Tarantool Clusters Federation имеет собственный инвентарь, в котором описываются подключения к двум независимым кластерам Tarantool.

Стенд с Tarantool Clusters Federation состоит из кластеров Tarantool, межкластерных репликаторов данных (компоненты Gateway и Destination) и хранилища конфигурации и состояния кластеров (etcd). Обратите внимание, что перед запуском данного сценария необходимо развернуть:

  • кластер etcd для хранения конфигурации и состояния кластеров;

  • кластеры Tarantool, поверх которых будет запущен Tarantool Clusters Federation.

Порядок действий:

  1. Установите TCF:

    • PATH_TO_INVENTORY — путь до файла инвентаря приложения на Tarantool EE.

    • PATH_TO_TCF_INVENTORY — путь до файла инвентаря самого TCF.

    • TCF_PACKAGE_NAME — имя архива с поставкой Tarantool Clusters Federation.

    • HOSTS - указание группы хостов TCF, например tcf из примера инвентаря.

    docker run --network host -it --rm \
        -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
        -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
        -v ${PATH_TO_TCF_INVENTORY}:/ansible/inventories/tcf.yml:Z \
        -v ${PATH_TO_TCF_PACKAGE}:/ansible/packages/${TCF_PACKAGE_NAME}:Z \
        -e SUPER_USER_NAME=${SUPER_USER_NAME} \
        -e TCF_PACKAGE_NAME=${TCF_PACKAGE_NAME} \
        ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
        ansible-playbook \
        -i /ansible/inventories/tcf.yml \
        -i /ansible/inventories/hosts.yml \
        --extra-vars '{
            "tcf_package_path":"/ansible/packages/'${TCF_PACKAGE_NAME}'",
            "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
            "super_user":"'${SUPER_USER_NAME}'",
            "tarantool_shared_become_user":"tarantool",
            "tarantool_shared_hosts":"'${HOSTS}'",
        }' \
        playbooks/tcf/install.yml
    

    Сценарий также настраивает автоматическую ротацию журналов. Настройку ротации можно отключить, если выставить значение переменной tarantool_configure_logrotate в false.

  2. После установки TCF настройте кластерные приложения. Для этого выполните сценарий Изменение настроек кластера (сценарий settings.yml).

    • Для кластеров Tarantool 2.x на основе Cartridge необходимо добавить в инвентарь каждого из кластеров секцию cartridge_app_config.cluster_federation. Пример:

      cartridge_app_config:
        cluster_federation:
          body:
            cluster_1: cluster_a
            cluster_2: cluster_b
            initial_status: active
            replication_password: "password"
            replication_user: replicator
            failover_timeout: 6
            max_suspect_counts: 3
            health_check_delay: 1
      

      Здесь:

      • собственное имя кластера равно значению параметра cluster_1.

      • параметры replication_user и replication_password должны соответствовать значениям tcf_user и tcf_user_password из инвентаря TCF.

      Значения параметров cluster_1 и cluster_2 должны быть зеркальными, то есть на втором кластере конфигурация будет следующая:

      cartridge_app_config:
        cluster_federation:
          body:
            cluster_1: cluster_b
            cluster_2: cluster_a
            initial_status: active
            replication_password: "password"
            replication_user: replicator
            failover_timeout: 6
            max_suspect_counts: 3
            health_check_delay: 1
      
    • Для кластеров на основе Tarantool 3.x необходимо добавить в инвентарь каждого из кластеров секции с настройками ролей roles.tcf-coordinator (задается на роутерах) и roles.tcf-worker (задается на всех узлах). Пример:

      roles_cfg:
        roles.tcf-worker:
          cluster_1: cluster_a
          cluster_2: cluster_b
          initial_status: active
          dml_users: [ tcf-dml ]
          replication_user: tcf-replicator
          replication_password: secret
          status_ttl: 4
          enable_system_check: true
        roles.tcf-coordinator:
          failover_timeout: 20
          health_check_delay: 2
          max_suspect_counts: 3
      

      Здесь:

      • собственное имя кластера равно значению параметра cluster_1.

      • параметры replication_user и replication_password должны соответствовать значениям tcf_user и tcf_user_password из инвентаря TCF.

      Значения параметров cluster_1 и cluster_2 должны быть зеркальными, то есть на втором кластере конфигурация будет следующая:

      roles_cfg:
        roles.tcf-worker:
          cluster_1: cluster_b
          cluster_2: cluster_a
          initial_status: passive
          dml_users: [ tcf-dml ]
          replication_user: tcf-replicator
          replication_password: secret
          status_ttl: 4
          enable_system_check: true
        roles.tcf-coordinator:
          failover_timeout: 20
          health_check_delay: 2
          max_suspect_counts: 3
      

Добавлено в версии 1.14.0: Добавлена поддержка TQE 3.x при отсутствии в инвентаре секций конфигурации grpc_port и publisher.

Поддержка TQE 3.x предназначена для работы с новым форматом конфигурации.

Определение режима конфигурации (legacy vs new):

  • Старый формат — ATE считает, что нужно сформировать конфигурацию TQE 2.x, если в конфигурации кластера TQE указаны секции grpc_port, grpc_host или publisher.

  • Новый формат — используется, если в конфигурации отсутствуют маркеры старого формата (grpc_port и publisher), даже если секция consumer не задана.

Поведение в режимах

Старый режим

  • если не указана секция конфигурации publisher.queues.*.connections, ATE автоматически заполнит её, используя адреса указанных в инвентаре роутеров;

  • если не указана секция конфигурации consumer.queues.*.connections, ATE автоматически заполнит её, используя адреса указанных в инвентаре узлов типа storage;

  • cовместимость с параметрами grpc_host и grpc_port обеспечивается автоматически.

Новый режим

  • если не указана секция конфигурации producer.tarantool.connections, ATE автоматически заполнит её адресами роутеров (routers);

  • если не указана секция конфигурации consumer.tarantool.connections, ATE автоматически заполнит её адресами узлов типа storage;

  • cекции producer.queues.* и consumer.queues.* наследуют базовые connections, если собственные подключения не заданы;

  • автоматически добавляются значения по умолчанию для параметров grpc_options и log.level.

Tarantool Clusters Federation: Пример инвентаря

Изменено в версии 1.1.0: Добавлен пример инвентаря.

Добавлено в версии 1.10.0: Добавлен пример указания SSL-сертификатов для компонентов Destination и Gateway.

Добавлено в версии 1.11.0: Добавлен пример указания alias для метрик компонентов Destination и Gateway. Добавлен пример указания опций truncate_collect_timeout и truncate_buffer_size для компонента Destination.

Добавлено в версии 1.11.0: Добавлена возможность указать destination.gateway.dial_timeout с помощью переменной tcf_dial_timeout в инвентаре.

Добавлено в версии 1.13.0: Добавлена поддержка параметра destination.gateways компонента Destination через переменную tcf_gateways

Добавлена поддержка параметров destination.storage и destination.storage_params.

Инвентарь представлен для топологии, где есть два кластера: Cluster A и Cluster B. TCF настроен на двустороннюю синхронизацию изменений.

Важно

Группы gateway и destination обязательны. Они отвечают за тип экземпляра TCF соответственно и используются во всех сценариях.

Для настройки безопасного соединения на протоколах GRPC и HTTP добавьте следующие три переменные в инвентарь:

tcf_ssl_cert_file: /path/to/server.crt
tcf_ssl_key_file: /path/to/server.key
tcf_ssl_ca_file: /path/to/ca.crt

Для настройки лейбла alias метрик компонентов Gateway и Destination (доступно с TCF 0.8.0) добавьте следующие переменные в инвентарь:

tcf_gateway_alias: gateway_a_b
tcf_destination_alias: destination_a_b

Для указания экземпляров компонента Gateway добавьте следующие переменные в инвентарь:

tcf_gateways:
  - host: gateway-a.example.org
    port: 8080
  - host: gateway-b.example.org
    port: 8080

Для подключения Destination к хранилищу добавьте следующие переменные в инвентарь:

tcf_destination_storage: etcd_v2
tcf_destination_storage_endpoints:
  - host: "{{ tarantool_etcd_host }}"
    port: 2379
tcf_destination_storage_prefix: /tcf
tcf_destination_storage_ttl: 30

Для настройки опций truncate_collect_timeout и truncate_buffer_size компонента Destination (доступно с TCF 0.9.0) добавьте следующие переменные в инвентарь:

tcf_destination_truncate_collect_timeout: '1m'
tcf_destination_truncate_buffer_size: 100000
  • tcf_destination_truncate_collect_timeout — это время, за которое ожидается получение события truncate с каждого из шардов кластера-источника, начиная с первого такого события. Тип значения - строка в формате число с единицей измерения (s - секунды, m - минуты, h - часы и т.д.).

  • tcf_destination_truncate_buffer_size - размер буфера с событиями, собираемые после операции TRUNCATE, которые будут применены после его выполнения. Тип значения - число, измеряется в количестве событий.

Для настройки авторизации на TCF Gateway/Destination, укажите в инвентаре TCF следующие параметры. Обратите внимание, что эти параметры будут добавлены ко всем Destination и Gateway. Для настройки воркеров кластера, передайте нужную настройку в конфигурацию кластера, как показано ниже.

tcf_authorization_provider: "keycloak"
tcf_authorization_provider_params:
   provider_params:
     url: "https://keycloak.example.com/"
     roles:
       info: ORDERDB_TCF_INFO     # default TCF_INFO
       toggle: ORDERDB_TCF_TOGGLE # default TCF_TOGGLE
       admin: ORDERDB_TCF_ADMIN   # default TCF_ADMIN
     ssl:
       ca_file: "/etc/ssl/certs/keycloak-ca.pem"
       cert_file: "/etc/ssl/certs/client.pem"
       key_file: "/etc/ssl/private/client-key.pem"

Если необходимо включить авторизацию для воркера, укажите её в соответствии с документацией TCF наравне с остальной конфигурацией: Чтобы настроить шифрование для исходящих запросов HTTP, если включена авторизация на репликаторе (Gateway/Destination), раскомментируйте параметры client_id, client_secret_path, realm:

roles_cfg:
  roles.tcf-worker:
    authorization:
      provider: keycloak
      provider_params:
        url: "https://keycloak.example.com/"
        roles:
          info: ORDERDB_TCF_INFO     # default TCF_INFO
          toggle: ORDERDB_TCF_TOGGLE # default TCF_TOGGLE
          admin: ORDERDB_TCF_ADMIN   # default TCF_ADMIN
        ssl:
          ca_file: "/etc/ssl/certs/keycloak-ca.pem"
          cert_file: "/etc/ssl/certs/client.pem"
          key_file: "/etc/ssl/private/client-key.pem"
        # client_id: "client"
        # client_secret_path: "/path/to/file"
        # realm: "myrealm"

Или в случае работы с Cartridge:

cartridge_app_config:
  clusters_federation:
    authorization:
      provider: keycloak
      provider_params:
        url: "https://keycloak.example.com/"
        roles:
          info: ORDERDB_TCF_INFO     -- default TCF_INFO
          toggle: ORDERDB_TCF_TOGGLE -- default TCF_TOGGLE
          admin: ORDERDB_TCF_ADMIN   -- default TCF_ADMIN
        ssl:
          ca_file: "/etc/ssl/certs/keycloak-ca.pem"
          cert_file: "/etc/ssl/certs/client.pem"
          key_file: "/etc/ssl/private/client-key.pem"
        # client_id: "client"
        # client_secret_path: "/path/to/file"
        # realm: "myrealm"

Tarantool Clusters Federation: Обновление

Добавлено в версии 1.1.0.

Сценарий предназначен для обновления версии продукта Tarantool Clusters Federation. После развертывания новой версии происходит перезапуск всех экземпляров TCF.

  • PATH_TO_INVENTORY — путь до файла инвентаря приложения на Tarantool EE.

  • PATH_TO_TCF_INVENTORY — путь до файла инвентаря самого TCF.

  • TCF_PACKAGE_NAME — имя архива с поставкой Tarantool Clusters Federation.

  • HOSTS - указание группы хостов TCF, например tcf из примера инвентаря.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -v ${PATH_TO_TCF_INVENTORY}:/ansible/inventories/tcf.yml:Z \
    -v ${PATH_TO_TCF_PACKAGE}:/ansible/packages/${TCF_PACKAGE_NAME}:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    -e TCF_PACKAGE_NAME=${TCF_PACKAGE_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook \
    -i /ansible/inventories/tcf.yml \
    -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "tcf_package_path":"/ansible/packages/'${TCF_PACKAGE_NAME}'",
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tcf/update.yml

Tarantool Clusters Federation: Перезапуск

Добавлено в версии 1.1.0.

Сценарий предназначен для перезапуска всех экземпляров Tarantool Clusters Federation.

  • PATH_TO_TCF_INVENTORY — путь до файла инвентаря самого TCF.

  • TCF_PACKAGE_NAME — имя архива с поставкой Tarantool Clusters Federation.

  • HOSTS - указание группы хостов TCF, например tcf из примера инвентаря.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_TCF_INVENTORY}:/ansible/inventories/tcf.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook \
    -i /ansible/inventories/tcf.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tcf/restart.yml --limit ${LIMIT}

Значение LIMIT может быть, например, tcf-host-3 – экземпляр типа gateway из примера.

Примечание

Если требуется перезапустить только репликатор данных Destination, обратитесь к разделам Перезапуск репликатора и Перезапуск репликатора с повторной инициализацией в руководстве администратора TCF.

Tarantool Clusters Federation: Остановка

Добавлено в версии 1.1.0.

Сценарий предназначен для остановки всех экземпляров Tarantool Clusters Federation.

  • PATH_TO_TCF_INVENTORY — путь до файла инвентаря самого TCF.

  • TCF_PACKAGE_NAME — имя архива с поставкой Tarantool Clusters Federation.

  • HOSTS - указание группы хостов TCF, например tcf из примера инвентаря.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_TCF_INVENTORY}:/ansible/inventories/tcf.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \
    ansible-playbook \
    -i /ansible/inventories/tcf.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
        "tarantool_shared_hosts":"'${HOSTS}'",
    }' \
    playbooks/tcf/stop.yml --limit ${LIMIT}

Tarantool Column Store

Для развертывания Tarantool Column Store используется сценарий из раздела Tarantool Column Store: Установка приложения. Для обновления и администрирования TCS используются сценарии из разделов Tarantool 3.x и Общие сценарии администрирования.

Смотрите также: Примеры инвентарей TCS.

Tarantool Column Store: Установка приложения

Добавлено в версии 1.2.0.

Изменено в версии 1.4.1: Сценарий установки работает для версии TCS на Tarantool 3.x.

Продукт TCS состоит из кластера Tarantool 3.x и API-сервиса под названием Scheduler. Каждый компонент развертывается отдельно.

Порядок действий:

  1. Установите кластерное хранилище.

    • PATH_TO_INVENTORY — путь до файла инвентаря.

    • PATH_TO_PACKAGE - путь до артефакта.

    • PACKAGE_NAME — имя архива с поставкой Tarantool Column Store.

    • HOSTS - группа хостов кластерного хранилища.

    docker run --network host -it --rm \
        -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
        -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
        -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
        -e SUPER_USER_NAME=${SUPER_USER_NAME} \
        -e PACKAGE_NAME=${PACKAGE_NAME} \
        ansible-tarantool-enterprise:latest \
        ansible-playbook -i /ansible/inventories/hosts.yml \
        --extra-vars '{
            "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
            "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
            "super_user":"'${SUPER_USER_NAME}'",
            "tarantool_shared_become_user":"tarantool",
            "tarantool_shared_hosts":"'${HOSTS}'",
        }' \
        playbooks/tcs/install.yml
    

Добавлено в версии 1.12.0: Добавлены переменные для установки TCS 1.x

  • tcs_v1_support (bool) - установите значение true, если используете динамический инвентарь для установки TCS 1.x.

  • tcs_http_credentials (object) - задайте username и password для секции конфигурации roles_cfg.app/aggregator_role.http.credentials, если используете динамический инвентарь для установки TCS 1.x.

  • tcs_sql_credentials (object) - задайте username и password для секции конфигурации roles_cfg.app/aggregator_role.arrow_flight_sql.credentials, если используете динамический инвентарь для установки TCS 1.x.

  • tcs_http_enabled (bool) - задайте значение false, если хотите отключить поддержку http-запросов для TCS. Значение по умолчанию: true.

  1. Только для версии < 1.0. Запустите сценарий установки API-сервиса. Он входит в поставку TCS и устанавливается из того же артефакта.

    Обратите внимание на переменную tarantool_shared_hosts: она указывает, какие из хостов в инвентаре являются API-сервисами. Можно указать группу.

    • HOSTS - группа API сервисов.

    docker run --network host -it --rm \
        -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
        -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
        -v ${PATH_TO_PACKAGE}:/ansible/packages/${PACKAGE_NAME}:Z \
        -e SUPER_USER_NAME=${SUPER_USER_NAME} \
        -e PACKAGE_NAME=${PACKAGE_NAME} \
        ansible-tarantool-enterprise:latest \
        ansible-playbook -i /ansible/inventories/hosts.yml \
        --extra-vars '{
            "cartridge_package_path":"/ansible/packages/'${PACKAGE_NAME}'",
            "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
            "super_user":"'${SUPER_USER_NAME}'",
            "tarantool_shared_become_user":"tarantool",
            "tarantool_shared_hosts":"'${HOSTS}'",
        }' \
        playbooks/tcs/install_scheduler.yml
    

Изменено в версии 1.14.0: Добавлены новые способы расширения конфигурации API-сервиса Scheduler: tcs_additional_config и tcs_scheduler_config_template.

  • tcs_additional_config (object) — дополнительные опции конфигурации, которые автоматически добавляются в конец сгенерированного YAML-конфига Scheduler. Поддерживаются словарь или список (mapping/sequence), которые сериализуются в YAML.

  • tcs_scheduler_config_template (string, путь к Jinja2-шаблону на контроллере) — полностью заменяет встроенный шаблон конфигурации Scheduler. Если переменная задана, роль использует указанный файл вместо roles/tcs/templates/tcs-scheduler-config.yml.j2.

Пример указания переменных tcs_additional_config и tcs_scheduler_config_template в динамическом инвентаре

constants:
  tcs_additional_config:
    metadata:
      environment: "test"
      generated_by: "ATE"

  tcs_scheduler_config_template: "/home/user/custom-templates/my-scheduler.yml.j2"

Tarantool Column Store 0.x: Пример инвентаря

Добавлено в версии 1.2.0.

Изменено в версии 1.4.0: Изменены имена полей конфигурации для версий TCS 0.15.1 и новее. depth -> index_depth, should_index -> indexed, arrow_data_type -> data_type.

Добавлено в версии 1.10.0: Добавлена возможность использования параметров features и metrics в scheduler. Features можно задавать в переменной tcs_scheduler_features через список (tcs_scheduler_features: [«experimental_api»]). Дополнительно включать/выключать features можно через переменную tcs_scheduler_features_enabled, если в переменной tcs_scheduler_features не заданы features то tcs_scheduler_features_enabled автоматически становится в значени$ Метрики также можно включать/выключать через переменную tcs_scheduler_metrics_enabled.

Изменено в версии 1.10.0: TCS обновлен до версии 0.27.0, поддержка версий младше 0.27 не гарантируется.

Tarantool Column Store 1.x: Пример динамического инвентаря

Примечание

Текущий пример и пример статического инвентаря можно найти в разделе «Примеры инвентарей».

Примечание

Обратите внимание, для корректной генерации инвентаря TCS 1.x необходимо указать переменную tcs_v1_support: true.

---
plugin: tarantool.enterprise.generator
cluster_name: tarantool
product: TCS

constants:
  ansible_ssh_common_args: -o IdentitiesOnly=yes -o UserKnownHostsFile=/dev/null
    -o StrictHostKeyChecking=no
  cartridge_app_name: tcs
  tarantool_etcd_host: "{{ tarantool_etcd_host }}"
  tcs_v1_support: true
  tcs_storage_group_name: aggregator
  tcs_storage_replicaset_name: aggregator-r01
  tarantool_wait_alive_delay: 2
  tarantool_wait_alive_retries: 50
  cartridge_extra_env:
    TCS_REPL_PASS: super-secret
  tcs_extra_env:
    TOKIO_WORKER_THREADS: 1
  tarantool_config_global:
    fiber:
      slice:
        err: 15
    credentials:
      users:
        replicator:
          password: "{% raw %}{{ context.replicator_password }}{% endraw %}"
          roles: [replication]
          privileges:
            - permissions: [execute]
              functions: [failover.execute]
        client:
          password: 'secret'
          roles: [super]
    memtx:
      memory: 114748364
    config:
      context:
        replicator_password:
          from: env
          env: TCS_REPL_PASS
    iproto:
      advertise:
        peer:
          login: 'replicator'
    compat:
      box_error_serialize_verbose: "new"
    failover:
      call_timeout: 1
      connect_timeout: 1
      lease_interval: 10
      probe_interval: 1
      renew_interval: 10
      stateboard:
        keepalive_interval: 15
        renew_interval: 3

servers:
  - name: 'vm_1'
    host: '{{ tarantool_ansible_host }}'
    advertise_host: '127.0.0.1'
    port: 2201
    user: '{{ super_user }}'
    zone: 'DC2'
    port_starts:
      iproto: 3444
      http: 8091

components:
  - name: coordinator
    replicasets: 1
    replicas: 2
  - name: aggregator
    replicasets: 1
    replicas: 2
    port_starts:
      http_streaming: 9081
    config:
      aggregator:
        rv_update_ms: 100
      replicaset:
        replication:
          failover: supervised
      group:
        roles: [app/aggregator_role, app/etcd_stateboard_client]
        roles_cfg:
          app/aggregator_role:
            tcs:
              aggregator:
                rv_update_ms: 100

Tarantool Column Store: Перезапуск экземпляров Scheduler API

Добавлено в версии 1.2.0.

  • LIMIT - группа хостов или индивидуальный хост, который вы хотите перезапустить.

docker run --network host -it --rm \
    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \
    -v ${PATH_TO_INVENTORY}:/ansible/inventories/hosts.yml:Z \
    -e SUPER_USER_NAME=${SUPER_USER_NAME} \
    ansible-tarantool-enterprise:latest \
    ansible-playbook -i /ansible/inventories/hosts.yml \
    --extra-vars '{
        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",
        "super_user":"'${SUPER_USER_NAME}'",
        "tarantool_shared_become_user":"tarantool",
    }' \
    playbooks/tcs/restart.yml --limit ${LIMIT}
Нашли ответ на свой вопрос?
Обратная связь