<b>Terraform и Ansible ломаются не в коде, а в порядке применения и границах ответственности</b>

<b>Terraform и Ansible ломаются не в коде, а в порядке применения и границах ответственности</b>

Infrastructure as Code работает, пока вы не пытаетесь заставить один инструмент делать чужую работу. Terraform должен описывать ресурсы и зависимости, Ansible — настраивать ОС, пакеты и сервисы. Если смешать это в один слой, получаются циклы, ручные костыли и любимое занятие продакшена: «а почему ресурс есть, а конфиг не применился?».

Базовые правила:
— Terraform создает инфраструктуру и хранит состояние отдельно от кода приложений.
— Ansible не должен управлять облачными ресурсами, если это уже делает Terraform.
— Между ними нужен явный контракт: outputs, inventory, data files, а не магия в переменных.
— Один pipeline = один предсказуемый порядок: сначала инфраструктура, потом конфигурация.

Типовая ошибка — писать idempotency «на глаз». Terraform план должен быть чистым, Ansible playbook — повторяемым без сюрпризов. Если после повторного прогона что-то меняется, это не особенность, это дефект процесса.

Для поддержки такого стека важны state-locking, разделение модулей по зонам ответственности и ревью не только кода, но и зависимостей между слоями. Безопасность начинается с доступа: секреты не хранятся в репозитории, а права на state и execution окружения должны быть минимальными.

Автоматизация — это не опция, а необходимость. Если порядок действий нельзя объяснить за минуту, он однажды объяснится сам через инцидент.