Terraform ו-Infrastructure as Code: תשתית כקוד, לא כזיכרון של מישהו

מאת צוות מדיה דיל · 03.09.2026 · טכנולוגיה · 6 דק׳

Configuration Drift, State File ונעילה מרוחקת, Plan לפני Apply, Modules לשימוש חוזר, שילוב עם GitOps, וסיכון סודות בתוך State.

תשתית שהוקמה ידנית דרך קונסולת Cloud היא בעיה שמתגלה רק כשמנסים לשחזר אותה — אף אחד לא זוכר בדיוק אילו הגדרות נבחרו, ואין דרך לדעת אם הסביבה בפרודקשן זהה לזו שנבדקה. Terraform פותר את זה על ידי הפיכת התשתית עצמה לקוד: קובץ שניתן ל-Review, ל-Version Control, ולשחזור מדויק בכל סביבה.

הבעיה שהגדרה ידנית יוצרת: Configuration Drift

כשמישהו משנה הגדרה ידנית בקונסולה כדי "לתקן משהו מהר", הסביבה בפועל מתחילה לסטות ממה שמתועד בכל מקום אחר — Drift שמצטבר עם הזמן עד שאף אחד לא בטוח מה בדיוק רץ בפרודקשן. Terraform פותר את זה על ידי כך שהקוד הוא מקור האמת היחיד, וכל שינוי ידני מחוץ לו מתגלה ב-Plan הבא כסטייה שצריך להסביר.

State File: הלב של Terraform ונקודת התורפה שלו

Terraform שומר Snapshot של מצב התשתית הידוע (State File) שממנו הוא מחשב מה השתנה בכל Apply. State File שאבד או התעדכן על ידי שני אנשים בו-זמנית בלי נעילה יכול לגרום ל-Terraform "לשכוח" משאבים קיימים ולנסות ליצור אותם מחדש. Remote State (למשל ב-S3 עם DynamoDB Lock) עם נעילה הוא לא אופציונלי בשום צוות עם יותר ממפתח אחד.

Declarative: מתארים תוצאה רצויה, לא צעדים

בניגוד לסקריפט אימפרטיבי שמריץ פקודות בסדר מוגדר, Terraform מתאר את מצב היעד הרצוי, ומחשב בעצמו את ההפרש מהמצב הנוכחי ואת סדר הפעולות הנדרש. זה מאפשר להריץ את אותו קוד שוב ושוב (Idempotent) בלי לדאוג שהרצה כפולה תיצור משאב פעמיים בטעות.

Plan לפני Apply: הבדיקה שמונעת הפתעות

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

Modules: שימוש חוזר בלי העתק-הדבק

Module הוא קטע Terraform עצמאי וניתן לפרמטריזציה — למשל "רשת VPC סטנדרטית" או "שירות ECS עם הגדרות ברירת מחדל" — שצוותים שונים יכולים לצרוך עם ערכים שונים בלי לשכפל את אותו קוד תשתית עשרות פעמים. זה גם המקום הטבעי לאכוף סטנדרטים ארגוניים (תיוג, הצפנה) במקום אחד.

Terraform ו-GitOps: זרימת עבודה מלאה

כשמריצים terraform plan ו-apply דרך Pull Request עם אישור נדרש, התשתית מקבלת בדיוק את אותה משמעת שקוד אפליקציה מקבל — בדיוק העיקרון שמתואר בGitOps, רק שכאן זה חל על התשתית עצמה ולא רק על מה שרץ עליה.

סודות בתוך State: סיכון שקל לפספס

State File לרוב מכיל ערכים רגישים בטקסט גלוי — סיסמאות מסד נתונים שנוצרו, מפתחות API — כי Terraform צריך לדעת את הערך המלא כדי לזהות שינוי. הגנה על ה-State עצמו (הצפנה במנוחה, גישה מוגבלת) חשובה לא פחות מהגנה על הסודות המקוריים, וכדאי לשלב עם גישת Secrets Management נכונה במקום להזין סודות ישירות כ-Variables בקוד ה-Terraform.

מתי Terraform הוא מורכבות מיותרת

לסביבת פיתוח זמנית שנוצרת ונהרסת תוך שעות, או לפרויקט עם משאב תשתית בודד ויציב שכמעט אף פעם לא משתנה, המשמעת המלאה של Terraform — State, Modules, תהליך Review — יכולה להיות תקורה מיותרת ביחס לתועלת. הכלי משתלם ברגע שיש יותר ממשאב אחד, יותר מסביבה אחת, או יותר ממי שנוגע בתשתית.

רוצים להפוך את התשתית שלכם לקוד מנוהל וניתן לשחזור? נשמח לעזור לכם להטמיע Terraform נכון בוואטסאפ.

תגיות: Terraform · Infrastructure as Code · DevOps · Cloud

← חזרה לבלוג · צור קשר