# ChatGPT и Claude пишут Ansible-плейбуки: как встроить ИИ в реальный воркфлоу
Каноническая страница: https://plainews.ru/posts/kak-ispolzovat-ii-dlya-napisaniya-i-optimizacii-ansible-pleybukov-v-2026-godu
Опубликовано: 2026-09-08T14:00:42.211Z

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

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

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

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

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

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

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

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

| Инструмент | Генерация плейбуков | Скаффолдинг ролей | Проверка идемпотентности |
| --- | --- | --- | --- |
| Claude / Claude Code | Полный плейбук с обработчиками | Генерирует структуру директорий роли | Предупреждает о неидемпотентных задачах |
| ChatGPT | Готовые плейбуки целиком | Генерирует defaults, tasks, templates | Предлагает check mode |
| GitHub Copilot | Построчное автодополнение YAML | Частичная генерация роли | Ограниченный анализ |

Отдельно стоит 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) удобнее построчного автодополнения.

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

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

**Плохо:**

```plain
Установи nginx
```

**Хорошо:**

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

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

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

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

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

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

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

> **Важно.** Модуль `docker_login` входит в коллекцию `community.docker`. В сгенерированном коде указывайте полное имя `community.docker.docker_login` и проверьте, что коллекция установлена на управляющей машине.

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

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

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

```bash
ansible-playbook --syntax-check site.yml
```

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

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

```bash
ansible-lint site.yml
```

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

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

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

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

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

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

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

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

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

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

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

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

```bash
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 году