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

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

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

Проверьте базовый каркас:
— state хранится централизованно и защищённо;
— модули изолируют повторяемые блоки, а не копируют конфиг;
— idempotency обязательна, иначе автоматизация превращается в лотерею;
— переменные и секреты разделены, а доступ к ним ограничен.

Для Terraform держите ресурсы минимально связанными, применяйте `plan` как обязательный этап и не допускайте прямых правок в облачной консоли без последующей синхронизации. Для Ansible важны inventory, роли и явные зависимости: playbook должен быть читаемым, иначе через три месяца его будет разбирать уже не инженер, а археолог.

Отдельно следите за границами: если задача меняет инфраструктуру — это Terraform; если настраивает уже поднятую машину — это Ansible. Такая дисциплина снижает дрейф конфигурации и упрощает откат. Автоматизация — это не опция, а необходимость.