סקירה כללית של מדיניות הסוכנים עבור Ops Agent

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

מדיניות סוכנים עבור Ops Agent

יש תמיכה במדיניות של סוכנים עבור Ops Agent בשתי רמות של מהדורות: GA ובטא. שני סוגי המדיניות מסתמכים על התכונות של OS Config שמסופקות על ידי VM Manager, אבל ההטמעות שונות. מומלץ להשתמש במדיניות של GA כשאפשר. ברוב המקרים, אפשר להמיר מדיניות בגרסת בטא למדיניות בגרסה זמינה לכולם.

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

• שימוש במדיניות של סוכנים (GA)
• שימוש במדיניות סוכנים (בטא)

ההבדלים בין מדיניות של סוכנים בגרסת בטא לבין מדיניות של סוכנים בגרסה זמינה לכולם

יש הבדלים בין מדיניות הסוכנים בגרסת הבטא לבין מדיניות הסוכנים בגרסה הזמינה לכולם:

• מנגנוני יצירה

  • מדיניות סוכנים בגרסת בטא נוצרת באמצעות:
    • קבוצת הפקודות gcloud beta compute instances ops-agents policies ב-Google Cloud SDK.
    • agent-policy מודול Terraform
  • מדיניות של סוכני GA נוצרת באמצעות:
    • קבוצת הפקודות gcloud compute instances ops-agents policies ב-Google Cloud SDK.
    • ops-agent-policy מודול Terraform

• תמיכה בסוכן Monitoring מדור קודם ובסוכן Logging

  • מדיניות סוכנים בגרסת בטא יכולה לנהל את סוכן ה-Monitoring ואת סוכן ה-Logging מדור קודם, וגם את סוכן התפעול.
  • מדיניות של סוכן GA מנהלת רק את סוכן תפעול.

• שדרוג אוטומטי של גרסת הסוכן

  • מדיניות של סוכני בטא יכולה לשמור את הסוכן בגרסה האחרונה על ידי שדרוג הסוכן.
  • מדיניות של סוכני GA לא תומכת בפעולת שדרוג אוטומטי. לגישות חלופיות, אפשר לעיין במאמר החלפת מדיניות שדרוג של סוכן בגרסת בטא.

• החלת מדיניות על מכונות Compute Engine עם שמות

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

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

  • מדיניות של סוכני בטא חלה באופן גלובלי על כל המקרים שנבחרו לפי קריטריוני המדיניות ב Google Cloud פרויקט.
  • מדיניות הסוכן של GA חלה על כל המקרים שנבחרו לפי קריטריוני המדיניות באזור שצוין במדיניות. לדוגמה, למדיניות שנוצרה באזור us-central1-a אין השפעה על מכונות וירטואליות באזורים אחרים.

יש גם הבדלים מבניים בין מדיניות הבטא לבין מדיניות הזמינות הכללית:

• כללי מדיניות שנוצרו באמצעות gcloud beta compute instances ops-agents policies מתארים כללי מדיניות של סוכנים על ידי העברת אפשרויות נפרדות לפקודות, לדוגמה:

  gcloud beta compute instances ops-agents policies create ops-agents-test-policy \
    --agent-rules="type=logging,enable-autoupgrade=false;type=metrics,enable-autoupgrade=false" \
    --description="A test policy." \
    --os-types=short-name=centos,version=7 \
    --instances=zones/us-central1-a/instances/test-instance \
    --project PROJECT_ID
  

  מודול Terraform של מדיניות הסוכן מספק את אותן היכולות.

• מדיניות שנוצרת באמצעות gcloud compute instances ops-agents policies מתארת מדיניות של סוכן באמצעות קובץ הגדרות YAML ואזור, לדוגמה:

  gcloud compute instances ops-agents policies create test-policy \
    --zone us-central1-a \
    --file test-policy.yaml \
    --project PROJECT_ID
  

  מודול Terraform של ops-agent-policy מספק את אותן יכולות.

שימוש במדיניות של גרסת בטא ושל גרסה זמינה לכולם

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

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

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

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

המרת מדיניות בטא למדיניות GA

אתם יכולים להמיר את מדיניות סוכן התפעול של Ops Agent בגרסת בטא למדיניות סוכן בגרסת GA, בתנאי שאין הבדלים בין סוגי המדיניות שאי אפשר לעקוף. אי אפשר להמיר מדיניות של סוכני בטא עבור סוכן המעקב או סוכן Logging בגרסה הקודמת למדיניות של סוכנים בגרסה הזמינה לכולם.

כדי להמיר מדיניות של סוכני בטא למדיניות של זמינות כללית באמצעות Google Cloud SDK:

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

   gcloud beta compute instances ops-agents policies list --project PROJECT_ID
   

2. מזהים את מדיניות הסוכנים בגרסת הבטא שרוצים להמיר למדיניות בגרסה הזמינה לכולם.

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

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

   2. יוצרים מדיניות של סוכן GA בכל אזור שבו נדרשת המדיניות. מידע על יצירת מדיניות של סוכני GA זמין במאמר בנושא יצירת מדיניות של סוכנים.

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

      gcloud beta compute instances ops-agents policies delete POLICY_ID --project PROJECT_ID
      

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

בקטעים הבאים מוסבר איך לטפל במקרים הבאים:

