מה זה Terraform בקצרה?

כלי Infrastructure as Code (IaC) שמאפשר להגדיר תשתיות ענן (שרתים, רשתות, Kubernetes) כקוד מוצהר. כותבים .tf, מריצים plan/apply – ותשתית מוכנה.

מתי צריך Remote State ולא Local?

תמיד בצוות/פרודקשן. Local state מתאים רק לניסויים אישיים. Remote (S3+DynamoDB) נותן locking, versioning, גיבוי ואבטחה.

מה ההבדל בין terraform plan ל-apply?

plan = preview צבעוני של שינויים בלי לבצע (+ ירוק=יצירה, ~ צהוב=שינוי). apply = מבצע בפועל ומבקש אישור.

איך משלבים Terraform ב-CI/CD?

PR → CI: fmt/validate/plan (artifact) → Merge → CD: apply. כל שינוי עובר review, אין apply ידני בפרודקשן.

איך מתחילים עם Terraform ב-AWS?

התקן Terraform + AWS CLI. צור main.tf עם provider AWS + EC2 פשוט. הרץ terraform init, plan ו-apply. בדוק ב-AWS Console, והשתמש ב-terraform destroy בסיום.

ללמוד Terraform: Infrastructure as Code

תוכן עניינים

Terraforrn מרכז ההתשתית כקוד של אנשי הדבאופס

מושגיי יסוד של Terraform

איך עובדים עם Terraform ( בסיסי )

מבנה הפרויקט ב Terraform

שימושים נפוצים ב Terraform

Terraform inside Gitops for CI/CD

ניהול אבטחה וBest Practices

FAQ ל Terraform

Terraforrn מרכז ההתשתית כקוד של אנשי הדבאופס

Terraform: Infrastructure as Code בלב DevOps

Terraform הוא כלי מוביל ל-Infrastructure as Code (IaC) – גישה שבה תשתיות IT (שרתים, רשתות, Kubernetes, מסדי נתונים) מוגדרות כקוד מוצהר שנשמר ב-Git ומבוצע אוטומטית. בתוך תהליך DevOps, Terraform נכנס בשלבי תשתית ואוטומציה – בין CI/CD לבניית סביבות, ומאפשר למהנדסי DevOps להקים, לעדכן ולנהל תשתיות ענן מורכבות בצורה שחזורית ומבוקרת.

למה דווקא Terraform? הוא מבטיח עקביות בין סביבות (אותו קוד = אותה תשתית ב-dev/staging/prod), סקייל לניהול מאות משאבים מרובי עננים, ואוטומציה מלאה שמחליפה לחיצות ידניות בקונסול. מול ניהול ידני ("לחיצות באוויר"), Terraform מביא שקיפות, גרסאות ושיתוף ידע.

Terraform מול כלים אחרים: פשוט יותר מ-AnsiBle (פחות agent-based), מוכוון תשתית יותר מ-Pulumi (לא דורש שפת תכנות), ובעל community ענק יותר מ-Pulumi או CloudFormation. בגובה העיניים – אם אתה ב-DevOps, Terraform הוא ה"שפה המשותפת" שכולם מכירים.

מושגיי יסוד של Terraform

הבסיס של המערכת, כדאי להכיר אותם

קבצי קונפיגורציה ושפת HCL

Terraform פועל על קבצי קונפיגורציה עם סיומת .tf (או .tf.json), שנכתבים בשפת HCL (HashiCorp Configuration Language) – שפה מוצהרת, קריאה ודומה ל-JSON אך ידידותית יותר למפתחים. הקבצים מגדירים את התשתית הרצויה בצורה declarative: אתה מצהיר "מה" אתה רוצה (למשל, שרת עם 4GB RAM), ו-Terraform דואג "איך" ליישם את זה.

Providers, Resources, Data Sources

Providers: "מתווכים" שמחברים את Terraform לספקי ענן (כמו AWS, Azure, GCP) או שירותים אחרים. דוגמה: provider "aws" { region = "us-east-1" }.
Resources: המשאבים עצמם – ה"לב" של הקוד. מגדירים VM, רשת או DB: resource "aws_instance" "web" { ami = "ami-123" instance_type = "t3.micro" }.
Data Sources: מאפשרים לשלוף מידע קיים מהתשתית (ללא יצירה), כמו AMI זמין או VPC קיים: data "aws_ami" "latest" { ... }.

