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

Last reviewed 2023-09-11 UTC

במדריך הזה נסביר איך להוסיף אפליקציה חדשה, לפתח תכונה לאפליקציה ולפרוס את האפליקציה לסביבת ייצור באמצעות טכניקות מודרניות של אינטגרציה רציפה (CI) ופיתוח רציף (CD) עם Google Kubernetes Engine‏ (GKE).

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

במדריך הזה משתמשים בכלים כמו Skaffold,‏ kustomize,‏ Artifact Registry,‏ סנכרון תצורות,‏ Cloud Build ו-Cloud Deploy כדי לפתח, לבנות ולפרוס את האפליקציה.

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

ארכיטקטורה

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

לולאת הפיתוח כוללת מאגרי קוד, צינורות עיבוד נתונים של Cloud Build ו-Cloud Deploy.

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

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

  2. כשמבצעים commit ודחיפה של הקוד למאגר האפליקציות, מופעל אוטומטית צינור CI ב-Cloud Build. תהליך ה-CI יוצר קובץ אימג' של קונטיינר ומעביר אותו בדחיפה ל-Artifact Registry.

  3. תהליך ה-CI יוצר גם מהדורת CD לאפליקציה ב-Cloud Deploy.

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

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

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

מידע נוסף על הכלים והתשתית שמשמשים בתהליך העבודה הזה זמין במאמר Modern CI/CD with GKE: Build a CI/CD system (מודרניזציה של CI/CD עם GKE: בניית מערכת CI/CD).

מטרות

  • הוספת אפליקציה חדשה.

  • פורסים את האפליקציה בסביבת הפיתוח.

  • מפתחים תכונה חדשה ומפרסים אותה בסביבת הפיתוח.

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

  • בודקים את החוסן של האפליקציה.

עלויות

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

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

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

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

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

הכנת הסביבה

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

    gcloud config set core/project PROJECT_ID

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

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

ארכיטקטורת ההפניה מכילה מפעל אפליקציות. המפעל הזה הוא אוסף של מאגר Git בשם application-factory-repo והטריגרים הבאים של Cloud Build:

  • create-app
  • tf-plan
  • tf-apply
  • create-team

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

  1. יצירת הגדרת האפליקציה: יוצרים את הגדרת האפליקציה בקובץ Terraform ושומרים אותה ב-application-factory-repo, שמשמש כקטלוג אפליקציות.

  2. יצירת תשתית האפליקציה: מריצים את Terraform בקובץ הגדרת האפליקציה כדי ליצור את תשתית האפליקציה. תשתית האפליקציה כוללת את הרכיבים הבאים:

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

    2. מאגר התשתית מתוך מאגר התשתית להתחלה שמארח את הקוד ליצירת צינור ה-CI ב-Cloud Build, צינור ה-CD ב-Cloud Deploy ומאגר Artifact Registry לאחסון ארטיפקטים.

    3. טריגר של Cloud Build לתשתית, שמקבל את הקוד במאגר התשתית ויוצר את המשאבים על סמך ההגדרה שלהם.

    4. מאגר אפליקציות ממאגר התחלת האפליקציות שמארח את קוד המקור של האפליקציה.

  3. יצירת משאבי CI/CD של האפליקציה: אתם משתמשים בתשתית האפליקציה כדי ליצור משאבי CI/CD לאפליקציה.

יוצרים הגדרה של אפליקציה:

