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

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

Infrastructure as Code работает только когда Terraform и Ansible не дублируют друг друга. Первый должен описывать инфраструктуру: сети, VM, IAM, DNS, диски. Второй — доводить хост до нужного состояния: пакеты, сервисы, конфиги, шаблоны. Если оба инструмента правят одно и то же, получаем дрейф, конфликт состояния и классическое «у меня локально было иначе».

Полезное правило: Terraform создаёт и уничтожает ресурсы, Ansible настраивает уже существующие. Не тащите в Terraform установки пакетов и сложную post-config логику — это ухудшает идемпотентность и делает план менее читаемым. И наоборот: не используйте Ansible для управления жизненным циклом облачных ресурсов, если это можно описать декларативно в Terraform. Автоматизация — это не опция, а необходимость.

Чтобы не превратить IaC в хрупкий набор скриптов, держите базовые практики:
— один источник правды для состояния;
— remote state с блокировкой;
— модули с чёткими входами и выходами;
— разделение env по workspace/каталогам, а не через if-ы в коде;
— проверка планов и lint до применения.

Отдельно следите за секретами: не храните их в переменных «на потом», не размазывайте по inventory и tfvars. Безопасность начинается с доступа. Если пайплайн не может пройти без ручного костыля, значит архитектура уже просит ревизию.

Код работает, но есть нюансы: IaC ценен не количеством строк, а предсказуемостью изменений. Если после `plan` и `playbook` вы всё ещё гадаете, что будет на хосте, значит стек пора упрощать.