תשתית כקוד (IaC) עם Terraform: ביקורת, הטמעה, CI/CD

הגדרה ידנית מול Terraform: מה נשבר בקנה מידה

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

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

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

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

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

מה נותן תיאור תשתית כקוד: אפקטים מדידים

תשתית המתוארת כקוד מפסיקה להיות אוסף של הגדרות ידניות: שרתים, רשתות, מאזני עומסים והרשאות גישה נוצרים מקבצים ב-repository. אותו תיאור בדיוק פורש סביבות זהות — בדיקה, קדם-פרודקשן ופרודקשן נבדלות רק בפרמטרים, ולא בסט של פקודות שנשכחו. זו בדיוק יכולת השחזור: הסביבה מפסיקה להיות תלויה במי ובאיזה סדר בנה אותה.

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

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

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

השוואת גישות לתיאור תשתית ב-Terraform

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

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

איך עובר היישום: שלבי העבודה ההנדסית

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

1. אודיט תשתית. משווים את המצב בפועל לפי נתוני הספק עם מה שמתואר בקוד ורשום במצב. מתעדים פערים, עריכות ידניות ומשאבים שלא הוכנסו — בדיוק הם מכשילים את ההרצה הראשונה.
2. תכנון הסכמה. מפרקים את התיאור למודולים לפי דומיינים: רשת, מחשוב, אחסון, הרשאות. מגדירים גבולות מצב, כדי שעריכה בדומיין אחד לא תיגע באחרים, וכללי שמות אחידים.
3. הגדרת סביבות. מקימים אחסון מצב משותף עם נעילה, קונפיגורציות נפרדות לכל סביבה, ומוציאים סודות מהקוד. משאבים קיימים מכניסים בייבוא — בלי ליצור מחדש.
4. בדיקות קבלה על עותק של המתאר. פורסים את המתאר מאפס, בודקים הרצה חוזרת: היא לא אמורה לשנות דבר. בנפרד בודקים שחזור, חזרה לאחור והתנהגות בעת הסרת תלות.
5. הטמעה בצינור. שינוי עובר בדיקת פורמט ותוכנית לפני היישום, והיישום — אחרי אישור של עמית. פוליסות חוסמות פעולות בלתי הפיכות, והיסטוריית העריכות נשארת במערכת בקרת הגרסאות.
6. מסירה לתפעול. מוסרים מודולים, נוהל שינויים וטיפול בתקלות טיפוסיות, ומכשירים את הצוות. את השינויים הראשונים מובילים יחד, עד שהמהנדס מבצע אותם לבד.

מה נשאר אצל הלקוח: קונפיגורציות, סכמות, נהלים

תשתית המתוארת בקוד Terraform מביאה תועלת רק כשהצוות שלכם יכול לקרוא ולשנות אותה בלעדינו. לכן אנחנו מוסרים לא "repository עובד", אלא ערכה הנדסית: תיאור, מבנה, כללים וסדר עבודה עם שינויים. להלן מה בדיוק נשאר בידיים שלכם.

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

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

קייס: העברת תשתית ידנית לניהול בקוד

הלקוח — צוות מוצר עם שלוש סביבות: פיתוח, בדיקות, פרודקשן. המתארים נבנו ביד לפי הוראה פנימית: המהנדס הגדיר לפי הסדר רשת, איזון עומסים, בסיסי נתונים והרשאות גישה. סביבה חדשה למשימה הוקמה בשני-שלושה ימים, והתוצאה הייתה תלויה במי בדיוק ביצע את הצעדים.

תיארנו את התשתית כקוד ב-Terraform: רשתות, מכונות, בסיסי נתונים, מדיניות גישה והקשרים ביניהם. פעולות ידניות הוחלפו בתיאורים ב-repository, שינויים עוברים בדיקה ומיושמים לפי תוכנית — לפני היישום רואים מה בדיוק ישתנה. היסטוריית העריכות נשמרת, והחזרה לאחור נעשית בחזרה לגרסה הקודמת של התיאור.

מה השתנה

פריסת המתאר התקצרה משני-שלושה ימים ל-30–40 דקות, ואותה תוצאה מתקבלת ללא תלות במי שמריץ את הבנייה. הפערים בין סביבת הבדיקות לפרודקשן הפסיקו להצטבר: הקונפיגורציה מתוארת פעם אחת ונעשה בה שימוש חוזר.

מטריקות לפני ואחרי

• בניית סביבה: 2–3 ימים ← 30–40 דקות
• אירועים בגלל פערי קונפיגורציה: כמה בחודש ← בודדים ברבעון
• שחזור סביבה אחרי תקלה: שעות של עבודה ידנית ← יישום התיאור בעשרות דקות

בדיקת שינויים לפני היישום סוגרת סוג של שגיאות שאת חלקן מצאו בעבר כבר בסביבת הפרודקשן.

מה לעשות אם התשתית כבר מוגדרת ידנית?

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

מכאן והלאה שינויים עוברים רק דרך התיאור, ופערים בין המצב המתואר למצב בפועל מתגלים בבדיקה תקופתית, ולא ברגע הכשל.

בחירת האסטרטגיה תלויה במספר המתארים ובמאגר הזמן לרוויזיה.

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

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

שאלות טכניות נפוצות על יישום ותמיכה

לפני ההתחלה הלקוחות שואלים אותן שאלות: מה לעשות אם התיאור ב-Terraform התפצל מהמצב בפועל, אפשר ליישם בלי לעצור שירותים, מי אחראי לשינויים ומה יהיה עם התמיכה בתשתית אחרי המסירה. להלן תשובות קצרות לספקות טכניים.

אפשר ליישם בלי לעצור שירותים?

כן. משאבים מוקמים לצד הקיימים, המעבר נעשה מבוקר והפיך, והמצב מתועד לפני ואחרי. השבתה נדרשת רק במקום שבו השירות עצמו דורש אותה.

איך מחולקת האחריות לשינויים?

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

מה יהיה עם התמיכה אם נישאר בלי קבלן?

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

איך נבדקת אבטחת העריכות?

שינויים עוברים בדיקה לפני היישום, ההרשאות מונפקות לפי תפקידים, והפעולות נרשמות ביומן. רואים מי ומה שינה ועל סמך מה.

נדון במשימה שלכם ונחזור עם תוכנית עבודה

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

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

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

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