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

Last reviewed 2024-12-13 UTC

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

תוכנית האב משתמשת בצינורות הבאים:

• צינור עיבוד הנתונים של תשתית הבסיס (חלק מתוכנית הבסיס לארגונים) פורס את מפעל האפליקציות, את צינור עיבוד הנתונים של התשתית מרובת הדיירים ואת צינור עיבוד הנתונים בהיקף הצי.
• פייפליין התשתית מרובת הדיירים פורס את אשכולות GKE ואת שאר השירותים המנוהלים שהתוכנית של אפליקציית הארגון מסתמכת עליהם.
• צינור הנתונים ברמת ה-Fleet מגדיר היקפי Fleet, מרחבי שמות ותפקידים והרשאות ב-RBAC.
• מפעל האפליקציות מספק מנגנון לפריסת צינורות חדשים של אפליקציות באמצעות תהליך מבוסס-תבניות.
• צינור עיבוד נתונים של CI/CD לאפליקציות מספק צינור עיבוד נתונים של CI/CD לפריסת שירותים באשכולות GKE.
• ‫סנכרון תצורות פורס ומנהל הגדרות נוספות של Kubernetes, כולל אילוצים של Policy Controller.

מאגרים, תורמים למאגרים וגורמים מאשרים של שינויים במאגרים

הפעלת צינורות ה-blueprint מתבצעת באמצעות שינויים במאגרי Git. בטבלה הבאה מתוארים המאגרים שבהם נעשה שימוש בתוכנית, מי תורם למאגר, מי מאשר שינויים במאגר, באיזה צינור נעשה שימוש במאגר ותיאור של מה שהמאגר מכיל.

מאגר	תורם/ת למאגר	הגורם המאשר את השינוי במאגר	פייפליין	תיאור
infra	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	צינור עיבוד נתונים של תשתית בסיסית	מאגר שמכיל את הקוד לפריסת צינור עיבוד הנתונים של תשתית מרובת דיירים, האפליקציה וצינור עיבוד הנתונים בהיקף הצי.
eab-infra	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	תשתית של דירות שותפים	מודולים של Terraform שמשמשים צוותים של פלטפורמות למפתחים כשהם יוצרים את התשתית
fleet-scope	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	היקף הצי	המאגר שמגדיר את מרחבי השמות וההיקפים של צוות הצי ב-fleet
app-factory	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	מפעל אפליקציות	הקוד שמגדיר את מאגר האפליקציות ומפנה למודולים במאגר terraform-modules
app-template	מפַתח האפליקציה	אופרטור של אפליקציות	Application factory	קוד הבסיס שמוצב במאגר app-code כשיוצרים את המאגר בפעם הראשונה
terraform-modules	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	Application factory תשתית של דירות שותפים	מודולים של Terraform שמגדירים את האפליקציה ואת התשתית
app-code	מפַתח האפליקציה	אופרטור של אפליקציות	CI/CD של אפליקציות	קוד האפליקציה שנפרס באשכולות GKE
config-policy	מפתח פלטפורמות למפתחים	אדמין של פלטפורמת פיתוח	סנכרון תצורות	המדיניות שבה נעשה שימוש באשכולות GKE כדי לשמור על ההגדרות שלהם

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

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

ה-pipeline של תשתית הבסיס מתואר בתוכנית הבסיסית של Enterprise והוא משמש כנקודת כניסה כללית לפריסות נוספות של משאבים. בטבלה הבאה מתוארים הרכיבים שנוצרים בצינור.

רכיב	תיאור
צינור של תשתית מרובת דיירים	יוצר את התשתית המשותפת שמשמשת את כל הדיירים בפלטפורמת הפיתוח.
פייפליין בהיקף צי הרכבים	יוצר מרחבי שמות וקישורי תפקידים של RBAC.
Application factory	יוצר צינורות עיבוד נתונים של CI/CD לאפליקציה, שמשמשים לפריסת השירותים.

צינור עיבוד נתונים של תשתית עם מספר דיירים

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

