מקור: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform

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

מבני קוד של Terraform

Terragrunt code structures

Source: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/large-terraform

This example contains code as an example of structuring Terraform configurations for a large-size infrastructure which uses:

• 2 AWS accounts

• 2 regions

• 2 separate environments (prod and stage which share nothing). Each environment lives in a separate AWS account and span resources between 2 regions

• Each environment uses a different version of the off-the-shelf infrastructure module (alb) sourced from Terraform Registry

• Each environment uses the same version of an internal module modules/network since it is sourced from a local directory.

קונבנציות כלליות

1. השתמש ב- _ (מקף תחתון) במקום - (מקף) בכל מקום (בשמות משאבים, בשמות מקורות נתונים, בשמות משתנים, בפלט וכו').

2. עדיף להשתמש באותיות קטנות ובמספרים (למרות ש- UTF-8 נתמך).

ארגומנטים של משאב ומקורות נתונים

1. אל תחזורו על סוג המשאב בשם המשאב (לא באופן חלקי או מלא):

2. השתמשו תמיד בשמות עצם (יחיד) עבור שמות.

3. השתמש ב - בתוך ערכי ארגומנטים ובמקומות שבהם הערך ייחשף לבני אדם (לדוגמה, בתוך שם DNS של RDS).

4. הארגומנטיים count / for_each מומלץ שיבואו כארגומנטים ראשונים בתוך משאבים ויופרדו בשורה חדשה משאר ההגדרות.

5. האגומנט tags מומלץ שיבוא אחרון, מיד אחרי lifecycles ושיפורד בשורה ריקה בין שאר המשאבים

6. בעת שימוש בתנאים ב- argumentcount / for_each עדיף להשתמש בערכים בוליאניים במקום להשתמש length או בביטויים אחרים.

דוגמאות לקוד של משאב

שימוש ב count / for_each

מיקום של tags

תנאים ב count

משתנים

1. אל תמציא מחדש את הגלגל במודולי המשאבים: name, description, ו default עבור משתנים, כפי שמוגדר בסעיף "הפניה לארגומנט" עבור המשאב שאיתו אתה עובד.

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

3. השתמשו בצורת שם עצם רבים כאשר סוג המשתנה הוא list(...) או map(...).

4. סדרו את ה keys בבלוק משתנה כך: description , type, default, validation.

5. כללו תמיד תיאור בכל המשתנים גם אם אתם סבורים שזה ברור מאליו (תזדקקו לו בעתיד).

6. העדפו שימוש בסוגים פשוטים (מספר, מחרוזת, רשימה(...), מפה(...), any) על-פני סוג ספציפי כגון אובייקט(), אלא אם כן עליכם לכלול אילוצים מחמירים על כל key.

7. השתמש בסוגים ספציפיים כגון map(map(string)) אם לכל רכיבי המפה יש סוג זהה (לדוגמה מחרוזת) או ניתן להמיר אותה אליה (לדוגמה, מספר ניתן להמרה למחרוזת).

8. השתמשו בסוג any כדי לנטרל את אימות הסוג כאשר יש לתמוך בסוגים מרובים.

9. הערך {} הוא לעתים מפה, אך לעתים אובייקט. השתמשו ב- tomap(...) כדי ליצור מפה כיוון שאין דרך ליצור אובייקט.

פלט

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

1. שם הפלט צריך לתאר את המאפיין שהוא מכיל.

2. מבנה טוב לשם הפלט נראה כך {name}_{type}_{attribute}

   1. {name}הוא שם משאב או מקור נתונים ללא קידומת ספק. {name} של aws_subnet יהיה subnet, בשבילaws_vpc זה vpc.

   2. {type} הוא סוג המשאב

   3. {attribute} הוא תכונה המוחזרת על-ידי הפלט
4. אם הפלט מחזיר ערך עם פונקציות אינטרפולציה ומשאבים מרובים, {name} ו- {type} צריכים להיות כלליים ככל האפשר (יש להשמיט קידומת זו).

5. אם הערך המוחזר הוא רשימה, עליו להיות לו שם עצם רבים.

6. כלול תמיד תיאור עבור כל התוצרים גם אם אתה סבור שזה ברור מאליו.

7. הימנע מהגדרת ארגומנט sensitive אלא אם אתה שולט באופן מלא בשימוש בפלט זה בכל המקומות בכל המודולים.

8. העדיפו try() (זמין מאז terraform 0.13) על concat(...13)

דוגמאות קוד output

החזר לכל היותר מזהה אחד של קבוצת אבטחה:

כאשר יש משאבים מרובים מאותו סוג, יש להשמיט this בשם הפלט:

השתמש בשם עצם רבים אם הערך המוחזר הוא רשימה

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

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

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

• מהי מורכבות הפרוייקט?

  • מספר המשאבים

  • מספר ה Terraform providers (ראה הערה אודות ״ספקים לוגיים״)

• באיזו תדירות התשתית שלך משתנה?

  • מ פעם בחודש/שבוע/יום

  • עד ברציפות (בכל פעם שיש גרסה/קוד חדש)

• מאתחלי שינוי קוד? האם לאפשר לשרת ה CI לעדכן את ה repoistory כאשר גרסה חדשה נבנת?

  • רק מפתחים יכולים לדחוף ל repoistory התשתיות

  • כולם יכולים להציע שינוי לכל דבר על-ידי פתיחת PR (כולל משימות אוטומטיות בשרת ה- CI)

• באיזו פלטפורמת פריסה או שירות פריסה אתה משתמש?

  • AWS CodeDeploy, Kubernetes, או OpenShift דורשים גישה קצת שונה

• איך סביבות קשורות אחת לשניה?

  • על פי סביבת עבודה, אזור פריסה, פרוייקט

תחילת העבודה עם בניית Terraform configurations

הצבת כל הקוד ב main.tf הוא רעיון טוב בתחילת העבודה או בעת כתיבת קוד לדוגמה. בכל המקרים האחרים, יהיה עליכם לפצל לכמה קבצים באופן לוגי:

• main.tf - משתמשים במודולים, הגדרות משתנים מקומיות, ומקורות נתונים כדי ליצור את כל המשאבים

• variables.tf - מכיל הצהרות של משתנים המשמשים ב main.tf

• outputs.tf - מכיל פלט מהמשאבים שנוצרו בmain.tf

• versions.tf - כולל את דרישות הגרסה של Terraform ושאר הספקים.

terraform.tfvars - אין להשתמש מלבד בקומפוזציה

כיצד לחשוב על מבנה הקוד של Terraform?

המלצות נפוצות לעיצוב הקוד

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

  • terraform plan ו terraform apply מבצעים קריאות API  בענן כדי לאמת את מצב המשאבים.

  • אם התשתית כולה רשומה בקובץ (או תיקייה) אחת, זמן הפריסה יתארך גם לשינויים קטנים בשל הצורך באימות

• רדיוס הסכנה (במקרה של פירצות אבטחה) קטן יותר כאשר יש פחות משאבים

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

• התחילו את הפרוייקט במצב של שמירת ה״מצב״ במקום מרוחק

  • הלפטופ שלכם הוא לא מקום לשמור ולאמת את התשתית שלכם