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

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

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

Базовые правила простые:
— Terraform описывает сеть, VM, IAM, диски, балансировщики.
— Ansible настраивает пакеты, сервисы, файлы, пользователей, cron.
— Не храните секреты в открытом виде; используйте vault или внешнее хранилище.
— Любое изменение проходит через plan/check mode и review, а не через SSH «по быстрому».

Отдельно следите за идемпотентностью. Если повторный запуск меняет систему без причины, это не автоматизация, а лотерея с логами. Хорошая практика — один репозиторий, но разные слои: modules для Terraform, roles для Ansible, единые naming conventions и понятные outputs. Тогда пайплайн читается, а не расшифровывается с чувством легкой тревоги.

Проверяйте не только apply, но и откат: что удалится, что останется, кто владеет состоянием и где лежит backend для state. Без этого любой «безопасный рефакторинг» превращается в инцидент с долгим обсуждением причин.

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