Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

שימוש בשרשרת הכלים של GKE Enterprise עם Active Assist

המסמך הזה הוא חלק מסדרה שדנה בדפוסי ארכיטקטורה שארגונים יכולים להשתמש בהם כדי לבצע אופטימיזציה של השימוש שלהם בענן בקנה מידה גדול באמצעות Active Assist. במדריך הזה נסביר איך ליצור צינור עיבוד נתונים לאוטומציה של המלצות ActiveAssist, שפועל עם ערכת הכלים של GKE Enterprise. המאמר מיועד לאנשים שמשתמשים ב-Config Sync כדי לנהל את סביבות GKE Enterprise שלהם וב-Config Connector כדי לנהל משאבים. Google Cloud החלקים האחרים בסדרה הם:

תבניות לשימוש ב-Active Assist בהיקף נרחב
שימוש בפייפליינים בלי שרת (serverless) עם Active Assist
שימוש בשרשרת הכלים של GKE Enterprise עם Active Assist (המסמך הזה)

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

הרחבת השימוש בחבילת Active Assist בארגון.
הפיכת Active Assist לחלק מצינור עיבוד הנתונים של אינטגרציה רציפה (CI) ופיתוח רציף (continuous delivery).
שליטה בבדיקה ובהפעלה של המלצות Active Assist באמצעות מבנים כמו בעיות ובקשות משיכה ב-GitHub.

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

ארכיטקטורה

בתרשים הארכיטקטורה הבא מוצגים הרכיבים שבהם משתמשים במדריך הזה.

רכיבים שמשמשים בארכיטקטורה.

הרכיבים משמשים בדרכים הבאות:

מאגר GitHub אל תחזור על עצמך (DRY), שמשמש לתבניות של Config Connector שאתם פורסים בפרויקטים בארגון Google Cloud שלכם.
מאגר אחד או יותר ב-GitHub שספציפיים לפרויקט או לסביבה ומכילים קובצי תצורה עם נתונים. המאגרים האלה עם נתונים מלאים מיועדים לסביבות שמנוהלות על ידי סנכרון תצורות. הם משתמשים ב-Config Connector כדי להפעיל ולנהל משאבים Google Cloud בארגון Google Cloud .
אשכול GKE שמשתמש בסנכרון תצורות לבקרת גרסאות ולזיהוי סטיות. בנוסף, מותקן ב-cluster הזה Config Connector. ‫Config Connector מאפשר לאשכול לנהל משאבים ב Google Cloudבארגון Google Cloud .
טריגר לפיתוח גרסת Build של Cloud Build שמפעיל build כשדוחפים תבנית למאגר ה-DRY ב-GitHub.
טריגר מתוזמן של Cloud Build שמפעיל build באופן תקופתי. עבודת ה-build משתמשת בפונקציית kpt. הפונקציה מפעילה את ממשקי ה-API של שירות ההמלצות של Active Assist כדי לאחזר המלצות פעילות. הוא בודק ומנתח את ההמלצות כדי לקבוע אם צריך לשנות את הגודל שלGoogle Cloud המשאבים שמנוהלים על ידי Config Connector או לבצע בהם אופטימיזציה. הפונקציה kpt יוצרת בעיה ב-GitHub במאגר DRY עם פרטים על השינוי המומלץ, אם יש צורך לשנות את הגודל של משאבים שמנוהלים על ידי Config Connector או לבצע אופטימיזציה שלהם. Google Cloud

תהליך העבודה של הארכיטקטורה הזו הוא כדלקמן:

