‫CI/CD מודרני עם GKE: יצירת מערכת CI/CD

ארכיטקטורת ההפניה הזו מספקת שיטה ותשתית ראשונית לבניית מערכת מודרנית של אינטגרציה רציפה/פיתוח רציף (CI/CD) באמצעות כלים כמו Google Kubernetes Engine,‏ Cloud Build,‏ Skaffold,‏ kustomize,‏ סנכרון תצורות,‏ Policy Controller,‏ Artifact Registry ו-Cloud Deploy.

המסמך הזה הוא חלק מסדרה:

המסמך הזה מיועד לאדריכלים ארגוניים ולמפתחי אפליקציות, וגם לצוותי אבטחת IT,‏ DevOps ו-Site Reliability Engineering. כדי להבין את המושגים במסמך הזה, כדאי שיהיה לכם ניסיון מסוים עם כלים ותהליכים אוטומטיים לפריסה.

תהליך עבודה של CI/CD

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

צוותים שונים מנהלים את מערכת ה-CI/CD או חולקים את האחריות עליה.

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

  • לניהול קוד מקור: GitHub
    • מאחסן את קוד האפליקציה וההגדרות.
    • מאפשר לבדוק את השינויים.
  • לניהול הגדרות של אפליקציות: kustomize
    • ההגדרה מגדירה את התצורה המיועדת של אפליקציה.
    • מאפשרת לכם להשתמש מחדש בפרימיטיבים או בתוכניות בסיסיות של הגדרות ולהרחיב אותם.
  • לאינטגרציה רציפה: Cloud Build
    • בודק ומאמת קוד מקור.
    • יוצרת ארטיפקטים של גרסת ה-build שהסביבה של הפריסה צורכת.
  • לפיתוח רציף (CD): Cloud Deploy
    • הגדרת תהליך ההשקה של קוד בסביבות שונות.
    • מספק אפשרות לביטול שינויים שנכשלו.
  • להגדרת התשתית: סנכרון תצורות
    • ההגדרה חלה באופן עקבי על האשכול ועל הגדרות המדיניות.
  • לאכיפת מדיניות: Policy Controller
    • מספק מנגנון שבעזרתו אפשר להגדיר מה מותר להפעיל בסביבה מסוימת על סמך כללי המדיניות של הארגון.
  • לניהול קונטיינרים: Google Kubernetes Engine‏ (GKE)‏
    • הפעלת הארטיפקטים שנבנו במהלך CI.
    • מספקת מתודולוגיות להרחבת נפח העבודה, לבדיקת תקינות ולפריסה של עומסי עבודה.
  • לגבי ארטיפקטים של קונטיינרים: Artifact Registry
    • מאחסן את הארטיפקטים (תמונות קונטיינר) שנבנו במהלך CI.

ארכיטקטורה

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

דיון כללי על ההיבטים האלה של מערכת CI/CD מופיע במאמר Modern CI/CD with GKE: A software delivery framework.

וריאציות של תרשים עזר לארכיטקטורה

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

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

ארכיטקטורה לדוגמה של כמה פרויקטים

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

מידע נוסף זמין במאמר Modern CI/CD with GKE: A software delivery framework.

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

תרשים עזר לארכיטקטורה של פרויקט יחיד

בגרסה single-project של ארכיטקטורת ההפניה מוסבר איך להגדיר את כל פלטפורמת הכנת תוכנה להפצה בפרויקט אחד ב- Google Cloud . הגרסה הזו יכולה לעזור למשתמשים שאין להם תפקידים עם הרשאות גבוהות ב-IAM להתקין את ארכיטקטורת ההפניה ולנסות אותה רק עם תפקיד הבעלים בפרויקט. במסמך הזה מוצגת גרסת הפרויקט היחיד של ארכיטקטורת ההפניה.

תשתית הפלטפורמה

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

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

מאגרי קודים

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

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

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

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

אזורי נחיתה של אפליקציות

בדוגמה הזו לארכיטקטורה, אזור הנחיתה של האפליקציה נוצר כשהאפליקציה מוקצה. במסמך הבא בסדרה הזו, Modern CI/CD with GKE: Apply the developer workflow, מוקצה יישום חדש שיוצר אזור נחיתה משלו. בתרשים הבא מוצגים הרכיבים החשובים של אזורי הנחיתה שמשמשים בארכיטקטורת ההפניה הזו:

