הגדרת Terragrunt לניהול קונפיגורציות Terraform

מדוע הגדרות Terragrunt ידניות מתפצלות כאשר הסביבות גדלות

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

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

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

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

מה נותנת שכבה אחידה לתיאור תשתית: פחות עריכות ידניות

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

מהירות הקמת סביבה ושחזור

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

יכולת חיזוי של שינויים וחזרה לאחור

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

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

Terragrunt, סביבות עבודה או מודולים: בחירה לסביבות

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

המגבלות של כל אפשרות

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

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

איך לבחור כשמספר השירותים גדל

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

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

שלבי יישום: ביקורת, סכמה, הגדרה, בדיקה, מסירה

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

ביקורת ומיפוי מלאי

1. ביקורת קונפיגורציות תשתית: אוספים מאגרים וקבצי מצב, מוצאים כפילויות של תיאורי משאבים, עריכות ידניות בקונסולה של הספק ופערים בין הסביבות.
2. תכנון מבנה הסביבות: קובץ שורש משותף עם הגדרות לאחסון מצב ולספקים, תיקיות נפרדות ל-dev/stage/prod, מודולים לשימוש חוזר במקום עותקים.
3. תוכנית העברת סביבות: סדר המיגרציה, העברת מצב בלי ליצור מחדש משאבים חיים, נקודת חזרה בכל שלב.

בדיקה לפני פרודקשן

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

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

מה נשאר במאגר: מודולים, תיקיות, מדיניות, תקנונים

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

הרכב המאגר

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

תיעוד ותקנון שינויים

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

מקרה בוחן: איך פריסת סביבה הפסיקה להיות עבודה ידנית

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

מה היה לפני

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

מה קרה אחרי

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

סביבה מוקמת בפקודה אחת תוך 20–25 דקות, ונותרו שלושה צעדים ידניים. שיעור החזרות לאחור ירד משליש מההרצות למקרה אחד מתוך עשרים, והחזרה למצב הקודם אורכת דקות.

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

במה Terragrunt שונה מסביבות עבודה ומתי הוא מיותר

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

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

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

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

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

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

ספקות לגבי אחסון המצב והרשאות: מפרקים לפי סעיפים

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

איך מחלקים הרשאות גישה בין צוותים?

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

מה עושים אם צריך לחזור משינוי?

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

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

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

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

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

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

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

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