צוותים מורשים עם גישה למאגר DRY יוצרים ומנהלים תבניות של Config Connector במאגר.
משימה ב-Cloud Build מופעלת כשיוצרים או משנים תבנית ומבצעים צ'ק-אין לענף main.
משימת Cloud Build מאכלסת את התבניות על ידי הפעלת פונקציות setter של kpt. המשימה מעבירה את קובצי התצורה עם הנתונים למאגר GitHub עם הנתונים. ‫Secret Manager משמש לאחסון מפתחות פריסה של GitHub למאגר הפרטי.
‫סנכרון תצורות עוקב אחרי שינויים במאגר המידע המלא ומחיל עדכונים שנמצאים במאגר על האשכול המנוהל.
‫Config Connector עוקב אחרי שינויים ומפעיל משאבים אם צריך ליצור או לעדכן משאבים כתוצאה משינויים ב-Kubernetes Resource Model ‏ (KRM) שהוחלו על ידי סנכרון תצורות. Google Cloud
טריגר מתוזמן של Cloud Build פועל באופן תקופתי כדי להפעיל את Recommender API ולאחזר המלצות פעילות לפרויקטים שמנוהלים על ידי Config Connector.
המשימה המתוזמנת של Cloud Build מפעילה פונקציית kpt בהתאמה אישית כדי להפעיל את Recommender API, לאחזר ולנתח המלצות פעילות.
הפונקציה kpt יוצרת בעיה ב-GitHub שמציגה השוואה בין הגדרת המשאב הנוכחית לבין ההגדרה המומלצת למשאב. בגישה הזו, בעיות ב-GitHub נוצרות במאגר DRY, וכך קל יותר לעקוב אחרי שינויים במאגר.

מטרות

יוצרים את מאגרי GitHub לדוגמה הבאים:
- מאגר DRY ל-KRM של Config Connector.
- מאגר שיכיל קובצי תצורה שעברו הידרציה ונוצרו באמצעות פקודות setter של kpt.
יוצרים אשכול GKE עם סנכרון תצורות ו-Config Connector.
יוצרים פונקציית kpt לדוגמה כדי לאחזר המלצות של Active Assist לפרויקטים שמנוהלים על ידי Config Connector.
יוצרים טריגר לפיתוח גרסת Build של Cloud Build שמופעל כשמעבירים תבנית בדחיפה לענף main של מאגר ה-DRY.
יוצרים משימה מתוזמנת של Cloud Build שמופעלת מעת לעת כדי לאחזר המלצות זמינות של Active Assist למשאבים שמנוהלים על ידי Config Connector.
כדי לבדוק את צינור הנתונים מקצה לקצה, אפשר להשתמש בהמלצות ה-stub שמופיעות במאגר GitHub של המדריך הזה.

עלויות

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

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

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

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

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

נכנסים לדף לבחירת הפרויקט במסוף Google Cloud .

כניסה לדף לבחירת הפרויקט
בוחרים או יוצרים Google Cloud פרויקט.
תפקידים שנדרשים כדי לבחור או ליצור פרויקט
- Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
- יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.
רושמים בצד את Google Cloud מזהה הפרויקט. משתמשים במזהה הזה בקטע הבא כשמגדירים את הסביבה. במהלך ההדרכה הזו, הפרויקט הזה נקרא פרויקט build.
מפעילים את ממשקי ה-API של Cloud Build,‏ Firestore,‏ App Engine,‏ Pub/Sub,‏ Cloud Run,‏ Cloud Scheduler ו-Cloud Source Repositories.
תפקידים שנדרשים להפעלת ממשקי API
כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים
הפעלת ממשקי ה-API
במדריך הזה משתמשים בפרטי הכניסה של האפליקציה שמוגדרים כברירת מחדל. אם מוצגת בקשה ליצור פרטי כניסה בדף הוספת פרטי כניסה לפרויקט, לוחצים על ביטול.
מוודאים שהחיוב מופעל בפרויקט Google Cloud .

הגדרת הסביבה

במדריך הזה, מריצים את כל הפקודות ב-Cloud Shell.

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

הפעלת Cloud Shell
מגדירים משתנים למזהה הפרויקט ולמספר הפרויקט של פרויקט build Google Cloud הנוכחי:
```
export RECO_MGR_PROJECT=PROJECT_ID
gcloud config set project $RECO_MGR_PROJECT
export RECO_MGR_PROJECT_NUMBER=$(gcloud projects describe $RECO_MGR_PROJECT --format='value(projectNumber)')
```
מחליפים את PROJECT_ID במזהה הפרויקט שרשמתם בקטע הקודם.