אשכול GKE כולל שלושה מרחבי שמות לאפליקציות שונות.

כל מרחב שמות כולל חשבון שירות שמשמש לאיחוד שירותי אימות הזהות של עומסי עבודה ב-GKE כדי לגשת לשירותים מחוץ למאגר Kubernetes, כמו Cloud Storage או Spanner. מרחב השמות כולל גם משאבים אחרים כמו מדיניות רשת, שמאפשרים לבודד או לשתף גבולות עם מרחבי שמות או אפליקציות אחרים.

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

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

מטרות

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

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

  1. בדף לבחירת הפרויקט במסוף Google Cloud , בוחרים פרויקט ב- Google Cloud או יוצרים אותו.

    תפקידים שנדרשים כדי לבחור או ליצור פרויקט

    • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
    • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים

    כניסה לדף לבחירת הפרויקט

  2. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

  3. במסוף Google Cloud , מפעילים את Cloud Shell.

    הפעלת Cloud Shell

פריסת ארכיטקטורת העזר

  1. ב-Cloud Shell, מגדירים את הפרויקט:

    gcloud config set core/project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט ב- Google Cloud .

  2. ב-Cloud Shell, משכפלים את מאגר ה-Git:

    git clone https://github.com/GoogleCloudPlatform/software-delivery-blueprint.git
cd software-delivery-blueprint/launch-scripts
git checkout single-project-blueprint

  3. יוצרים אסימון גישה אישי ב-GitHub עם ההיקפים הבאים:

    • repo
    • delete_repo
    • admin:org
    • admin:repo_hook

  4. יש קובץ ריק בשם vars.sh בתיקייה software-delivery-bluprint/launch-scripts. מוסיפים את התוכן הבא לקובץ: 

    cat << EOF >vars.sh
export INFRA_SETUP_REPO="gke-infrastructure-repo"
export APP_SETUP_REPO="application-factory-repo"
export GITHUB_USER=GITHUB_USER
export TOKEN=TOKEN
export GITHUB_ORG=GITHUB_ORG
export REGION="us-central1"
export SEC_REGION="us-west1"
export TRIGGER_TYPE="webhook"
EOF

    מחליפים את GITHUB_USER בשם המשתמש ב-GitHub.

    מחליפים את TOKEN באסימון הגישה האישי של GitHub.

    מחליפים את GITHUB_ORG בשם הארגון ב-GitHub.

  5. מריצים את הסקריפט bootstrap.sh. אם Cloud Shell מבקש הרשאה, לוחצים על Authorize:

    ./bootstrap.sh

    הסקריפט מאתחל את פלטפורמת הכנת תוכנה להפצה.

עיון במאגרי הקוד

בקטע הזה תבחנו את מאגרי הקוד.

כניסה ל-GitHub

  1. בדפדפן אינטרנט, עוברים אל github.com ונכנסים לחשבון.
  2. לוחצים על סמל התמונה בחלק העליון של הממשק.
  3. לוחצים על הארגונים שלך.
  4. בוחרים את הארגון שציינתם כקלט בקובץ vars.sh.
  5. לוחצים על הכרטיסייה Repositories (מאגרי מידע).

עיון במאגרי התחלה, אופרטור, הגדרה ותשתית

מאגרי starter,‏ operator,‏ configuration ו-infrastructure הם המקומות שבהם אופרטורים ואדמינים של פלטפורמות מגדירים את השיטות המומלצות הנפוצות לבנייה על הפלטפורמה ולהפעלתה. המאגרים האלה נוצרים בארגון שלכם ב-GitHub כשמפעילים את ארכיטקטורת העזר.

כל מאגר ברשימה כולל תיאור קצר.

מאגרי נתונים למתחילים

מאגרי קוד למתחילים עוזרים להטמיע שיטות מומלצות ל-CI/CD, לתשתית ולפיתוח בפלטפורמה. מידע נוסף זמין במאמר Modern CI/CD with GKE: A software delivery framework (מודרניזציה של CI/CD באמצעות GKE: מסגרת להכנת תוכנה להפצה).

מאגרי נתונים לתחילת העבודה עם אפליקציות

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

