‫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 שהסביבה של הפריסה צורכת.
  • לפיתוח רציף: Cloud Deploy
    • הגדרת תהליך ההשקה של קוד בסביבות שונות.
    • מספק אפשרות לביטול שינויים שנכשלו.
  • להגדרת התשתית: סנכרון תצורות
    • ההגדרה חלה באופן עקבי על האשכול ועל הגדרות המדיניות.
  • לאכיפת מדיניות: Policy Controller
    • מספק מנגנון שבעזרתו אפשר להגדיר מה מותר להפעיל בסביבה נתונה על סמך המדיניות של הארגון.
  • לתיזמור קונטיינרים: Google Kubernetes Engine
    • הפעלת הארטיפקטים שנבנו במהלך 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. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  2. Verify that billing is enabled for your Google Cloud project.

  3. In the Google Cloud console, activate Cloud Shell.

    Activate 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.

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

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

    מאגרי תשתית

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

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

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

    פייפליין

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

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

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

    כשמתבצעת דחיפה אל 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 של סביבת Staging, שולחים בקשת משיכה (pull request) מהסתעפות הפיתוח להסתעפות סביבת Staging:

      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, מומלץ להשתמש ב-Config Sync. מידע נוסף על ניהול המשאבים האלה זמין במאמר מאגרי תצורות ומדיניות.

    יישום של הארכיטקטורה

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

    הסרת המשאבים

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

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

    1. In the Google Cloud console, go to the Manage resources page.

      Go to Manage resources

    2. In the project list, select the project that you want to delete, and then click Delete.
    3. In the dialog, type the project ID, and then click Shut down to delete the project.

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

    • ב-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

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