IaC и GitOps

Terraform, IaC и GitOps: как держать infrastructure drift под контролем

Terraform и GitOps должны делать изменения спокойнее. Но часто выходит наоборот: state непонятен, часть ресурсов давно меняют руками, plan пугает, а drift замечают только после инцидента.

Обновлено 13 июня 2026 г.10 минут

Почему Terraform перестают трогать

Сначала Terraform внедряют, чтобы инфраструктура была описана кодом. Через год команда может бояться запускать apply: непонятно, какой state актуален, какие ресурсы импортированы, что менялось руками и почему plan предлагает слишком много изменений.

Это не проблема самого Terraform. Обычно сломан процесс вокруг него: нет владельцев modules, нет понятного backend/state, нет review plan, есть ручные изменения в cloud console и нет регулярного drift review.

state хранится непонятно или без locking/backup;

modules копировались между проектами и разошлись по поведению;

часть ресурсов создана руками, но не импортирована;

plan слишком большой, поэтому его никто внимательно не читает;

production apply зависит от одного инженера и личного контекста.

Базовая настройка Terraform, которой можно доверять

Перед расширением IaC нужно привести в порядок базовые вещи: remote state, locking, backup, разделение окружений, naming, provider versions и правила запуска plan/apply.

Хороший признак — любой инженер может открыть pull request, увидеть понятный terraform plan, получить review и понять, какие ресурсы изменятся и какой blast radius у изменения.

remote backend с locking и резервным копированием state;

отдельные environments/workspaces или явная структура каталогов;

закреплённые provider versions и predictable module inputs;

terraform fmt/validate/plan в CI/CD до merge;

разделение прав: кто может plan, кто может apply, кто согласует production.

Drift control: как находить ручные изменения до аварии

Infrastructure drift — это не только техническая проблема. Часто drift появляется потому, что команде нужно срочно починить production, а безопасного IaC-процесса нет. Поэтому задача не только запретить ручные изменения, а сделать нормальный путь быстрее и понятнее.

Регулярный drift review показывает, где реальное состояние отличается от Terraform state и репозитория. После этого нужно решить: импортировать ресурс, описать изменение кодом, зафиксировать исключение или убрать ручную правку.

запускать plan на регулярной основе и после критичных ручных изменений;

вести список ресурсов, которые временно не управляются Terraform;

импортировать ручные ресурсы малыми группами, с backup state и dry-run;

отдельно проверять IAM, DNS, networks, security groups, Kubernetes node groups и managed databases;

фиксировать исключения явно, чтобы drift не становился скрытой нормой.

Где заканчивается Terraform и начинается GitOps

Terraform и GitOps часто смешивают. В простой модели Terraform отвечает за инфраструктурные ресурсы: cloud, сети, IAM, Kubernetes clusters, registry, DNS, managed services. GitOps отвечает за состояние приложений и Kubernetes-манифестов внутри кластера.

Argo CD или Flux помогают видеть, что реально применено в Kubernetes, кто менял manifests и почему кластер ушёл от Git. Но если cloud/IAM/storage не описаны через IaC, GitOps не решит весь infrastructure drift.

Terraform: cloud resources, IAM, networks, clusters, managed services, DNS, registry;

Helm/Kustomize: упаковка Kubernetes-конфигураций;

Argo CD/Flux: sync, health, diff и rollback Kubernetes workloads;

CI/CD: проверки, approvals, promotion между окружениями;

runbook: кто делает emergency change и как возвращает его в код.

План внедрения без большого риска для production

Не стоит переводить всю инфраструктуру в Terraform одним большим заходом. Безопаснее начать с inventory, выбрать ограниченный scope и двигаться через маленькие проверяемые изменения.

Если Terraform уже есть, первым шагом часто становится не новая автоматизация, а аудит: state, modules, drift, ручные изменения, права, CI-проверки и документация по apply.

собрать inventory ресурсов и связать их с сервисами/владельцами;

оценить state, backend, modules, provider versions и ручные изменения;

выбрать первый безопасный scope: labels, DNS, monitoring, отдельные IAM/service accounts или non-critical resources;

настроить CI: fmt, validate, plan, policy checks и approvals;

документировать apply, rollback, emergency changes и порядок возврата ручных правок в код.

Что должно быть на выходе

Результат настройки Terraform и IaC — не просто красивый репозиторий. Команда должна понимать, где живёт state, кто владеет modules, как читать plan, где разрешены исключения и как безопасно применить изменение в production.

Если после внедрения Terraform команда продолжает менять ресурсы руками и боится plan, значит процесс не заработал. Нужно возвращаться к drift review, ownership, smaller scopes и понятной модели apply.

понятная структура modules/environments и owners;

remote state с locking, backup и правилами доступа;

CI/CD проверки terraform fmt, validate, plan и policy gates;

регулярный drift review и список исключений;

план сопровождения Terraform: provider updates, imports, module review и безопасный apply.

FAQ

Что такое infrastructure drift?

Это расхождение между описанием инфраструктуры в коде/state и реальным production. Drift часто появляется после ручных изменений в cloud console, срочных инцидентов, неполного импорта ресурсов или разных правил между окружениями.

Можно ли внедрить Terraform в уже работающую инфраструктуру?

Да, но поэтапно: inventory, backup state, dry-run, импорт небольших групп ресурсов и проверка plan до apply. Самые критичные production-ресурсы лучше переносить отдельно, с понятным blast radius и откатом.

GitOps заменяет Terraform?

Нет. GitOps обычно управляет Kubernetes-манифестами и sync внутри кластера. Terraform чаще управляет cloud resources, IAM, network, managed services, DNS и самим кластером. В production они дополняют друг друга.

Как безопасно запускать terraform apply в production?

Через маленький scope, review plan, approvals, locking, backup state и согласованное окно изменений. Apply не должен зависеть от личной машины одного инженера и не должен выполняться без понятного rollback/emergency plan.