מאגרי התחלת האפליקציות app-template-python, app-template-java ו-app-template-golang מכילים קוד boilerplate שאפשר להשתמש בו כדי ליצור אפליקציות חדשות. בנוסף ליצירת אפליקציות חדשות, אתם יכולים ליצור תבניות חדשות על סמך הדרישות של האפליקציה. מאגרי האפליקציות שמופיעים בארכיטקטורה לדוגמה מכילים:

  • ‫kustomize base ו-patches בתיקייה k8s.

  • קוד המקור של האפליקציה.

  • Dockerfile שמתאר איך לבנות ולהריץ את האפליקציה.

  • קובץ cloudbuild.yaml שמתאר את השיטות המומלצות לשלבי CI.

  • קובץ skaffold.yaml שמתאר את שלבי הפריסה.

במסמך הבא בסדרה הזו, Modern CI/CD with GKE: Apply the developer workflow, תשתמשו במאגר app-template-python כדי ליצור אפליקציה חדשה.

מאגרי תשתית למתחילים

במאגרי התחלה של תשתית, המפעילים והאדמינים של התשתית יכולים לקודד ולתעד שיטות מומלצות כמו צינורות CI/CD,‏ IaC, איסוף מדדים, רישום ביומן ואבטחה של התשתית. הארכיטקטורה כוללת דוגמאות למאגרי אתחול של תשתית באמצעות Terraform. מאגר התחלה של תשתית infra-template מכיל קוד boilerplate ל-Terraform, שאפשר להשתמש בו כדי ליצור את משאבי התשתית שאפליקציה צריכה, כמו קטגוריית Cloud Storage, מסד נתונים של Spanner או משאבים אחרים.

מאגרי תבניות משותפים

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

מאגרי אופרטורים

בארכיטקטורת ההפניה, מאגרי האופרטור זהים למאגרי התחלת האפליקציה. המפעילים מנהלים את הקבצים שנדרשים ל-CI ול-CD במאגרי התחלה של האפליקציה. תרשים העזר לארכיטקטורה כולל את המאגרים app-template-python, app-template-java ו-app-template-golang.

  • אלה תבניות למתחילים שמכילות את מניפסטים הבסיסיים של Kubernetes לאפליקציות שפועלות ב-Kubernetes בפלטפורמה. מפעילים יכולים לעדכן את קובצי המניפסט בתבניות ההתחלתיות לפי הצורך. העדכונים נאספים כשיוצרים אפליקציה.
  • הקבצים cloudbuild.yaml ו-skaffold.yaml במאגרים האלה כוללים את השיטות המומלצות להפעלת CI ו-CD בפלטפורמה, בהתאמה. בדומה להגדרות של האפליקציה, מפעילים יכולים לעדכן ולהוסיף שלבים לשיטות המומלצות. צינורות (pipelines) של אפליקציות נפרדות נוצרים באמצעות השלבים העדכניים.

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

התרשים הבא ממחיש הגדרת בסיס לאפליקציית Spring Boot:

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

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

מידע נוסף על שימוש ב-kustomize לניהול מניפסטים של Kubernetes זמין במסמכי העזרה של kustomize.

מאגרי תצורה ומדיניות

ארכיטקטורת ההפניה כוללת הטמעה של מאגר מדיניות והגדרות שמשתמש ב-סנכרון תצורות וב-Policy Controller. מאגר acm-gke-infrastructure-repo מכיל את ההגדרות ואת כללי המדיניות שאתם פורסים באשכולות של סביבת האפליקציה. ההגדרה שמוגדרת ומאוחסנת על ידי אדמינים של הפלטפורמה במאגרים האלה חשובה כדי להבטיח שלפלטפורמה יהיה מראה ותחושה עקביים עבור צוותי התפעול והפיתוח.

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

הגדרות אישיות

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

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

מדיניות

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

בתרשים הבא מוצג תהליך הבקשה ליצירת משאב באמצעות Policy Controller:

קודם מגדירים כלל מדיניות ואז מחילים אותו באמצעות כלים שונים כמו kubectl ולקוחות API.

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

מידע נוסף על ניהול מדיניות זמין במאמר סקירה כללית של Policy Controller.

מאגרי תשתית