מגדירים משתנים לאזור הפריסה:

export REGION=us-central1
export ZONE=us-central1-a

משכפלים את המאגר שמכיל את הקוד של האפליקציה לדוגמה שבה נעשה שימוש במדריך הזה:
```
git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
```
עוברים לספריית הפרויקט:
```
cd activeassist-anthos-toolchain
```

יצירת צינור עיבוד הנתונים

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

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

הגדרת מאגרי GitHub פרטיים לדוגמה

בקטעים הבאים מוגדרים מאגרי GitHub לדוגמה לצורך המדריך הזה.

הגדרת מאגר פרטי ב-GitHub לפי העיקרון DRY

יוצרים מאגר פרטי ב-GitHub למאגר DRY. חשוב לרשום את השם שנתתם למאגר.
ב-Cloud Shell, יוצרים משתנה סביבה לשם המשתמש שלכם ב-GitHub ולשם מאגר ה-DRY:
```
export REPO_OWNER=YOUR_GITHUB_USERNAME
export DRY_REPO_NAME=YOUR_PRIVATE_DRY_REPO
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫YOUR_GITHUB_USERNAME: שם המשתמש שלכם ב-GitHub.
- ‫YOUR_PRIVATE_DRY_REPO: השם של מאגר ה-DRY.
צריך ליצור אסימון גישה אישי (PAT) כדי ליצור בעיות במאגר הזה. הצינור יוצר בעיות ב-GitHub אם יש המלצות של Active Assist שצריך לבדוק. מידע נוסף על יצירת PAT ב-GitHub זמין במאמרי העזרה של GitHub.

כשמגדירים היקף לאסימון הזה, בוחרים באפשרות Full control of private repositories (שליטה מלאה במאגרי מידע פרטיים).
ב-Cloud Shell, יוצרים משתנה סביבה עבור ה-PAT שיצרתם:
```
export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
```
מחליפים את YOUR_PERSONAL_ACCESS_TOKEN באסימון שלכם.

הגדרת מאגר פרטי ב-GitHub עם נתונים

יוצרים מאגר פרטי ב-GitHub עבור המאגר המלא. חשוב לרשום את השם שנותנים למאגר.
ב-Cloud Shell, מגדירים משתנה סביבה למאגר המידע שעבר הידרציה:
```
export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
export HYDRATED_REPO='git@github.com:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
```
מחליפים את YOUR_PRIVATE_HYDRATED_REPO בשם המאגר המלא.
יוצרים זוג מפתחות לפריסה:
```
ssh-keygen -t rsa -b 4096 \
-C 'active-assist-robot' \
-N '' \
-f $(pwd)/active-assist-robot
```
מפתח פריסה מאפשר לכם לפרוס למאגר GitHub פרטי כשאתם מריצים משימת Cloud Build כדי להוסיף נתונים לקובצי הגדרות.
מדפיסים את המפתח שנוצר:
```
cat $(pwd)/active-assist-robot.pub
```
מוסיפים את מפתח הפריסה למאגר הפרטי ב-GitHub. כשמוסיפים את מפתח הפריסה, חשוב לסמן את האפשרות Allow write access (מתן הרשאת כתיבה). כדי ללמוד איך להוסיף מפתחות פריסה למאגרי GitHub, אפשר לעיין במאמרי העזרה של GitHub בנושא ניהול מפתחות פריסה.

העלאת מפתחות GitHub ל-Secret Manager

ב-Cloud Shell, יוצרים סוד לאחסון המפתח הפרטי מזוג מפתחות הפריסה:
```
gcloud secrets create github-ssh-key \
  --data-file=$(pwd)/active-assist-robot