בטבלה הבאה מתוארים הרכיבים שצינור הנתונים של התשתית מרובת הדיירים יוצר.

רכיב	תיאור
אשכולות GKE	השירות הזה מספק אירוח לשירותים של האפליקציה שמופעלת בקונטיינר.
Policy Controller	מספק מדיניות שעוזרת לוודא שההגדרות של אשכולות ושירותים של GKE תקינות.
סנכרון תצורות	הכלי מחיל את כללי המדיניות של Policy Controller על אשכולות ושומר על יישום עקבי של כללי המדיניות.
מפתח Cloud Key Management Service ‏(Cloud KMS)	המערכת יוצרת את מפתח ההצפנה שמבוסס על מפתח הצפנה בניהול הלקוח (CMEK) ל-GKE, ל-AlloyDB ל-PostgreSQL ול-Secret Manager.
סוד ב-Secret Manager	מספק מאגר סודי לזוג מפתחות RSA שמשמש לאימות משתמשים באמצעות אסימוני אינטרנט מסוג JSON‏ (JWT).
מדיניות אבטחה של Cloud Armor	מציג את המדיניות שבה נעשה שימוש בחומת האש של אפליקציות האינטרנט ב-Cloud Armor.

פייפליין בהיקף הצי

צינור הנתונים בהיקף הצי אחראי להגדרת מרחבי השמות והקשרים של RBAC באשכולות GKE של הצי. בטבלה הבאה מתוארים הרכיבים שנוצרים בצינור העיבוד (pipeline) ברמת הצי.

רכיב	תיאור
מרחב שמות	הגדרה של האשכולות הלוגיים בתוך האשכול הפיזי.
RBAC (תפקידים וקישורים)	ההרשאה שמוגדרת לחשבון שירות של Kubernetes ברמת האשכול או ברמת מרחב השמות.

מפעל אפליקציות

מפעל האפליקציות נפרס על ידי צינור התשתית הבסיסי ומשמש ליצירת תשתית לכל אפליקציה חדשה. התשתית הזו כוללת פרויקט ב- Google Cloud שמכיל את צינור עיבוד הנתונים של CI/CD של האפליקציה.

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

ה-application factory כולל את הרכיבים הבאים:

• מאגר של מפעל אפליקציות: מאגר Git שבו מאוחסנת הגדרת האפליקציה הדקלרטיבית.
• צינורות ליצירת אפליקציות: צינורות שנדרש בהם Cloud Build כדי לבצע את הפעולות הבאות:
  • יוצרים הגדרה הצהרתית של האפליקציה ומאחסנים אותה בקטלוג האפליקציות.
  • מחילים את הגדרת האפליקציה הדקלרטיבית כדי ליצור את משאבי האפליקציה.
• מאגר תבניות של אפליקציות למתחילים: תבניות ליצירת אפליקציה פשוטה (לדוגמה, מיקרו-שירות ב-Python, ב-Golang או ב-Java).
• מודולים משותפים: מודולים של Terraform שנוצרו באמצעות שיטות סטנדרטיות ומשמשים למטרות שונות, כולל צירוף אפליקציות ופריסה שלהן.

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

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

צינור עיבוד נתונים של CI/CD באפליקציה

פייפליין CI/CD של אפליקציה מאפשר לבצע אוטומציה של בנייה ופריסה של אפליקציות מבוססות-קונטיינר. הפייפליין מורכב משלבים של אינטגרציה רציפה (CI) ופריסה רציפה (CD). ארכיטקטורת צינור עיבוד הנתונים מבוססת על תוכנית הבסיס המאובטחת של CI/CD.

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

כדי להגיע לאשכולות GKE דרך נתיב רשת פרטי ולנהל את kubeconfigהאימות, צינור ה-CI/CD של האפליקציה מתקשר עם אשכולות GKE דרך שער Connect. צינור עיבוד הנתונים משתמש גם במאגרי כתובות פרטיים לסביבת ה-CI/CD.

