Использование Ansible-коллекции

Установите инсталлятор:

1. Скачайте архив с коллекцией из личного кабинета на сайте tarantool.io или используйте архив, полученный напрямую от доверенного лица. Архив с коллекцией имеет вид tarantool-enterprise-${VERSION}.tar.gz, где ${VERSION} -- нужная версия инсталлятора ATE.

2. Установите коллекцию с помощью ansible-galaxy:

    
   ansible-galaxy collection install --force tarantool-enterprise-${VERSION}.tar.gz

Роль tarantool.enterprise.os_configure выполняет следующие функции:

• определяет, поддерживается ли текущая операционная система;
• создает systemd unit-файлы в домашней директории пользователя tarantool.

Ansible Tarantool Enterprise не использует механизм gather_facts по умолчанию, поэтому многие сценарии начинаются с задачи find_os.yml для определения операционной системы. Добавьте вызов роли tarantool.enterprise.os_configure перед использованием других ролей из Ansible Tarantool Enterprise.

 
- ansible.builtin.import_role:    name: tarantool.enterprise.os_configure    tasks_from: find_os.yml

Запуск роли целиком (main.yml) создаст unit-файлы.

 
- ansible.builtin.import_role:    name: tarantool.enterprise.os_configure

Эта роль нужна для работы с приложениями на Tarantool Cartridge.

Ей соответствует полностью вшитая open-source роль tarantool.cartridge. Документация доступна на GitHub.

Особенности использования в составе коллекции:

• Необходимо корректно указать путь до директории custom_steps/ в переменной cartridge_custom_steps_dir.
• Переменная cartridge_scenario должна быть объявлена и иметь тип List. Можно использовать переменную cartridge_scenario_name, чтобы указать исполняемую последовательность по умолчанию. В таком случае указывать cartridge_scenario нужно только при желании изменить стандартное исполнение.

Есть специальный набор переменных, которые регулируют, каким образом запускаются сценарии:

• tarantool_shared_become_user – выставляет значение переменной ansible_become_user. По умолчанию – tarantool.
• tarantool_shared_become_method – выставляет значение переменной ansible_become_method. По умолчанию – sudo.
• tarantool_shared_become – выставляет значение параметра become в сценариях. По умолчанию – true.
• tarantool_shared_hosts – выставляет значение параметра hosts в сценариях. В большинстве сценариев значением по умолчанию является all. Исключением являются сценарии для TCF.

Вы можете управлять tarantool_shared_hosts для создания сложных сценариев с использованием уже существующих сценариев из коллекции Ansible Tarantool Enterprise.

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

 
- name: Switch leaders to RESERVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.switch_leaders_to  vars:    tarantool_shared_hosts: "RESERVE"- name: Update ACTIVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.update_internal  vars:    tarantool_shared_hosts: "ACTIVE"- name: Wait for cluster to become healthy  ansible.builtin.import_playbook: tarantool.enterprise.wait_is_healthy  vars:    tarantool_shared_hosts: "all"- name: Return leaders to ACTIVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.switch_leaders_to  vars:    tarantool_shared_hosts: "ACTIVE"- name: Update RESERVE datacenter  ansible.builtin.import_playbook: tarantool.enterprise.update_internal  vars:    tarantool_shared_hosts: "RESERVE"- name: Wait for cluster to become healthy  ansible.builtin.import_playbook: tarantool.enterprise.wait_is_healthy  vars:    tarantool_shared_hosts: "all"

Аналогичный механизм реализован в сценарии tarantool.enterprise.update_2x из коллекции Ansible Tarantool Enterprise.

Для шардированного кластера TCS 1.x часть состояния (конфигурация и данные шардирования) хранится в ETCD. Обычный механизм tarantool.enterprise.backup/tarantool.enterprise.restore не восстанавливает эту часть состояния корректно, так как ETCD использует механизм ревизий (revision), который теряется при простом сохранении/восстановлении данных по префиксу.

Для TCS предусмотрены отдельные плейбуки playbooks/tcs/backup.yml и playbooks/tcs/restore.yml, которые дополнительно сохраняют и восстанавливают состояние ETCD целиком с помощью механизма сохранения снимков (etcdctl snapshot save / etcdutl snapshot restore). Это сохраняет точную историю ревизии ETCD, в отличие от восстановления по отдельным ключам.

Список всех переменных с описанием и значениями по умолчанию см. в разделе Сохранение и восстановление данных кластера TCS.

 
ansible-playbook playbooks/tcs/backup.yml -i <inventory>

Плейбук выполняет:

1. Стандартное создание резервной копии данных Tarantool через tarantool.enterprise.backup (на хостах storages/schedulers).
2. Сохранение снимка ETCD (etcdctl snapshot save) происходит на одном из ETCD хостов. Согласно официальной документации etcd, для восстановления кластера достаточно одного снимка, все члены восстанавливаются из одного и того же файла.
3. Копирование снимка на управляющий узел (машину, откуда запущен ansible-playbook) для последующего использования при восстановлении.

 
ansible-playbook playbooks/tcs/restore.yml -i <inventory> \  -e tcs_confirm_restore=true

Плейбук выполняет:

1. Остановку кластера TCS.
2. Остановку ETCD на всех хостах.
3. Раздачу снимка ETCD с управляющего узла на все ETCD-хосты.
4. Восстановление ETCD из снимка (etcdutl snapshot restore) на каждом хосте синхронно.
5. Запуск ETCD и ожидание готовности кластера.
6. Восстановление данных Tarantool через tarantool.enterprise.restore.
7. Запуск кластера TCS.
8. Проверку здоровья ETCD-кластера.