```

יוצרים סוד לאחסון ה-PAT:

echo $GITHUB_TOKEN | gcloud secrets create github-pat --data-file=-

יצירת אשכול GKE

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

ב-Cloud Shell, יוצרים אשכול GKE חדש עם התוסף Config Connector מופעל:

gcloud container clusters create sample-ops \
  --machine-type n1-standard-4 \
  --zone $ZONE \
  --release-channel regular \
  --addons ConfigConnector \
  --workload-pool=$RECO_MGR_PROJECT.svc.id.goog \
  --enable-stackdriver-kubernetes \
  --enable-ip-alias

כדי ליצור זהות ולהגדיר את Config Connector, צריך לפעול לפי ההוראות שבקטעים הבאים במדריך Installing with the GKE add-on.
1. יצירת זהות
2. הגדרת Config Connector
מתקינים את סנכרון תצורות באשכול GKE שיצרתם. כשמגדירים את סנכרון תצורות, צריך לבצע את הפעולות הבאות:
1. משתמשים בטוקן כדי להעניק לסנכרון תצורות גישת קריאה בלבד ל-Git. משתמשים בטוקן GitHub שיצרתם כשאתם מגדירים מאגר GitHub פרטי של DRY. הטוקן זמין דרך משתנה הסביבה $GITHUB_TOKEN.
2. הגדרת סנכרון תצורות באמצעות gcloud מגדירים את ההגדרות הבאות:
  1. sourceFormat: hierarchy
  2. syncRepo: https://github.com/YOUR_GITHUB_USERNAME/YOUR_PRIVATE_HYDRATED_REPO
  3. ‫syncBranch: main
  4. ‫secretType: token
  5. ‫policyDir: לא ממלאים את האפשרות הזו

יצירת טריגר לפיתוח גרסת Build של Cloud להעברה בדחיפה למאגר המידע המלא

בקטעים הבאים תיצרו טריגר לפיתוח גרסת Build של Cloud Build שמופעל כשמעלים תבניות לענף הראשי של מאגר YOUR_PRIVATE_DRY_REPO. הטריגר הזה מפעיל את השלבים שיוצרים את התבניות של config-as-data KRM במאגר YOUR_PRIVATE_DRY_REPO ומעביר את קובצי התצורה שנוצרו למאגר YOUR_PRIVATE_HYDRATED_REPO.

חיבור Cloud Build למאגרים שלכם ב-GitHub

בקטע הזה תחברו את מאגרי GitHub‏ YOUR_PRIVATE_DRY_REPO ו-YOUR_PRIVATE_HYDRATED_REPO ל-Cloud Build.

נכנסים לדף של אפליקציית Cloud Build ב-GitHub Marketplace.

כניסה לדף של אפליקציית Cloud Build
לוחצים על Setup with Google Cloud Build (הגדרה באמצעות Google Cloud Build).
אם מתבקשים, נכנסים לחשבון GitHub.
לוחצים על Only select repositories (רק מאגרים נבחרים).

משתמשים בתפריט הנפתח Select repositories כדי להפעיל גישה למאגרי YOUR_PRIVATE_DRY_REPO ו-YOUR_PRIVATE_HYDRATED_REPO דרך אפליקציית Cloud Build.
לוחצים על התקנה.
נכנסים אל Google Cloud. מוצג הדף הרשאה ומופיעה בקשה לאשר לאפליקציית Google Cloud Build להתחבר אל Google Cloud.
לוחצים על Authorize Google Cloud Build by GoogleCloudBuild (מתן הרשאה ל-Google Cloud Build על ידי GoogleCloudBuild). תופנו אל מסוף Google Cloud .
בוחרים את הפרויקט Google Cloud .
מסמנים את תיבת הסימון של ההסכמה ולוחצים על הבא.
לוחצים על התקנה.
נכנסים אל Google Cloud. מוצג הדף הרשאה ומופיעה בקשה לאשר לאפליקציית Google Cloud Build להתחבר אל Google Cloud.
לוחצים על Authorize Google Cloud Build by GoogleCloudBuild (מתן הרשאה ל-Google Cloud Build על ידי GoogleCloudBuild). תופנו אל מסוף Google Cloud .
בוחרים את הפרויקט Google Cloud .
מסמנים את תיבת הסימון של ההסכמה ולוחצים על הבא.
בדף Select repository שמופיע, בוחרים את המאגרים הבאים ב-GitHub:
- YOUR_PRIVATE_DRY_REPO
- YOUR_PRIVATE_HYDRATED_REPO
לוחצים על Connect (חיבור) ואז על Done (סיום).

יצירת טריגר לפיתוח גרסת Build של Cloud למאגר DRY

ב-Cloud Shell, מריצים את הפקודה הבאה:
```
envsubst < cloudbuild.template.yaml > cloudbuild.yaml
```
הפקודה יוצרת קובץ cloudbuild.yaml.

יוצרים את הטריגר:

gcloud beta builds triggers create github \
  --name ActiveAssistDemo \
  --repo-name=$DRY_REPO_NAME \
  --repo-owner=$REPO_OWNER \
  --branch-pattern="main" \
  --build-config=cloudbuild.yaml

נותנים לחשבון השירות ב-Cloud Build הרשאה לגשת ל-Secret Manager:

gcloud secrets add-iam-policy-binding github-ssh-key  \
  --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

gcloud secrets add-iam-policy-binding github-pat  \
  --member="serviceAccount:${RECO_MGR_PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \
  --role="roles/secretmanager.secretAccessor"

יצירת טריגר מתוזמן של Cloud Build להמלצות של Active Assist

בקטעים הבאים תיצרו טריגר מתוזמן של Cloud Build שפועל באופן מחזורי. הטריגר הזה מאחזר המלצות של Active Assist באמצעות פונקציית kpt, וקובע אם יש המלצות פעילות למשאבים במאגר YOUR_PRIVATE_HYDRATED_REPO. פונקציית kpt גם יוצרת בעיה ב-GitHub במאגר YOUR_PRIVATE_HYDRATED_REPO אם יש המלצות פעילות להגדרת משאבים שצריך לבדוק וליישם.

יצירת תמונה של Cloud Build

בקטע הזה תיצרו תמונת Cloud Build עם רכיבי kpt,‏ gh ו-Node.

ב-Cloud Shell, יוצרים קובץ אימג' של Docker ומעבירים אותו בדחיפה ל-Container Registry:

gcloud auth configure-docker

docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function

docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1

יצירת טריגר לפיתוח גרסת Build למאגר המידע המיובש

ב-Cloud Shell, יוצרים את קובץ התצורה שנדרש להגדרת טריגר לפיתוח גרסת Build מתוזמן של Cloud Build:
```
 envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
