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

סדרת המדריכים הזו מיועדת לאדמינים ולמפעילים בתחום ה-IT שרוצים לפרוס, להריץ ולנהל סביבות אפליקציות מודרניות שפועלות ב-Google Kubernetes Engine. בסדרת המדריכים הזו תלמדו איך להגדיר מעקב והתראות, לשנות את גודל עומסי העבודה ולבצע סימולציה של כשל, והכול באמצעות אפליקציית המיקרו-שירותים לדוגמה Cymbal Bank:

יצירת אשכול ופריסת אפליקציה לדוגמה
מעקב באמצעות השירות המנוהל של Google Cloud ל-Prometheus
התאמה לעומסי עבודה
סימולציה של כשל
ניהול שינויים באופן מרכזי (המדריך הזה)

סקירה כללית ומטרות

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

במדריך ליצירת אשכול יצרתם אשכול ופרסתם את אפליקציית Cymbal Bank באשכול הזה.

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

יצירת מאגר Git וחיבור שלו ל-Cloud Build
יצירת אשכול, רישום שלו לצי, והתקנת סנכרון תצורות בצי האשכולות
שימוש בחבילת צי לפרסום Cymbal Bank ומשאבים אחרים באשכול או בצי

עלויות

אם מפעילים את GKE ומפריסים את אפליקציית הדוגמה Cymbal Bank בסדרת הדרכות הזו, יחויבו עלויות לכל אשכול עבור GKE ב- Google Cloud , כמו שמופיע בדף התמחור, עד להשבתת GKE או למחיקת הפרויקט.

אתם אחראים גם לעלויות אחרות Google Cloud שנוצרות בזמן הפעלת אפליקציית הדוגמה Cymbal Bank, כמו חיובים על מכונות וירטואליות ב-Compute Engine ומאזני עומסים.

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

כדי ללמוד איך לאחסן משאבים ממאגר Git, לבצע בהם שינויים ולפרוס אותם, צריך להשלים את המדריך הראשון ליצירת אשכול GKE שמשתמש במצב Autopilot ולפריסת אפליקציית המיקרו-שירותים לדוגמה של Cymbal Bank.

מומלץ להשלים את סדרת המדריכים הזו של Cymbal Bank לפי הסדר. במהלך ההתקדמות בסדרת המדריכים, תרכשו מיומנויות חדשות ותשתמשו ב Google Cloud מוצרים ובשירותים נוספים.

כדי להשתמש ב-סנכרון תצורות לפריסת מניפסטים של Kubernetes ממאגר Git לאשכולות, צריך להפעיל את ממשקי ה-API הבאים:

gcloud services enable configdelivery.googleapis.com cloudbuild.googleapis.com developerconnect.googleapis.com

יצירת מאגר Git וחיבור שלו ל-Cloud Build

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

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

כדי להדגים איך לאחסן ולבצע שינויים ב-Git, יוצרים Fork למאגר Cymbal Bank ומקשרים אותו ל-Cloud Build.

חיבור מאגר Cymbal Bank

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

כדי ליצור Fork של המאגר:

ב-GitHub, עוברים אל מאגר הדוגמאות Cymbal Bank (bank-of-anthos).
לוחצים על Fork כדי לקבל עותק של המאגר עם קובצי המקור.
אם צריך, נכנסים לחשבון GitHub. אם יש לכם גישה לארגונים או לצוותים אחרים ב-GitHub, ודאו שאתם יוצרים עותק של המאגר בחשבון לשימוש אישי שלכם.

עכשיו יש לכם עותק מסועף של מאגר Cymbal Bank. כל מניפסטים של Kubernetes שאתם פורסים נמצאים בתיקייה /kubernetes-manifests.

חיבור המאגר ל-Cloud Build

‫Cloud Build הוא שירות שיכול להריץ גרסאות build ב- Google Cloud, ואפשר להשתמש בו לפיתוח רציף (continuous delivery) בסגנון GitOps. שירות חבילות הצי של Config Sync משתמש ב-Cloud Build כדי לאחזר את משאבי Kubernetes ממאגר ה-Git שלכם ולפרוס אותם באשכולות. כשמשתמשים בחבילת Fleet, צריך להגדיר את Cloud Build רק פעם אחת לכל מאגר שרוצים לסנכרן. ממשק ה-API של חבילת הצי יוצר באופן אוטומטי את הטריגרים של גרסת ה-build באמצעות Cloud Build.