מריצים את הטריגר create-app כדי ליצור קובץ הגדרת אפליקציה ב-application-factory-repo. קובץ ההגדרה מכיל את ההגדרה הדקלרטיבית של המשאבים שנדרשים ליצירת אפליקציה.

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

    כניסה לדף Cloud Build

  2. לוחצים על create-app trigger (טריגר).

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

  4. ב-Cloud Shell, מפעילים את הטריגר על ידי שליחת בקשת curl לכתובת ה-URL שהתקבלה בשלב הקודם והעברת הפרמטרים כמטען ייעודי (payload) אליה.

    curl "WEBHOOK_URL" -d '{"message": {"app": "sample","runtime": "python","trigger_type": "webhook","github_team": ""}}'

    בדוגמת הקוד הקודמת:

    • מחליפים את WEBHOOK_URL בכתובת ה-URL שהתקבלה מהטריגר.

    • ‫"app": "sample" מציין את שם האפליקציה.

    • ‫"runtime": "python" אומר למפעל האפליקציות להשתמש בתבנית Python כדי ליצור מאגרי אפליקציות.

    • ‫"trigger_type": "webhook" מציין את הסוג של צינורות CI/CD לאפליקציה.

    • ‫"github_team": "" הוא צוות ב-GitHub שישויך למאגרים שייווצרו עבור האפליקציה. מכיוון שעדיין לא יצרת צוות ב-GitHub, צריך להעביר אותו כמחרוזת ריקה.

  5. בודקים את צינור עיבוד הנתונים כדי לראות אם יש טריגר create-app:

    כניסה לדף Cloud Build History.

    יש צינור חדש לטריגר create-app. אחרי שהתהליך מסתיים, הגדרת האפליקציה נוצרת ב-application-factory-repo.

  6. בודקים את קובץ הגדרת האפליקציה:

    1. בדפדפן אינטרנט, עוברים אל GitHub ונכנסים לחשבון.

    2. לוחצים על סמל התמונה ואז על Your organizations. בוחרים את הארגון.

    3. לוחצים על המאגר application-factory-repo, עוברים לתיקייה apps/python ופותחים את הקובץ החדש שנקרא sample.tf שנוצר על ידי הטריגר create-app. בודקים את הקובץ. הקובץ הזה מכיל קוד Terraform ליצירת אפליקציה חדשה.

יצירת תשתית לאפליקציה:

אחרי שיוצרים את הגדרת האפליקציה, מפעילים את הטריגר tf-apply כדי ליצור את התשתית של האפליקציה.

  1. במסוף Google Cloud :

    כניסה לדף Cloud Build .

    לוחצים על הטריגר tf-apply.

  2. לוחצים על 'הצגת תצוגה מקדימה של כתובת ה-URL' כדי להציג את כתובת ה-URL שנדרשת להפעלת ה-webhook.

  3. מפעילים את הטריגר:

    curl "WEBHOOK_URL" -d '{}'

    בדוגמת הקוד הקודמת:

    • מחליפים את WEBHOOK_URL בכתובת ה-URL שהתקבלה מהטריגר.

  4. בודקים את צינור עיבוד הנתונים כדי לראות אם יש טריגר tf-apply:

    כניסה לדף Cloud Build History.

    יש צינור חדש לטריגר tf-apply. מחכים לסיום.

הטריגר הזה יוצר את תשתית האפליקציה.

בודקים את תשתית האפליקציה:

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

אזור נחיתה

  1. נכנסים ל-Cloud Shell ומגדירים את הפרויקט. 

    gcloud config set core/project PROJECT_ID

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

  2. קבלת פרטי כניסה לאשכול GKE לפיתוח.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  3. בודקים את מרחב השמות של האפליקציה. מרחב השמות נקרא על שם האפליקציה, sample.

    kubectl get namespaces sample

    הפלט אמור להיראות כך: 

    NAME     STATUS   AGE
sample   Active   15m

  4. בודקים את חשבון השירות במרחב השמות.

    kubectl get serviceaccounts -n sample

    יש חשבון שירות בנוסף לחשבון שמוגדר כברירת מחדל. הפלט אמור להיראות כך: 

    NAME         SECRETS   AGE
default      0         15m
sample-ksa   0         15m

מאגר תשתית

בדפדפן אינטרנט, עוברים אל GitHub ונכנסים לחשבון. לוחצים על סמל התמונה. אחר כך לוחצים על Your organizations. בוחרים את הארגון ולוחצים על מאגר sample-infra.

מאגר המידע הזה כולל ארבעה ענפים: cicd-trigger, ‏ dev, ‏ staging ו-prod. הוא מכיל גם ארבע תיקיות: cicd-trigger,‏ dev,‏ staging ו-prod. הענף שמוגדר כברירת מחדל הוא cicd-trigger, ואפשר לדחוף אליו את הקוד. לענפים אחרים יש כללי הגנה, ולכן אי אפשר לדחוף קוד ישירות לענפים האלה. כדי להעביר את הקוד לענפים האלה, צריך ליצור בקשת משיכה. התיקייה cicd-trigger מכילה קוד ליצירת משאבי CI/CD לאפליקציה, והתיקיות dev,‏ staging ו-prod מכילות קוד ליצירת תשתית לסביבות שונות של האפליקציה.

