במסמך הזה מפורטות שיטות מומלצות לניהול גרסאות שכדאי להשתמש בהן כשמשתמשים ב-Terraform עבור Google Cloud.
כמו בסוגים אחרים של קוד, אפשר לאחסן את קוד התשתית במערכת לניהול גרסאות כדי לשמור על ההיסטוריה ולחזור בקלות לגרסאות הקודמות.
המדריך הזה אינו מבוא ל-Terraform. למידע על שימוש ב-Terraform עם Google Cloud, אפשר לעיין במאמר תחילת העבודה עם Terraform.
שימוש בשיטת ברירת המחדל להסתעפות
לכל המאגרים שמכילים קוד של Terraform, יש להשתמש בשיטה הבאה כברירת מחדל:
- ההסתעפות
mainהיא ההסתעפות הראשית של הפיתוח והיא מייצגת את הקוד העדכני ביותר שעבר אישור. ההסתעפותmainהיא מוגנת. - הפיתוח מתרחש בהסתעפויות של פיתוח פיצ'רים ותיקוני באגים שמתפצלות מההסתעפות הראשית (
main).- להסתעפויות של פיתוח פיצ'רים יש לתת את השם
feature/$feature_name. - להסתעפויות של תיקוני באגים יש לתת את השם
fix/$bugfix_name.
- להסתעפויות של פיתוח פיצ'רים יש לתת את השם
- לאחר השלמת הפיתוח של הפיצ'ר או תיקון הבאג, יש למזג אותם חזרה להסתעפות
mainעם בקשת משיכה (pull request). - כדי למנוע קונפליקטים בין הסתעפויות, צריך לבצע rebase להסתעפויות לפני שממזגים ביניהן.
שימוש בהסתעפות סביבתית להגדרות ברמה הבסיסית (root)
במאגרים שכוללים הגדרות ברמה הבסיסית שפרוסות ישירות ב-Google Cloud, צריך אסטרטגיית השקה בטוחה. מומלץ ליצור הסתעפות נפרדת לכל סביבה. כך, אם רוצים לשנות את ההגדרות ב-Terraform, אפשר למזג את השינויים בין ההסתעפויות השונות.
הפעלת הרשאות גישה נרחבות
חשוב להגדיר את קוד המקור ואת המאגרים של Terraform כדי שתהיה גישה רחבה לארגונים של מהנדסי התוכנה, לבעלי התשתיות (לדוגמה, מהנדסי SRE) ולבעלי העניין בתשתית (לדוגמה, מפתחים). כך אפשר להבטיח שלבעלי עניין בתשתית תהיה הבנה טובה יותר של התשתית שהם תלויים בה.
חשוב לעודד בעלי עניין בתשתית לשלוח בקשות למיזוג כחלק מהתהליך של בקשת השינוי.
הגנה על סודות ואי חשיפתם
לעולם אין לשמור סודות למערכות לניהול גרסאות, כולל בהגדרות של Terraform. במקום זאת, אפשר להעלות אותם למערכת כמו Secret Manager ולהפנות אליהם באמצעות מקורות נתונים.
חשוב לזכור שערכים רגישים כאלה יכולים להגיע בסופו של דבר לקובצי מצב ועלולים גם להיחשף כפלט.
סידור המאגרים לפי תחומי צוותים
למרות שאפשר להשתמש בספריות נפרדות כדי לנהל תחומים לוגיים שונים של משאבים, התחומים הארגוניים והלוגיסטיקה קובעים את המבנה שלהמאגר. באופן כללי, כדאי לפעול לפי העיקרון העיצובי שקובע שהגדרות עם דרישות ניהול ואישור שונות יקובצו במאגרים שונים של מערכות לניהול גרסאות. כדי להמחיש את העיקרון הזה, ריכזנו כאן כמה הגדרות אפשריות של מאגרים:
מאגר מרכזי אחד: במודל הזה, צוות אחד של הפלטפורמה מנהל במרוכז את כל הקוד של Terraform. כדי שהשימוש במודל הזה יצליח, מומלץ לעבוד עם צוות תשתיות ייעודי, שיהיה אחראי על הניהול הכולל של הענן ויאשר את השינויים שצוותים אחרים יבקשו.
מאגרי צוות: במודל הזה, כל צוות יהיה אחראי על המאגר שלו ב-Terraform, וינהל את כל מה שקשור לתשתית שבבעלותו. לדוגמה, לצוות האבטחה יכול להיות מאגר שבו מנהלים את אמצעי בקרת האבטחה, בזמן שלצוותי האפליקציות יכול להיות מאגר משלהם ב-Terraform לפריסה ולניהול של אפליקציות.
סידור המאגרים לפי התחומים השונים של הצוותים הוא המבנה הטוב ביותר לרוב התרחישים בארגון.
מאגרים מופרדים: במודל הזה, כל רכיב לוגי של Terraform מפוצל למאגר משלו. לדוגמה, יכול להיות מאגר ייעודי לרכיב Networking, ומאגר נפרד למאגר project factory המשמש ליצירה וניהול של פרויקטים. השיטה הזאת מוצלחת בסביבות מבוזרות מאוד שבהן האחריות עוברת לעיתים קרובות מצוות אחד לשני.
דוגמה למבנה של מאגר
אפשר לשלב את העקרונות האלה כדי לפצל את ההגדרות של Terraform בין סוגים שונים של מאגרים:
- מאגר בסיסי
- מאגרים ספציפיים לאפליקציות ולצוותים
מאגר בסיסי
מאגר בסיסי שמכיל רכיבים עיקריים חשובים, כמו תיקיות או הממשק הארגוני של IAM. הצוות המרכזי של הענן יכול לנהל את מאגר הנתונים הזה.
- במאגר הזה יש לכלול ספרייה לכל רכיב ראשי (לדוגמה, תיקיות, רשתות וכו').
- בספריות הרכיבים יש לכלול תיקייה נפרדת לכל סביבה (בהתאם להנחיות למבנה הספרייה שהזכרנו קודם).
מאגרים ספציפיים לאפליקציות ולצוותים
מאגרים שהם ספציפיים לאפליקציות ולצוותים צריך לפרוס בנפרד לכל צוות. כך הם יוכלו לנהל בנפרד הגדרות שהן ייחודיות וספציפיות לאפליקציות ב-Terraform.
