Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
מקור: https://github.com/antonbabenko/terraform-best-practices/tree/master/examples/small-terraform
דוגמא זו מכילה קוד לבניית קונפיגורציית Terraform עבור תשתית בקנה מידה קטן, שבה לא נעשה שימוש בתלות חיצונית.
מושלם להתחלה ולשיכתוב בהמשך
מושלם עבור מודולי משאבים קטנים
מתאים למודולי תשתית קטנים וליניאריים
טוב למספר קטן של משאבים (פחות מ- 20-30)
קובץ מצב יחיד עבור כל המשאבים יכול להאט את תהליך העבודה עם Terraform אם מספר המשאבים גדל
(שקול להשתמש בארגומנט - יעד (target-)
להגבלת מספר המשאבים)
Type | Description | Readiness |
---|---|---|
Type | Description | Readiness |
---|---|---|
מספר משאבים מועט, ללא תלות חיצונית. חשבון AWS יחיד. region בודד. סביבה אחת.
כן
מספר חשבונות וסביבות של AWS, מודולי תשתית מוכנים, מידול קומפוזיציות בעזרת terraform.
כן
חשבונות AWS רבים, regions רבים, דחיפות להורדת העתק הדבק, מודולי תשתית מותאמים אישית, שימוש כבד בקומפוזיצות. שימוש ב terraform.
בתהליכים
ענק
Several providers (AWS, GCP, Azure). Multi-cloud deployments. Using Terraform.
לא
בינוני
מספר חשבונות וסביבות של AWS, מודולי תשתית מוכנים, מידול קומפוזיציות בעזרת terragrunt.
לא
גדול
חשבונות AWS רבים, regions רבים, דחיפות להורדת העתק הדבק, מודולי תשתית מותאמים אישית, שימוש כבד בקומפוזיצות. שימוש ב terragrunt.
לא
ענק
מספר ספקים (AWS, GCP, AZURE). פריסות על גבי מספר עננים. שימוש ב terragrunt
לא
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.
In a large project like described here the benefits of using Terragrunt become very visible. See Code Structures examples with Terragrunt.
Perfect for projects where infrastructure is logically separated (separate AWS accounts)
Good when there is no is need to modify resources shared between AWS accounts (one environment = one AWS account = one state file)
Good when there is no need for the orchestration of changes between the environments
Good when infrastructure resources are different per environment on purpose and can't be generalized (eg, some resources are absent in one environment or in some regions)
As the project grows, it will be harder to keep these environments up-to-date with each other. Consider using infrastructure modules (off-the-shelf or internal) for repeatable tasks.
אין סיבה שלא לעקוב לפחות אחרי המוסכמות האלו :)
היזהרו בעת מתן השמות למשאבי הענן עצמם, לעיתים קרובות יש מגבלות בשמות מותרים. יש משאבים לדוגמא שלא יכולים להכיל מקפים, חלקם מחוייבים בקונבציות אחרות. המוסכמות בספר זה מתייחסות למתן שמות לאובייקטי Terraform בלבד.
השתמש ב- _ (מקף תחתון) במקום - (מקף) בכל מקום (בשמות משאבים, בשמות מקורות נתונים, בשמות משתנים, בפלט וכו').
עדיף להשתמש באותיות קטנות ובמספרים (למרות ש- UTF-8 נתמך).
אל תחזורו על סוג המשאב בשם המשאב (לא באופן חלקי או מלא):
השתמשו תמיד בשמות עצם (יחיד) עבור שמות.
השתמש ב -
בתוך ערכי ארגומנטים ובמקומות שבהם הערך ייחשף לבני אדם (לדוגמה, בתוך שם DNS של RDS).
הארגומנטיים count
/ for_each
מומלץ שיבואו כארגומנטים ראשונים בתוך משאבים ויופרדו בשורה חדשה משאר ההגדרות.
האגומנט tags
מומלץ שיבוא אחרון, מיד אחרי lifecycles
ושיפורד בשורה ריקה בין שאר המשאבים
בעת שימוש בתנאים ב- argumentcount
/ for_each
עדיף להשתמש בערכים בוליאניים במקום להשתמש length
או בביטויים אחרים.
count
/ for_each
tags
count
אל תמציא מחדש את הגלגל במודולי המשאבים: name
, description
, ו default
עבור משתנים, כפי שמוגדר בסעיף "הפניה לארגומנט" עבור המשאב שאיתו אתה עובד.
התמיכה באימות במשתנים מוגבלת למדי (לדוגמה, אין אפשרות לגשת למשתנים אחרים או לבצע בדיקות מידע). תכנן בהתאם לכך משום שבמקרים רבים תכונה זו אינה שימושית.
השתמשו בצורת שם עצם רבים כאשר סוג המשתנה הוא list(...)
או map(...)
.
סדרו את ה keys
בבלוק משתנה כך: description
, type
, default
, validation
.
כללו תמיד תיאור בכל המשתנים גם אם אתם סבורים שזה ברור מאליו (תזדקקו לו בעתיד).
העדפו שימוש בסוגים פשוטים (מספר, מחרוזת, רשימה(...), מפה(...), any
) על-פני סוג ספציפי כגון אובייקט(), אלא אם כן עליכם לכלול אילוצים מחמירים על כל key
.
השתמש בסוגים ספציפיים כגון map(map(string))
אם לכל רכיבי המפה יש סוג זהה (לדוגמה מחרוזת) או ניתן להמיר אותה אליה (לדוגמה, מספר ניתן להמרה למחרוזת).
השתמשו בסוג any
כדי לנטרל את אימות הסוג כאשר יש לתמוך בסוגים מרובים.
הערך {} הוא לעתים מפה, אך לעתים אובייקט. השתמשו ב- tomap(...)
כדי ליצור מפה כיוון שאין דרך ליצור אובייקט.
צרו פלט עקבי ומובן מחוץ לסקופ שלו (כאשר משתמש משתמש במודול, צריך להיות ברור איזה סוג ותכונה של הערך שהוא מחזיר).
שם הפלט צריך לתאר את המאפיין שהוא מכיל.
מבנה טוב לשם הפלט נראה כך {name}_{type}_{attribute}
{name}
הוא שם משאב או מקור נתונים ללא קידומת ספק. {name}
של aws_subnet
יהיה subnet
, בשבילaws_vpc
זה vpc
.
{type}
הוא סוג המשאב
{attribute}
הוא תכונה המוחזרת על-ידי הפלט
אם הפלט מחזיר ערך עם פונקציות אינטרפולציה ומשאבים מרובים, {name} ו- {type} צריכים להיות כלליים ככל האפשר (יש להשמיט קידומת זו).
אם הערך המוחזר הוא רשימה, עליו להיות לו שם עצם רבים.
כלול תמיד תיאור עבור כל התוצרים גם אם אתה סבור שזה ברור מאליו.
הימנע מהגדרת ארגומנט sensitive
אלא אם אתה שולט באופן מלא בשימוש בפלט זה בכל המקומות בכל המודולים.
העדיפו try()
(זמין מאז terraform 0.13) על concat(...13)
output
החזר לכל היותר מזהה אחד של קבוצת אבטחה:
כאשר יש משאבים מרובים מאותו סוג, יש להשמיט this
בשם הפלט:
שאלות הקשורות למבנה של קוד Terraform הן השאלות הנפוצות ביותר בקהילה. כולם חשבו גם על מבנה הקוד הטוב ביותר עבור הפרוייקט בשלב מסוים.
זו אחת השאלות שבהן קיימים פתרונות רבים וקשה מאוד לתת עצות אוניברסליות, אז נתחיל בהבנת מה אנחנו עוסקים בו.
מהי מורכבות הפרוייקט?
מספר המשאבים
מספר ה Terraform providers (ראה הערה אודות ״ספקים לוגיים״)
באיזו תדירות התשתית שלך משתנה?
מ פעם בחודש/שבוע/יום
עד ברציפות (בכל פעם שיש גרסה/קוד חדש)
מאתחלי שינוי קוד? האם לאפשר לשרת ה CI לעדכן את ה repoistory כאשר גרסה חדשה נבנת?
רק מפתחים יכולים לדחוף ל repoistory התשתיות
כולם יכולים להציע שינוי לכל דבר על-ידי פתיחת PR (כולל משימות אוטומטיות בשרת ה- CI)
באיזו פלטפורמת פריסה או שירות פריסה אתה משתמש?
AWS CodeDeploy, Kubernetes, או OpenShift דורשים גישה קצת שונה
איך סביבות קשורות אחת לשניה?
על פי סביבת עבודה, אזור פריסה, פרוייקט
הצבת כל הקוד ב main.tf
הוא רעיון טוב בתחילת העבודה או בעת כתיבת קוד לדוגמה. בכל המקרים האחרים, יהיה עליכם לפצל לכמה קבצים באופן לוגי:
main.tf
- משתמשים במודולים, הגדרות משתנים מקומיות, ומקורות נתונים כדי ליצור את כל המשאבים
variables.tf
- מכיל הצהרות של משתנים המשמשים ב main.tf
outputs.tf
- מכיל פלט מהמשאבים שנוצרו בmain.tf
versions.tf
- כולל את דרישות הגרסה של Terraform ושאר הספקים.
terraform.tfvars
- אין להשתמש מלבד בקומפוזציה
אנא ודאו שאתם מבינים מושגים מרכזיים כגון - מודול, משאב בודד, מודול תשתיתי וקומפוזיציה, כי נעשה בהם שימוש בדוגמאות הבאות.
קל ומהיר יותר לעבוד עם מספר מצומצם של משאבים בכל תיקיית הרצה
terraform plan
ו terraform apply
מבצעים קריאות API בענן כדי לאמת את מצב המשאבים.
אם התשתית כולה רשומה בקובץ (או תיקייה) אחת, זמן הפריסה יתארך גם לשינויים קטנים בשל הצורך באימות
רדיוס הסכנה (במקרה של פירצות אבטחה) קטן יותר כאשר יש פחות משאבים
בידוד משאבים לא קשורים זה לזה לקומפוזיציות נפרדות מצמצות את הסיכון שמשהו ישתבש בעת בנייה, הריסה וגם בעת פירצת אבטחה
התחילו את הפרוייקט במצב של שמירת ה״מצב״ במקום מרוחק
הלפטופ שלכם הוא לא מקום לשמור ולאמת את התשתית שלכם