מתודולוגיית פריסה

Last reviewed 2025-05-15 UTC

מומלץ להשתמש בתשתית הצהרתית כדי לפרוס את התשתית הבסיסית באופן עקבי וניתן לשליטה. הגישה הזו עוזרת להטמיע בצינורות שלכם אמצעי בקרה של מדיניות לגבי הגדרות מקובלות של משאבים, וכך מאפשרת ניהול עקבי. הפריסה של תוכנית הבסיס מתבצעת באמצעות תהליך GitOps, עם Terraform שמשמש להגדרת התשתית כקוד (IaC), מאגר Git לניהול גרסאות ולאישור קוד ו-Cloud Build לאוטומציה של CI/CD בצינור הפריסה. במאמר ניהול התשתית כקוד באמצעות Terraform, ‏Cloud Build ו-GitOps מוסבר על הרעיון הזה.

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

שכבות של צינור עיבוד נתונים

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

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

בתרשים מוצגות שכבות צינור עיבוד הנתונים במודל הזה:

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

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

פייפליין הבסיס

צינור הנתונים של התשתית פורס את משאבי התשתית. הוא גם מגדיר את צינור עיבוד הנתונים של התשתית שמשמש לפריסת התשתית שעומסי העבודה משתמשים בה.

כדי ליצור את צינור הנתונים של השכבה הבסיסית, קודם כל צריך לשכפל או לחבר את terraform-example-foundation למאגר Git משלכם. כדי להגדיר את תיקיית ה-bootstrap והמשאבים, פועלים לפי השלבים שמפורטים בקובץ 0-bootstrap README.

שלב

תיאור

0-bootstrap

אתחול של Google Cloud ארגון. בשלב הזה מוגדר גם צינור עיבוד נתונים של CI/CD לקוד של תוכנית האב בשלבים הבאים. פרויקט ה-CICD מכיל את צינור הנתונים הבסיסי של Cloud Build לפריסת משאבים. seedהפרויקט כולל את קטגוריות ה-Cloud Storage שמכילות את מצב Terraform של תשתית הבסיס, וכולל חשבונות שירות עם הרשאות גבוהות מאוד שמשמשים את צינור הנתונים של תשתית הבסיס ליצירת משאבים. מצב Terraform מוגן באמצעות ניהול גרסאות של אובייקטים באחסון. כשצינור ה-CI/CD פועל, הוא פועל בתור חשבונות השירות שמנוהלים בפרויקט seed.

אחרי שיוצרים את צינור עיבוד הנתונים של המודל הבסיסי בשלב 0-bootstrap, השלבים הבאים מפריסים משאבים בצינור עיבוד הנתונים של המודל הבסיסי. קוראים את ההוראות בקובץ ה-README לכל שלב ומיישמים כל שלב ברצף.

שלב	תיאור
1-org	הגדרה של תיקיות משותפות ברמה העליונה, פרויקטים לשירותים משותפים, רישום ביומן ברמת הארגון והגדרות אבטחה בסיסיות באמצעות מדיניות ארגונית.
2-environments	הגדרת סביבות פיתוח, סביבות ללא ייצור וסביבות ייצור בתוך הארגון Google Cloud שיצרתם.
3-networks-dual-svpc או 3-networks-hub-and-spoke	הגדרת רשתות VPC משותפות בטופולוגיה שבחרתם ובמשאבי הרשת המשויכים.

צינור עיבוד הנתונים של התשתית

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

בתרשים הבא מוסבר איך תוכנית ה-blueprint מגדירה כמה צינורות (pipelines) של תשתית שמיועדים לשימוש של צוותים נפרדים.

בתרשים מוסברים מושגי המפתח הבאים:

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

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

ב-terraform-example-foundation, שלב 4 מגדיר צינור עיבוד נתונים של תשתית, ובשלב 5 מוצגת דוגמה לשימוש בצינור הזה כדי לפרוס משאבי תשתית.

שלב	תיאור
4-projects	הגדרה של מבנה תיקיות, פרויקטים וצינור להעברת נתונים של תשתית.
‫5-app-infra (אופציונלי)	פריסת פרויקטים של עומסי עבודה עם מכונה של Compute Engine באמצעות צינור התשתית כדוגמה.

פייפליין הבקשות

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

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

אוטומציה של צינורות עיבוד נתונים באמצעות Cloud Build

התוכנית משתמשת ב-Cloud Build כדי לבצע אוטומציה של תהליכי CI/CD. בטבלה הבאה מתוארים אמצעי הבקרה שמוטמעים בצינור העיבוד של התשתית ובצינור העיבוד של הבסיס, שנפרסים על ידי מאגר terraform-example-foundation. אם אתם מפתחים צינורות משלכם באמצעות כלים אחרים לאוטומציה של CI/CD, מומלץ להחיל אמצעי בקרה דומים.

