Настройка автоматического Terraform Plan/Apply в CI/CD

# backend.tf	erraform {
  backend "s3" {
    bucket         = "mycompany-terraform-state"
    key            = "production/main.tfstate"
    region         = "eu-west-1"
    dynamodb_table = "terraform-state-lock"
    encrypt        = true
  }
}

dynamodb_table для State Locking — критично. Без блокировки два одновременных terraform apply (например, два PR мержатся одновременно) могут привести к corrupt state или конфликтующим изменениям инфраструктуры.

Как защитить production-окружение при автоматическом apply?

Ключевой принцип — двухступенчатая схема: plan автоматически, apply вручную с правами production. Мы добавляем when: manual на apply-стадию и используем environment: production для разграничения доступа. Дополнительно настраивается RBAC в GitLab/GitHub: только определённые пользователи могут подтверждать apply.

Для критических изменений (удаление ресурсов) можно добавить approval-правила — например, запросить отдельный апрув от тимлида.

Пайплайн: plan на PR, apply после мержа

Стандартная двухступенчатая схема с validate:

# .gitlab-ci.yml
stages:
  - validate
  - plan
  - apply

terraform:validate:
  stage: validate
  image: hashicorp/terraform:1.7
  script:
    - terraform init -backend=false
    - terraform validate
    - terraform fmt -check -recursive
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

terraform:plan:
  stage: plan
  image: hashicorp/terraform:1.7
  script:
    - terraform init
    - terraform plan -out=tfplan -var-file="environments/${ENV}/terraform.tfvars"
    - terraform show -json tfplan > tfplan.json
  artifacts:
    paths:
      - tfplan
      - tfplan.json
    expire_in: 1 week
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == "main"

terraform:apply:
  stage: apply
  image: hashicorp/terraform:1.7
  script:
    - terraform init
    - terraform apply -auto-approve tfplan
  dependencies:
    - terraform:plan
  rules:
    - if: $CI_COMMIT_BRANCH == "main"
      when: manual
  environment:
    name: production

when: manual на apply — обязательно для production. Plan выполняется автоматически, apply требует нажатия кнопки от человека с нужными правами.

Как настроить автокомментарий plan-результата в Pull Request?

Самое ценное в terraform-пайплайне — видеть diff прямо в PR, без захода в CI. Для этого используется Atlantis или написанный скрипт с GitHub/GitLab API. Atlantis обеспечивает в 2 раза более быструю обратную связь за счёт комментариев в реальном времени по сравнению с встроенными решениями.

В GitHub Actions с использованием dflook/terraform-github-actions:

---
- name: Terraform Plan
  uses: dflook/terraform-plan@v1
  with:
    path: infrastructure/
    var_file: |
      environments/production/terraform.tfvars
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
    AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}

Action автоматически добавляет комментарий к PR с полным выводом terraform plan: что будет добавлено, изменено, удалено. При последующих коммитах в ветку комментарий обновляется, а не создаётся новый.

Atlantis для командной работы — настройка автоматического terraform

Если команда большая и нужен полноценный workflow с /atlantis plan и /atlantis apply командами прямо из комментариев PR — Atlantis решает это из коробки. Запускается как отдельный сервис (Helm chart в кластере или standalone VM), подписывается на webhook'и GitHub/GitLab.

# atlantis.yaml version: 3
projects:
  - name: production
    dir: infrastructure/environments/production
    workspace: production
    autoplan:
      when_modified: ["*.tf", "../modules/**/*.tf"]
      enabled: true
    apply_requirements: [approved, mergeable]

apply_requirements: [approved, mergeable] — apply невозможен без апрувала PR и без статуса "mergeable" (все обязательные checks прошли).

Безопасность: credentials в CI

Статические AWS credentials в CI Variables — приемлемо для начала, но лучший вариант — OIDC-интеграция. CI-система получает временный токен через OIDC, обменивает его на IAM-роль через aws sts assume-role-with-web-identity. Никаких долгоживущих секретов.

---
- name: Configure AWS credentials via OIDC
  uses: aws-actions/configure-aws-credentials@v4
  with:
    role-to-assume: arn:aws:iam::123456789:role/github-actions-terraform
    aws-region: eu-west-1
---

IAM-роль настраивается с trust policy, ограниченной конкретным репозиторием и веткой. Токен живёт 1 час и не может утечь из пайплайна.

Что входит в работу (deliverables)

Сроки и как начать

Базовая интеграция plan/apply в GitLab CI с remote state — от 1 дня. Настройка с Atlantis, OIDC, автокомментариями и workspace-стратегией для нескольких окружений — от 2 до 3 дней. Стоимость рассчитывается индивидуально после аудита текущей IaC-инфраструктуры. Получите консультацию — наши инженеры оценят ваш проект и предложат оптимальное решение.