• מדיניות של סוכני בטא שבוחרת מופעים עם שמות
• מדיניות שדרוג סוכנים בגרסת בטא

המרת מדיניות בגרסת בטא של מופע בעל שם למדיניות בגרסה זמינה לכולם (GA)

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

1. מחילים תווית על המופעים בקבוצת המכונות הווירטואליות שרוצים לבחור. כדי להחיל תווית על מכונה וירטואלית קיימת, משתמשים בפקודה gcloud compute instances add-labels, כמו בדוגמה הבאה:

   gcloud compute instances add-labels INSTANCE_NAME --labels=KEY=VALUE
   

2. מתארים מדיניות של סוכן GA שבוחר מכונות וירטואליות עם התווית החדשה באמצעות המבנה instanceFilter בהגדרה. בדוגמה הבאה נוצר קובץ בשם config.yaml שמכיל מדיניות שתואמת לתווית שהוחלה בשלב הקודם:

   cat > config.yaml << EOF
   agentsRule:
     packageState: installed
     version: 2.47.0
   instanceFilter:
     inclusionLabels:
     - labels:
       KEY: VALUE
   EOF
   

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

3. יוצרים מדיניות של סוכן GA בכל אזור שבו יש מכונות וירטואליות עם התווית החדשה:

   gcloud compute instances ops-agents policies create POLICY_ID \
     --zone ZONE \
     --file config.yaml
     --project PROJECT_ID
   

   מידע נוסף על יצירת מדיניות של סוכני GA זמין במאמר יצירת מדיניות של סוכנים.

החלפת מדיניות שדרוג של סוכני בטא

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

• כדי לוודא שסוכן התפעול תמיד מעודכן, אפשר להשתמש ב-OS Patch כדי ליצור ולהריץ הטמעת תיקון שתעדכן את הסוכן לגרסה העדכנית.

• כדי לבצע שדרוג חד-פעמי:

  1. כדי לדעת מהי הגרסה האחרונה של סוכן התפעול, אפשר לעיין בהערות לגבי הגרסה ב-GitHub.

  2. יוצרים או משנים מדיניות של סוכן שמתקינה את הגרסה האחרונה של הסוכן. לדוגמה, אם הגרסה העדכנית היא 2.60.0, תוכלו להשתמש בקובץ YAML של מדיניות סוכן שדומה לזה:

     agentsRule:
       packageState: installed
       version: 2.60.0
     instanceFilter:
     [...]
     

  3. מחילים את המדיניות על מכונות וירטואליות בכל אזור.

מערכות הפעלה נתמכות

אפשר להחיל מדיניות של סוכן על מכונות וירטואליות ב-Compute Engine שמריצות את מערכות ההפעלה שמוצגות בטבלה הבאה:

מערכת הפעלה	‫סוכן תפעול מדיניות (GA & בטא^†)	סוכן Logging (מדיניות בטא^† בלבד)	סוכן מעקב (מדיניות בטא^† בלבד)
CentOS 8
Rocky Linux 8
RHEL 6
‫RHEL 7: rhel-7, rhel-7-6-sap-ha, rhel-7-7-sap-ha, rhel-7-9-sap-ha			^‡
‫RHEL 8: rhel-8, rhel-8-4-sap-ha, rhel-8-6-sap-ha, rhel-8-8-sap-ha			^‡
‫Debian 9 (Stretch)
‫Debian 11 (Bullseye)
תמונות VM של למידה עמוקה (Deep Learning) שמבוססות על Debian 11 (‏Bullseye)
‫Ubuntu LTS 18.04 (Bionic Beaver): ubuntu-1804-lts, ubuntu-minimal-1804-lts
‫Ubuntu LTS 20.04 (Focal Fossa): ubuntu-2004-lts, ubuntu-minimal-2004-lts
‫Ubuntu LTS 22.04 (Jammy Jellyfish): buntu-2204-lts, ubuntu-minimal-2204-lts
‫SLES 12: sles-12, sles-12-sp5-sap
‫SLES 15:‏ sles-15, sles-15-sp2-sap, sles-15-sp3-sap, sles-15-sp4-sap, sles-15-sp5-sap, sles-15-sp6-sap
‫OpenSUSE Leap 15: opensuse-leap (opensuse-leap-15-3-*, opensuse-leap-15-4-*)
‫Windows Server:‏ 2016, ‏ 2019, ‏ 2022, ‏ Core 2016, ‏ Core 2019, ‏ Core 2022

‫^†  במדיניות של סוכני בטא, העמודות של הסוכן ממופות לסוג הסוכן שצוין בקריאה לפונקציה gcloud beta compute instances ops-agents policies create:

• ‫סוכן תפעול ממופה לסוג הסוכן ops-agent.
• סוכן Logging ממופה לסוג הסוכן logging.
• סוכן המעקב ממופה לסוג הסוכן metrics.

^‡ אין תמיכה בסוכן המעקב ב-rhel-7-9-sap-ha, ב-rhel-8-2-sap-ha או ב-rhel-8-4-sap-ha.

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

מידע על שימוש במדיניות של סוכנים לניהול Ops Agent זמין במאמרים הבאים:

• שימוש במדיניות של סוכנים (GA)
• שימוש במדיניות סוכנים (בטא)