Desired State, Plan, Apply, State File

Desired State: המצב הרצוי שכתבת בקוד – Terraform משווה אותו למציאות.
Plan: terraform plan מציג preview של שינויים (מה ייווצר/ישתנה/יימחק) בלי לבצע.
Apply: terraform apply מבצע את השינויים בפועל, מעדכן את התשתית.
State File: קובץ terraform.tfstate ששומר את המצב הנוכחי של התשתית (local או remote). חיוני לשינויים עתידיים, ולכן צריך להגן עליו (remote state מומלץ בפרודקשן).

5 מושגים חשובים ב-Terraform

Provider – מתווך שמחבר את Terraform לספק ענן (AWS, Azure, GCP). מגדיר אישורים, אזור ותצורה בסיסית.
Resource – היחידה המרכזית: משאב כמו VM, רשת או DB ש-Terraform יוצר/מנהל בתשתית.
State File – קובץ terraform.tfstate ששומר את המצב הנוכחי של כל המשאבים; חיוני לתכנון שינויים.
Plan – פקודת terraform plan שמציגה preview של שינויים לפני ביצוע (מה ייווצר/ישתנה).
Apply – פקודת terraform apply שבונה/מעדכנת את התשתית לפי הקוד המוצהר.

איך עובדים עם Terraform ( בסיסי )

זרימת עבודה טיפוסית ב-Terraform

שלבי terraform init / plan / apply / destroy

Terraform פועל בלולאה מובנית של 4 פקודות עיקריות שיוצרות זרימה declarative:

terraform init – אתחול הפרויקט: הורדת providers, מודולים, הגדרת backend ל-state. רץ פעם אחת או אחרי שינויי providers.
terraform plan – תכנון: משווה את הקוד (desired state) למציאות, מציג preview צבעוני של שינויים (+ יצירה, ~ שינוי, - מחיקה).
terraform apply – ביצוע: מממש את התוכנית, מבקש אישור ומעדכן את התשתית + state file.
terraform destroy – הרס: מוחק את כל המשאבים (זהיר! דורש אישור מפורש).

איך נראית עבודה יומיומית עם Terraform

בוקר: git pull, terraform plan לבדיקת drift (שינויים ידניים שקורים לפעמים).
פיתוח: כותבים/משנים .tf, plan מקומי לבדיקה, commit + PR.
CI/CD: pipeline אוטומטי מריץ init/plan בכל push, מייצר plan file כ-artifact.
פרודקשן: approve ב-Slack/UI, pipeline מריץ apply עם locking על state.
תחזוקה: terraform state list לבדיקת משאבים, refresh לעדכון state.

בעיות נפוצות בשלב העבודה הראשוני

Provider לא מותקן: שכחו init → שגיאה "provider not found".
State קיים ולא תואם: מחקו state ידנית → terraform refresh או import.
הרשאות חסרות: API keys שגויים → apply נכשל באמצע.
Dependencies מעגליים: resource A תלוי ב-B ולהיפך → שינוי סדר/שימוש ב-data sources.
Version drift: שדרגו Terraform → init -upgrade לפני plan.

דף הנחיות בסיסי: Terraform למתחילים

התקנה ראשונית

הורד Terraform מ-terraform.io (בחר גרסה יציבה).
חלץ והוסף ל-PATH: export PATH=$PATH:$HOME/.terraform (Linux/Mac).
בדוק: terraform version – צריך להציג גרסה.
התקן editor תוסף: VS Code + HashiCorp Terraform extension.

פרויקט ראשון: שרת פשוט ב-AWS

צור תיקייה my-first-tf, כתוב 3 קבצים:

main.tf:

text

terraform {

  required_providers {

    aws = {

      source  = "hashicorp/aws"

      version = "~> 5.0"

    }

  }

}

provider "aws" {
region = "us-east-1"
}

resource "aws_instance" "web" {
ami = "ami-0c02fb55956c7d316" # Amazon Linux 2023
instance_type = "t3.micro"

tags = {
Name = "MyFirstTerraformServer"
}
}

variables.tf (אופציונלי):

