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

כדי להמיר מדיניות של סוכנים בגרסת בטא למדיניות בגרסת GA באמצעות 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.69.0, תוכלו להשתמש בקובץ YAML של מדיניות סוכן שדומה לזה:

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

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

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

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

מערכת הפעלה	‫סוכן תפעול (GA & בטא^† policies)	סוכן 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 ממופה לסוג הסוכן תפעול ops-agent.
• סוכן Logging ממופה לסוג הסוכן logging.
• סוכן המעקב ממופה לסוג הסוכן metrics.

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

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

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

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