שליטה	תיאור
הפרדה בין הגדרות build כדי לאמת את הקוד לפני הפריסה	התוכנית משתמשת בשני קבצים להגדרת build של Cloud Build לכל צינור העיבוד, ולכל מאגר שמשויך לשלב יש שני טריגרים של Cloud Build שמשויכים לקבצים האלה להגדרת build. כשמעבירים קוד לענף במאגר, קובצי תצורת ה-build מופעלים כדי להריץ קודם את cloudbuild-tf-plan.yaml, שמאמת את הקוד באמצעות בדיקות מדיניות ותוכנית Terraform מול הענף הזה, ואז מריץ את cloudbuild-tf-apply.yaml, שמאמת את התוצאה של התוכנית הזו.terraform apply
בדיקות מדיניות ב-Terraform	תוכנית ה-blueprint כוללת קבוצה של אילוצים של Open Policy Agent שנאכפים על ידי אימות המדיניות ב-Google Cloud CLI. האילוצים האלה מגדירים את תצורות המשאבים הקבילות שאפשר לפרוס באמצעות צינור עיבוד הנתונים. אם גרסת build לא עומדת בדרישות המדיניות בהגדרת ה-build הראשונה, הגדרת ה-build השנייה לא תפרוס משאבים. המדיניות שנאכפת בתוכנית הבסיסית היא הסתעפות מ-GoogleCloudPlatform/policy-library ב-GitHub. אתם יכולים לכתוב כללי מדיניות נוספים לספרייה כדי לאכוף כללי מדיניות מותאמים אישית בהתאם לדרישות שלכם.
העקרון של הרשאות מינימליות	לצינור עיבוד הנתונים של השכבה הבסיסית יש חשבון שירות שונה לכל שלב, עם מדיניות הרשאה שמעניקה רק את תפקידי ה-IAM המינימליים לשלב הזה. כל טריגר לפיתוח גרסת Build של Cloud Build פועל כחשבון השירות הספציפי של אותו שלב. שימוש בחשבונות שונים עוזר לצמצם את הסיכון ששינוי במאגר אחד ישפיע על המשאבים שמנוהלים על ידי מאגר אחר. כדי להבין אילו תפקידי IAM חלים על כל חשבון שירות, אפשר לעיין בקוד Terraform sa.tf בשלב האתחול.
מאגרי מומחים פרטיים ב-Cloud Build	התוכנית משתמשת בבריכות פרטיות של Cloud Build. בריכות פרטיות מאפשרות לכם לאכוף אמצעי בקרה נוספים, כמו הגבלת הגישה למאגרי מידע ציבוריים או הפעלת Cloud Build בתוך היקף של VPC Service Controls.
Cloud Build custom builders	התוכנית יוצרת כלי בנייה מותאם אישית משלה כדי להריץ את Terraform. מידע נוסף זמין במאמר 0-bootstrap/Dockerfile. הבקרה הזו מבטיחה שהצינור יפעל באופן עקבי עם קבוצה ידועה של ספריות בגרסאות קבועות.
אישור פריסה	אפשר גם להוסיף שלב של אישור ידני ל-Cloud Build. האישור הזה מוסיף נקודת ביקורת נוספת אחרי הפעלת ה-build אבל לפני ההרצה שלו, כדי שמשתמש עם הרשאות יוכל לאשר את ה-build באופן ידני.

אסטרטגיית הסתעפות

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

הדיאגרמה מתארת שלוש הסתעפויות קבועות ב-Git (פיתוח, לא ייצור וייצור) שמשקפות את הסביבות התואמותGoogle Cloud . יש גם כמה ענפים זמניים של תכונות שלא תואמים למשאבים שנפרסו בסביבותGoogle Cloud .

מומלץ לאכוף תהליך של בקשת משיכה (pull request) (PR) במערכת Git, כך שכל קוד שממוזג עם ענף מתמשך יקבל אישור של בקשת משיכה.

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

1. כשמפתחים יכולות חדשות או עובדים על תיקון באג, צריך ליצור הסתעפות חדשה על בסיס הסתעפות הפיתוח. כדאי להשתמש במוסכמת שמות להסתעפות שכוללת את סוג השינוי, מספר כרטיס או מזהה אחר ותיאור קריא לאנשים, כמו feature/123456-org-policies.
2. כשמסיימים את העבודה בהסתעפות של הפיצ'ר, פותחים בקשת משיכה (PR) שמכוונת להסתעפות הפיתוח.
3. כששולחים את ה-PR, הוא מפעיל את צינור הנתונים של הקרן כדי לבצע את הפעולות terraform plan ו-terraform validate, להכין את השינויים ולאמת אותם.
4. אחרי שמאמתים את השינויים בקוד, ממזגים את הפיצ'ר או את תיקון הבאג עם הסתעפות הפיתוח.
5. תהליך המיזוג מפעיל את צינור הנתונים הבסיסי terraform apply כדי לפרוס את השינויים האחרונים בהסתעפות הפיתוח בסביבת הפיתוח.
6. בודקים את השינויים בסביבת הפיתוח באמצעות בדיקות ידניות, בדיקות פונקציונליות או בדיקות מקצה לקצה שרלוונטיות לתרחיש השימוש. לאחר מכן, כדי להעביר את השינויים לסביבה ללא ייצור, פותחים בקשת מיזוג שמכוונת להסתעפות ללא ייצור וממזגים את השינויים.
7. כדי לפרוס משאבים בסביבת הייצור, חוזרים על אותו תהליך כמו בשלב 6: בודקים ומאמתים את המשאבים שנפרסו, פותחים בקשת משיכה (PR) לענף הייצור וממזגים.

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

• קראו על שיטות מומלצות לביצוע פעולות (המאמר הבא בסדרה).