הגדרת Terraform Plan/Apply אוטומטי בצנרת CI/CD

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

# backend.tf terraform { backend "s3" { bucket = "mycompany-terraform-state" key = "production/main.tfstate" region = "eu-west-1" dynamodb_table = "terraform-state-lock" encrypt = true } } עבור State Locking הוא קריטי. ללא נעילה, שני dynamodb_table במקביל (למשל, שני PRs שמוזגים בו-זמנית) יכולים להוביל ל-state פגום או לשינויי תשתית מתנגשים.

איך להגן על סביבת הייצור במהלך Apply אוטומטי?

עיקרון מפתח — סכמה דו-שלבית: plan אוטומטי, apply ידני עם הרשאות ייצור. אנו מוסיפים terraform apply לשלב ה-apply ומשתמשים ב-when: manual להפרדת גישה. בנוסף, RBAC ב-GitLab/GitHub מוגדר כך שרק משתמשים מסוימים יכולים לאשר apply.

עבור שינויים קריטיים (מחיקת משאבים), ניתן להוסיף כללי אישור — למשל, לבקש אישור נפרד ממנהל הצוות.

Pipeline: Plan על PR, Apply לאחר Merge

סכמה דו-שלבית סטנדרטית עם 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

environment: production על apply הוא חובה לייצור. Plan רץ אוטומטית, apply דורש לחיצת כפתור מאדם עם ההרשאות המתאימות.

איך להגדיר תגובה אוטומטית של תוצאות Plan ב-Pull Request?

הדבר הכי valuable ב-terraform pipeline הוא לראות את ה-diff ישירות ב-PR, מבלי ללכת ל-CI. לשם כך, אנו משתמשים ב-Atlantis או בסקריפט מותאם עם GitHub/GitLab API. Atlantis מספק פידבק מהיר פי 2 בזכות תגובות בזמן אמת בהשוואה לפתרונות מובנים.

ב-GitHub Actions באמצעות # .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 :

---
- 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 עם פלט ה-when: manual המלא: מה יתווסף, ישתנה, יימחק. ב-commits הבאים לענף, התגובה מתעדכנת, לא נוצרת מחדש.

Atlantis לעבודת צוות — הגדרת Terraform אוטומטית

אם הצוות גדול וזקוק ל-workflow מלא עם פקודות 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 }} ישירות מתגובות PR — Atlantis מתמודד עם זה out of the box. הוא רץ כשירות נפרד (Helm chart בקלאסטר או VM עצמאי), נרשם ל-GitHub/GitLab webhooks.

---
# 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]
---

terraform plan — apply בלתי אפשרי ללא אישור PR וסטטוס "mergeable" (כל הבדיקות הנדרשות עברו).

אבטחה: אישורים ב-CI

אישורי AWS סטטיים ב-CI Variables מקובלים להתחלה, אבל האפשרות הטובה ביותר היא שילוב OIDC. מערכת ה-CI מקבלת token זמני דרך OIDC וממירה אותו ל-IAM role באמצעות apply_requirements: [approved, mergeable]. ללא סודות ארוכי טווח.

---
- 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 role מוגדר עם trust policy המוגבל ל-repo וענף ספציפיים. ה-token חי למשך שעה ולא יכול לדלוף מה-pipeline.

מה כלול בעבודה (תוצרים)

לוח זמנים ואיך להתחיל

שילוב plan/apply בסיסי ב-GitLab CI עם state מרוחק — מיום אחד. הגדרה עם Atlantis, OIDC, תגובות אוטומטיות, ואסטרטגיית workspaces לסביבות מרובות — מיומיים עד 3 ימים. העלות מחושבת באופן אישי לאחר בדיקת תשתית ה-IaC הנוכחית שלכם. קבלו ייעוץ — המהנדסים שלנו יעריכו את הפרויקט שלכם ויציעו את הפתרון האופטימלי.