טריגר תשתית

  • במסוף Google Cloud :

    כניסה לדף Cloud Build

    יש טריגר חדש בשם deploy-infra-sample.

  • הטריגר הזה מחובר למאגר sample-infra כך שכאשר מתבצעת העברת קוד למאגר הזה, הטריגר מופעל ומזהה את הענף שבו התבצעה ההעברה, עובר לתיקייה המתאימה בענף הזה ומריץ שם את Terraform. לדוגמה, אם הקוד נדחף להסתעפות cicd-trigger, הטריגר מפעיל את Terraform בתיקייה cicd-trigger של ההסתעפות cicd-trigger. באופן דומה, כשמתבצעת דחיפה לענף dev, הטריגר מפעיל את Terraform בתיקיית הפיתוח של ענף הפיתוח וכן הלאה.

מאגר אפליקציות

  • עוברים אל GitHub ומציגים את המאגרים שמופיעים מתחת לארגון. נוצר מאגר חדש בשם sample. מאגר המידע הזה מארח את קוד המקור ואת השלבים לבניית קונטיינרים ב-Dockerfile, הגדרות kustomize שמתארות את ההגדרות הנדרשות של האפליקציה ו-skaffold.yaml שמגדיר את שלבי הפריסה שבהם Cloud Deploy ישתמש ל-CD.

יצירת משאבי CI/CD לאפליקציה

אחרי שיוצרים את השלד של האפליקציה, מריצים את הטריגר deploy-infra-sample כדי ליצור את משאבי ה-CI/CD שלה. אפשר להפעיל את הטריגר באופן ידני באמצעות כתובת ה-URL של ה-webhook שלו, או לבצע פעולת Commit במאגר git sample-infra.

  1. כדי להפעיל את הטריגר לפיתוח גרסת Build של Cloud, מוסיפים שורה חדשה לקובץ במאגר. אחר כך דוחפים את השינויים:

    1. אם עדיין לא השתמשתם ב-Git ב-Cloud Shell, תצטרכו להגדיר את Git עם השם וכתובת האימייל שלכם. המידע הזה ישמש את Git לזיהוי כשאתם יוצרים התחייבויות ב-Cloud Shell:

      git config --global user.email "GITHUB_EMAIL_ADDRESS"
git config --global user.name "GITHUB_USERNAME"

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫GITHUB_EMAIL_ADDRESS: כתובת האימייל שמשויכת לחשבון GitHub שלכם
      • ‫GITHUB_USERNAME: שם המשתמש שמשויך לחשבון GitHub

    2. משכפלים את מאגר ה-Git‏ sample-infra:

      git clone https://github.com/GITHUB_ORG/sample-infra

cd sample-infra

      מחליפים את מה שכתוב בשדות הבאים:

      • ‫GITHUB_ORG בארגון שלכם ב-GitHub.

      הענף cicd-trigger שמוגדר כברירת מחדל נבדק.

    3. מוסיפים שורה חדשה לקובץ env/cicd-trigger/main.tf, מבצעים קומיט לשינוי ודוחפים אותו.

        echo "" >> env/cicd-trigger/main.tf

    4. שומרים ודוחפים את השינויים:

      git add .
git commit -m "A dummy commit to invoke the infrastrucutre trigger"
git push
cd ..

      ברגע שהשינויים נדחפים, מופעל הטריגר deploy-infra-sample של Cloud Deploy.

  2. עוקבים אחרי הסטטוס של הטריגר:

    נכנסים לדף ההיסטוריה של Cloud Build כדי לראות את הצינור וממתינים להשלמתו.