כדי לחבר את המאגר שלכם ב-GitHub ל-Cloud Build:

פותחים את הדף Cloud Build במסוף Google Cloud ולוחצים על Repositories.

פתיחת הדף Repositories
מוודאים שאתם נמצאים בדף מאגרים מהדור השני. אם צריך, לוחצים על View repositories (דור שני).
לוחצים על יצירת קישור למארח.
בתפריט Region, בוחרים באפשרות us-central1 (Iowa) כאזור.

זהירות: אפשר לבחור רק את us-central1 (איווה) כאזור. החיבור ל-Cloud Build וחבילת הצי צריכים להיות באותו אזור. חבילות כלל המכשירים בארגון (גרסת Preview) תומכות רק ב-us-central1.
בשדה שם, מקלידים cymbal-bank-connection כשם החיבור.
לוחצים על Connect.
אם זו הפעם הראשונה שאתם מחברים את Cloud Build לחשבון GitHub שלכם, מבצעים את השלבים הבאים:
1. מאשרים את הבקשה לטוקן OAuth של GitHub. האסימון מאוחסן ב-Secret Manager לשימוש בחיבור GitHub של Cloud Build. לוחצים על Continue.
2. מתקינים את Cloud Build במאגר שלכם ב-GitHub. בוחרים באפשרות התקנה בחשבון חדש.
3. בחלון החדש של GitHub שנפתח, בוחרים את החשבון ב-GitHub שבו יצרתם את הפיצול של Cymbal Bank קודם לכן. בסביבת ייצור, אפשר לבחור חשבונות או מאגרי מידע אחרים שיש לכם גישה שהוענקה אליהם.
4. פועלים לפי ההנחיות לאימות כדי לאשר את הזהות שלכם ב-GitHub.
5. בחלון GitHub לגישה למאגר Cloud Build, בוחרים באפשרות Only select repositories.
6. בתפריט הנפתח שבו מופיעים המאגרים, בוחרים את ה-fork של bank-of-anthos.
7. לוחצים על Save.
בדף Cloud Build במסוף Google Cloud , לוחצים על Link repository כדי לקשר מאגר Git חדש ל-Cloud Build.
בתפריט Connection (חיבור), בוחרים באפשרות cymbal-bank-connection.
בתפריט Repositories, בוחרים את ה-fork של bank-of-anthos.
לוחצים על קישור.

יצירת אשכולות

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

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

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

יוצרים אשכול GKE שמדמה סביבת פיתוח:
```
gcloud container clusters create-auto scalable-apps-dev \
  --project=PROJECT_ID \
  --region=REGION \
  --fleet-project=PROJECT_ID \
  --release-channel=rapid
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫PROJECT_ID עם המזהה שנוצר אוטומטית של הפרויקט שיצרתם בקטע הקודם. מזהה הפרויקט שונה בדרך כלל משם הפרויקט. לדוגמה, שם הפרויקט יכול להיות scalable-apps, אבל מזהה הפרויקט יכול להיות scalable-apps-567123.
- ‫REGION באזור שבו רוצים ליצור את האשכול, כמו us-central1.
תוויות הן צמדי מפתח/ערך שאפשר להוסיף למשאבי GKE כדי לעזור בארגון שלהם. במקרה של חבילות צי, אפשר להשתמש בתוויות של חברות בצי כדי להתאים אישית את האשכולות שהחבילה מטרגטת. אין תמיכה בסוגים אחרים של תוויות.

מוסיפים תווית לחברות בצי:
```
gcloud container fleet memberships update scalable-apps-dev \
    --update-labels=env=dev
