ChatGPT и Claude пишут Ansible-плейбуки: как встроить ИИ в реальный воркфлоу

Роль с обработчиками, шаблонами и секретами в Vault — это много шаблонного кода, который из проекта в проект почти не меняется. ИИ-ассистенты снимают эту рутину, но только при правильно выстроенном процессе: конкретный промпт, обязательные проверки, ручное ревью. Разбираем, какой инструмент брать под задачу, как формулировать запросы и где сгенерированный код ломается.

Зачем подключать ИИ к работе с Ansible

Структура ролей, обработчики (handlers), условия идемпотентности и обработка ошибок повторяются от проекта к проекту с небольшими вариациями. Архитектурных решений эта часть не требует — её нужно просто написать правильно.

Где ИИ даёт выигрыш:

• Шаблонный код. Структура роли, базовые задачи и стандартные обработчики генерируются за секунды вместо ручного набора.
• Порог входа. Инженер, который ещё не выучил весь синтаксис, описывает задачу словами и получает рабочий черновик.
• Отладка. Ассистент объясняет, почему плейбук падает, и предлагает исправление быстрее ручного разбора трассировки.
• Рефакторинг. Перевод устаревшего синтаксиса в актуальный, вынос переменных, разбивка монолитного плейбука на роли.

Понимание Ansible при этом никуда не уходит. Ревью на идемпотентность, безопасность и соответствие конвенциям команды остаётся за инженером.

Какой инструмент выбрать под задачу

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

Отдельно стоит Ansible Lightspeed — решение Red Hat на базе IBM watsonx Code Assistant, встроенное в Ansible Automation Platform (AAP). Оно точнее следует конвенциям Ansible из коробки, но требует подписки на AAP.

Как выбирать:

• Сложный production-плейбук с нуля (несколько ролей, секреты через Ansible Vault, условная логика) — Claude или ChatGPT. На нетиповых требованиях универсальные модели справляются лучше специализированных.
• Автодополнение в редакторе, когда паттерны проекта уже устоялись, — GitHub Copilot или Cursor.
• Команда на AAP, которая пишет Ansible каждый день, — Lightspeed: узкая специализация даёт более точные результаты.
• Объяснение и отладка готового плейбука — диалоговый формат (Claude, ChatGPT, объяснения в Lightspeed) удобнее построчного автодополнения.

Как формулировать промпты

Расплывчатый промпт даёт шаблонный результат. Сравните:

Плохо:

Установи nginx

Хорошо:

Сгенерируй Ansible-роль для установки nginx 1.25 на RHEL 9.
worker_processes задаётся по числу CPU на хосте.
Сервис перезапускается только при изменении конфига — через handler.
Роль должна быть идемпотентной: повторный запуск не меняет состояние системы.
Объясни, почему выбран каждый модуль.

Что стоит указывать в запросе всегда:

• целевую ОС и версии пакетов — «установи nginx» и «установи nginx 1.25 на RHEL 9» дают принципиально разный результат;
• условия перезапуска сервисов и обработку ошибок — не оставляйте их на усмотрение модели;
• требование идемпотентности и хранения секретов в Vault — модель не обязательно добавит это сама;
• просьбу объяснить выбор модулей — так проще поймать неоптимальный подход.

Пример: деплой контейнера из приватного registry

Задача: развернуть Docker-приложение на 20 серверах. Образы тянутся из приватного registry, конфигурации версионируются, перезапускаются только затронутые сервисы. Запрос:

Сгенерируй Ansible-роль для деплоя Docker-контейнера из приватного registry
на группу хостов docker_hosts. Требования:
- аутентификация в registry через docker_login с credentials из Vault;
- версия образа передаётся переменной app_version;
- перезапуск сервиса только при изменении версии (handler);
- проверка сертификата registry перед pull;
- обработка ошибок: fail с понятным сообщением при неудачном pull.

На выходе — роль с отдельными задачами аутентификации, секретами в Ansible Vault, условными обработчиками перезапуска, базовой обработкой ошибок и проверкой сертификата перед pull. Запрос «разверни докер-контейнер» тоже даст рабочий плейбук, но обобщённый — его придётся дорабатывать руками.

Пошаговый воркфлоу: от промпта до прода

Шаг 1. Черновик. Отправьте конкретный промпт и попросите полную структуру роли: defaults/main.yml, tasks/main.yml, handlers/main.yml, шаблоны.

Шаг 2. Синтаксис.

ansible-playbook --syntax-check site.yml

