GitLab CI
Тема дорожной карты · Terraform
GitLab CI для Terraform автоматизирует полный жизненный цикл IaC — terraform init, terraform validate, terraform plan и terraform apply — в стадиях конвейера .gitlab-ci.yml, которые запускаются при merge request'ах и пушах в защищённые ветки. GitLab предоставляет управляемый бэкенд Terraform state (gitlab remote state), что избавляет команды от необходимости держать отдельный S3-бакет для блокировки состояния, упрощая настройку для проектов на AWS, Azure или GCP. Официальный Docker-образ registry.gitlab.com/gitlab-org/terraform-images включает terraform, tflint и вспомогательные утилиты, обеспечивая согласованность задач plan и apply на всех GitLab CI-раннерах. GitLab CI для Terraform поддерживает среда-специфичные tfvars через переменные CI/CD, аутентификацию в облаке через OIDC и ручные gates подтверждения для задач apply, чтобы непроверенные изменения не попадали в production. Интеграция проверок Checkov или OPA как стадии validate перед terraform plan гарантирует, что каждый merge request проверяется на наличие некорректных конфигураций безопасности до создания инфраструктуры.
Как это работает
GitLab CI обычно: PR открыт → CI гоняет terraform fmt -check, validate, tflint, tfsec, потом terraform plan против state целевой среды и постит plan комментом в PR. На merge в main → CI делает terraform apply автоматически (с гейтами одобрения для prod). Инструменты: Atlantis (open-source PR-автоматизация), Terraform Cloud / Enterprise (managed-предложение HashiCorp), env0, Spacelift, GitHub Actions / GitLab CI с кастомными workflow.
Когда применять
Автоматизируйте весь flow до деплоя в production. PR-comment с plan — killer-фича: ревьюеры видят, что именно меняется. Требуйте approval до apply для production (ручной гейт). Запускайте plan по расписанию (drift-detection) — выявляет ручные изменения. Для RF / суверенности — self-host Atlantis на Yandex Cloud + GitLab-раннер; избегайте Terraform Cloud (US-hosted).
Типичные ошибки
Ловушки GitLab CI: auto-apply в prod без approval-гейта (один плохой PR = плохой prod); долгие plan, превышающие время CI-раннера (делите на меньшие root-модули); credentials в CI-логах (маскируйте, никогда не echo); не обработаны конкурентные PR за один lock (Atlantis ставит в очередь; Terraform Cloud сериализует).