```

יוצרים את הטריגר לפיתוח גרסת Build ב-Cloud:

gcloud beta builds triggers create github \
  --name ActiveAssistScheduledRecommendations \
  --repo-name=YOUR_PRIVATE_HYDRATED_REPO \
  --repo-owner=$REPO_OWNER \
  --branch-pattern="main" \
  --build-config=cloudbuild-scheduled-recommendations.yaml

קבלת המזהה של הטריגר הזה:

export TRIGGER_ID=`gcloud beta builds triggers describe \
  ActiveAssistScheduledRecommendations \
  --format="value(id)"`

יצירת משימה של Cloud Scheduler להפעלת הטריגר

ב-Cloud Shell, יוצרים חשבון שירות:

gcloud iam service-accounts create build-invoker \
   --description "Service Account used by Cloud Scheduler to invoke the sample scheduled Cloud Build job" \
   --display-name "recommender-scheduler-sa" \
   --project $RECO_MGR_PROJECT

משימות של Cloud Scheduler משתמשות בחשבון השירות הזה כדי להריץ את השירות recommender-parser.

נותנים לחשבון השירות את ההרשאות להפעלת משימה ב-Cloud Build:

gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
  --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
  --role roles/cloudbuild.builds.editor \
  --project $RECO_MGR_PROJECT

 gcloud projects add-iam-policy-binding $RECO_MGR_PROJECT \
   --member serviceAccount:build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com \
   --role roles/serviceusage.serviceUsageConsumer \
   --project $RECO_MGR_PROJECT

יוצרים משימה של Cloud Scheduler כדי להפעיל את הטריגר שיצרתם בשלב הקודם:

gcloud scheduler jobs create http scheduled-build \
   --project $RECO_MGR_PROJECT \
   --time-zone "America/Los_Angeles" \
   --schedule="0 */3 * * *" \
   --uri="https://cloudbuild.googleapis.com/v1/projects/${RECO_MGR_PROJECT}/triggers/${TRIGGER_ID}:run" \
   --description="Scheduler job to invoke Cloud Build" \
   --oauth-service-account-email="build-invoker@$RECO_MGR_PROJECT.iam.gserviceaccount.com" \
   --headers="Content-Type=application/json" \
   --http-method="POST" \

בוחרים באפשרות Y אם רואים את ההודעה הבאה:

There is no App Engine app in the project.

אם מוצגת בקשה לבחור את האזור שבו רוצים למקם את אפליקציית App Engine, בוחרים באזור us-central.

ביצוע שמירה ודחיפה של קובצי תצורת ה-build של Cloud Build ל-GitHub

מעבירים בדחיפה את שני קובצי תצורת ה-build של Cloud שיצרתם אל מאגר YOUR_PRIVATE_DRY_REPO:

git remote add dry https://github.com/$REPO_OWNER/$DRY_REPO_NAME.git

git add cloudbuild.yaml
git add cloudbuild-scheduled-recommendations.yaml
git commit -m "Added cloudbuild configuration YAMLs"
git push dry main

יכול להיות שתתבקשו להזין את פרטי הכניסה שלכם ל-GitHub כשאתם שולחים אל המאגר הפרטי שלכם.

בדיקת התוצאה של משימת Cloud Build

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

ב-Cloud Shell, באשכול sample-ops, מוודאים שיש לכם מרחב שמות בשם activeassist-kcc:
```
kubectl get ns | grep activeassist-kcc
```
‫Config Connector פורס מכונה לדוגמה של Compute Engine שפועלת בPROJECT_IDפרויקט.

מוודאים שהמכונה ב-Compute Engine נמצאת בפרויקט:
```
 gcloud compute instances list | grep \
 computeinstance-sample-cloudmachine
