Terraform לסטארטאפים: מתשתית ידנית ל-IaC תוך 30 יום

רוב הסטארטאפים מתחילים תשתית באותה דרך: מישהו נכנס לקונסולת AWS או GCP, מקים database, S3 bucket, load balancer, ומשיק. זה עובד — עד שמצטרף מהנדס שני ושואל "איך אני מקבל עותק של הסביבה הזאת?", והתשובה הכנה היא "תשאלו את מי שלחץ על הכפתורים".

זה הרגע שבו infrastructure-as-code מפסיק להיות nice-to-have. אין צורך לאמץ את Terraform בבת אחת, ואין צורך לכתוב מחדש את כל מה שכבר בנוי. המדריך הזה מכסה חמישה דפוסים שחשובים לפני שהתשתית שלכם גדלה מעבר לידע שבטני, ועוד טריק אחד שמאפשר לאמץ את Terraform בלי להרוס את מה שכבר רץ.

למה תשתית ידנית נשברת

תשתית שהוקמה בקונסולה חסרת היסטוריה, תהליך review, ודרך אמינה לשחזר אותה. תבניות הכשל צפויות:

• אין audit trail. כלל ב-security group משתנה ואף אחד לא יודע מי שינה או למה.
• אין reproducibility. staging ו-production מתרחקים אחד מהשני כי מישהו תיקן staging ידנית.
• bus factor של אחד. האדם היחיד שהקים הכל עוזב, וה-runbook חי בראש שלו.
• אין review. שינוי שהיה נתפס ב-pull request הולך ישר ל-production.

Terraform פותר את כל ארבעת אלה: כל שינוי הוא plan שאפשר להשוות, נבדק כמו קוד, מיושם באופן עקבי, ומגורסן ב-git.

5 דפוסי Terraform שכל סטארטאפ צריך

1. State מרוחק ב-S3 או GCS — לעולם לא state מקומי

Terraform עוקב אחרי המשאבים האמיתיים שהוא מנהל בקובץ state. אם הקובץ הזה חי על המחשב הנייד שלכם, יש לכם נקודת כשל יחידה ואין דרך לחבר צוות להריץ terraform apply בבטחה.

terraform {
  backend "s3" {
    bucket         = "yourco-terraform-state"
    key            = "prod/terraform.tfstate"
    region         = "us-east-1"
    dynamodb_table = "terraform-locks"
    encrypt        = true
  }
}

השורה dynamodb_table מפעילה state locking — היא מונעת משני אנשים (או מאדם ומ-job של CI) להריץ apply באותו זמן ולשבש את ה-state. ב-GCP, השתמשו ב-backend של GCS במקום; הוא נועל באופן טבעי בלי טבלה נפרדת.

הגדירו את זה לפני שאתם כותבים בלוק resource ראשון. אפשר להעביר state בהמשך, אבל זה מוסיף סיכון שאין סיבה לקחת.

2. מבנה מודולים — לא לחזור על עצמכם בין סביבות

טעות נפוצה בהתחלה היא main.tf ענק אחד עם הכל בפנים, מועתק-מודבק בין dev ל-prod עם עריכות קטנות. זה בדיוק המקום שבו drift מתגנב פנימה.

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

modules/
  vpc/
  database/
  service/
environments/
  dev/
    main.tf        # קורא ל-modules/vpc, modules/database, modules/service
  staging/
    main.tf
  prod/
    main.tf

ה-main.tf של כל סביבה הוא קובץ קצר שמחבר מודולים עם קלטים שונים — גודל instance, מספר replica, שם domain. קוד המודול עצמו זהה בכל מקום, כך שתיקון או שיפור ב-modules/database משפר כל סביבה ברגע שהוא מיושם.

3. Workspaces (או תיקיות) לכל סביבה

Terraform נותן לכם שתי דרכים להפריד בין dev, staging ו-prod: workspaces (קובץ state אחד, כמה instances בעלי שם) או תיקיות נפרדות (state עצמאי מלא לכל סביבה, כפי שהוצג למעלה). לסטארטאפים, תיקיות נפרדות לכל סביבה הן בדרך כלל ברירת המחדל הבטוחה יותר — טעות ב-dev לא יכולה לגעת בטעות ב-state של prod, כי הם לא נמצאים באותו קובץ state בכלל.

שמרו את terraform workspace למקרים שבהם הסביבות זהות באמת וקצרות טווח, כמו סביבות preview זמניות ל-PR.

4. קובצי משתנים, לא ערכים מקודדים

כל ערך ספציפי לסביבה — סוג instance, domain, מספר replica — שייך לקובץ .tfvars, לא מקודד בקריאה למודול:

