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

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

• SUPER_USER_NAME — имя пользователя для SSH-подключения.
• PATH_TO_PRIVATE_KEY — полный путь к приватному ключу.
• PATH_TO_INVENTORY — полный путь к файлу инвентаря.
• PATH_TO_PACKAGE — полный путь к архиву с приложением.
• PACKAGE_NAME — имя архива с приложением.
• DEPLOY_TOOL_VERSION_TAG — версия инсталлятора.
• LIMIT — указание для Ansible, на каких хостах или группах хостов производить действия.

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

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

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

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

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

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

• global -- общая переменная tarantool_config_global.
• group -- tarantool_config_group на уровне Ansible-групп.
• replicaset -- tarantool_config_replicaset на том же уровне Ansible-групп, где определена переменная replicaset_alias.
• instance -- собственные переменные у хоста.

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

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

Основной сценарий для развертывания приложений и продуктов на основе 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 '{        "tarantool_package_path":"/ansible/packages/'${PACKAGE_NAME}'",        "ansible_ssh_private_key_file":"/ansible/.ssh/id_private_key",        "super_user":"'${SUPER_USER_NAME}'"    }' \    playbooks/install.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 '{        "tarantool_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.yml

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

Обязательно укажите адреса серверов ETCD в переменной tarantool_config_storage_endpoints. Адреса должны быть доступны с сервера, на котором разворачиваются экземпляры 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/configure.yml --limit ${HOSTS}

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

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

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

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

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

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

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

Данный сценарий аналогичен отправке конфигурации в ETCD, но используется для кластеров, где в качестве хранилища конфигурации используется Tarantool-based Configuration Storage (TbCS).

Обязательно укажите переменную tarantool_config_storage со значением 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_config_storage":"tarantool"    }' \    playbooks/configure.yml --limit ${HOSTS}

В этом сценарии с минимальным временем простоя выполняется последовательное (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} \    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",        "tarantool_package_path":"/ansible/packages/'${PACKAGE_NAME}'",        "storage_group":"${STORAGE_GROUP_NAME}",        "tarantool_replication_sync_check_enabled": true    }' \    playbooks/continuous_update.yml

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

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

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

• tarantool_replication_sync_check_enabled (boolean) — включает проверку синхронизации перед переключением мастера.
  • false ← (default)
• update_batch_size (string) — количество параллельно обновляемых узлов хранилища.
  • 1 ← (default)
• tt_failover_status_retries (number) — количество повторных попыток для проверки статуса восстановления после отказа (failover).
  • 5 ← (default)
• tt_failover_status_delay (number) — задержка в секундах для проверки статуса восстановления после отказа.
  • 50 ← (default)
• tarantool_replication_sync_retries (number) — количество попыток проверки синхронизации репликации перед переключением мастера.
  • 120 ← (default)
• tarantool_replication_sync_delay (number) — задержка в секундах между попытками проверки синхронизации репликации.
  • 5 ← (default)
• tarantool_replication_sync_max_lag (number) — максимальный допустимый модуль лага репликации на целевом экземпляре перед переключением, в секундах. Временной лаг не равен расхождению количества строк.
  • 1 ← (default)
• schedulers_name_list (string) — список экземпляров scheduler. Данная переменная необходима, если в inventory-файле для экземпляров scheduler задана переменная replicaset_alias.

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

• check
  • tarantool_wait_alive_retries (integer) — количество повторных проверок доступности экземпляра Tarantool после рестарта.
  • tarantool_wait_alive_delay (integer) — время ожидания (в секундах) между проверками доступности экземпляра.
• wait_replication_sync.yml
  • tarantool_replication_sync_retries (number) — количество попыток проверки синхронизации репликации.
  • tarantool_replication_sync_delay (number) — задержка в секундах между попытками проверки синхронизации репликации.
  • tarantool_replication_sync_max_lag (number) — максимальный допустимый модуль лага репликации на целевом экземпляре в секундах.
• switch_leader (supervised failover)
  • tt_failover_status_timeout (integer) — время ожидания в секундах выполнения команды failover switch.
  • tt_failover_status_retries (integer) — количество ретраев для запроса статуса выполнения команды failover switch.
  • tt_failover_status_delay (integer) — время ожидания в секундах выполнения команды failover status.
