זיהוי סטיית Terraform: אוטומציה, CI/CD, התראות

Terraform Drift Detection: Automation, CI/CD, Alerts

תארו לעצמכם: הסביבת הייצור שלכם רצה יציב, אבל אחרי terraform apply שירות פתאום קורס. מסתבר שעמית שינה ידנית קבוצת אבטחה בקונסולת AWS "לחמש דקות", וה-apply הבא דרס את העריכה הזו. זהו drift — הפער בין הקוד למציאות. הוא מצטבר בשקט ומתבטא ברגע הגרוע ביותר. לפי נתוני התעשייה, יותר ממחצית מתקלות תשתית הענן קשורות ל-drift. מקור בפרויקט אחד עם 500 רשומות משאבים, drift הצטבר במשך 3 שבועות עד שצומת Kubernetes קריטי נכשל. לאחר הגדרת ה-plan האוטומטית שלנו, אי-התאמות זוהו תוך 10 דקות לפני ה-apply. אנחנו צוות של מהנדסי DevOps עם ניסיון בתשתית ענן. אנו נקים זיהוי drift אוטומטי turnkey כך שתמיד תדעו על הבדלים לפני שהם גורמים לתקלה.

מה זה Drift ולמה הוא מסוכן

Drift הוא ההבדל בין מה שמתואר בתצורת ה-Terraform שלכם (והשמור ב-state) לבין מה שבאמת קיים בענן. גורמים: עריכות ידניות בקונסולה, עדכוני שדות אוטומטיים של הספק, applies מענפים מיושנים. Drift יכול להוביל לזמן השבתה בלתי צפוי, אובדן נתונים או פרצות אבטחה. לדוגמה, שינוי מקרי בכללי חומת אש יכול לחשוף מסד נתונים.

terraform plan הוא הכלי המרכזי לזיהוי drift. הוא משווה את ה-state עם המשאבים האמיתיים ומראה שינויים. אם plan מראה שינויים במקום שבו אף אחד לא נגע בקוד, זהו אות ל-drift.

למה אוטומציה של זיהוי Drift היא קריטית

הרצה ידנית של plan לפני כל deploy אינה מספיקה. Drift יכול להתרחש בין גרסאות. אוטומציה מספקת:

• זיהוי מוקדם של אי-התאמות (לפני החלת שינויים)
• הפחתת MTTR משעות לדקות — פי 10 מהר יותר מחיפוש ידני. הלקוח שלנו הפחית את ה-MTTR משעתיים ל-10 דקות, וחוסך כ-$2,500 לכל תקלה.
• ביקורת על שינויי ענן שעקפו את Git

אנו מבטיחים יציבות תשתית: לאחר ההתקנה, תקבלו התראות drift קבועות בערוץ המועדף עליכם. האוטומציה שלנו מזהה drift תוך 5 דקות מהתרחשותו. טיפלנו ביותר מ-200 אירועי drift בשנה האחרונה.

איך אנו מגדירים זיהוי Drift

אנו מתקינים זאת על כל 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

המפתח הוא # .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 : קוד יציאה 0 — אין שינויים, 1 — שגיאה, 2 — drift. אנו מגיבים רק לקוד 2.

עבור Atlantis, אנו משתמשים ב-PR drift ייעודי שנוצר מחדש בכל ריצה. ל-Spacelift ו-Terraform Cloud יש זיהוי drift מובנה — אנו מפעילים אותו תוך יום אחד.

השוואת שיטות לזיהוי Drift

תדירות בדיקה מומלצת

מה לעשות עם Drift שזוהה

שלוש אפשרויות:

• החזרה באמצעות apply — אם שינוי הענן אינו רצוי (מישהו ערך ידנית), -detailed-exitcode משחזר את התצורה כך שתתאים לקוד. זהו התרחיש המרכזי.
• עדכון תצורה — אם השינוי מכוון, עדכנו את קובץ ה-terraform apply, צרו PR, ואזמזגו. לאחר המיזוג ה-drift נעלם.
• הוספת .tf — אם שדה מנוהל על ידי שירות חיצוני (למשל, lifecycle { ignore_changes } ב-Auto Scaling Group).

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

התהליך שלנו

1. ביקורת על תשתית ה-Terraform הנוכחית: ניתוח קבצי state, pipeline, וספקים. קביעת היקף וצווארי בקבוק. איסוף כל קבצי ה-state וחשבונות ספק הענן המתאימים.
2. בחירת שיטת זיהוי ה-drift האופטימלית למחסנית ולתקציב שלכם. התחשבות בתדירות השינויים, מספר המשאבים ודרישות האבטחה.
3. הגדרת משימה מתוזמנת (CI/CD או שירות חיצוני) בתדירות הנדרשת. התאמה לתשתית שלכם.
4. שילוב התראות (Slack, PagerDuty, Telegram) עם פרטי השינוי. הוספת צבירת התראות להפחתת רעש.
5. תיעוד התהליך ו-runbook לאירועים. הכשרת הצוות שלכם לטיפול ב-drift.
6. תמיכה לאחר ההשקה: חודש של ייעוץ והתאמות.

מה כלול

• תוצאות ביקורת: דוח על מצב התשתית הנוכחי, סיכונים שזוהו והמלצות.
• זיהוי drift מוגדר: שיטה נבחרת עם תדירות והתראות רצויות.
• תיעוד: תיאור תהליך, runbook, הוראות לצוות.
• הכשרה: סדנה למהנדסים שלכם על drift ותגובה.
• תמיכה: חודש של ליווי לאחר ההשקה, כולל התאמות הגדרות.

מדדים וויזואליזציה

לפרויקטים גדולים, אנו משלימים את ההתראות עם מדדים: ייצוא מספר המשאבים עם drift ל-Prometheus דרך exporter מותאם. אבל עבור 90% מהצוותים, התראות Slack עם פלט desired_capacity מספיקות. אופציונלית, ניתן להגדיר לוחות מחוונים של Grafana למעקב אחר drift בין סביבות.

ציר זמן ואיך להתחיל

התקנה סטנדרטית אורכת 1 עד 3 ימים תלוי במספר קבצי ה-state והפלטפורמה. ההתקנה בדרך כלל אורכת יומיים, ומצטמצמת ליום אחד בסביבות פשוטות. צרו קשר — נעריך את הפרויקט שלכם ונציע פתרון. קבלו ייעוץ על אוטומציית drift עוד היום.