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

Last reviewed 2025-05-15 UTC

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

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

שכבות של פייפליין

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

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

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

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

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

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

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

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

שלב

תיאור

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 משותפות בטופולוגיה שבחרתם ובמשאבי הרשת המשויכים.

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

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

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

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

• כל צינור עיבוד נתונים של תשתית משמש לניהול משאבי תשתית בנפרד ממשאבי הבסיס.
• לכל יחידה עסקית יש צינור משלה של תשתית, שמנוהל בפרויקט ייעודי בתיקייה 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	תוכנית האב יוצרת custom builder משלה כדי להריץ את Terraform. מידע נוסף זמין במאמר 0-bootstrap/Dockerfile. אמצעי הבקרה הזה מבטיח שהצינור יפעל באופן עקבי עם קבוצה ידועה של ספריות בגרסאות מוצמדות.
אישור פריסה	אפשר גם להוסיף שלב של אישור ידני ל-Cloud Build. האישור הזה מוסיף נקודת ביקורת נוספת אחרי הפעלת ה-build אבל לפני ההרצה שלו, כדי שמשתמש עם הרשאות יוכל לאשר את ה-build באופן ידני.

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

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

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

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

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

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

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

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