text

variable "aws_region" {

  default = "us-east-1"

}

outputs.tf:

text

output "instance_ip" {

  value = aws_instance.web.public_ip

}

זרימת העבודה המלאה

bash

# 1. אתחול (פעם ראשונה בלבד)

terraform init

# 2. תכנון (תמיד!)
terraform plan

# 3. ביצוע (אישור ידני)
terraform apply

# 4. בדיקת תוצאות
terraform output

# 5. הרס (זהיר!)
terraform destroy

טבלה: מה כל פקודה עושה

פקודה	מה עושה	מתי להריץ
`init`	הורדת providers, backend setup	פעם ראשונה / שינוי providers
`plan`	Preview שינויים (+ יצירה, ~ שינוי, - מחיקה)	לפני כל apply
`apply`	בונה/מעדכן תשתית	אחרי plan מאושר
`destroy`	מוחק הכל	סיום ניסוי / cleanup

טעויות נפוצות + פתרונות

text

שגיאה: "provider not found"

פתרון: `terraform init`

שגיאה: "NoCredentialProviders"
פתרון: הגדר AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY

שגיאה: "state already locked"
פתרון: `terraform force-unlock <lock-id>`

תשתית קיימת?
פתרון: `terraform import aws_instance.web i-1234567890abcdef0`

צעדים הבאים

נסה את הדוגמה ב-AWS Free Tier
למד variables + מודולים (terraform-docs ל-documentation)
שדרג ל-remote state (S3 + DynamoDB)
הוסף ל-Git + GitHub Actions pipeline

טיפ זהב: תמיד plan לפני apply. תמיד backup ל-state file!

מבנה הפרויקט ב Terraform

חלוקה לקבצים: main, variables, outputs

פרויקט Terraform מאורגן בקבצי .tf נפרדים לאחריות ברורה:

text

my-terraform-project/
├── main.tf          # providers, resources מרכזיים, מודולים
├── variables.tf     # משתנים ניתנים להתאמה (region, instance_type)
├── terraform.tfvars # ערכי משתנים לסביבה ספציפית (לא ב-Git!)
├── outputs.tf       # פלטים חשובים (IP, ARN, endpoints)
├── versions.tf      # required_version, required_providers
└── README.md        # תיעוד + `terraform-docs`

דוגמה:

text

# main.tf
module "vpc" {
  source = "./modules/vpc"
  cidr_block = var.vpc_cidr
}

# variables.tf  
variable "vpc_cidr" {
  description = "VPC CIDR block"
  type        = string
  default     = "10.0.0.0/16"
}

מודולים – מתי ולמה להשתמש

מודולים הם "חבילות קוד" שניתן לשחזר. השתמש כש:

קוד חוזר (VPC בכל סביבה)
הפרדה לאחריות (רשת, DB, app)
שיתוף בין צוותים/פרויקטים

מתי לא: פרויקט זעיר (<50 שורות).

ארגון לפי סביבות (dev/stage/prod) ועבודה בצוות

text

terraform-org/
├── environments/
│   ├── dev/
│   │   ├── terraform.tfvars (instance_type = "t3.micro")
│   │   └── backend.tf (S3 bucket: dev-terraform-state)
│   ├── stage/ 
│   └── prod/
├── modules/
│   ├── vpc/
│   ├── ec2/
│   └── rds/
└── global/          # shared resources (DNS, IAM roles)

זרימת עבודה בצוות:

Branch per feature: git checkout -b vpc-ha
Local plan + terraform fmt/validate
PR → CI/CD: plan כ-artifact
Merge → auto-apply (dev) / manual approve (prod)

6 מודולים נפוצים ב-Terraform

מודול	תיאור	דוגמת שימוש
vpc	Virtual Private Cloud + subnets	`module "vpc" { source = "terraform-aws-modules/vpc/aws" }`
ec2	EC2 instances + security groups	Auto Scaling Group + Load Balancer
rds	Relational Database Service	Multi-AZ PostgreSQL/MySQL
eks	Elastic Kubernetes Service	Managed K8s cluster + node groups
s3	S3 buckets + policies	Static website + private data
cloudwatch	Monitoring + alarms + dashboards	CPU>80%, error rate, latency