```
כשיוצרים את חבילת הצי בהמשך המדריך הזה, התווית הזו מבטיחה שהמשאבים יופעלו רק באשכול scalable-apps-dev ולא באשכול scalable-apps מהמדריך הראשון בסדרה הזו.

התקנת סנכרון תצורות

מתקינים את סנכרון תצורות בשני האשכולות:

נכנסים לדף Config במסוף Google Cloud , בקטע Features.

מעבר אל Config

לוחצים על Install Config Sync (התקנת סנכרון תצורות).
משאירים את האפשרות שדרוגים ידניים מסומנת.
תפריט הגרסאות צריך להיות מוגדר כברירת מחדל לגרסה העדכנית של סנכרון תצורות. אם צריך, בוחרים את הגרסה העדכנית ביותר.
בקטע Installation options (אפשרויות התקנה), בוחרים באפשרות Install Config Sync on entire fleet (recommended) (התקנת סנכרון תצורות בכל הצי (מומלץ)).
לוחצים על Install Config Sync (התקנת סנכרון תצורות).
בכרטיסייה Settings של סנכרון תצורות, בודקים את השדה Status ברשימת האשכולות. אחרי כמה דקות, הסטטוס יהיה 'בהמתנה' עד שהאשכול יוגדר בצורה נכונה ל-סנכרון תצורות. יכולות לעבור עד 10 דקות עד שהסטטוס ישתנה למופעל.

פריסת Cymbal Bank

במדריך הראשון בסדרה הזו השתמשתם בפקודות kubectl כדי להחיל את הגדרות האפליקציה על האשכול. במדריך הזה נשתמש בתכונה fleet packages של Config Sync כדי לפרוס את אותן הגדרות לאשכול חדש. בהמשך המאמר מופיעה דוגמה להוספת משאב חדש למאגר Git ולפריסת המשאבים האלה בצי של אשכולות.

הגדרה של חשבון שירות ל-Cloud Build

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

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

יוצרים את חשבון השירות:

gcloud iam service-accounts create "cymbal-bank-service-account"

כדי לתת לחשבון השירות הרשאה לאחזר משאבים ממאגר Git, מוסיפים קישור למדיניות IAM לתפקיד Resource Bundle Publisher:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --member="serviceAccount:cymbal-bank-service-account@PROJECT_ID.iam.gserviceaccount.com" \
   --role='roles/configdelivery.resourceBundlePublisher'
```
אם מוצגת בקשה לעשות זאת, בוחרים באפשרות None בתור התנאי למדיניות.
כדי לתת לחשבון השירות הרשאה לכתוב יומנים, מוסיפים קישור למדיניות IAM לתפקיד Logs Writer:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
   --member="serviceAccount:cymbal-bank-service-account@PROJECT_ID.iam.gserviceaccount.com" \
   --role='roles/logging.logWriter'
```
אם מוצגת בקשה לעשות זאת, בוחרים באפשרות None בתור התנאי למדיניות.

יצירת גרסה לאפליקציית Cymbal Bank

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

בחלון של דפדפן האינטרנט של ה-fork של Cymbal Bank ב-GitHub, בקטע Releases בסרגל הצד, לוחצים על Create a new release.
בוחרים בתפריט בחירת תג ומקלידים v1.0.0 בתור התג. לוחצים על יצירת תג חדש.
לוחצים על פרסום הגרסה.

מגדירים אימות

בדומה למדריך הראשון בסדרה הזו, צריך ליצור JWT כדי לטפל באימות משתמשים ו-Kubernetes Secret כדי לאחסן את ה-JWT עבור האשכול החדש שיצרתם. מומלץ שלכל אשכול יהיה JWT ייחודי לאימות.

ב-Cloud Shell, יוצרים את ה-JWT:

openssl genrsa -out jwtRS256.key 4096
openssl rsa -in jwtRS256.key -outform PEM -pubout -out jwtRS256.key.pub

יוצרים את הסוד של Kubernetes:

kubectl create secret generic jwt-key --from-file=./jwtRS256.key --from-file=./jwtRS256.key.pub

פריסת אפליקציית Cymbal Bank באמצעות חבילת צי

FleetPackage הוא API הצהרתי לפריסה של כמה מניפסטים של Kubernetes בצי של אשכולות.

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

ב-Cloud Shell, מגדירים את מיקום ברירת המחדל לפקודות configdelivery של Google Cloud CLI. בדומה לחיבור המאגר ל-Cloud Build, צריך להשתמש ב-us-central1 בזמן שהתכונה 'חבילות צי' נמצאת בגרסת טרום-השקה (Preview):
```
gcloud config set config_delivery/location us-central1
```
יוצרים קובץ בשם fleetpackage-spec.yaml עם התוכן הבא:
```
resourceBundleSelector:
  cloudBuildRepository:
    name: projects/PROJECT_ID/locations/us-central1/connections/cymbal-bank-connection/repositories/REPOSITORY_NAME
    tag: v1.0.0
    serviceAccount: projects/PROJECT_ID/serviceAccounts/cymbal-bank-service-account@PROJECT_ID.iam.gserviceaccount.com
    variantsPattern: kubernetes-manifests
