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

במסמך הזה מפורטות הנחיות והמלצות לבדיקת מודולים והגדרות של Terraform. Google Cloud

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

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

שימוש קודם כל בשיטות בדיקה פחות יקרות

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

  • ניתוח סטטי: בדיקת התחביר והמבנה של ההגדרות ללא צורך לפרוס בכלל משאבים, באמצעות כלים כמו מהדרים (compilers), לינטרים (linters) והרצות בדיקה. כדי לעשות את זה, משתמשים בפקודה terraform validate.
  • בדיקת השילוב של המודולים: כדי לוודא שהמודולים פועלים כמו שצריך, יש לבדוק כל מודול בנפרד. בבדיקת השילוב של המודולים, צריך לפרוס את המודול בסביבת הבדיקה ולוודא שהמשאבים שצופים שייווצרו אכן נוצרים. אפשר להיעזר ב-frameworks של בדיקות כדי להקל על כתיבת הבדיקות:
  • בדיקה מקצה לקצה: על ידי הרחבת הבדיקות לסביבה כולה אפשר לוודא שהמודולים השונים פועלים היטב ביחד. כשמשתמשים בשיטה הזו, צריך ליצור את הארכיטקטורה המלאה על ידי פריסת כל המודולים בסביבת בדיקה חדשה. באידיאל, סביבת הבדיקה צריכה להיות דומה ככל האפשר לסביבת הייצור. השיטה הזו אמנם יקרה, אבל היא מאפשרת לבדוק במידה הגבוהה ביותר של ביטחון שהשינויים לא פוגעים בסביבת הייצור.

התחלה בַּקטנה

חשוב לוודא שהבדיקות החוזרות נבנות זו על גבי זו. כדאי לשקול להתחיל מבדיקות קטנות ולאחר מכן להתקדם לבדיקות מורכבות יותר, בגישה של ניסוי וטעיה (fail fast).

רנדומיזציה של מזהי פרויקטים ושמות משאבים

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

שימוש בסביבה נפרדת לבדיקה

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

מחיקת משאבי הבדיקה

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

כדי לכבות סופית את כל האובייקטים המרוחקים שמנוהלים על ידי הגדרה מסוימת, יש להשתמש בפקודה terraform destroy. חלק ממסגרות הבדיקה (frameworks) כוללות כבר שלב מובנה של מחיקת משאבים. לדוגמה, אם משתמשים ב-Terratest, אפשר להוסיף לבדיקה את הפקודה defer terraform.Destroy(t, terraformOptions). אם משתמשים ב-Kitchen-Terraform, אפשר למחוק את סביבת העבודה באמצעות הפקודה terraform kitchen delete WORKSPACE_NAME.

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

קיצור זמני הבדיקות

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

  • הרצת בדיקות במקביל במסגרות בדיקה מסוימות (frameworks) אפשר לבצע מספר בדיקות ב-Terraform בו-זמנית.
    • לדוגמה, ב-Terratest אפשר להוסיף את השורה t.Parallel() אחרי ההגדרה של פונקציית הבדיקה.
  • בדיקה בשלבים מומלץ להפריד את הבדיקות להגדרות עצמאיות שאפשר לבדוק בנפרד. בגישה הזאת לא צריך לעבור את כל השלבים כשמבצעים את הבדיקה, ומקצרים את מחזור החזרה לפיתוח.
    • לדוגמה, ב-Kitchen-Terraform אפשר לפצל את הבדיקה לחבילות נפרדות. כשמבצעים בדיקה חוזרת, אפשר לבצע כל חבילה בנפרד.
    • באופן דומה, כשמשתמשים ב-Terratest, אפשר לעטוף כל שלב בבדיקה באמצעות stage(t, STAGE_NAME, CORRESPONDING_TESTFUNCTION). אפשר להגדיר משתני סביבה שמציינים אילו בדיקות להפעיל. לדוגמה, SKIPSTAGE_NAME="true".
    • התוכנית לבדיקת ה-framework תומכת בביצוע מדורג.

המאמרים הבאים