במקור המידע הזה יש הטמעה של מאגר תשתית באמצעות Terraform. מאגר gke-infrastructure-repo מכיל תשתית כקוד ליצירת אשכולות GKE לסביבות פיתוח, Staging וייצור, ולהגדרת סנכרון תצורות בהם באמצעות מאגר acm-gke-infrastructure-repo. התיקייה gke-infrastructure-repo מכילה שלוש הסתעפויות, אחת לכל סביבת פיתוח, Staging וייצור. בכל ענף יש גם תיקיות של פיתוח, Staging וייצור.

עיון בצינור ובאינפראסטרוקטורה

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

פייפליין

בקטע הזה תלמדו על פייפליין של תשתית כשירות (IaaS) ותפעילו פתרונות חכמים כדי ליצור את התשתית המשותפת, כולל אשכולות GKE. הפייפליין הוא טריגר לפיתוח גרסת Build של Cloud Build בשם create-infra בפרויקט Google Cloud שמקושר למאגר התשתית gke-infrastructure-repo. אתם פועלים לפי מתודולוגיית GitOps כדי ליצור תשתית, כמו שמוסבר בסרטון סביבות GCP שניתן לשחזר לפי עומס באמצעות צינורות עיבוד נתונים של Cloud Build בשימוש בתשתית כקוד.

ל-gke-infrastructure-repo יש ענפים לפיתוח, Staging וייצור. במאגר יש גם תיקיות dev,‏ staging ו-production שתואמות לענפים האלה. יש כללי הגנה על הסתעפות במאגר, שמבטיחים שאפשר לדחוף את הקוד רק לסניף הפיתוח. כדי להעביר את הקוד לענפי ההכנה והייצור, צריך ליצור בקשת משיכה.

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

כשמתבצעת דחיפה אל gke-infrastructure-repo, מופעל הטריגר create-infra. הטריגר הזה מזהה את הענף שבו בוצעה הפעולה push ועובר לתיקייה המתאימה במאגר באותו ענף. אחרי שהיא מוצאת את התיקייה המתאימה, היא מריצה את Terraform באמצעות הקבצים שהתיקייה מכילה. לדוגמה, אם הקוד נדחף לסניף הפיתוח, הטריגר מפעיל את Terraform בתיקיית הפיתוח של סניף הפיתוח כדי ליצור אשכול GKE לפיתוח. באופן דומה, כשמתבצעת פעולת push להסתעפות staging, הטריגר מפעיל את Terraform בתיקיית הביניים של הסתעפות הביניים כדי ליצור אשכול GKE של ביניים.

מריצים את צינור הנתונים כדי ליצור אשכולות GKE:

  1. במסוף Google Cloud , עוברים לדף Cloud Build.

    כניסה לדף Cloud Build

    • יש חמישה טריגרים של Cloud Build webhook. מחפשים את הטריגר בשם create-infra. הטריגר הזה יוצר את התשתית המשותפת, כולל אשכולות GKE.

  2. לוחצים על שם הטריגר. הגדרת הטריגר תיפתח.

  3. לוחצים על פתיחת העורך כדי לראות את השלבים שהטריגר מפעיל.

    הטריגרים האחרים משמשים כשמפעילים אפליקציה ב-Modern CI/CD with GKE: Apply the developer workflow

    טריגרים של Cloud Build.

  4. במסוף Google Cloud , עוברים לדף Cloud Build.

    כניסה לדף ההיסטוריה של Cloud Build

    בודקים את הפייפליין שמופיע בדף ההיסטוריה. כשפרסתם את פלטפורמת הכנת התוכנה להפצה באמצעות bootstrap.sh, הסקריפט דחף את הקוד לענף הפיתוח של מאגר gke-infrastructure-repo שהפעיל את הפייפליין הזה ויצר את אשכול GKE של הפיתוח.

  5. כדי ליצור אשכול GKE של סביבת פיתוח, שולחים בקשת מיזוג (pull request) מענף הפיתוח לענף סביבת הפיתוח:

    1. עוברים אל GitHub ומנווטים אל המאגר gke-infrastructure-repo.

    2. לוחצים על Pull requests (בקשות משיכה) ואז על New pull request (בקשת משיכה חדשה).

    3. בתפריט Base, בוחרים באפשרות staging, ובתפריט Compare, בוחרים באפשרות dev.

    4. לוחצים על Create pull request.

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

  7. במסוף Google Cloud , עוברים אל דף ההיסטוריה של Cloud Build.

    כניסה לדף ההיסטוריה של Cloud Build

    צינור עיבוד נתונים שני של Cloud Build מתחיל בפרויקט. צינור עיבוד הנתונים הזה יוצר את אשכול ה-GKE של שלב הביניים.

  8. כדי ליצור אשכולות GKE של סביבת הייצור, שולחים pull request מסניף הביניים לסניף הייצור:

    1. עוברים אל GitHub ומנווטים אל המאגר gke-infrastructure-repo.

    2. לוחצים על Pull requests (בקשות משיכה) ואז על New pull request (בקשת משיכה חדשה).

    3. בתפריט Base, בוחרים באפשרות prod, ובתפריט Compare, בוחרים באפשרות staging.

    4. לוחצים על Create pull request.

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

  10. במסוף Google Cloud , עוברים אל דף ההיסטוריה של Cloud Build.

    כניסה לדף ההיסטוריה של Cloud Build

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