כל מאגר המקורות של הקוד של אפליקציה כולל הגדרות Kubernetes. ההגדרות האלה מאפשרות לאפליקציות לפעול בהצלחה כשירותי Kubernetes ב-GKE. בטבלה הבאה מתוארים סוגי ההגדרות של Kubernetes שצינור עיבוד הנתונים של CI/CD באפליקציה חל עליהן.

רכיב	תיאור
פריסה	הגדרה של קבוצת פודים (קונטיינרים) שניתנים להרחבה.
Service	הופך את הפריסה לזמינה ברשת האשכול.
שירות וירטואלי	הופך שירות לחלק מ-Service mesh.
כלל יעד	הגדרת הדרך שבה עמיתים ב-Service mesh צריכים להגיע לשירות וירטואלי. משמש בתוכנית ה-blueprint להגדרת איזון עומסים מקומי לתנועת נתונים ממזרח למערב.
מדיניות הרשאות	הגדרת בקרת גישה בין עומסי עבודה ב-Service mesh.
חשבון שירות של Kubernetes	ההגדרה מגדירה את הזהות שבה משתמש שירות Kubernetes. במאמר איחוד זהויות של עומסי עבודה ל-GKE מוסבר על Google Cloud חשבון השירות שמשמש לגישה לGoogle Cloud משאבים.
Gateway	מאפשרת לתעבורת נתונים נכנסת (ingress) חיצונית להגיע לשירות. השער נדרש רק בפריסות שמקבלות תנועה חיצונית.
GCPBackendPolicy	הגדרת SSL,‏ Cloud Armor,‏ session affinity ו-connection draining לפריסות שמקבלות תנועה חיצונית. ‫GCPBackendPolicy משמש רק לפריסות שמקבלות תנועה חיצונית.
PodMonitoring	ההגדרה קובעת את איסוף המדדים של Prometheus שמיוצאים על ידי אפליקציה.

אינטגרציה רציפה (CI)

בתרשים הבא מוצג תהליך האינטגרציה הרציפה.

התהליך הוא כזה:

1. מפתח מבצע קומיט של קוד האפליקציה למאגר קוד המקור של האפליקציה. הפעולה הזו מפעילה את Cloud Build כדי להתחיל את צינור השילוב.
2. ‫Cloud Build יוצר קובץ אימג' של קונטיינר, מעביר את קובץ האימג' של הקונטיינר ל-Artifact Registry ויוצר תקציר של קובץ האימג'.
3. ‫Cloud Build מבצע בדיקות אוטומטיות לאפליקציה. יכול להיות שיתבצעו חבילות בדיקה שונות בהתאם לשפת האפליקציה.
4. ‫Cloud Build מבצע את הסריקות הבאות בקובץ האימג' של הקונטיינר:
   1. ‫Cloud Build מנתח את הקונטיינר באמצעות מסגרת Container Structure Tests. המסגרת הזו מבצעת בדיקות של פקודות, בדיקות של קיום קבצים, בדיקות של תוכן קבצים ובדיקות של מטא-נתונים.
   2. ב-Cloud Build נעשה שימוש בסריקת נקודות חולשה כדי לזהות נקודות חולשה בקובץ האימג' של הקונטיינר, בהשוואה למסד נתונים של נקודות חולשה שמתוחזק על ידי Google Cloud.
5. ‫Cloud Build מאשר את התמונה כדי להמשיך בצינור עיבוד הנתונים אחרי תוצאות סריקה מוצלחות.
6. ‫Binary Authorization חותם על התמונה. ‫Binary Authorization הוא שירות ב- Google Cloud שמספק אבטחה לשרשרת אספקת תוכנה לאפליקציות מבוססות-קונטיינרים באמצעות מדיניות, כללים, הערות, אישורים, גורמים מאמתים וחותמים. בזמן הפריסה, כלי האכיפה של מדיניות Binary Authorization עוזר לוודא את המקור של הקונטיינר לפני שהוא מאפשר את הפריסה שלו.
7. ‫Cloud Build יוצר גרסת הפצה ב-Cloud Deploy כדי להתחיל את תהליך הפריסה.

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

