‫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
    • בודק ומאמת קוד מקור.
    • יוצר פריטי מידע שסביבת הפריסה צורכת.
  • לפיתוח רציף (CD): Cloud Deploy
    • הגדרת תהליך ההשקה של קוד בסביבות שונות.
    • מאפשר לבטל שינויים שנכשלו.
  • להגדרת התשתית: סנכרון תצורות
    • מחיל באופן עקבי את הגדרות האשכול והמדיניות.
  • לאכיפת מדיניות: Policy Controller
    • מספק מנגנון שבעזרתו אפשר להגדיר מה מותר להפעיל בסביבה נתונה על סמך כללי המדיניות של הארגון.
  • לתיזמור קונטיינרים: Google Kubernetes Engine
    • מפעיל את הארטיפקטים שנבנו במהלך ה-CI.
    • מספק שיטות להרחבת נפח העבודה, לבדיקת תקינות ולפריסה של עומסי עבודה.
  • לפריטי מידע שנוצרו בתהליך הפיתוח (Artifact) של קונטיינרים: Artifact Registry
    • מאחסן את הארטיפקטים (תמונות של קונטיינרים) שנבנו במהלך CI.

ארכיטקטורה

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

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

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

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

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

ארכיטקטורת הפניה מרובת-פרויקטים

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

למידע נוסף, ראו Modern CI/CD with GKE: A הכנת תוכנה להפצה framework.

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

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

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

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

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

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

מאגרי קודים

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

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

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

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

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

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

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

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

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

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

מטרות

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

עלויות

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

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

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

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

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

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

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

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

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

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

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

    הפעלת 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 שמתאר את שלבי הפריסה.

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

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

במאגרי התשתית למתחילים, המפעילים והאדמינים של התשתית יכולים לקודד ולתעד שיטות מומלצות כמו צינורות CI/CD,‏ IaC, איסוף מדדים, רישום ביומן ואבטחה של התשתית. הארכיטקטורה כוללת דוגמאות למאגרי תשתית ראשוניים באמצעות Terraform. מאגר ה-infrastructure starter של 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.

מידע נוסף על ניהול מדיניות זמין במאמר סקירה כללית של 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 שתואמות לענפים האלה. במאגר יש כללי הגנה על ההסתעפות שמוודאים שאפשר להעביר את הקוד רק להסתעפות dev. כדי להעביר את הקוד להסתעפויות של סביבת ה-Staging וסביבת הייצור, צריך ליצור בקשת משיכה.

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

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

מריצים את צינור הנתונים כדי ליצור אשכולות 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

    טריגרים לפיתוח גרסת Build ב-Cloud.

  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. אם אתם אדמינים במאגר, אתם יכולים למזג את בקשת המשיכה (pull request). אם לא, צריך לבקש מהאדמין למזג את בקשת ה-pull.

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

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

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

תשתית

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

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

    כניסה לדף Kubernetes clusters

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

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

אוסף פיתוח

אשכול הפיתוח (gke-dev-us-central1) מעניק למפתחים גישה למרחב שמות שבו הם יכולים לבצע איטרציות על האפליקציות שלהם. אנחנו ממליצים לצוותים להשתמש בכלים כמו Skaffold, שמספקים תהליך עבודה איטרטיבי על ידי מעקב פעיל אחרי הקוד בפיתוח והחלה מחדש שלו על סביבות הפיתוח ככל שמבוצעים שינויים. לולאת האיטרציה הזו דומה לHot Reload. עם זאת, במקום להיות ספציפית לשפת תכנות, הלולאה פועלת עם כל אפליקציה שאפשר ליצור באמצעות קובץ אימג' של 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, יוצרים אפליקציה חדשה, מוסיפים תכונה ואז פורסים את האפליקציה בסביבות הבדיקה והייצור.

הסרת המשאבים

אם רוצים לנסות את המסמך הבא בסדרה, 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

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