בדיקת משאבי CICD של אפליקציות

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

  1. במסוף Google Cloud :

    נכנסים לדף Cloud Build ומציגים את טריגר deploy-app-sample.

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

  2. עוברים לדף Artifact Registry ורואים את המאגר החדש עם השם sample.

    מאגר ה-Artifact הזה מאחסן את פריטי המידע שנוצרו בתהליך פיתוח (Artifact) של האפליקציה.

  3. עוברים לדף של צינור העברת הנתונים של Cloud Deploy ומציגים את צינור העברת הנתונים עם השם sample. זהו צינור עיבוד הנתונים לפריסה רציפה (CD) שפורס את האפליקציה באשכולות GKE.

פריסת האפליקציה בסביבת הפיתוח

הטריגר deploy-app-sample מחובר למאגר האפליקציות שנקרא sample. אפשר להפעיל את הטריגר באופן ידני באמצעות כתובת ה-URL של ה-webhook, או באמצעות שליחה למאגר האפליקציות.

  1. מוסיפים שורה חדשה לקובץ במאגר sample ומבצעים push של השינויים כדי להפעיל את הטריגר לפיתוח גרסת Build של Cloud Build:

    1. משכפלים את מאגר ה-Git‏ sample:

      ב-Cloud Shell:

      git clone https://github.com/GITHUB_ORG/sample

cd sample

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

    2. מוסיפים שורה חדשה לקובץ skaffold.yaml.

        echo "" >> skaffold.yaml

    3. שומרים ודוחפים את השינויים:

      git add .
git commit -m "A dummy commit to invoke CI/CD trigger"
git push

    4. ברגע שהשינויים נדחפים, מופעל הטריגר deploy-app-sample של Cloud Deploy.

  2. עוקבים אחרי הסטטוס של הטריגר:

    נכנסים לדף ההיסטוריה של Cloud Build כדי לראות את הצינור וממתינים להשלמתו.

    הטריגר מפעיל את השלבים שמוגדרים בהגדרות שלו. השלב הראשון הוא ליצור קובץ אימג' של Docker מקוד האפליקציה במאגר sample. השלב האחרון הוא להפעיל את צינור עיבוד הנתונים של Cloud Deploy שפורס את האפליקציה באשכול GKE של הפיתוח.

  3. בודקים את הפריסה באשכול הפיתוח:

    כניסה לדף Cloud Deploy pipeline.

    לוחצים על sample צינור עיבוד הנתונים. הפריסה באשכול GKE לפיתוח מתחילה. מחכים לסיום.

מוודאים שהאפליקציה נפרסה בהצלחה :

  1. קבלת פרטי כניסה לאשכול הפיתוח.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a

  2. מנהור לאשכול GKE.

    gcloud container clusters get-credentials gke-dev-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. בסרגל הכלים של Cloud Shell, לוחצים על

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

    הפלט שיתקבל:

    Hello World!

  4. ב-Cloud Shell, מקישים על CTRL+C כדי לסיים את העברת היציאה.

הוספת תכונה חדשה לאפליקציה

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

  1. ב-Cloud Shell, משנים את הספרייה למאגר sample שכבר שוכפל:

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

      sed -i "s/Hello World/My new feature/g" main.py

  3. שומרים ודוחפים את השינויים:

    git add .
git commit -m "Changed the message"
git push

    ברגע שהקוד מועבר למאגר ב-GitHub, מופעל טריגר ה-webhook‏ deploy-app-sample.

  4. עוקבים אחרי הסטטוס של הטריגר בדף ההיסטוריה של Cloud Build ומחכים לסיום.

  5. כניסה לדף Cloud Deploy pipeline

    לוחצים על sample צינור עיבוד הנתונים. הפריסה באשכול GKE לפיתוח מתחילה. מחכים לסיום.

מוודאים שהאפליקציה נפרסה בהצלחה :

  1. אם פתחתם Cloud Shell חדש, מקבלים פרטי כניסה לאשכול הפיתוח:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a

  2. מנהור לאשכול GKE:

    gcloud container clusters get-credentials gke-dev-us-central1 --zone us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

  3. בסרגל הכלים של Cloud Shell, לוחצים על

    ‫ Web Preview, ואז לוחצים על Preview on port 8080:

    פקודות בסרגל הכלים של Cloud Shell.

    הפלט שיתקבל:

    My new feature!

  4. ב-Cloud Shell, מקישים על CTRL+C כדי לסיים את העברת היציאה.

קידום השינוי לאשכולות של סביבת הבדיקה וסביבת הייצור

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

