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

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

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

Рабочая схема проста:
— в Terraform держим сети, VM, балансировщики, IAM и зависимости между ними;
— в Ansible — пакеты, сервисы, конфиги, шаблоны и idempotent-изменения;
— секреты не храним в репозитории, даже если очень просит дедлайн;
— изменения прогоняем через план, проверку и отдельный pipeline, а не через SSH на живой сервер.

Отдельный риск — порядок запуска. Terraform не должен ждать, пока Ansible “настроит что-нибудь важное”, а Ansible не обязан угадывать, поднялась ли инфраструктура полностью. Связку лучше строить через outputs, inventory generation и явные зависимости. Код работает, но есть нюансы: если состояние ресурсов скрыто в голове одного инженера, это уже не IaC, а коллективная память.

Минимальный чек-лист: единый backend для state, lock на конкурентные изменения, шаблоны без ручной правки, и обязательный rollback-план для каждого изменения. Автоматизация — это не опция, а необходимость.