# environments/prod/prod.tfvars
instance_type   = "db.r6g.large"
replica_count   = 3
domain_name     = "app.yourco.com"

terraform plan -var-file="prod.tfvars"

זה הופך את ההבדל בין סביבות למפורש ולניתן ל-review בקובץ אחד, במקום קבור בין כמה קבצי .tf. זה גם אומר שקידום שינוי config מ-staging ל-prod הוא diff של שורה אחת בקובץ .tfvars — קל ל-review, קל ל-audit.

5. terraform import — קליטת משאבים קיימים בלי כתיבה מחדש

זה הדפוס שבאמת פותח את האימוץ. אין צורך להרוס את ה-database שהוקם בקונסולה וליצור אותו מחדש ב-Terraform — אפשר להביא אותו תחת ניהול כמו שהוא:

# כתבו קודם את בלוק ה-resource, תואם לקונפיגורציה של המשאב האמיתי
resource "aws_db_instance" "main" {
  # ... קונפיגורציה שתואמת ל-instance הקיים
}

# ואז ייבאו את המשאב הקיים ל-state
terraform import aws_db_instance.main your-db-instance-id

# הריצו plan — הוא אמור להראות "no changes" אם הקונפיגורציה תואמת למציאות
terraform plan

המשמעת המרכזית: אחרי הייבוא, הריצו terraform plan וודאו שהוא מראה אפס שינויים לפני שאתם נוגעים בכל דבר אחר. אם הוא מראה diff, קונפיגורציית ה-.tf שלכם עדיין לא תואמת למשאב האמיתי — תקנו את הקונפיגורציה, לא את התשתית, עד שה-plan נקי. רק אז התחילו לבצע שינויים דרך Terraform מכאן והלאה.

ייבאו סוג משאב אחד בכל פעם — התחילו עם משהו בסיכון נמוך כמו S3 bucket או security group, לא ה-database של production, כדי שהצוות יבנה ביטחון בתהליך לפני שנוגעים במשהו קריטי.

עלות הכאוס: ידני מול IaC על פני 12 חודשים

	ידני (קונסולה)	Terraform (IaC)
הקמת סביבה חדשה	יום-יומיים, נוטה לטעויות	דקות, terraform apply
קליטת מהנדס חדש	ימים של העברת ידע שבטני	קריאת קוד המודול
תקרית production: "מה השתנה?"	grep על CloudTrail, לשאול מסביב	git log על repo התשתית
Disaster recovery	בנייה מחדש מהזיכרון	terraform apply באזור חדש
הערכת זמן תפעול לחודש ב-10 מהנדסים	15–25 שעות כיבוי שריפות של drift	3–5 שעות, בעיקר שינויים מתוכננים

הפער לא דרמטי בחודש הראשון. הוא מצטבר בכל פעם שמישהו נוגע בתשתית ידנית במקום דרך plan שעבר review — ועד חודש שישי, צוותים שדילגו על IaC מוציאים זמן הנדסה אמיתי רק כדי לשמור על סביבות מסונכרנות.

איפה להתחיל השבוע

אין צורך להעביר הכל ל-Terraform ביום הראשון. המסלול הריאלי של 30 יום:

1. שבוע 1 — הקימו state מרוחק (S3/GCS + locking), בחרו מבנה מודולים, ייבאו את המשאב שהכי הרבה נוגעים בו (בדרך כלל ה-VPC או database).
2. שבוע 2 — הביאו את שאר הרשת והמחשוב תחת ניהול דרך terraform import.
3. שבוע 3 — פצלו סביבות לתיקיות נפרדות עם .tfvars, וודאו ש-staging ו-prod שניהם plan נקי.
4. שבוע 4 — חברו terraform plan ל-CI בכל pull request, כך שכל שינוי תשתית עובר review לפני apply.

מה הלאה

Terraform משתלב באופן טבעי עם pipeline ה-CI/CD שכבר רץ אצלכם — אותו review של PR ששוער את קוד האפליקציה שלכם צריך לשער גם שינויי תשתית. אם עדיין לא הגדרתם את זה, קראו צ׳קליסט ה-CI/CD הראשון שלכם לרצף המדויק, ומדריך ה-DevOps לסטארטאפ לתמונת הפלטפורמה המלאה.

יושבים על סביבה שהוקמה בקונסולה ורוצים חוות דעת שנייה לפני שמתחילים לייבא אותה ל-Terraform? הזמינו שיחת היכרות חינם — נמפה את התשתית הנוכחית שלכם ונמסור תוכנית אימוץ IaC בעדיפויות.