Playbook, который раньше выполнялся на 20 хостах за минуту, после расширения инвентаря до 400 хостов стал выполняться почти 40 минут, хотя сами задачи не изменились. Какие настройки Ansible (forks, pipelining, стратегия выполнения) влияют на время прогона при большом количестве хостов, и как диагностировать, что именно является узким местом?

Короткий ответ

Ключевые параметры — forks (сколько хостов обрабатывается параллельно за раз, по умолчанию всего 5, что при 400 хостах означает 80 последовательных батчей), pipelining (отключает отдельную передачу модуля файлом по SSH, уменьшая число SSH-подключений на задачу) и strategy (дефолтная linear ждёт завершения задачи на всех хостах батча перед следующей задачей, тогда как free позволяет каждому хосту идти по плейбуку в своём темпе); диагностировать узкое место помогает профилирование через ANSIBLE_CALLBACKS_ENABLED=timer,profile_tasks или встроенный плагин profile_tasks, который показывает время каждой задачи и помогает понять, SSH-overhead это или реально долгая задача.

Как это работает подробнее

при forks = 5 Ansible делит 400 хостов на 80 последовательных групп по 5, и каждая задача внутри плейбука выполняется этими батчами, так что даже быстрая задача (1 секунда на хосте) на 400 хостах с такими forks растягивается на значимое время просто из-за количества батчей; pipelining убирает лишний шаг копирования скрипта модуля на хост через SFTP/SCP перед выполнением, что при высокой задержке сети или большом количестве мелких задач даёт заметный выигрыш.

Пример кода

example.txtКопировать

# ansible.cfg
[defaults]
forks = 50
strategy = linear
callback_whitelist = profile_tasks
[ssh_connection]
pipelining = True
$ ANSIBLE_STDOUT_CALLBACK=profile_tasks ansible-playbook -i inventory site.yml
Sunday 04 October 2026  15:10:02 +0000 (0:00:28.311)  Install packages ------- 28.31s
Sunday 04 October 2026  15:10:30 +0000 (0:00:02.014)  Copy config ------------  2.01s

Что использовать на практике

• Практика. для большого инвентаря стоит поднять forks до разумного числа, соответствующего возможностям control node и целевой инфраструктуры (сотни, если control node и сеть это выдерживают), включить pipelining = True в ansible.cfg (требует отсутствия requiretty в sudoers на хостах), и для плейбуков без строгих межзадачных зависимостей между хостами переключиться на strategy: free; также полезно разбивать очень большие прогоны на serial батчи, если цель — не скорость, а контролируемый rollout (например, canary-раскатка конфигурации).

Подводные камни

• Ошибка. частая ошибка — увеличивать только forks, не включая pipelining и не проверяя профиль задач, из-за чего настоящим узким местом остаётся, например, одна конкретная медленная задача (скачивание большого файла), которую параллелизация по хостам не ускоряет; другая ошибка — включить strategy: free для плейбука, где поздние задачи реально зависят от того, что все хосты прошли более ранний шаг (например, миграция схемы БД перед деплоем кода), что приводит к состоянию гонки между хостами.