מבנה הקוד

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ספקים לוגיים פועלים באופן מלא במסגרת הלוגיקה של Terraform ולעתים קרובות אינם מקיימים אינטראקציה עם שירותים אחרים, כך שנוכל לחשוב על מורכבותם כ-O(1). הספקים הלוגיים הנפוצים ביותר כוללים את random, local, terraform, null, time.

תחילת העבודה עם בניית 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  בענן כדי לאמת את מצב המשאבים.

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

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

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

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

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

  • ניהול קבצי ״מצב״ בגיט זה סיוט

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

• תרגלו מוסכמת מתן שמות ומבנה קוד עקבי

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

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

• שמור על מודולי משאבים פשוטים ככל האפשר

• אל תכתבו ״ערכים קשיחים״ אל תוך המודולים כאשר אפשר להשיג אותם כמשתנה או מתוך מקור נתונים אחר

• השתמשו במקורות נתונים (data resources) וב terraform_remote_state כדבק בין מודולי תשתית מורכבים בקומפוזיציה

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

אורקסטרציה של מודולי תשתית וקומפוזיציות תשתית

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

יש לפחות 5 קבוצות שונות של פתרונות אורכיסטרציה שבהם מפתחים משתמשים:

1. שימוש אך ורק בTerraform בלבד. מפתחים הרי צריכים לדעת אך ורק Terraform בשביל לבצע את העבודה

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

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

4. Ansible או כלי אוטומציה שונים. משומש בדרך כלל כאשר השימוש ב Terraform נעשה אחרי השימוש באנסיבל, או כאשר Ansible UI כבר בשימוש.

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

ספר זה סוקר את שני הדרכים הראשונות, Terraform only ו Terragrunt.

ראו דוגמאות של מבני קוד עבור Terraform ו Terragrunt בפרק הבא.