טיפ זהב: השתמש ב-Terraform Registry למודולים מוכנים (community-tested). תמיד pin גרסאות: version = "~> 3.0".

שימושים נפוצים ב Terraform

שימושים נפוצים למהנדסי DevOps

הקמת תשתית ענן בסיסית (רשתות, שרתים, DB)

מהנדסי DevOps משתמשים ב-Terraform להקמת תשתית מלאה מאפס – מרשתות ועד אפליקציה:

text

VPC (רשת) → Subnets → Security Groups → 
EC2/RDS (שרתים+DB) → Load Balancer → Auto Scaling

דוגמה פשוטה (main.tf):

text

module "vpc" { source = "terraform-aws-modules/vpc/aws" version = "~> 5.0" }
module "web_servers" { 
  source = "terraform-aws-modules/ec2-instance/aws"
  instances = 2
}
module "db" { source = "terraform-aws-modules/rds/aws" }

Terraform ל-Kubernetes, Serverless, שירותי ניטור

Kubernetes: EKS/GKE/AKS cluster + node groups + IRSA (IAM Roles for Service Accounts)
Serverless: Lambda functions + API Gateway + DynamoDB/EventBridge
ניטור: CloudWatch/Grafana dashboards, alarms על CPU>80%, error rate

דוגמה K8s:

text

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  cluster_name    = "my-cluster"
  cluster_version = "1.30"
}

דוגמאות ל"סטאקים" נפוצים בארגון

סטאק	רכיבים עיקריים	מתאים ל...
Web App בסיסי	VPC + ALB + EC2 ASG + RDS	אפליקציות מסורתיות
Stateless Microservices	EKS + ALB Ingress + RDS Aurora	K8s מודרני
Serverless API	API Gateway + Lambda + DynamoDB + S3	APIs ללא שרתים

סטאקים AWS ספציפיים

text

1. EKS Production Stack
├── VPC (public/private subnets)
├── EKS Control Plane (3 AZs)
├── Managed Node Groups (Spot + On-Demand)
├── RDS Aurora PostgreSQL (Multi-AZ)
└── CloudWatch Container Insights

2. Data Lake Stack  
├── S3 Data Lake Buckets
├── Glue Crawlers + Catalog
├── Athena Workgroups
├── Lambda ETL Jobs
└── QuickSight Dashboards

סטאקים GCP ספציפיים

text

1. GKE Autopilot Stack
├── VPC (Shared VPC)
├── GKE Autopilot Cluster
├── Cloud SQL PostgreSQL HA
├── Cloud Load Balancing
└── Cloud Monitoring + Logging

2. BigQuery Data Warehouse
├── BigQuery Datasets + Views
├── Cloud Storage Staging
├── Cloud Functions Pipelines
├── Cloud Composer (Airflow)
└── Data Catalog

טיפ DevOps: התחל עם terraform-aws-modules/vpc/aws ו-terraform-aws-modules/eks/aws – מודולים בוגרים ומבדוקים. כל סטאק צריך remote state + workspaces לסביבות שונות.

Terraform inside Gitops for CI/CD

שילוב Terraform בפייפליין CI/CD

Terraform משתלב ב-CI/CD כשלב Infrastructure Pipeline נפרד (או בתוך app pipeline), עם זרימה אוטומטית:

text

Git Push → CI: fmt/validate/plan → Artifact → 
Manual Approve (prod) → CD: apply → Slack notify

דוגמה GitHub Actions (terraform-plan.yml):

text

jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: hashicorp/setup-terraform@v3
      - run: terraform init
      - run: terraform fmt -check
      - run: terraform validate
      - run: terraform plan -out=tfplan
      - uses: actions/upload-artifact@v4
        with: { name: tfplan, path: tfplan }

בדיקות fmt/validate, plan כ-artifact, אישור apply

שלב CI	פקודה	תוצאה
Format	`terraform fmt -check`	בודק פורמט, block ב-PR
Validate	`terraform validate`	syntax + dependencies
Security	`tfsec` / `checkov`	סריקת אבטחה (open ports)
Plan	`terraform plan -out=tfplan`	artifact ל-review
CD Apply	`terraform apply tfplan`	רק אחרי approve

דוגמה CD:

text

  apply:
    needs: plan
    if: github.ref == 'refs/heads/main'
    permissions: write-all
    steps:
      - run: terraform apply -auto-approve tfplan

עבודה לפי GitOps וניהול שינויים מבוקרים

GitOps = Infrastructure as Code + Git as Source of Truth:

כל שינוי .tf → PR → CI plan ב-comment
Merge → auto-deploy ל-dev
Prod: manual approve ב-Slack/Teams + audit log
Drift Detection: cron job יומי plan → alert אם שינויים ידניים

כלים מומלצים:

text

- GitHub Actions / GitLab CI / Jenkins
- Atlantis / Terragrunt (multi-env)
- Terraform Cloud / Spacelift (enterprise)
- Backstage (self-service portal)

טיפ זהב: עולם ללא terraform apply ידני. הכל דרך PRs + auto-plan. State ב-remote (S3+DynamoDB) עם locking. Prod דורש 2 approvals מינימום.

ההיגיון בשילוב Terraform כמערכת של CI/CD

Terraform הופך תשתית מ"אמנות ידנית" ל"תהליך תוכנה" – בדיוק כמו CI/CD לאפליקציות. ההיגיון המרכזי הוא שליטה, בטיחות ושקיפות:

1. כל שינוי עובר review ואישור

במקום apply מקומי שמישהו מריץ מחשב הנייד:
PR → CI plan → comment עם preview → merge → auto-deploy.
אין "לחיצות בקונסול" בפרודקשן – הכל מתועד ומאושר.

2. בדיקות אוטומטיות לפני הרס

text

fmt → validate → security scan (tfsec) → plan

אם משהו נשבר – PR נחסם. אין deploy מלוכלך לפרודקשן.

3. ניהול State מרכזי + Locking

State ב-S3/DynamoDB – לא בלוקאלי של מישהו
Locking: שני מהנדסים לא יכולים apply בו זמנית
Drift Detection: cron יומי שמתריע על שינויים ידניים

4. סביבות מבודדות + Audit Trail

text

dev: auto-apply בכל merge
stage: manual approve
prod: 2 approvals + Slack notification

כל שינוי מתועד ב-Git + CI logs – אפשר לבדוק "מי שינה מה ומתי".

5. מהירות + אמינות בסקייל

100 מהנדסים לא יכולים לנהל תשתית ידנית
Pipeline מטפל ב-עשרות סביבות במקביל
Rollback פשוט: revert commit → auto-rollback תשתית

במילים פשוטות: Terraform ב-CI/CD הופך תשתית מ"מי יודע מה קורה פה" ל"תהליך תוכנה עם בדיקות, review ושליטה". זה DevOps אמיתי – לא רק buzzword.[spacelift]

ניהול אבטחה וBest Practices

Local state לעומת remote state

Local state (terraform.tfstate): קובץ מקומי שמתעדכן אחרי כל apply. מתאים לניסויים ולפרויקטים אישיים, אבל מסוכן בצוותים – ניתן למחוק אותו בטעות, ואין הגנה מפני apply מקבילי.
Remote state: שמירה בענן (S3 + DynamoDB ב-AWS, GCS ב-GCP, Terraform Cloud). חובה בפרודקשן כי הוא תומך versioning, encryption וגיבויים אוטומטיים.

דוגמת הגדרת backend (versions.tf):

text

terraform {
  backend "s3" {
    bucket         = "prod-terraform-state"
    key            = "env/dev/vpc.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-state-locks"
  }
}

רץ terraform init אחרי הוספת backend כדי להעביר state.

נעילה (locking), הרשאות ואבטחת state

Locking: מנגנון מובנה שמונע שני apply בו-זמנית. Remote backends (כמו S3 + DynamoDB) מספקים lock אוטומטי – אם מישהו ננעל, CI/CD יחכה או יתריע.
הרשאות: הגדר least privilege ב-IAM roles – provider מקבל רק ec2:Describe*, ec2:Create* (לא ec2:Terminate*).
אבטחת state:
- הצפנה (SSE-KMS/SSE-S3)
- Bucket policy: private בלבד, MFA delete
- גישה דרך IAM roles (לא access keys בקוד)

מבנה מודולרי, naming conventions, הפרדת אחריות

