Виявлення дрейфу Terraform: автоматизація, CI/CD, сповіщення

Виявлення дрейфу Terraform: автоматизація, CI/CD, сповіщення

Уявіть: ваш продакшен працює стабільно, але раптово після чергового terraform apply падає сервіс. З'ясовується, що хтось із колег вручну змінив security group у консолі AWS «на 5 хвилин», а наступний apply перезатер цю правку. Це дрейф (drift) — розбіжність між кодом і реальністю. Він накопичується непомітно і проявляється в найнесподіваніший момент. Згідно з галузевими даними, понад половина інцидентів у хмарній інфраструктурі пов'язані з дрейфом. На одному проекті з 500 ресурсними записами дрейф накопичувався 3 тижні, поки не впала критична нода Kubernetes. Після нашого налаштування автоматичного plan розбіжності виявлялися за 10 хвилин до apply. Ми — команда DevOps-інженерів з досвідом у хмарній інфраструктурі. Налаштуємо автоматичне виявлення дрейфу під ключ, щоб ви завжди знали про розбіжності до того, як вони викличуть інцидент. Отримайте консультацію з автоматизації дрейфу вже сьогодні.

Що таке дрейф і чому він небезпечний

Drift — це розбіжність між тим, що описано в Terraform-конфігурації (і закріплено в state), і тим, що реально існує в хмарі. Причини: ручні правки в консолі, автооновлення полів провайдером, apply з застарілої гілки. Дрейф може призвести до несподіваних простоїв, втрати даних або порушення безпеки. Наприклад, випадкова зміна правил firewall відкриває доступ до бази даних.

terraform plan — головний інструмент виявлення дрейфу. Він порівнює state з реальними ресурсами і показує зміни. Якщо plan показує зміни там, де ніхто не змінював код — це сигнал дрейфу.

Чому автоматизація виявлення дрейфу критична?

Ручний запуск plan перед кожним деплоєм — недостатньо. Дрейф може виникнути між релізами. Автоматизація дає:

• Раннє виявлення розбіжностей (до застосування змін)
• Зниження MTTR з годин до хвилин — у 10 разів швидше ручного пошуку
• Аудит змін у хмарі, що не пройшли через Git

Ми гарантуємо стабільність вашої інфраструктури: після налаштування ви отримаєте регулярні сповіщення про дрейф у зручний канал.

Як ми налаштовуємо drift detection?

Налаштовуємо на будь-якому CI/CD: GitLab CI, GitHub Actions, Atlantis, Terraform Cloud, Spacelift. Приклад для GitLab CI:

---
# .gitlab-ci.yml
drift-detection:
  stage: check
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  script:
    - terraform init -reconfigure
    - terraform plan -detailed-exitcode -out=drift.plan 2>&1 | tee plan.log
  after_script:
    - |
      if [ $? -eq 2 ]; then
        curl -X POST $SLACK_WEBHOOK -d '{"text":"Terraform drift detected in production!"}'
      fi

Ключове — -detailed-exitcode: код 0 — немає змін, 1 — помилка, 2 — дрейф. Реагуємо тільки на код 2.

Для Atlantis використовуємо окремий drift PR, який перестворюється при кожному запуску. Spacelift і Terraform Cloud мають вбудований drift detection — ми підключаємо його за 1 день.

Порівняння методів drift detection

Рекомендована частота перевірок

Що робити з виявленим дрейфом?

Три варіанти:

• Відновити через apply — якщо зміна в хмарі небажана (хтось поправив руками), terraform apply поверне конфіг у відповідність до коду. Це основний сценарій.
• Оновити конфіг — якщо зміна навмисна, оновлюємо .tf-файл, робимо PR, мержимо. Після merge дрейф зникне.
• Додати lifecycle { ignore_changes } — якщо поле керується зовнішнім сервісом (наприклад, desired_capacity у Auto Scaling Group).

resource "aws_autoscaling_group" "main" { lifecycle { ignore_changes = [desired_capacity] } } 

Процес роботи

1. Аудит поточної інфраструктури Terraform: аналізуємо state-файли, pipeline, провайдери. Визначаємо обсяг і вузькі місця.
2. Вибір оптимального методу drift detection під ваш стек і бюджет. Враховуємо частоту змін, кількість ресурсів, вимоги до безпеки.
3. Налаштування scheduled job (CI/CD або зовнішній сервіс) з потрібною частотою. Пиляємо під вашу інфраструктуру.
4. Інтеграція сповіщень (Slack, PagerDuty, Telegram) з деталізацією змін. Додаємо агрегацію алертів для зниження шуму.
5. Документація по процесу та runbook для інцидентів. Навчаємо команду роботі з drift detection.
6. Підтримка після запуску: 1 місяць консультацій та доналаштувань.

Що входить в роботу

• Результати аудиту: звіт по поточному стану інфраструктури, виявлені ризики та рекомендації.
• Налаштований drift detection: вибраний метод з потрібною частотою та сповіщеннями.
• Документація: опис процесу, runbook, інструкції для команди.
• Навчання: воркшоп для ваших інженерів по роботі з drift та реагуванню.
• Підтримка: місяць супроводу після впровадження, включаючи коригування налаштувань.

Метрики та візуалізація

Для великих проектів доповнюємо алертинг метриками: експортуємо кількість ресурсів з drift у Prometheus через кастомний експортер. Але для 90% команд достатньо Slack-сповіщень з текстом terraform plan. Додатково можна налаштувати дашборди в Grafana для відстеження дрейфу по середовищах.

Терміни та як почати

Стандартне налаштування займає від 1 до 3 днів залежно від кількості state-файлів та платформи. Зв'яжіться з нами — оцінимо ваш проект і запропонуємо рішення. Отримайте консультацію з автоматизації дрейфу вже сьогодні.