Производительность и pipelining
Тема дорожной карты · Ansible
Лучшие практики оптимизации производительности Ansible направлены на устранение накладных расходов SSH-per-task, которые могут замедлить выполнение больших playbook при применении к сотням хостов без дополнительной настройки. Наиболее эффективная оптимизация — включение SSH pipelining (pipelining = True в ansible.cfg в секции [ssh_connection]), которое устраняет шаг копирования временных файлов и может сократить накладные расходы на задачу на порядок. Дополнительный прирост производительности дают: высокое значение forks (например, forks = 50), использование gather_facts: false в play, не требующих системных фактов, включение кеширования фактов с бэкендом jsonfile или redis для исключения повторного сбора фактов при каждом запуске, а также выбор стратегии free, позволяющей быстрым хостам продвигаться без ожидания медленных. Для очень больших inventory сторонний плагин стратегии mitogen заменяет SSH-транспортный уровень Ansible значительно более быстрой мультиплексированной моделью соединений, способной сократить общее время выполнения playbook на 50–80%.
Как это работает
Производительность и pipelining для production: пиньте каждую collection + role-версию, шифруйте все секреты Vault'ом, разделяйте prod/staging-inventory, гоняйте плейбуки из CI (не с ноутов), тестируйте --check --diff против staging сначала, ansible-lint + yamllint в CI, структурируйте проекты по рекомендуемой раскладке Ansible (group_vars, host_vars, roles/, collections/, playbooks/), версионируйте всё включая inventories, периодический drift-detection.
Когда применять
Применяйте с первого дня — ретрофит потом болезненный. К ansible-коду — те же ревью-стандарты, что и к app. Molecule — для тестов ролей в изоляции. ansible-lint сразу; правила ловят реальные баги (no-changed-when, no-handler, risky-shell-pipe). Заведите runbook для редкого сценария "откат".
Типичные ошибки
Ловушки Производительность и pipelining: "ansible — это просто конфиг, тесты не нужны" (он меняет реальную инфру на опечатке); ad-hoc команды с ноутов в prod (нет аудита, нет ревью); пропуск --check --diff когда уже "опытный" (Мёрфи никогда в отпуске); нет версионирования inventory (откуда эта группа?). Относитесь к ansible как к infra-коду с той же строгостью, что и к app-коду.