• switch_leader (election)
  • promote_timeout (integer) — время ожидания в секундах выполнения promote на экземпляре.

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

   • определение порядка обновления экземпляров хранилища (storage);
   • проверка режима работы восстановления после отказа;
   • определение списка мастер-узлов, экземпляров хранилища и stateless-экземпляров.
   • проверка работоспособности всех узлов кластера Tarantool перед обновлением;

2. Перед переключением дождаться, чтобы на целевом экземпляре все существующие upstream-соединения имели статус follow, а модуль лага был меньше tarantool_replication_sync_max_lag. RO-экземпляр без upstream-соединений не проходит проверку, RW-экземпляр без них проходит без ожидания. При превышении времени ожидания переключение не выполняется; записи приложения при проверке не блокируются.

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

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

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

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

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

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

7. Ожидание синхронизации данных между мастером и обновленными бывшими мастер-узлами.

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

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

   • выполнение box.schema.upgrade() на routers_list и replicaset_masters_list с помощью плейбука eval_schema_update.yml;
   • проверка здоровья кластера после обновления.

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

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

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

 
---plugin: tarantool.enterprise.generatorcluster_name: tarantoolproduct: tarantoolconstants:  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/:{{ tarantool_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

Настройте параметр roles.cfg.roles.httpd.default с помощью переменной tarantool_httpd_ssl_params:

 
---plugin: tarantool.enterprise.generatorcluster_name: tarantoolproduct: tarantoolconstants:  tarantool_httpd_ssl_params:      ssl_key_file: 'certs/server.key'      ssl_cert_file: 'certs/server.crt'      ssl_ca_file: 'certs/root_ca.crt'      ssl_verify_client: 'off'

Всё, что задано в переменной tarantool_httpd_ssl_params, будет указано в конфигурации Tarantool в каждой секции roles.cfg.roles.httpd.default "как есть". Например, указанные выше настройки будут преобразованы в следующую секцию конфигурации для всех экземпляров:

 
---roles_cfg:  roles.httpd:    default:      ssl_key_file: "certs/server.key"      ssl_cert_file: "certs/server.crt"      ssl_ca_file: "certs/root_ca.crt"      ssl_verify_client: "off"

Настройка 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]

 
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/switch_leader.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_ssl_verify_host (string) — Наличие проверки серверного сертификата etcd. Например: '{"tt_ssl_verify_host": "False"}'.
• tt_config_storage_username (string) — Имя пользователя для логина в централизованном хранилище конфигурации (etcd или хранилище на основе Tarantool).
• tt_config_storage_password (string) — Пароль пользователя для логина в централизованном хранилище конфигурации (etcd или хранилище на основе Tarantool).

Сценарий playbooks/backup_pitr.yml выполняет резервное копирование кластера Tarantool 3.x на основе утилиты tt backup: полное (--target=full) и инкрементальное (--target=incremental) копирование с возможностью последующего восстановления на момент времени (PITR).

Сценарий выполняется в несколько фаз:

1. планирование — tt backup plan -c <uri-хранилища-конфигурации> (один раз на хосте сбора);
2. снятие на мастерах — tt backup start;
3. сбор артефактов на хосте сбора;
4. загрузка в хранилище — tt backup upload (один раз на хосте сбора);
5. финализация на мастерах — tt backup finalize;
6. проверка и очистка — tt backup last/verify/gc (один раз на хосте сбора).

Фазы plan/upload/last/verify/gc выполняются на хосте сбора, который задаётся переменной tarantool_pitr_backup_host (обязательная; для управляющего узла Ansible — localhost).

Артефакты по умолчанию проходят через управляющий узел Ansible: tt backup start пишет архив и манифест каждого мастера в его рабочий каталог, затем сценарий забирает их на управляющий узел и передаёт в хранилище командой tt backup upload. Для S3 и файлового хранилища это одинаково — до загрузки архивы лежат локально. Если на управляющем узле недостаточно места либо нужно исключить его из цепочки, включите общую файловую систему tarantool_pitr_backup_shared_fs: true или задайте tarantool_pitr_backup_dir на смонтированном томе достаточного объёма. Подробнее — см. раздел Сбор артефактов и требования к диску.

tt backup не создаёт точек восстановления, а tt restore plan выбирает момент восстановления исключительно по ним. Точки восстановления создаёт встроенная роль roles.recovery-point-manager, включённая в конфигурацию кластера (см. раздел Точка восстановления). Роль периодически создаёт точку в каждом наборе реплик; для подключения к наборам реплик ей нужен отдельный пользователь с правом execute на box.backup.recovery_point.create.

Конфигурация кластера передаётся в tt backup plan флагом -c: сценарий подставляет URI централизованного хранилища конфигурации (etcd или хранилище на основе Tarantool), который строится из переменных tt_config_storage_endpoint, tt_config_storage_prefix, tt_config_storage_username, tt_config_storage_password (см. раздел Переменные tt CLI).

 
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",      "tarantool_pitr_storage":"file:///mnt/backups",      "tarantool_pitr_storage_root":"/mnt/backups",      "tarantool_pitr_cluster_name":"payments",      "tarantool_pitr_environment":"prod",      "tarantool_pitr_backup_host":"backup-host",      "tarantool_pitr_tt_bin_dir":"/usr/bin"  }' \  playbooks/backup_pitr.yml

Обязательные переменные: tarantool_pitr_storage, tarantool_pitr_cluster_name, tarantool_pitr_environment, tarantool_pitr_backup_host (для управляющего узла Ansible — localhost). tarantool_pitr_tt_bin_dir необязательна: на хостах кластера используется per-instance tt, а явно её задают только для выделенного хоста сбора или управляющего узла.

Полный список переменных сценария приведён в разделе Переменные PITR-резервирования.

Сценарий playbooks/restore_pitr.yml восстанавливает кластер Tarantool 3.x на момент времени T из резервной копии, созданной сценарием playbooks/backup_pitr.yml. Восстановление выполняется на основе утилиты tt restore: плейбук строит план (tt restore plan) — полная резервная копия плюс цепочка инкрементов и per-shard позиции (replica_id, lsn) — а затем применяет его на целевых узлах (tt restore apply).

Сценарий выполняется в несколько фаз:

1. валидация входных переменных (до любых разрушающих действий);
2. планирование — tt restore plan (один раз на хосте восстановления, всегда с URI централизованного хранилища конфигурации);
3. остановка кластера и очистка каталогов данных экземпляров;
4. раздача скачанных архивов по целевым узлам;
5. применение — tt restore apply (один раз на набор реплик, на мастере из манифеста); снимки состояния/WAL/vinyl раскладываются в раздельные каталоги нативными флагами --snapshot-dir/--wal-dir/--vinyl-dir;
6. удаление резервных копий данных (.pre-restore-*).

После tt restore apply кластер не запускается автоматически (по RFC): старт выполняется отдельно оператором (например, сценарием playbooks/start.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 \  -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",      "tarantool_shared_hosts":"payments",      "tarantool_pitr_storage":"file:///mnt/backups",      "tarantool_pitr_storage_root":"/mnt/backups",      "tarantool_pitr_cluster_name":"payments",      "tarantool_pitr_environment":"prod",      "tarantool_pitr_restore_host":"restore-host",      "tarantool_pitr_tt_bin_dir":"/usr/bin"  }' \  playbooks/restore_pitr.yml

Переменные:

• [обязательные] tarantool_pitr_storage, tarantool_shared_hosts, tarantool_pitr_restore_host (для управляющего узла Ansible — localhost).
• [необязательные] tarantool_pitr_cluster_name и tarantool_pitr_environment: они выбирают поддерево хранилища и должны совпадать с резервированием (если пусты — восстановление читает корень хранилища).
• [необязательные] tarantool_pitr_restore_target_time либо tarantool_pitr_restore_point_label: момент восстановления. По умолчанию — последняя доступная точка (авто-выбор), но через эти переменные можно задать момент восстановления явным образом.
• [необязательная] tarantool_pitr_tt_bin_dir: на хостах кластера используется утилита tt для каждого экземпляра, а явно её задают только для выделенного хоста восстановления или управляющего узла.

Список доступных точек восстановления (только для хранилища type: fs, нужен tarantool_pitr_storage_root) можно получить, не выполняя восстановление:

 
ansible-playbook -i /ansible/inventories/hosts.yml --tags list-points playbooks/restore_pitr.yml

Полный список переменных сценария приведён в разделе Переменные PITR-восстановления.

Смотрите также:

• Примеры инвентарей TCM;
• Инвентарь для генератора с TCM.

Сценарий предназначен для развертывания, настройки и запуска продукта 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/install.yml

Команда для запуска сценария с помощью 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

При первом запуске TCM можно автоматически создать роли и пользователей с помощью переменных tcm_initial_roles и tcm_initial_users.

• tcm_initial_roles — список ролей, которые будут созданы при первом запуске TCM. Каждая роль может содержать:

  • id (строка, опционально) — если не указан, TCM сгенерирует его автоматически при создании роли;
  • name (строка, обязательно) — название роли;
  • description (строка, опционально) — описание роли;
  • permissions (список строк или список объектов с resource/actions) — права доступа.

• tcm_initial_users — список пользователей, которые будут созданы при первом запуске TCM. Каждый пользователь может содержать:

  • fullname (строка, обязательно) — полное имя пользователя;
  • description (строка, опционально) — описание пользователя;
  • secret-type (строка: password или public-key, обязательно) — тип секрета;
  • secret-key (строка, обязательно) — пароль (если secret-type: password) или приватный ключ (если secret-type: public-key);
  • public-key (строка, обязательно для всех типов secret-type, длина > 3 символов) — публичный SSH-ключ;
  • role-ids (список строк с идентификаторами ролей, опционально) — если не указаны, пользователь создается без дополнительных ролей.

Пример использования этих переменных в инвентаре представлен в разделе Примеры инвентарей TCM.

Подробное описание переменных см. в разделе Переменные TCM.

Плейбук tcm_add_tbcs.yml добавляет кластер Tarantool-based Configuration Storage (TbCS) в уже запущенный TCM как static-кластер (в UI — «from configuration»). Кластер TbCS — это само хранилище конфигурации, поэтому у него нет внешнего хранилища, из которого TCM мог бы читать его конфигурацию (провайдеры etcd или tarantool): вместо этого в TCM передаётся снимок топологии кластера.

Плейбук является runtime-аналогом варианта начальной загрузки (bootstrap): секция tcm_tbcs_static_config в инвентаре для генератора добавляет кластер TbCS в TCM ещё на этапе установки, а этот плейбук — в работающий TCM. Для present и absent плейбук идемпотентен: кластер ищется по имени и добавляется или удаляется только при необходимости. Для ручного обновления укажите tcm_tbcs_state: update: существующий static-кластер обновляется при каждом запуске, без сравнения с сохранённым снимком.

Перед изменением состояния плейбук проверяет версию TCM через API и завершается с ошибкой, если она ниже 1.11 (в таких версиях нет провайдера static).

Команда для запуска сценария с помощью 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}'",        "tcm_tbcs_name":"TbCS"    }' \    playbooks/tcm_add_tbcs.yml

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

• tcm_tbcs_state (string) — present добавляет кластер, если его ещё нет; update вручную обновляет YAML-снимок и параметры подключения (tarantool-connection) существующего static-кластера; absent удаляет кластер, если он есть, и использует провайдер static. Для update и absent при нескольких кластерах с таким именем плейбук завершается ошибкой. При update кластер должен уже существовать: плейбук не сравнивает конфигурации и выполняет обновление при каждом запуске. Метаданные (description, color, urls, integrityCheck, signaturePrivateKeyFile) сохраняются из существующей записи TCM; текущий пароль и сохранённый YAML-снимок плейбук не запрашивает. По умолчанию — present.
• tcm_tbcs_name (string) — имя кластера в TCM. Значение по умолчанию: TbCS.
• tcm_tbcs_static_config_content (string) — готовый YAML-снимок конфигурации кластера TbCS. Если не задан, плейбук читает отрендеренную конфигурацию с хоста хранилища конфигурации (у которого is_config_storage: true).
• tcm_tbcs_username, tcm_tbcs_password (string) — учётные данные подключения к кластеру (tarantool-connection). По умолчанию берутся из tcm_etcd_username / tcm_etcd_password (учётные данные storage-подключения TCM) при tcm_storage_provider: tarantool. В остальных случаях задайте tcm_tbcs_username / tcm_tbcs_password явно — иначе плейбук завершится с ошибкой.
• tcm_host, tcm_port — адрес API TCM. По умолчанию берутся из инвентаря, порт — 8080.

TLS для подключения TCM к экземплярам TbCS (tarantool-connection.ssl) плейбук выводит из tarantool_iproto_ssl_params на хосте хранилища конфигурации. Настройки TLS собственного storage-подключения TCM (tcm_tarantool_ssl_*) для этого блока не используются. Отдельной переменной для него нет.

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

• TDB 2.x и TDB 3.x: сценарии из разделов

  • Tarantool DataBase 2.x и 3.x: Установка и запуск
  • Tarantool 3.x;
  • Общие сценарии администрирования.

  Для публикации и применения миграций в TDB 2.x и 3.x используется сценарий

  • Применение миграций с помощью tt CLI.

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

Сценарий предназначен для развертывания, настройки и запуска продукта Tarantool DataBase. Используемый сценарий подробно описан в разделе Tarantool 3.x: Установка приложения.

Стенд с Tarantool DB состоит из кластера Tarantool DB, веб-интерфейса TCM и централизованного хранилища конфигурации — etcd или хранилища конфигурации на основе Tarantool (Tarantool-based configuration storage, далее — TBCS). Обратите внимание, что перед запуском сценария необходимо настроить отдельный кластер для хранения конфигурации кластеров — etcd или TBCS.

После запуска кластера Tarantool DB дождитесь завершения развертывания и запустите сценарий check.yml для проверки работоспособности кластера. Затем запустите модуль шардирования vshard с помощью сценария tt_vshard_bootstrap.yml или команды tt replicaset vshard bootstrap.

Установить TCM после запуска Tarantool DB можно с помощью сценария Tarantool Cluster Manager: Установка и запуск.

TDB Worker — это узел-обработчик для работы с Tarantool DB с помощью библиотек из экосистемы Tarantool.

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

• PATH_TO_PACKAGE — полный путь к директории с архивами.
• TDB_WORKER_PACKAGE_NAME — имя архива с поставкой TDB Worker.
• HOSTS — указание группы хостов TDB Worker, например tdb-worker из примера инвентаря.

 
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}/${TDB_WORKER_PACKAGE_NAME}:/ansible/packages/${TDB_WORKER_PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e TDB_WORKER_PACKAGE_NAME=${TDB_WORKER_PACKAGE_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars '{        "tdb_worker_package_path":"/ansible/packages/'${TDB_WORKER_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/tdb_worker/install.yml

Основные переменные:

• tdb_worker_package_path (string) — путь к архиву с поставкой TDB Worker.
• tdb_worker_instrumentation_url (string) — адрес хоста TDB Worker. По умолчанию: {{ ansible_host }}:9080.
• tdb_worker_name (string) — имя исполняемого файла. По умолчанию: http_server.
• tdb_worker_additional_config (dict) — дополнительная конфигурация для TDB Worker. По умолчанию: {}.

С полным списком переменных можно ознакомиться в разделе документации Переменные TDB Worker.

Сценарий предназначен для обновления версии TDB Worker. Обновление выполняется путем доставки новой версии пакета и перезапуска сервиса при изменении версии.

 
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}/${TDB_WORKER_PACKAGE_NAME}:/ansible/packages/${TDB_WORKER_PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e TDB_WORKER_PACKAGE_NAME=${TDB_WORKER_PACKAGE_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook -i /ansible/inventories/hosts.yml \    --extra-vars '{        "tdb_worker_package_path":"/ansible/packages/'${TDB_WORKER_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/tdb_worker/install.yml

Сценарий предназначен для полного удаления TDB Worker: остановка сервиса, удаление systemd-юнита, очистка директорий и удаление ключей из etcd.

• HOSTS — указание группы хостов TDB Worker.

 
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",        "tarantool_shared_hosts":"'${HOSTS}'"    }' \    playbooks/tdb_worker/uninstall.yml

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

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

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

• TQE версии 1.10 и выше - сценарии из разделов Tarantool 3.x, Администрирование TQE и Общие сценарии администрирования.

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

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

• 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 '{        "tarantool_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/install.yml

В стандартных плейбуках ATE (start.yml, stop.yml, restart.yml) не учитывается порядок запуска сервисов TQE: модуль API (message-queue-ee) должен стартовать после готовности ядра (Tarantool), а останавливаться — до остановки ядра. Плейбуки в playbooks/tqe/ решают эту проблему.

Выполняет HTTP-проверки эндпоинтов /readyz и /livez модуля API.

• /readyz — готовность API к работе: проверяет started, producer-tarantool, consumer-tarantool;
• /livez — живость подключений API: проверяет producer-tarantool, consumer-tarantool.

 
ansible-playbook -i <INVENTORY> \    -e tarantool_shared_hosts=<API_HOSTS> \    playbooks/tqe/health.yml

Параметры проверки настраиваются переменными tqe_health_readyz_retries, tqe_health_readyz_delay, tqe_health_livez_retries, tqe_health_livez_delay (см. раздел «Переменные TQE»). Порт проверки — tqe_health_port (по умолчанию config.core_port).

Запускает сервисы в правильном порядке: ядро → ожидание готовности ядра → модуль API → проверка здоровья API.

 
ansible-playbook -i <INVENTORY> \    -e tqe_core_hosts=<CORE_HOSTS> \    -e tqe_api_hosts=<API_HOSTS> \    playbooks/tqe/start.yml

Переменная tqe_api_hosts опциональна: если модуль API отсутствует, шаги с ним пропускаются.

Останавливает сервисы в правильном порядке: модуль API → ядро.

 
ansible-playbook -i <INVENTORY> \    -e tqe_core_hosts=<CORE_HOSTS> \    -e tqe_api_hosts=<API_HOSTS> \    playbooks/tqe/stop.yml

Перезапускает сервисы: остановка API → перезапуск ядра → ожидание готовности ядра → запуск API → проверка здоровья API.

 
ansible-playbook -i <INVENTORY> \    -e tqe_core_hosts=<CORE_HOSTS> \    -e tqe_api_hosts=<API_HOSTS> \    playbooks/tqe/restart.yml

Для обновления TQE используется стандартный плейбук playbooks/continuous_update.yml. Если в кластере есть экземпляры модуля API (gRPC), обновление вызывает плейбук playbooks/tqe/update_api.yml автоматически: каждый API-экземпляр перелинковывается на доставленную версию пакета, его сервис перезапускается, после чего проверяется здоровье API.

 
ansible-playbook -i <INVENTORY> \    -e tarantool_package_path=<PACKAGE>.tar.gz \    -e storage_group=<STORAGE_GROUP> \    playbooks/continuous_update.yml

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

Сценарий предназначен для развертывания и настройки продукта 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/install.yml

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

2. После установки TCF настройте кластерные приложения. Для этого добавьте в инвентарь каждого из кластеров секции с настройками ролей roles.tcf-coordinator (задается на роутерах) и roles.tcf-worker (задается на всех узлах) и примените конфигурацию (например, сценарием configure.yml). Пример:

    
   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

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

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

 
tcf_ssl_cert_file: /path/to/server.crttcf_ssl_key_file: /path/to/server.keytcf_ssl_ca_file: /path/to/ca.crt

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

 
tcf_gateway_alias: gateway_a_btcf_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_v2tcf_destination_storage_endpoints:  - host: etcd    port: 2379tcf_destination_storage_prefix: /tcftcf_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"

Сценарий предназначен для обновления версии продукта 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.

• 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 из примера.

Сценарий предназначен для остановки всех экземпляров 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: Установка приложения. Для обновления и администрирования TCS используются сценарии из разделов Tarantool 3.x и Общие сценарии администрирования.

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

Продукт 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 '{        "tarantool_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/install.yml

Переменные для установки 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.
• tcs_listen_host (string) - адрес (хост или сетевой интерфейс), на котором компоненты TCS принимают подключения. По умолчанию используется advertise_host.

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 '{        "tarantool_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/install.yml

Пример указания переменных 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"

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

Для развертывания Tarantool Change Data Capture (далее -- Tarantool CDC) используется сценарий из раздела Tarantool Change Data Capture: Установка и запуск. Для обновления и администрирования Tarantool CDC используются сценарии из разделов Tarantool 3.x и Общие сценарии администрирования.

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

Сценарий предназначен для развертывания и настройки продукта Tarantool CDC. Tarantool CDC имеет собственный инвентарь, в котором задаются настройки Универсального Обработчика. Его основные компоненты -- Коннектор Источника (Source Connector) и Коннектор Приемника (Sink Connector), входящие в состав Tarantool CDC.

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

• кластер etcd для хранения конфигурации и состояния кластеров;
• кластеры баз данных для передачи данных;
• кластер TQE.

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

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

   • PATH_TO_CDC_INVENTORY — путь до файла инвентаря Tarantool CDC.
   • PATH_TO_CDC_PACKAGE - путь до артефакта на локальной машине (включая имя файла).
   • CDC_PACKAGE_NAME — имя архива с поставкой Tarantool CDC.
   • CDC_SINK_CONNECTOR_PACKAGE_NAME — имя Коннектора Приемника Tarantool CDC (берется из списка официальных коннекторов CDC).
   • CDC_SOURCE_CONNECTOR_PACKAGE_NAME — имя Коннектора Источника Tarantool CDC (берется из списка официальных коннекторов CDC).
   • HOSTS - указание группы хостов Tarantool CDC, например CDC из примера инвентаря.
   • DEPLOY_TOOL_VERSION_TAG – версия инсталлятора.
   • SUPER_USER_NAME – логин для суперпользователя от имени которого могут выполняться действия в плейбуке.

    
   docker run --network host -it --rm \    -v ${PATH_TO_PRIVATE_KEY}:/ansible/.ssh/id_private_key:Z \    -v ${PATH_TO_CDC_INVENTORY}:/ansible/inventories/inventory_cdc.yml:Z \    -v ${PATH_TO_CDC_PACKAGE}:/ansible/packages/${CDC_PACKAGE_NAME}:Z \    -e SUPER_USER_NAME=${SUPER_USER_NAME} \    -e CDC_PACKAGE_NAME=${CDC_PACKAGE_NAME} \    ansible-tarantool-enterprise:${DEPLOY_TOOL_VERSION_TAG} \    ansible-playbook \    -i /ansible/inventories/inventory_cdc.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}'",        "cdc_package_name":"'${CDC_PACKAGE_NAME}'",        "cdc_sink_connector_package_name":"'${CDC_SINK_CONNECTOR_PACKAGE_NAME}'",        "cdc_source_connector_package_name":"'${CDC_SOURCE_CONNECTOR_PACKAGE_NAME}'",        "cdc_package_path":"/ansible/packages/'${CDC_PACKAGE_NAME}'"    }' \    playbooks/install.yml

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

• cdc_sink_connector_params (object) — параметры конфигурации для компонента Коннектор Приемника.
  • undefined ← (default)
• cdc_source_connector_params (object) — параметры конфигурации для компонента Коннектор Источника.
  • undefined ← (default)
• cdc_offset_params (object) — параметры конфигурации для offset Tarantool CDC.
  • undefined ← (default)
• cdc_throttle_params (object) — параметры троттлинга при передаче данных Tarantool CDC.
  • 'throttler.max.rps: -1' ← (default)
• cdc_package_name (string) — название архива с артефактами Tarantool CDC.
  • undefined ← (default)
• cdc_sink_connector_package_name (string) — название Коннектора Приемника Tarantool CDC.
  • undefined ← (default)
• cdc_source_connector_package_name (string) — название Коннектора Источника Tarantool CDC.
  • undefined ← (default)

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

• cdc_worker_params (object) — параметры конфигурации для воркера Tarantool CDC.
  • undefined ← (default)
• cdc_log_params (object) — параметры логгирования для Tarantool CDC.
  • undefined ← (default)