יצירת אזור נחיתה באשכולות GKE של סביבת פיתוח וסביבת ייצור

  1. יצירת אזור נחיתה באשכול GKE של סביבת Staging: צריך ליצור בקשת משיכה (pull request) מענף הפיתוח לענף Staging ב-acm-gke-infrastructure-repo ולמזג אותה.

    1. עוברים אל המאגר acm-gke-infrastructure-repo ב-GitHub. לוחצים על הלחצן Pull requests ואז על הלחצן New pull request. בתפריט Base (בסיס), בוחרים באפשרות staging (סביבת ביניים), ובתפריט Compare (השוואה), בוחרים באפשרות dev (פיתוח). לוחצים על הלחצן Create pull request.

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

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

  2. יצירת אזור נחיתה באשכולות GKE בסביבת הייצור: צריך ליצור בקשת משיכה מענף ההכנה לענף הייצור ולמזג אותה.

    1. לוחצים על הלחצן Pull requests ואז על הלחצן New pull request. בתפריט Base (בסיס), בוחרים באפשרות prod (ייצור), ובתפריט Compare (השוואה), בוחרים באפשרות staging (העלאה לבמה). לוחצים על הלחצן Create pull request.

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

    הכלי Config Sync מסנכרן את השינויים שמגיעים לענף prod של מאגר acm-gke-infrastructure-repo עם אשכולות GKE בסביבת הייצור, וכתוצאה מכך נוצר אזור נחיתה לאפליקציה באשכולות GKE בסביבת הייצור.

העברת השינויים מסביבת הפיתוח לסביבת הביניים

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

  1. מאתרים את השם של הגרסה האחרונה ושומרים אותו כמשתנה סביבה:

      export RELEASE=$(gcloud deploy targets describe dev --region=us-central1 --format="json" | jq -r '."Active Pipeline"[0]."projects/PROJECT_ID/locations/us-central1/deliveryPipelines/sample"."Latest release"' | awk -F '/' '{print $NF}')

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

    מוודאים שמשתנה הסביבה הוגדר:

      echo $RELEASE

  2. ב-Cloud Shell, מריצים את הפקודה הבאה כדי להפעיל את הקידום של הגרסה מסביבת הפיתוח לסביבת הבדיקה:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=staging --quiet

  3. בדיקת הפריסה בסביבת פיתוח:

    כניסה לדף Cloud Deploy pipeline

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

  4. מוודאים שהפריסה בסביבת הבדיקה התבצעה בהצלחה:

    1. קבלת פרטי כניסה לאשכול ההכנה:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a

    2. מנהור לאשכול GKE:

      gcloud container clusters get-credentials gke-staging-us-central1 --location us-central1-a && kubectl port-forward --namespace sample $(kubectl get pod --namespace sample --selector="deploy.cloud.google.com/delivery-pipeline-id=sample" --output jsonpath='{.items[0].metadata.name}') 8080:8080

    3. בסרגל הכלים של Cloud Shell, לוחצים על

      ‫ Web Preview, ואז לוחצים על Preview on port 8080:

      פקודות בסרגל הכלים של Cloud Shell.

      הפלט שיתקבל:

      My new feature!

    4. ב-Cloud Shell, מקישים על CTRL+C כדי לסיים את העברת היציאה.

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