target:
  fleet:
    project: projects/PROJECT_ID
    selector:
      matchLabels:
        env: dev
rolloutStrategy:
  rolling:
    maxConcurrent: 1
variantSelector:
  variantNameTemplate: kubernetes-manifests
```
מחליפים את REPOSITORY_NAME בשם המאגר, כפי שהוא מופיע בחיבור Cloud Build.

שדות הבחירה תואמים לתווית החברות בצי שיצרתם קודם. כך אפשר לוודא שהאפליקציה Cymbal Bank נפרסת רק באשכול scalable-apps-dev. אוסף השרתים scalable-apps מההדרכה הראשונה לא מושפע. בקטע הבא מוצגת דוגמה לחבילת fleet שמיועדת לכל האשכולות ב-fleet.

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

יוצרים את חבילת הצי:

gcloud container fleet packages create cymbal-bank-fleet-package \
    --source=fleetpackage-spec.yaml \
    --project=PROJECT_ID

מוודאים שחבילת Fleet נוצרה:
```
gcloud container fleet packages list
```
בפלט מופיע הסטטוס של טריגר לפיתוח גרסת Build. אחרי כמה שניות, השדה MESSAGE מתעדכן עם פלט שדומה לזה:
```
MESSAGES: Build status: WORKING. The release is still being built; see the build status on the following page:
```
אפשר ללחוץ על הקישור שמופיע כדי לראות את יומני הסטרימינג של משימת Cloud Build. יכול להיות שיחלפו כמה דקות עד ש-Cloud Build יעבד את טריגר לפיתוח גרסת Build.
כשטריגר לפיתוח גרסת Build מסתיים בהצלחה, הפלט של gcloud container fleet packages list דומה לזה:
```
NAME: cymbal-bank-fleet-package
STATE: ACTIVE
CREATE_TIME: 2024-07-09T15:15:56
ACTIVE_ROLLOUT: rollout-20240709-153621
LAST_COMPLETED_ROLLOUT:
MESSAGES:
```
חבילת הצי מתחילה להפיץ את משאבי Kubernetes בצי.
בדף Google Kubernetes Engine במסוף Google Cloud , בוחרים את אשכול scalable-apps-dev ועוברים לדף Workloads כדי לראות תצוגה מצטברת של עומסי העבודה שנפרסים בכל אשכולות GKE:

פתיחת הדף Workloads

יכול להיות שיוצגו לכם שגיאות בזמן שהטייס האוטומטי משנה את ה-Pods כדי לעמוד בדרישות המשאבים. אחרי כמה דקות, הפודים אמורים להתחיל לפעול עם הסטטוס OK.
כדי לראות את ממשק האינטרנט של Cymbal Bank, פועלים לפי השלבים הבאים:
1. בדף Google Kubernetes Engine במסוף Google Cloud , עוברים לדף Gateways, Services & Ingress.
  
  כניסה לדף Gateways, Services & Ingress
2. כדי למצוא את הכניסה ל-Cymbal Bank, לוחצים על הכרטיסייה 'שירותים' ומחפשים את השירות עם השם frontend.
3. לוחצים על הקישור Endpoint של ה-Ingress frontend, כמו 198.51.100.143:80, כדי לפתוח את ממשק האינטרנט של Cymbal Bank.

פריסת משאבים בכל המכשירים

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

הוספת משאבים חדשים למאגר Git

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

בחלון של דפדפן אינטרנט עם ה-fork של Cymbal Bank ב-GitHub, לוחצים על Add file ואז על Create new file.

נותנים לקובץ את השם new-resource/nginx.yaml ומדביקים בו את התוכן הבא:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx:1.14.2
        name: nginx
        ports:
        - containerPort: 80

לוחצים על Commit changes... (ביצוע השינויים).
בתיבת הדו-שיח לאישור, משאירים את האפשרות Commit directly to the main branch (ביצוע קומיט ישירות לענף main) מסומנת ולוחצים על Commit changes (ביצוע קומיט של השינויים).

הערה: בתרחיש אמיתי, סביר להניח שתיצרו במקום זאת בקשת משיכה חדשה כדי שהשינוי שלכם ייבדק ויאושר.
בדף הראשי של מאגר Cymbal Bank המחובר, בוחרים באפשרות Releases (גרסאות) בסרגל הצד.
בראש הדף, בוחרים באפשרות יצירת טיוטה של גרסה חדשה.
בוחרים בתפריט בחירת תג ומקלידים v1.1.0 בתור התג. לוחצים על יצירת תג חדש.
לוחצים על פרסום הגרסה.

פריסת משאב באשכולות באמצעות חבילת Fleet

כדי לפרוס את המשאב החדש, יוצרים חבילת צי חדשה:

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

ב-Cloud Shell, יוצרים קובץ בשם new-deployment-fleet-package.yaml עם התוכן הבא:

resourceBundleSelector:
  cloudBuildRepository:
    name: projects/PROJECT_ID/locations/us-central1/connections/cymbal-bank-connection/repositories/REPOSITORY_NAME
    tag: v1.1.0
    serviceAccount: projects/PROJECT_ID/serviceAccounts/cymbal-bank-service-account@PROJECT_ID.iam.gserviceaccount.com
    variantsPattern: kubernetes-manifests/new-resource
target:
  fleet:
    project: projects/PROJECT_ID
rolloutStrategy:
  rolling:
    maxConcurrent: 1
variantSelector:
  variantNameTemplate: new-resource

כדי להתחיל את ההשקה, יוצרים את חבילת ההפצה:

gcloud container fleet packages create new-deployment-fleet-package \
    --source=new-deployment-fleet-package.yaml \
    --project=PROJECT_ID

מוודאים שחבילת Fleet נוצרה:
```
gcloud container fleet packages list
```
אפשר ללחוץ על הקישור שמופיע כדי לראות את יומני הסטרימינג של משימת Cloud Build.

חבילת ה-Fleet מתחילה להפיץ את משאבי Kubernetes ב-Fleet. יכול להיות שיחלפו כמה דקות עד שההשקה תתחיל ותסתיים.
בדף Google Kubernetes Engine במסוף Google Cloud , עוברים לדף Workloads כדי לראות תצוגה מצטברת של עומסי העבודה שנפרסים בכל אשכולות GKE:

פתיחת הדף Workloads

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

מחיקת משאבים בכל הצי

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

כדי להסיר משאבים ספציפיים, פועלים לפי השלבים הבאים:

מוחקים את המשאב ממאגר ה-Git.
יוצרים גרסה חדשה ב-Git ויוצרים תג חדש.
מעדכנים את השדה של חבילת הצי tag.
מריצים את הפקודה לעדכון חבילות בצי.

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

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

gcloud container fleet packages delete new-deployment-fleet-package --force

הסרת המשאבים

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

זהירות: כשמוחקים פרויקט:

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

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

In the Google Cloud console, go to the Manage resources page.
Go to Manage resources
In the project list, select the project that you want to delete, and then click Delete.
In the dialog, type the project ID, and then click Shut down to delete the project.

כדי למחוק את המאגר המפוצל:

בחלון דפדפן האינטרנט של המאגר המפוצל של Cymbal Bank ב-GitHub, מתחת לשם המאגר, לוחצים על Settings.
בדף ההגדרות הכלליות (שנבחר כברירת מחדל), עוברים לקטע Danger Zone (אזור מסוכן) ולוחצים על Delete this repository (מחיקת המאגר הזה).
לוחצים על I want to delete this repository (אני רוצה למחוק את המאגר הזה).
קוראים את האזהרות ולוחצים על קראתי והבנתי את ההשפעות האלה.
כדי לוודא שאתם מוחקים את המאגר הנכון, בשדה הטקסט, מקלידים את השם של מאגר Cymbal Bank המפוצל.
לוחצים על Delete this repository (מחיקת המאגר הזה).

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

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