Первый фильтр: отсекает ошибки YAML и структуры плейбука до запуска на реальных хостах.

Шаг 3. Линтер.

ansible-lint site.yml

ansible-lint ловит нарушения best practices, которые синтаксически корректны, но расходятся с конвенциями Ansible. ИИ-генерация от них не застрахована: например, вызов через command там, где есть специализированный модуль, или короткие имена модулей вместо полных (FQCN).

Шаг 4. Идемпотентность.

# Первый запуск — приводит хосты к целевому состоянию
ansible-playbook -i inventory site.yml

# Второй запуск — не должен ничего менять
ansible-playbook -i inventory site.yml

Запускайте на тестовом окружении. Во втором прогоне итоговая сводка PLAY RECAP должна показать changed=0. Если нет — ищите задачи, которые не проверяют текущее состояние. Частый виновник — command или shell без creates/removes.

Шаг 5. Ревью безопасности. Вручную проверьте:

• секреты идут через Ansible Vault, а не лежат открытым текстом;
• права доступа на файлы и директории выставлены явно;
• для критичных задач продуманы условия отката.

# Правильно: значение берётся из переменной, зашифрованной Vault
registry_password: "{{ vault_registry_password }}"

# Неправильно: секрет в открытом виде
registry_password: "mysecretpassword123"

Шаг 6. Staging. ИИ-сгенерированный плейбук проходит через тестовое окружение так же, как написанный вручную. Только потом — прод.

Как сделать проверку повторяемой

Если команда генерирует плейбуки регулярно, проверку стоит превратить из разового ручного действия в отдельный QA-этап, который прогоняется перед каждым продовым деплоем. Проще всего собрать шаги 2–4 в один шаг CI:

set -e
ansible-playbook --syntax-check site.yml
ansible-lint site.yml
ansible-playbook -i inventory/staging site.yml
# повторный прогон: в PLAY RECAP ожидаем changed=0
ansible-playbook -i inventory/staging site.yml

set -e останавливает пайплайн на первой упавшей команде, так что плейбук с ошибкой синтаксиса или замечаниями линтера до staging не дойдёт.

Где ломается ИИ-генерация

Shell-обёртки вместо модулей. Универсальные модели иногда выдают не-Ansible-нативный код: например, вызов kubectl через shell вместо модуля kubernetes.core.k8s. Такой вариант может работать, но он неидемпотентен и неидиоматичен: command и shell не проверяют текущее состояние и по умолчанию помечают задачу как изменённую при каждом запуске.

Короткие имена модулей. Модели учились на коде разных лет. Проверяйте, что модули указаны полными именами: ansible.builtin.copy вместо copy, community.docker.docker_container вместо docker_container.

Секреты в открытом виде. Если явно не попросить Vault, модель может положить пароль прямо в defaults/main.yml или vars/. Проверяйте это на ревью, а не постфактум.

Незнакомые модули и параметры. Всё, что видите впервые, сверяйте с документацией коллекции: корректный YAML ещё не значит, что модуль примет такие аргументы.

Зависимость от экосистемы. Lightspeed точнее в рамках Ansible, но привязан к AAP и не покрывает остальной стек DevOps-инженера — Python, Terraform, Bash.

FAQ

Можно ли полностью доверить ИИ написание продовых плейбуков?

Нет. Сгенерированный код требует проверки синтаксиса, линтинга, теста на идемпотентность и ревью безопасности. ИИ ускоряет черновой этап, но не заменяет проверку перед продом.

Нужно ли знать Ansible, чтобы пользоваться ИИ-генерацией?

Да. Без понимания модулей, идемпотентности и структуры ролей невозможно качественно проверить и доработать черновик. ИИ усиливает навыки, но не заменяет их.

Стоит ли платить за Ansible Lightspeed?

Если несколько инженеров в команде ежедневно пишут Ansible и уже работают на AAP, специализированное решение обычно окупается за счёт экономии на шаблонном коде. Тому, кто пишет плейбуки нечасто, универсальный ассистент закроет большую часть задач дешевле.

Как проверить, что плейбук идемпотентен?

Запустите его дважды подряд на тестовом окружении. Если второй прогон показывает изменения при уже достигнутом целевом состоянии, плейбук требует доработки.

Безопасно ли генерировать плейбуки с секретами?

Только если явно потребовать в промпте Ansible Vault и проверить это на ревью. По умолчанию модель может оставить чувствительные данные открытым текстом.

Источники

• Habr AI: Как использовать ИИ для написания и оптимизации Ansible-плейбуков в 2026 году