```
סוג המכונה MACHINE_TYPE הוא n1-standard-1.

הרצת בדיקות מקצה לקצה

כדי לאפשר לכם לבדוק את צינור הנתונים מקצה לקצה, המאגר ששיבטתם עבור המדריך הזה מספק המלצות לדוגמה (stubs). משתמשים ב-stubs האלה כדי להריץ את צינור הנתונים מקצה לקצה. ה-stub מחקה מטען ייעודי (payload) של המלצה מ-Active Assist, והוא כולל המלצה לשנות את סוג המכונה של מכונת Compute Engine שנפרסה מסוג המכונה n1-standard-1 לסוג המכונה g1-small.

בקטע הזה מפעילים ידנית את טריגר לפיתוח גרסת Build המתוזמן של Cloud Build כדי להריץ את המשימה שמשתמשת בפונקציית kpt כדי לאחזר המלצות של Active Assist. כמו כן, תוכלו לוודא שנוצרה בעיה ב-GitHub במאגר YOUR_PRIVATE_DRY_REPO.

פותחים את הדף Build Triggers במסוף Google Cloud .

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

הטריגר יוצר issue ב-GitHub במאגר YOUR_PRIVATE_DRY_REPO. הבעיה דומה לבעיה הבאה:
```
gcloud auth configure-docker

docker build -t gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1 ./recommender-kpt-function

docker push gcr.io/$RECO_MGR_PROJECT/kpt-dev-gh:1
```
בדוגמה לבעיה, הפלט של הפונקציה kpt מראה שהסוג הנוכחי של MACHINE_TYPE במכונה של Compute Engine הוא סוג n1-standard-1. ההמלצה של Active Assist היא לשנות את הסוג לg1-small.

בודקי בקרת גרסאות בארגון יכולים לבדוק בעיות אוטומטיות ב-GitHub ולטפל בהן בהתאם לצורך בארגון.

הסרת המשאבים

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

במסוף Google Cloud , נכנסים לדף Manage resources.
כניסה לדף Manage resources
ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.