שימוש בשרשרת הכלים של 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 don't repeat yourself (DRY)‎, שמשמש לתבניות של Config Connector שאתם פורסים בפרויקטים בארגון Google Cloud .
• מאגר אחד או יותר ב-GitHub, שספציפיים לפרויקט או לסביבה ומכילים קובצי תצורה שעברו הידרציה. המאגרים האלה עם נתונים מלאים מיועדים לסביבות שמנוהלות על ידי סנכרון תצורות. הם משתמשים ב-Config Connector כדי להפעיל ולנהל משאבים Google Cloud בארגון Google Cloud .
• אשכול GKE שמשתמש בסנכרון תצורות לבקרת גרסאות ולזיהוי סטיות. גם Config Connector מותקן באשכול הזה. ‫Config Connector מאפשר לאשכול לנהל משאבים ב Google Cloudהארגון Google Cloud .
• טריגר לפיתוח גרסת Build של Cloud Build שמפעיל build כשדוחפים תבנית למאגר GitHub DRY.
• טריגר מתוזמן של Cloud Build שמפעיל גרסת build באופן תקופתי. משימת ה-build משתמשת בפונקציית kpt. הפונקציה מפעילה את ממשקי ה-Recommender API של Active Assist כדי לאחזר המלצות פעילות. הוא בודק ומנתח המלצות כדי לקבוע אם צריך לשנות את הגודל של משאביGoogle Cloud שמנוהלים על ידי Config Connector או לבצע בהם אופטימיזציה. פונקציית kpt יוצרת בעיה ב-GitHub במאגר DRY עם פרטים על השינוי המומלץ, אם יש צורך לשנות את הגודל של משאבים שמנוהלים על ידי Config Connector Google Cloud או לבצע אופטימיזציה שלהם.

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

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

מטרות

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

עלויות

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

• Cloud Build
• Cloud Run
• Firestore
• Pub/Sub
• Container Registry
• Cloud Scheduler
• Google Kubernetes Engine (GKE) Enterprise edition

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

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

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

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

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

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

2. בוחרים או יוצרים Google Cloud פרויקט.

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

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
   הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שקשורים אליו.
3. רושמים בצד את מזהה הפרויקט ב- Google Cloud . תשתמשו במזהה הזה בקטע הבא כשתגדירו את הסביבה. במדריך הזה, הפרויקט הזה נקרא פרויקט build.

4. מפעילים את ממשקי ה-API של Cloud Build,‏ Firestore,‏ App Engine,‏ Pub/Sub,‏ Cloud Run,‏ Cloud Scheduler ו-Cloud Source Repositories, אם חלק מהם עדיין לא מופעלים.

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, צריך את ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין בממשק 'שימוש בשירות'' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

   הפעלת ממשקי ה-API

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

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

הגדרת הסביבה

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

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

   הפעלת Cloud Shell

2. מגדירים משתנים למזהה הפרויקט ולמספר הפרויקט של פרויקט 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 במזהה הפרויקט שציינתם בקטע הקודם.

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

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

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

   git clone https://github.com/GoogleCloudPlatform/activeassist-anthos-toolchain.git
   

5. עוברים לספריית הפרויקט:

   cd activeassist-anthos-toolchain
   

פיתוח הפייפליין

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

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

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

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

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

1. יוצרים מאגר פרטי ב-GitHub למאגר DRY. חשוב לרשום את השם שנתתם למאגר.

2. ב-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.

3. צריך ליצור אסימון גישה אישי (PAT) כדי ליצור בעיות במאגר הזה. הצינור יוצר בעיות ב-GitHub אם יש המלצות של Active Assist שצריך לבדוק. מידע נוסף על יצירת אסימוני PAT ב-GitHub זמין במאמרי העזרה של GitHub.

   כשמגדירים היקף לאסימון הזה, בוחרים באפשרות Full control of private repositories.

4. ב-Cloud Shell, יוצרים משתנה סביבה עבור ה-PAT שיצרתם:

   export GITHUB_TOKEN=YOUR_PERSONAL_ACCESS_TOKEN
   

   מחליפים את YOUR_PERSONAL_ACCESS_TOKEN באסימון משלכם.

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

1. יוצרים מאגר פרטי ב-GitHub עבור המאגר המלא. חשוב לרשום את השם שנתתם למאגר.

2. ב-Cloud Shell, מגדירים משתנה סביבה למאגר המידע שעבר הידרציה:

   export HYDRATED_REPO_NAME=YOUR_PRIVATE_HYDRATED_REPO
   export HYDRATED_REPO='[e-mail]:$REPO_OWNER/$HYDRATED_REPO_NAME.git'
   

   מחליפים את YOUR_PRIVATE_HYDRATED_REPO בשם המאגר המלא.

3. יוצרים זוג מפתחות לפריסה:

   ssh-keygen -t rsa -b 4096 \
   -C 'active-assist-robot' \
   -N '' \
   -f $(pwd)/active-assist-robot
   

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

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

   cat $(pwd)/active-assist-robot.pub
   

5. מוסיפים את מפתח הפריסה למאגר הפרטי ב-GitHub. כשמוסיפים את מפתח הפריסה, חשוב לבחור באפשרות Allow write access. כדי ללמוד איך להוסיף מפתחות פריסה למאגרי GitHub, אפשר לעיין במאמרי העזרה של GitHub בנושא ניהול מפתחות פריסה.

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

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

   gcloud secrets create github-ssh-key \
     --data-file=$(pwd)/active-assist-robot
   

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

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

