בדיקת תשתיות: Terratest ו-kitchen-terraform עבור Terraform

Terratest: מדוע בדיקה ידנית של Terraform אינה מתרחבת

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

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

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

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

מה נותנת בדיקה אוטומטית של קוד תשתית

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

אילו סוגי כשלים נעלמים

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

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

כמה זמן אורכת בדיקת שינוי

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

צפיות בפריסה לסביבות ייצור

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

Terratest ו-kitchen-terraform: גישות לבדיקת קונפיגורציות

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

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

אפשרויות בדיקה

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

שלבי הטמעת בדיקות של קוד תשתית

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

1. ביקורת תשתית. מנתחים תיאורי משאבים, מודולים והיסטוריית שינויים: היכן תיקון של משאב אחד גרר יצירה מחדש של תלויים, והיכן הקונפיגורציה סתרה את המצב בפועל. התוצאה — רשימת צווארי בקבוק עם הערכת תדירות וחומרת הכשל.
2. סכמת בדיקות. מגדירים מה בודקים בשלב התוכנית (הרכב משאבים, קשרים, ערכי מאפיינים), ומה — רק בסביבה פרוסה: זמינות שירותים, הרשאות גישה, אידמפוטנטיות של יישום חוזר.
3. הגדרת סביבת בדיקות. מרכיבים פרויקט מבודד עם חשבונות בדיקה, הגבלת זמן חיים וניקוי אוטומטי של משאבים — הסביבה לא צוברת אשפה ולא מפריעה לצוותים סמוכים.
4. מערך בדיקות. Terratest מכסה תרחישים של „הרמנו — בדקנו — מחקנו“, kitchen-terraform — השוואת המצב בפועל למצופה. המערך מחולק לרמות: קונטור מהיר, אינטגרציה, מקצה לקצה.
5. חיבור לצינור הבנייה. בדיקות מהירות רצות בכל קומיט, סביבת הבדיקות המלאה — על ענפי שחרור. הבדיקות מופעלות במקביל בפרויקטים נפרדים, והתוצאה חוסמת יישום שינויים במקרה של כשל.
6. ניתוח התראות שווא. בדיקות לא יציבות מרפאים לפי הסיבה — מרוצי נתונים, משאבים משותפים, פסקי זמן קצרים מדי — ולא על ידי השבתה. מחזיקים בכלל: בדיקה שהושבתה חוזרת באותו יום.
7. העברה. מוסרים נהל תחזוקה, תיאור רמות הבדיקה והוראות להוספת מודול חדש — הצוות מרחיב את המערך בלעדינו.

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

תוצרי הטמעה: קונפיגורציות, תרשימים, נהלים

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

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

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

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

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

מה עשינו

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

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

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

מה השתנה

שיעור השינויים שהגיעו לסביבת הייצור וחזרו לאחור ירד מ-30% לאפס בתוך רבעון. בדיקה שנמשכה יומיים של עבודה ידנית מסתיימת ב-25 דקות ומתבצעת במקביל בין הסביבות.

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

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

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

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

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

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

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

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

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

שאלות טכניות נפוצות על בדיקת תשתית

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

מה עושים עם סודות בבדיקות?

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

האם אפשר להריץ בדיקות מקומית?

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

מי מתחזק את מערך הבדיקות?

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

נדון במשימה: איך עובר הניתוח הראשון

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

מה אנחנו מביאים ומפרטים בפגישה הראשונה:

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

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