עכשיו מקדמים את הגרסה מ-staging ל-prod. יש לכם שני אשכולות של ייצור ול-Cloud Deploy יש יעד לכל אחד מהם בשם prod1 ו-prod2 בהתאמה.

  1. ב-Cloud Shell, מריצים את הפקודה הבאה כדי להפעיל את הקידום של הגרסה מהסביבה הזמנית לאשכול prod1:

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod1 --quiet

  2. הפצה לאשכולות של סביבת הייצור דורשת אישור, ולכן ההשקה מתבצעת רק אחרי שתאשרו אותה. כדי לראות אותו:

    כניסה לדף Cloud Deploy pipeline

    לוחצים על sample צינור. ההשקה ל-prod1 דורשת אישור, וצריך את התפקיד clouddeploy.approver כדי לאשר את ההשקה. כיוון שאתם הבעלים של הפרויקט, יש לכם גישה לאישור ההפצה.

  3. מאשרים את השחרור ל-prod1:

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

     export ROLLOUT=$(gcloud deploy targets describe prod1 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    מאשרים את ההפצה:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  4. אחרי האישור, מתחילה ההפצה של prod1. אפשר לעקוב אחר ההתקדמות בדף צינור עיבוד הנתונים של Cloud Deploy.

  5. אחרי שפריסת prod1 תושלם, מתחילים את פרסום prod2.

     gcloud deploy releases promote --release=$RELEASE --delivery-pipeline=sample  --region=us-central1 --to-target=prod2 --quiet

  6. גם הפצה ל-prod2 דורשת אישור. מאשרים את השחרור לאשכול prod2:

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

     export ROLLOUT=$(gcloud deploy targets describe prod2 --region=us-central1 --format="json" | jq -r '."Pending Approvals"[]' | awk -F '/' '{print $NF}')

    מאשרים את ההפצה:

     gcloud deploy rollouts approve $ROLLOUT --delivery-pipeline=sample --region=us-central1 --release=$RELEASE --quiet

  7. אחרי האישור, מתחילה ההפצה של prod2. אפשר לעקוב אחר ההתקדמות בדף צינור עיבוד הנתונים של Cloud Deploy.

  8. אחרי שצינורות Cloud Deploy ב-prod1 וב-prod2 מסתיימים, צריך לוודא שהפריסה באשכול הייצור בוצעה בהצלחה.

    1. נוצר Multi Cluster Ingress באשכולות הייצור, ואתם משתמשים במאזן עומסים כדי לגשת לאפליקציית הייצור. ההגדרות האלה של Multi Cluster Ingress נוצרות באמצעות קובצי YAML‏ k8s/prod/mci.yaml ו-k8s/prod/mcs.yaml במאגר sample. כששולחים בקשה לכתובת ה-IP של מאזן העומסים, Multi Cluster Ingress מעבירה את הבקשה לאחד משני המופעים של האפליקציה שפועלים בשני אשכולות GKE שונים.

    2. מציגים את כלל ההעברה שמשויך למאזן העומסים כדי למצוא את כתובת ה-IP.

      gcloud compute forwarding-rules list

    3. הפלט אמור להיראות כך: 

      NAME: mci-qqxs9x-fw-sample-sample-ingress
REGION:
IP_ADDRESS: 34.36.123.118
IP_PROTOCOL: TCP
TARGET: mci-qqxs9x-sample-sample-ingress

    4. פותחים דפדפן אינטרנט ומזינים את הכתובת הבאה בכתובת ה-URL: 

      http://IP_ADDRESS:80

      מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים.

      הפלט שיתקבל:

      My new feature!

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

בדיקת עמידות האפליקציה

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

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

כדי לבדוק את החוסן:

  1. מאתרים את מאגר הצמתים של אשכולות GKE בסביבת הייצור שפועלים באזור us-west1. 

     gcloud container clusters describe gke-prod-us-west1 --location=us-west1-a --format=json | jq ".nodePools[0].instanceGroupUrls[]" | tr '"' ' ' |  awk -F '/' '{for(i=NF-2; i<=NF; i=i+2) printf ("%s ",$i); print  ""}'

  2. הפלט אמור להיראות כך:

    us-west1-b gke-gke-prod-us-west1-node-pool-01-6ad4e1ed-grp
us-west1-c gke-gke-prod-us-west1-node-pool-01-98407373-grp

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

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

     gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_1  --zone=ZONE_1 --max-unavailable=100%

 gcloud compute instance-groups managed rolling-action restart INSTANCE_GROUP_2  --zone=ZONE_2 --max-unavailable=100%

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

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

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

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

  4. בודקים את הסטטוס של קבוצת המופעים.

    כניסה לדף Instance groups

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

    הסטטוס של קבוצות המופעים.

  5. פותחים דפדפן אינטרנט ומזינים את הכתובת הבאה בכתובת ה-URL: 

    http://IP_ADDRESS:80

    מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים.

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

     My new feature!

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

ניהול האפליקציה

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

הסרת המשאבים

כדי להימנע מחיובים בחשבון 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.

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