פרויקט גדול = מבנה מודולרי עם הפרדה ברורה:

text

terraform-project/
├── environments/
│   ├── dev/terraform.tfvars
│   └── prod/terraform.tfvars
├── modules/
│   ├── vpc/          # רק רשתות
│   ├── app-servers/  # רק EC2/ASG
│   └── database/     # רק RDS
└── shared/           # IAM roles גלובליים

Naming conventions:

text

resource "aws_vpc" "prod_app_vpc" { ... }  # env + service + resource
module "dev_vpc_eu_west_1" { ... }         # env + module + region
variable "instance_type" { default = "t3.micro" }  # תיאורי ברור

עקרון: 1 מודול = 1 אחריות. מקסימום 200 שורות לקובץ. השתמש ב-terraform-docs ליצירת README אוטומטי.

טיפ זהב: מעבר ל-remote state הוא הצעד החשוב ביותר. תמיד terraform plan לפני apply. Pin גרסאות: version = "~> 5.0".

טעויות נפוצות ואיך להימנע מהן

1. State נמחק או אבד

הסימפטום: terraform plan חושב שכל התשתית צריכה להימחק.
למה קורה: מישהו מחק terraform.tfstate או שכח לגבות.
פתרון מונע:

Remote state תמיד (S3 + DynamoDB) עם versioning
גיבוי יומי של state file
terraform state pull > backup.tfstate לפני שינויים גדולים

2. State Locked (נעילה תקועה)

הסימפטום: Error: Error locking state: ... already locked
למה קורה: CI/CD נתקע באמצע apply, lock לא שוחרר.
פתרון מיידי: terraform force-unlock <lock-id>
פתרון מונע: Timeout קצר ב-CI/CD (10 דקות), monitoring על locks

3. Drift – שינויים ידניים בקונסול

הסימפטום: terraform plan מראה מחיקות/שינויים לא צפויים.
למה קורה: מישהו שינה AMI/EC2 type דרך קונסול.
פתרון:

bash

# Drift detection יומי
terraform plan -detailed-exitcode > /dev/null
if [ $? -eq 2 ]; then echo "Drift detected!"; fi

מדיניות: "אסור לשנות קונסול, רק דרך Terraform"

4. Dependencies מעגליות

הסימפטום: apply תקוע לנצח, cycle error.
למה קורה: VPC תלוי ב-Security Group ולהיפך.
פתרון:

text

# במקום circular dep
data "aws_security_group" "existing" { ... }
# או explicit depends_on
resource "aws_instance" "web" {
  depends_on = [aws_security_group.sg]
}

5. Secrets בקוד/Git

הסימפטום: AWS keys חשופים ב-GitHub.
פתרון:

text

variable "db_password" { sensitive = true }
# ב-terraform.tfvars (לא commit!)
db_password = "supersecret123"

כלים: git-secrets, truffleHog ב-CI

6. Apply ללא Plan

הסימפטום: הפתעות בפרודקשן (שרתים נמחקים).
פתרון מונע:

text

# GitHub Actions - plan חובה
- run: terraform plan -out=tfplan
- uses: actions/upload-artifact@v4
- run: terraform apply tfplan  # רק אחרי approve

7. Provider Version Drift

הסימפטום: terraform init שובר תאימות.
פתרון:

text

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.40.0"  # Pin גרסאות!
    }
  }
  required_version = ">= 1.5.0"
}

8. 500 שורות ב-main.tf אחד

הסימפטום: קשה לתחזק, אי אפשר להבין מה קורה.
פתרון: מבנה מודולרי:

text

modules/
├── vpc/
├── app/
├── db/
└── monitoring/

טעות קלאסית	תוצאה	מניעה
Local state בצוות	Apply מקבילי	Remote state + locking
Apply בלי plan	שרתים נמחקים	CI/CD policy
Drift ידני	Plan מלוכלך	Drift detection cron
Secrets ב-Git	חשבון פרוץ	sensitive vars + scans

טיפ זהב: terraform plan -destroy פעם בחודש לבדיקת destroy בטוח. terrascan ל-security. תמיד backup state.

FAQ ל Terraform

תחומי לימוד הכי מבוקשים בהייטק בשנת 2026