תשתית

בקטע הזה נבחן את התשתית שנוצרה על ידי צינורות הנתונים.

  • נכנסים לדף Kubernetes clusters במסוף Google Cloud .

    כניסה לדף Kubernetes clusters

    בדף הזה מפורטים האשכולות שמשמשים לפיתוח (gke-dev-us-central1), לבדיקות (gke-staging-us-central1) ולייצור ( gke-prod-us-central1, gke-prod-us-west1):

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

אשכול פיתוח

אשכול הפיתוח (gke-dev-us-central1) מעניק למפתחים גישה למרחב שמות שבו הם יכולים לבצע איטרציות על האפליקציות שלהם. מומלץ לצוותים להשתמש בכלים כמו Skaffold, שמספקים תהליך עבודה איטרטיבי על ידי מעקב פעיל אחרי הקוד בפיתוח והחלה מחדש על סביבות הפיתוח כשמתבצעים שינויים. לולאת האיטרציה הזו דומה לטעינה מחדש בזמן אמת. אבל במקום להיות ספציפי לשפת תכנות, הלולאה פועלת עם כל אפליקציה שאפשר ליצור באמצעות קובץ אימג' של Docker. אפשר להריץ את הלולאה בתוך אשכול Kubernetes.

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

במסמך הבא בסדרה הזו, מודרניזציה של CI/CD עם GKE: יישום תהליך העבודה של המפתח, תשתמשו ב-Skaffold וב-CI/CD כדי ליצור את לולאת הפיתוח.

אשכול Staging

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

קלאסטר ייצור

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

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

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

אחרי שסיימתם לעיין בארכיטקטורת ההפניה, אתם יכולים לעיין בתהליך העבודה של מפתח שמבוסס על ההטמעה הזו. במסמך הבא בסדרה הזו, Modern CI/CD with GKE: Apply the developer workflow, יוצרים אפליקציה חדשה, מוסיפים תכונה ואז פורסים את האפליקציה בסביבות של staging וייצור.

הסרת המשאבים

אם רוצים לנסות את המסמך הבא בסדרה, Modern CI/CD with GKE: Applying the developer workflow, לא מוחקים את הפרויקט או את המשאבים שמשויכים לארכיטקטורת ההפניה הזו. אחרת, כדי להימנע מחיובים בחשבון Google Cloudעל המשאבים שבהם השתמשתם בארכיטקטורת ההפניה, אתם יכולים למחוק את הפרויקט או להסיר את המשאבים באופן ידני.

מחיקת הפרויקט

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

הסרת המשאבים באופן ידני

  • ב-Cloud Shell, מסירים את התשתית:

      gcloud container clusters delete gke-dev-us-central1
  gcloud container clusters delete gke-staging-us-central1
  gcloud container clusters delete gke-prod-us-central1
  gcloud container clusters delete gke-prod-us-west1
  gcloud beta builds triggers delete create-infra
  gcloud beta builds triggers delete add-team-files
  gcloud beta builds triggers delete create-app
  gcloud beta builds triggers delete tf-plan
  gcloud beta builds triggers delete tf-apply

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