פריסה רציפה

הדיאגרמה הבאה מציגה את תהליך הפריסה הרציפה (CD).

התהליך הוא כזה:

1. בסוף תהליך ה-build, צינור ה-CI/CD של האפליקציה יוצר גרסה חדשה של Cloud Deploy כדי להשיק את קובצי האימג' החדשים של הקונטיינרים באופן הדרגתי בכל סביבה.
2. ‫Cloud Deploy מתחיל פריסה לסביבה הראשונה בצינור עיבוד הנתונים לפריסה, שהיא בדרך כלל סביבת פיתוח. כל שלב בהטמעה מוגדר לדרוש אישור ידני.
3. צינורות עיבוד הנתונים של Cloud Deploy משתמשים בפריסה רציפה כדי לפרוס תמונות לכל אשכול בסביבה לפי הסדר.
4. בסוף כל שלב פריסה, Cloud Deploy מאמת את הפונקציונליות של הקונטיינרים שנפרסו. אפשר להגדיר את השלבים האלה בהגדרות של Skaffold עבור האפליקציות.

פריסת אפליקציה חדשה

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

כדי להגדיר אפליקציה חדשה:

1. אופרטור של אפליקציות מגדיר אפליקציה חדשה בדייר (tenant) שלו על ידי הרצת טריגר לפיתוח גרסת Build של Cloud Build כדי ליצור את הגדרת האפליקציה.
2. הטריגר מוסיף רשומה חדשה לאפליקציה ב-Terraform ומבצע commit לשינוי במאגר של מפעל האפליקציות.
3. השינוי שבוצע מפעיל את היצירה של מאגרי מידע ופרויקטים ספציפיים לאפליקציה.
4. מערכת Cloud Build מבצעת את הפעולות הבאות:
   1. יוצר שתי מאגרי Git חדשים לאירוח קוד המקור של האפליקציה ו-IaC.
   2. הכלי מעביר את המניפסטים של Kubernetes לכללי מדיניות של רשת ואת איחוד הזהויות של עומסי העבודה ל-GKE אל מאגר ניהול ההגדרות.
   3. יוצר את פרויקט ה-CI/CD של האפליקציה ואת טריגר ה-IaC של Cloud Build.
5. הטריגר של Cloud Build IaC לאפליקציה יוצר את צינור ה-CI/CD של האפליקציה ואת מאגר Artifact Registry בפרויקט ה-CI/CD של האפליקציה.
6. ‫סנכרון תצורות פורס את מדיניות הרשת ב-Kubernetes ואת ההגדרות של איחוד זהויות של עומסי עבודה ל-GKE באשכולות GKE מרובי-דיירים.
7. פייפליין ליצירת היקף Fleet יוצר את היקף ה-Fleet ואת מרחב השמות של האפליקציה באשכולות GKE עם ריבוי דיירים.
8. צינור ה-CI/CD של האפליקציה מבצע את הפריסה הראשונית של האפליקציה לאשכולות GKE.
9. אופציונלית, צוות האפליקציה משתמש בטריגר IaC של Cloud Build כדי לפרוס פרויקטים ומשאבים נוספים (לדוגמה, מסדי נתונים ושירותים מנוהלים אחרים) לפרויקטים ייעודיים של דייר יחיד, אחד לכל סביבה.

ניהול ההגדרות והמדיניות של GKE

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

בתוכנית הזו, סנכרון תצורות מחיל אילוצים של Policy Controller. ההגדרות האלה מגדירות אמצעי בקרה לאבטחה ולתאימות, כפי שהוגדרו על ידי האדמינים של פלטפורמת הפיתוח בארגון. תוכנית הפעולה הזו מסתמכת על צינורות אחרים כדי להחיל הגדרות אחרות: צינורות ה-CI/CD של האפליקציה מחילים הגדרה ספציפית לאפליקציה, וצינור ה-fleet-scope יוצר מרחבי שמות ושיוכי תפקידים קשורים.

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

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