יצירת אשכול GKE

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

1. ב-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
   

2. כדי ליצור זהות ולהגדיר את Config Connector, צריך לפעול לפי ההוראות שבקטעים הבאים במדריך Installing with the GKE add-on.

   1. יצירת זהות
   2. הגדרת Config Connector

3. מתקינים את סנכרון תצורות באשכול 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.

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

   כניסה לדף של אפליקציית Cloud Build

2. לוחצים על הגדרה באמצעות Google Cloud Build.

3. אם מתבקשים, נכנסים לחשבון GitHub.

4. לוחצים על Only select repositories.

   משתמשים בתפריט הנפתח Select repositories כדי להפעיל גישה למאגרי YOUR_PRIVATE_DRY_REPO ו-YOUR_PRIVATE_HYDRATED_REPO דרך אפליקציית Cloud Build.

5. לוחצים על התקנה.

6. נכנסים אל Google Cloud. בדף Authorization שמופיע, מאשרים לאפליקציית Google Cloud Build להתחבר אל Google Cloud.

7. לוחצים על Authorize Google Cloud Build by GoogleCloudBuild. תועברו אל מסוף Google Cloud .

8. בוחרים את הפרויקט Google Cloud .

9. מסמנים את תיבת הסימון של ההסכמה ולוחצים על הבא.

10. לוחצים על התקנה.

11. נכנסים אל Google Cloud. מוצג הדף הרשאה ומופיעה בקשה לאשר לאפליקציית Google Cloud Build להתחבר אל Google Cloud.

12. לוחצים על Authorize Google Cloud Build by GoogleCloudBuild (מתן הרשאה ל-Google Cloud Build על ידי GoogleCloudBuild). תועברו אל מסוף Google Cloud .

13. בוחרים את הפרויקט Google Cloud .

14. מסמנים את תיבת הסימון של ההסכמה ולוחצים על הבא.

15. בדף Select repository שמופיע, בוחרים את המאגרים הבאים ב-GitHub:

    • YOUR_PRIVATE_DRY_REPO
    • YOUR_PRIVATE_HYDRATED_REPO

16. לוחצים על Connect (חיבור) ואז על Done (סיום).

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

1. ב-Cloud Shell, מריצים את הפקודה הבאה:

   envsubst < cloudbuild.template.yaml > cloudbuild.yaml
   

   הפקודה יוצרת קובץ cloudbuild.yaml.

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

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

3. נותנים לחשבון השירות של 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

הערה: במדריך הזה משתמשים ב-stubs כדי לבדוק את צינור הנתונים. כשמשתמשים בצינור (pipeline) עבור פרויקטים של Google Cloud , חשוב לוודא שנותנים לחשבון השירות ב-Cloud Build את ההרשאות שהוא צריך כדי לאחזר המלצות מ-Active Assist.

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

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

בקטע הזה תיצרו קובץ אימג' של Cloud Build עם רכיבי kpt,‏ gh ו-Node.

1. ב-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 למאגר המידע המיובש

1. ב-Cloud Shell, יוצרים את קובץ התצורה שנדרש להגדרת טריגר לפיתוח גרסת Build מתוזמן של Cloud Build:

    envsubst < cloudbuild-scheduled-recommendations.template.yaml > cloudbuild-scheduled-recommendations.yaml
   

2. יוצרים את הטריגר לפיתוח גרסת 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
   

3. משיגים את המזהה של הטריגר הזה:

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

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

1. ב-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.

2. נותנים לחשבון השירות את ההרשאות להפעיל משימה ב-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
   

3. יוצרים משימה של 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.

ביצוע Commit ודחיפה של קובצי ההגדרות של 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.

1. ב-Cloud Shell, באשכול sample-ops, מוודאים שיש מרחב שמות בשם activeassist-kcc:

   kubectl get ns | grep activeassist-kcc
   

2. ‫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.

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

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

   כניסה לדף טריגרים לפיתוח גרסת Build

2. בוחרים את הטריגר ActiveAssistScheduledRecommendations.

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

   הטריגר יוצר 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 מראה שהסוג הנוכחי של מופע Compute Engine MACHINE_TYPE הוא סוג n1-standard-1. ההמלצה של Active Assist היא לשנות אותו לסוג g1-small.

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

הסרת המשאבים

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

זהירות: כשמוחקים פרויקט:
• התוכן של הפרויקט נמחק כולו. אם השתמשתם בפרויקט קיים כדי לתרגל את המשימות במדריך הזה, כשתמחקו אותו תימחק גם כל העבודה שביצעתם באותו פרויקט.
• מאבדים את מזהה הפרויקט בהתאמה אישית. כשיצרתם את הפרויקט, יכולתם לבחור לו מזהה פרויקט בהתאמה אישית כדי להשתמש בו בעתיד. כדי לשמור על כתובות ה-URL שמשתמשות במזהה הפרויקט, כמו appspot.com, צריך למחוק את המשאבים שנבחרו בפרויקט אבל לא את הפרויקט כולו.
1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

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

• Google Cloud מידע נוסף על טכנולוגיות ללא שרת (serverless)
• קראו על איך לשלב המלצות של כלים לבקרת מדיניות בצינור עיבוד נתונים של תשתית כקוד (IaC).