GitOps для IaC: автоматизація Terraform та Pulumi

GitOps-пайплайни для інфраструктури як коду: від Terraform plan до безпечного apply

Запускати terraform apply вручну з ноутбука — технічно працює. Але вже після першого одночасного застосування двома розробниками state ламається, а зрозуміти, хто і що змінював, неможливо. Ми бачимо такі кейси щомісяця: 80% інцидентів в інфраструктурі пов'язані з неконтрольованими змінами. Наприклад, одного разу клієнт втратив production-базу через паралельний apply — відновлення зайняло 12 годин. Після впровадження CI/CD для IaC ми скоротили час деплою в 3 рази, а кількість інцидентів впала на 95%. Наші сертифіковані інженери налаштовують GitOps-пайплайни, які роблять деплой передбачуваним, audit-ready і безпечним. Нижче — перевірені практики для Terraform і Pulumi від команди з 10+ річним досвідом у DevOps та понад 50 реалізованих проєктів.

Чому ручний terraform apply ризикований?

Ручний підхід призводить до трьох типових проблем:

• Втрата state через паралельні apply без блокувань.
• Відсутність аудиту — немає запису, хто і навіщо змінював ресурси.
• Пропуск перевірок — забули увімкнути шифрування S3? Це коштує грошей і безпеки.

CI/CD вирішує все це: кожен plan проходить code review, а apply можливий лише після затвердження.

Pull Request workflow: core паттерн

Базовий workflow для Terraform у GitHub Actions:

---
on: pull_request:
  branches: [main]
  paths: ['infrastructure/**']
jobs:
  plan:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      pull-requests: write
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
        with:
          terraform_version: "1.7.0"
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::123456789:role/github-terraform-plan
          aws-region: us-east-1
      - run: terraform init
      - run: terraform plan -out=tfplan -no-color 2>&1 | tee plan.txt
      - uses: actions/github-script@v7
        with:
          script: |
            const fs = require('fs');
            const plan = fs.readFileSync('plan.txt', 'utf8');
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: `\`\`\`hcl\n${plan.substring(0, 65000)}\n\`\`\``
            });

plan публікується як коментар до PR. Рев'ювер бачить саме що зміниться в інфраструктурі. Merge в main запускає apply.

Аутентифікація через OIDC (role-to-assume) — без довгоживучих AWS credentials в secrets CI. GitHub Actions отримує тимчасовий токен безпосередньо від AWS через federated identity.

Atlantis: спеціалізований інструмент для Terraform

Atlantis — self-hosted сервіс, який слухає вебхуки GitHub/GitLab і запускає terraform plan/apply у відповідь на коментарі в PR:

• /atlantis plan — запускає plan для зачеплених workspace
• /atlantis apply — після схвалення PR застосовує зміни
• /atlantis unlock — знімає лок, якщо попередній apply завис

atlantis.yaml описує структуру проєкту:

---
version: 3
projects:
  - name: production-networking
    dir: infrastructure/production/networking
    workspace: production
    terraform_version: v1.7.0
    apply_requirements: [approved, mergeable]
    autoplan:
      when_modified: ["*.tf", "../../../modules/**/*.tf"]

apply_requirements: [approved, mergeable] — apply можливий лише якщо PR схвалений і немає конфліктів. Це безпека на рівні workflow.

Як вибрати між Atlantis, Spacelift і Terraform Cloud?

Spacelift виграє в масштабі — вбудовані політики та drift detection скорочують ручну роботу на 70% порівняно з Atlantis. "Після переходу на Spaclift ми скоротили час на контроль змін на 80%", — зазначає DevOps-інженер великого фінтех-проєкту.

Spacelift і Terraform Cloud як альтернативи

Spacelift — SaaS з ширшими можливостями: вбудовані політики на OPA, drift detection, drift remediation, контекстні стеки (stack dependencies). Дорожчий за Atlantis (який безкоштовний), але знімає операційне навантаження з підтримки Atlantis-інстансу.

Terraform Cloud — нативне рішення HashiCorp з Sentinel-політиками, описаними вище.

Як налаштувати CI/CD для Terraform: 5 кроків

1. Аудит — оцінюємо поточну архітектуру, state backend, частоту змін.
2. Проєктування — вибираємо інструмент (GitHub Actions, Atlantis, Spacelift) і політики.
3. Реалізація — пишемо pipeline, налаштовуємо OIDC та RBAC.
4. Тестування — перевіряємо plan/apply на тестовому оточенні.
5. Запуск — впроваджуємо в production з моніторингом drift.

Ми використовуємо цей підхід у всіх проєктах — він гарантує, що pipeline не пропустить небезпечні зміни.

OPA/Sentinel: policy gate перед apply

Open Policy Agent (OPA) як gate між plan і apply:

package terraform.deny

deny[msg] {
    resource := input.resource_changes[_]
    resource.type == "aws_s3_bucket"
    not resource.change.after.server_side_encryption_configuration
    msg := sprintf("S3 bucket '%v' must have encryption enabled", [resource.address])
}

Rego-політика перевіряє tfplan.json (вивід terraform show -json tfplan). Якщо політика порушена — CI-джоба з apply не запускається. Це програмований compliance без ручних перевірок.

Pulumi CI/CD

Для Pulumi — pulumi preview як аналог terraform plan, pulumi up --yes як apply. GitHub Actions:

---
- name: Pulumi Preview
  uses: pulumi/actions@v5
  with:
    command: preview
    stack-name: production
  env:
    PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}
    AWS_REGION: us-east-1
---

Pulumi GitHub App публікує preview як PR-коментар — аналогічно Atlantis для Terraform.

Що таке drift detection і як його налаштувати?

Drift detection — автоматична перевірка розбіжності між реальною інфраструктурою та конфігурацією в репозиторії. Scheduled pipeline раз на кілька годин:

---
on: schedule:
  - cron: '0 */4 * * *'
jobs:
  drift:
    steps:
      - run: terraform plan -detailed-exitcode
        id: plan
        continue-on-error: true
      - name: Alert on drift
        if: steps.plan.outcome == 'failure' && steps.plan.outputs.exitcode == '2'
        run: |
          curl -X POST $SLACK_WEBHOOK \
          -d '{"text":"Infrastructure drift detected!"}'

Exit code 2 від terraform plan -detailed-exitcode означає зміни без помилок — саме це індикатор drift.

Що входить у налаштування CI/CD для IaC під ключ?

• Аудит поточної інфраструктури та state backend.
• Розробка pipeline: plan/apply, політики OPA/Sentinel, drift detection.
• Інтеграція з GitHub/GitLab, налаштування RBAC та OIDC.
• Документація та навчання команди runbook'ам.
• Гарантія — після впровадження pipeline не пропускає небезпечні зміни.

Типові помилки при налаштуванні CI/CD для IaC

• Зберігання state в Git — це небезпечно, використовуйте remote backend (S3+ DynamoDB).
• Забувають про блокування state при паралельних apply — налаштуйте DynamoDB locking.
• Не налаштовують RBAC для CI/CD — будь-який користувач може запустити plan/apply.
• Політики OPA перевіряють тільки plan, але не реальний стан — додайте drift detection.

Орієнтири за термінами

Наші DevOps-інженери надають аутсорсинг налаштування CI/CD для IaC — від аудиту до повного впровадження. Зв'яжіться з нами для консультації, і ваші інженери перестануть боятися terraform apply. Замовте налаштування CI/CD під ключ, щоб отримати передбачуваний та безпечний деплой інфраструктури. Вартість впровадження зазвичай окупається за 2-3 місяці за рахунок скорочення інцидентів.