Недавно я наткнулся на узкое место в коде нашей игры.Мы последовательно развертывали наши кластеры (например, набор реплик mongoDB ) - то есть одну виртуальную машину за другой, каждый из которых ожидал, пока предыдущий будет запущен и работает.
Это замедлило время развертывания всего кластера в несколько раз.
Чтобы решить эту проблему, я начал копаться в асинхронных действиях ansible и объединении в пул и нашел несколько примеров параллельных циклов и стратегий " fire-and-Forgot " длясценарии как у нас.
Особенность в том, что мы определили нашу собственную заданную задачу «настроить виртуальную машину и создать ее» (create_instance.yml
), которая включается и получает различные переменные настройки из книги воспроизведения и абстрагирует весь процесс, выполнивразные команды KVM / shell.
Используя " Параллельное выполнение задачи в Ansible " в качестве ссылки, я получил что-то вроде:
- name: Generate VMs for DB
hosts: hypervisor_fe
tags: platform,mongodb
tasks:
- include: tasks/create_instance.yml
vars:
vm: "{{ item }}"
with_items: "{{ mongodb.vms }}"
register: mongo_instances
async: 7200
poll: 0
- name: Wait for instance creation to complete
async_status: jid={{ item.ansible_job_id }}
register: mongo_jobs
until: mongo_jobs.finished
retries: 300
with_items: "{{ mongo_instances.results }}"
Однако эта настройка, кажется, игнорирует весь новый асинхронный код и сохраняет старое последовательное поведение. Я предполагаю, что это связано с нет.и гранулярность игр внутри импортированной задачи.Если я вместо этого заменю include
для одиночной, явной долгосрочной задачи - скажем, например,
- name: Test async operation
shell: ping -c1 {{ item.hostname }} && sleep 20
Это, кажется, работает просто отлично, выполняя по одному ping каждомуitem
и затем переход к следующему действию.
Верно ли это предположение?У кого-нибудь есть опыт работы с include
и асинхронными циклами в ansible?Нужно ли перемещать асинхронное объявление в одиночную игру внутри импортированного кода?