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

אפשר ליצור ולנהל מדיניות של סוכנים באמצעות קבוצת הפקודות gcloud compute instances ops-agents policies ב-Google Cloud CLI או באמצעות מודול Terraform‏ ops-agent-policy. מדיניות של סוכנים משתמשת בחבילת הכלים VM Manager ב-Compute Engine כדי לנהל מדיניות של מערכת הפעלה, שיכולה להפוך את הפריסה והתחזוקה של הגדרות תוכנה לאוטומטיות, כמו סוכן תפעול. אי אפשר להחיל את כללי המדיניות האלה על סוכן המעקב מדור קודם או על סוכן Logging מדור קודם.

מדיניות הסוכן של GA משתמשת במשאבי הקצאת מדיניות של מערכת ההפעלה ב-OS Config API. למרות שיש קבוצת פקודות כללית של ה-CLI של gcloud לניהול הקצאות של מדיניות מערכת ההפעלה, gcloud compute os-config os-policy-assignments, קבוצת הפקודות gcloud compute instances ops-agents policies מיועדת במיוחד למדיניות של הסוכן שמתוארת במסמך הזה.

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

מודול Terraform‏ ops-agent-policy מבוסס על הפקודות gcloud compute instances ops-agents policies מ-SDK של Google Cloud. מידע על אופן הפעולה של Terraform זמין במאמר שימוש ב-Terraform.

לפני שמשתמשים ב-Google Cloud CLI או במודול Terraform כדי ליצור מדיניות של סוכנים, צריך לבצע את השלבים הבאים:

  1. אם אתם מתכוונים להשתמש בפקודות gcloud compute instances ops-agents policies, ואם עדיין לא עשיתם זאת, אתם צריכים להתקין את Google Cloud CLI.

  2. אם אתם מתכוונים להשתמש במודול Terraform, אתם צריכים לבצע את הפעולות הבאות:

    1. מידע על התקנת Terraform זמין במאמר התקנה והגדרה של Terraform. ‫Terraform כבר מותקן ב-Cloud Shell.

    2. משכפלים את מאגר terraform-google-cloud-operations שמכיל את מודול ops-agent-policy:

      git clone https://github.com/terraform-google-modules/terraform-google-cloud-operations

  3. מורידים ומריצים את הסקריפט prepare-for-ops-agents-policies.sh כדי להפעיל את ממשקי ה-API הנדרשים ולהגדיר את ההרשאות המתאימות לשימוש ב-Google Cloud CLI או ב-Terraform.

    מידע על הסקריפט מופיע במאמר הסקריפט prepare-for-ops-agents-policies.sh.

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

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

איך מוודאים שהסוכן של OS Config מותקן

יכול להיות שתצטרכו להתקין ולהגדיר ידנית את הסוכן של OS Config במכונות וירטואליות שנוצרו לפני OS Config. מידע על התקנה ידנית ואימות של סוכן OS Config זמין ברשימת המשימות לאימות של VM Manager.

איך מוצאים ערכים של מידע על מערכת ההפעלה

אם רוצים להחיל מדיניות של סוכנים על מערכות הפעלה או גרסאות ספציפיות, צריך לדעת את הערכים שמשמשים את OS Config כדי להתייחס אליהן.

כדי למצוא את הערכים של השדות osShortName ו-osVersion למכונת VM, משתמשים בפקודות הבאות:

gcloud compute instances os-inventory describe INSTANCE_NAME \
--zone ZONE | grep "^ShortName: "

gcloud compute instances os-inventory describe INSTANCE_NAME \
--zone ZONE | grep "^Version: "

כדי להשתמש בפקודות האלה, צריך להתקין את סוכן OS Config במכונה הווירטואלית.

יצירת מדיניות של סוכן לניהול סוכן התפעול

שורת פקודה

כדי ליצור מדיניות של סוכן, משתמשים בפקודה gcloud compute instances ops-agents policies create. המבנה של הפקודה הזו הוא:

gcloud compute instances ops-agents policies create POLICY_ID \
  --zone ZONE \
  --file path/to/policy-description-file.yaml \
  --project PROJECT_ID

כשמשתמשים בפקודה הזו, מחליפים את המשתנים באופן הבא:

  • ‫POLICY_ID הוא שם המדיניות.
  • ‫ZONE הוא תחום (zone) של Compute Engine. מדיניות של סוכנים חלה רק על מכונות וירטואליות באזור שצוין. כדי להחיל מדיניות בכמה אזורים, צריך ליצור כמה סוגי מדיניות.
  • ‫path/to/policy-description-file.yaml הוא הנתיב לקובץ YAML שמתאר את המדיניות. מידע על המבנה של הקובץ הזה זמין במאמר בנושא תיאור מדיניות הסוכן.
  • ‫PROJECT_ID הוא מזהה הפרויקט שלכם. Google Cloud

מידע על פקודות אחרות בקבוצת הפקודות ועל האפשרויות הזמינות מופיע במאמרי העזרה בנושא gcloud compute instances ops-agents policies.

תיאור של מדיניות הסוכן

כדי לספק מידע על מדיניות ל-gcloud compute instances ops-agents policies create, צריך ליצור קובץ YAML שמתאר את המדיניות ולהעביר את הקובץ לפקודה כערך של האפשרות --file.

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

הפורמט של קובץ תיאור המדיניות ב-YAML

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

  • ‫agentsRule, שקובע אם מדיניות הסוכן תתקין או תסיר את סוכן התפעול, ומציין את הגרסה של סוכן התפעול שבה יתבצעו הפעולות.

  • ‫instanceFilter, שמתאר את המכונות הווירטואליות שבהן המדיניות חלה.

המבנה של קבוצת השדות agentsRule

לשדה agentsRule יש את המבנה הבא:

agentsRule:
  packageState: installed|removed
  version: latest|2.*.*|2.x.y
  • השדה packageState מציין למדיניות את המצב הרצוי של סוכן תפעול. הערכים התקינים הם installed ו-removed.

  • השדה version מציין את הגרסה של סוכן התפעול שצריך להתקין או להסיר. אפשר לציין את הערכים הבאים:

    • ‫latest היא הגרסה העדכנית ביותר של סוכן תפעול.
    • ‫2.*.* היא הגרסה האחרונה של הגרסה הראשית 2 של סוכן תפעול.
    • ‫2.x.y מציין מהדורה ספציפית של גרסה ראשית 2.

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

המבנה של קבוצת השדות instanceFilter

קבוצת השדות instanceFilter מציינת את המכונות הווירטואליות באזור שאליו חל המסנן. קבוצת השדות הזו היא ייצוג YAML של המבנה InstanceFilter שמשמש את משאב OSPolicyAssignment ב-OS Config API.

קבוצת השדות instanceFilter יכולה להיות באחד מהמבנים הבאים:

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

    instanceFilter:
  all: True

    אם משתמשים במסנן all: True, אי אפשר לציין קריטריונים אחרים.

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

    • תוויות במכונה הווירטואלית, להכללה או להחרגה:
      • inclusionLabels:
      • exclusionLabels:
    • מערכת הפעלה: inventories:

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

    instanceFilter:
  inclusionLabels:
  - labels:
      env: prod
  exclusionLabels:
  - labels:
      app: web
  inventories:
  - osShortName: rhel
    osVersion: '7.*'
  - osShortName: debian
    osVersion: '11'

    מידע על איתור הערכים של מערכת ההפעלה זמין במאמר בנושא איתור מידע על מערכת ההפעלה.

Terraform

כדי ליצור מדיניות סוכן בהתאמה אישית מלאה, משתמשים במודול ops-agent-policy בספרייה modules במאגר terraform-google-cloud-operations. המודול הזה דורש את אותם פרטים שנדרשים בפקודה gcloud compute instances ops-agents policies create. כדי לראות תיאור של כל השדות שמשמשים לתיאור מדיניות של סוכן, בוחרים בכרטיסייה Command-line.

הספרייה examples במאגר terraform-google-cloud-operations מכילה קבצים שמספקים לכם הרבה מהמשתנים שנדרשים למודול ops-agent-policy. מידע נוסף מופיע במאמר דוגמאות להגדרות מדיניות.

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform. מידע על אופן הפעולה של Terraform זמין במאמר שימוש ב-Terraform.

אימות הסטטוס של מדיניות הסוכן

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

הדף OS policies ב-Compute Engine

בדף OS policies ב-Compute Engine מפורט מידע על מדיניות הסוכן שמנהלת את סוכן תפעול ועל מכונות וירטואליות בכרטיסייה VM instances. לדוגמה:

  • בעמודה State (מצב) אפשר לראות אם מדיניות הותקנה בהצלחה (Compliant), נמצאת בתהליך (Pending), יכול להיות שההתקנה נכשלה (Unknown) או שהיא חסרה (No policies).
  • בעמודה VM monitored מצוין אם סוכן תפעול מנוהל על ידי OS Config ‏ ("Monitored") או לא ("Not monitored").

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

נכנסים לדף OS policies במסוף Google Cloud :

מעבר אל מדיניות OS

אם משתמשים בסרגל החיפוש כדי למצוא את הדף הזה, בוחרים את התוצאה שכותרת המשנה שלה היא Compute Engine.

בכרטיסייה OS policies של Compute Engine VM instances מוצג מידע על סוכנים שמנוהלים על ידי כל מדיניות מערכת ההפעלה בפרויקטGoogle Cloud . כללי המדיניות האלה מסומנים בתווית goog-ops-agent-policy.

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

    כדי להבחין בין כללי המדיניות, משתמשים בכרטיסייה OS policy assignments בדף כדי לראות את מזהי המדיניות של כל הקצאות המדיניות בפרויקט Google Cloud .

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

הדף VM Instances ב-Cloud Monitoring

בדף VM Instances ב-Cloud Monitoring יש עמודה בשם Agent שבה מפורט הסוכן שמותקן בכל מכונת VM. אם מותקן סוכן תפעול, מופיע גם אינדיקטור לסוכנים מותקנים שהגרסה שלהם ישנה יותר מהגרסה העדכנית.

נכנסים לדף VM Instances במסוף Google Cloud :

כניסה לדף VM Instances

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

הגדרות מדיניות לדוגמה

בקטע הזה מפורטות דוגמאות להגדרת מדיניות של סוכנים כשמשתמשים ב-Google Cloud SDK או ב-Terraform.

שורת פקודה

דוגמאות לקובצי תיאור מדיניות

בקטע הזה מופיעות כמה דוגמאות לקובצי תיאור מדיניות ב-YAML למגוון תרחישים. בדוגמאות מניחים שקובץ ה-YAML נקרא agent-policy-description.yaml ושיוצרים את המדיניות באזור us-central1-a באמצעות פקודה כמו זו:

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

התקנה בכל המכונות הווירטואליות

כדי להתקין את הגרסה העדכנית של סוכן תפעול בכל המכונות הווירטואליות באזור us-central1-a, משתמשים בתיאור המדיניות הבא:

agentsRule:
  packageState: installed
  version: latest
instanceFilter:
  all: True

הסרה מכל המכונות הווירטואליות

כדי להסיר את הגרסה העדכנית של סוכן תפעול מכל המכונות הווירטואליות באזור us-central1-a, משתמשים בתיאור המדיניות הבא:

agentsRule:
  packageState: removed
  version: latest
instanceFilter:
  all: True

התקנה במכונות וירטואליות על סמך תוויות

כדי להתקין את הגרסה העדכנית של סוכן תפעול בכל המכונות הווירטואליות באזור us-central1-a עם התווית env=prod או app=web, משתמשים בתיאור המדיניות הבא:

agentsRule:
  packageState: installed
  version: latest
instanceFilter:
  inclusionLabels:
  - labels:
      env: prod
  - labels:
      app: web

כשמציינים כמה ערכים של labels: להכללה או להחרגה, מכונה וירטואלית תתאים אם אחת מהתוויות קיימת. כלומר, קבוצות התוויות להכללה או להחרגה מותאמות כפעולה לוגית של OR ולא כפעולה לוגית של AND.

התקנה במכונות וירטואליות על סמך תוויות אחרות

כדי להתקין את הגרסה העדכנית של סוכן תפעול בכל המכונות הווירטואליות באזור us-central1-a שמופעל בהן Debian 11, למעט אלה עם התוויות env=prod ו-app=web6, משתמשים בתיאור המדיניות הבא:

agentsRule:
  packageState: installed
  version: latest
instanceFilter:
  exclusionLabels:
  - labels:
      env: prod
      app: web6
  inventories:
  - osShortName: debian
    osVersion: '11'

כשמציינים כמה צמדים של מפתח/ערך בתוך רשומה אחת של labels: להכללה או להחרגה, VM תתאים אם כל התוויות קיימות. כלומר, התוויות מותאמות כפעולה לוגית של AND ולא כפעולה לוגית של OR.

התקנה במכונות וירטואליות לפי מערכת הפעלה

כדי להתקין את הגרסה העדכנית 2 של סוכן תפעול בכל המכונות הווירטואליות שפועלות ב-Debian 11 או ב-RHEL 7.* באזור us-central1-a, משתמשים בתיאור המדיניות הבא:

agentsRule:
  packageState: installed
  version: 2.*.*
instanceFilter:
  inventories:
  - osShortName: rhel
    osVersion: '7.*'
  - osShortName: debian
    osVersion: '11'

Terraform

בקטע הזה מתוארות הדוגמאות בספרייה examples של מאגר terraform-google-cloud-operations. בדוגמאות האלה יש קבצים שמגדירים בשבילכם הרבה מהמשתנים שנדרשים על ידי מודול ops-agent-policy. אפשר גם להעתיק את הדוגמאות ולשנות אותן. לדוגמה, כל הדוגמאות האלה מתקינות את סוכן התפעול, אבל אפשר לשנות אותן כדי למחוק את הסוכן במקום להתקין אותו.

כדי ללמוד איך להחיל הגדרות ב-Terraform או להסיר אותן, ראו פקודות בסיסיות ב-Terraform.

לדוגמה: ops_agent_policy_install_all

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

כשמריצים את הפקודה terraform plan או terraform apply, מוצגת בקשה להזנת הערכים הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud

לדוגמה: ops_agent_policy_install_all_in_region

בדוגמה הזו מותקנת הגרסה העדכנית של סוכן תפעול בכל מכונות ה-VM שעומדות בדרישות באזור נתון, כמו us-west1. אזור מכיל כמה אזורים, ובמקרה הזה: us-west-1a,‏ us-west-1b ו-us-west-1c.

כשמריצים את הפקודה terraform plan או terraform apply, מוצגת בקשה להזנת הערכים הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫REGION: האזור שבו רוצים להתקין את הסוכן במכונות הווירטואליות

לדוגמה: ops_agent_policy_install_all_in_zone

בדוגמה הזו מותקנת הגרסה העדכנית של סוכן תפעול בכל מכונות ה-VM שעומדות בדרישות באזור נתון, כמו us-central1-a.

כשמריצים את הפקודה terraform plan או terraform apply, מוצגת בקשה להזנת הערכים הבאים:

  • ‫PROJECT_ID: מזהה הפרויקט ב- Google Cloud
  • ‫ZONE: האזור שבו רוצים להתקין את הסוכן במכונות הווירטואליות

פתרון בעיות במדיניות של סוכן GA

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

הפקודות של ops-agents policy נכשלות

כשפקודה gcloud compute instances ops-agents policies נכשלת, בתשובה מוצגת שגיאת אימות. כדי לתקן את השגיאות, צריך לתקן את הארגומנטים של הפקודה ואת הדגלים כמו שמוצע בהודעת השגיאה.

בנוסף לשגיאות האימות, יכול להיות שיוצגו שגיאות שמצביעות על התנאים הבאים:

בקטעים הבאים מפורטים התנאים האלה.

הרשאת IAM לא מספיקה

אם פקודת gcloud compute instances ops-agents policies נכשלת עם שגיאת הרשאה, צריך לוודא שהפעלתם את סקריפט prepare-for-ops-agents-policies.sh כמו שמתואר בקטע לפני שמתחילים כדי להגדיר את תפקידי המדיניות של OS Config:

מידע נוסף על הסקריפט prepare-for-ops-agents-policies.sh זמין במאמר בנושא הסקריפט prepare-for-ops-agents-policies.sh.

‫OS Config API לא מופעל

דוגמה לשגיאה:

API [osconfig.googleapis.com] not enabled on project PROJECT_ID.
Would you like to enable and retry (this will take a few minutes)?
(y/N)?

אפשר להזין y כדי להפעיל את ה-API, או להריץ את הסקריפט prepare-for-ops-agents-policies.sh שמתואר בקטע לפני שמתחילים כדי להעניק את כל ההרשאות הנדרשות. אם מזינים y בהנחיה בהודעת השגיאה, עדיין צריך להריץ את הסקריפט prepare-for-ops-agents-policies.sh כדי להגדיר את ההרשאות הנדרשות.

כדי לוודא ש-OS Config API מופעל בפרויקט, מריצים את הפקודות הבאות:

gcloud services list --project PROJECT_ID | grep osconfig.googleapis.com

הפלט הצפוי:

osconfig.googleapis.com    Cloud OS Config API

המדיניות כבר קיימת

דוגמה לשגיאה:

ALREADY_EXISTS: Requested entity already exists

השגיאה הזו מציינת שהמדיניות הזו כבר קיימת עם אותו שם, מזהה פרויקט ואזור. כדי לאשר את זה, אפשר להשתמש בפקודה gcloud compute instances ops-agents policies describe.

המדיניות לא קיימת

דוגמה לשגיאה:

NOT_FOUND: Requested entity was not found

יכול להיות שהשגיאה הזו מציינת שהמדיניות מעולם לא נוצרה, שהמדיניות נמחקה או שמזהה המדיניות שצוין שגוי. חשוב לוודא שהתווית POLICY_ID שבה משתמשים בפקודה gcloud compute instances ops-agents policies describe, update או delete תואמת למדיניות קיימת. כדי לראות את רשימת כללי המדיניות של הסוכן, משתמשים בפקודה gcloud compute instances ops-agents policies list.

המדיניות נוצרת אבל נראה שאין לה השפעה

סוכני OS Config נפרסים בכל מכונה ב-Compute Engine כדי לנהל את החבילות של סוכני רישום ביומן ומעקב. יכול להיות שלמדיניות לא תהיה השפעה אם לא מותקן סוכן OS Config בבסיס מערכת ההפעלה.

Linux

כדי לוודא שהסוכן של OS Config מותקן, מריצים את הפקודה הבאה:

gcloud compute ssh instance-id \
    --project project-id \
    -- sudo systemctl status google-osconfig-agent

פלט לדוגמה:

    google-osconfig-agent.service - Google OSConfig Agent
    Loaded: loaded (/lib/systemd/system/google-osconfig-agent.service; enabled; vendor preset:
    Active: active (running) since Wed 2020-01-15 00:14:22 UTC; 6min ago
    Main PID: 369 (google_osconfig)
     Tasks: 8 (limit: 4374)
    Memory: 102.7M
    CGroup: /system.slice/google-osconfig-agent.service
            └─369 /usr/bin/google_osconfig_agent

Windows

כדי לוודא שהסוכן של OS Config מותקן, מבצעים את השלבים הבאים:

  1. מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.

  2. פותחים טרמינל ב-PowerShell ומריצים את פקודת PowerShell הבאה. לא צריך הרשאות אדמין.

    Get-Service google_osconfig_agent

פלט לדוגמה:

    Status   Name               DisplayName
    ------   ----               -----------
    Running  google_osconfig_a… Google OSConfig Agent

אם סוכן OS Config לא מותקן, יכול להיות שאתם משתמשים במערכת הפעלה שלא תומכת ב-VM Manager. במסמך פרטים על מערכת ההפעלה ב-Compute Engine מצוין אילו תכונות של VM Manager נתמכות בכל מערכת הפעלה של Compute Engine.

אם מערכת ההפעלה תומכת ב-VM Manager, אפשר להתקין את הסוכן של OS Config באופן ידני.

הסוכן OS Config מותקן אבל לא מתקין את סוכן התפעול

כדי לבדוק אם יש שגיאות כשסוכן OS Config מחיל מדיניות, אפשר לבדוק את היומן של סוכן OS Config. אפשר לעשות את זה באמצעות כלי Logs Explorer או באמצעות SSH או RDP כדי לבדוק מכונות ספציפיות של Compute Engine.

כדי לראות את היומנים של הסוכן OS Config ב-Logs Explorer, משתמשים במסנן הבא:

resource.type="gce_instance"
logId(OSConfigAgent)

כדי לראות את היומנים של הסוכן OS Config:

‫CentOS‏, RHEL‏,
SLES‏, SUSE

מריצים את הפקודה הבאה: 

gcloud compute ssh INSTANCE_ID \
    --project PROJECT_ID \
    -- sudo cat /var/log/messages \
       | grep "OSConfigAgent\|google-fluentd\|stackdriver-agent"

‫Debian, ‏ Ubuntu

מריצים את הפקודה הבאה: 

gcloud compute ssh INSTANCE_ID \
    --project PROJECT_ID \
    -- sudo cat /var/log/syslog \
       | grep "OSConfigAgent\|google-fluentd\|stackdriver-agent"

Windows

  1. מתחברים למופע באמצעות RDP או כלי דומה ומתחברים ל-Windows.

  2. פותחים את האפליקציה Event Viewer, בוחרים באפשרות Windows Logs > Application ומחפשים יומנים עם Source ששווה ל-OSConfigAgent.

אם יש שגיאה בהתחברות לשירות OS Config, צריך לוודא שמריצים את הסקריפט prepare-for-ops-agents-policies.sh כמו שמתואר בקטע לפני שמתחילים כדי להגדיר את המטא-נתונים של OS Config.

כדי לוודא שהמטא-נתונים של OS Config מופעלים, אפשר להריץ את הפקודה הבאה:

gcloud compute project-info describe \
    --project PROJECT_ID \
    | grep "enable-osconfig\|enable-guest-attributes" -A 1

הפלט הצפוי:

- key: enable-guest-attributes
  value: 'TRUE'
- key: enable-osconfig
  value: 'TRUE'

סוכן התפעול מותקן אבל לא פועל בצורה תקינה

מידע נוסף על ניפוי באגים ב-Ops Agent זמין במאמר פתרון בעיות ב-Ops Agent.

הפעלת יומנים ברמת ניפוי הבאגים עבור הסוכן של OS Config

מומלץ להפעיל רישום ביומן ברמת ניפוי הבאגים בסוכן OS Config כשמדווחים על בעיה.

אפשר להגדיר את המטא-נתונים osconfig-log-level: debug כדי להפעיל רישום ביומן ברמת ניפוי הבאגים עבור הסוכן OS Config. היומנים שנאספו מכילים מידע נוסף שיכול לעזור בחקירה.

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

gcloud compute project-info add-metadata \
    --project PROJECT_ID \
    --metadata osconfig-log-level=debug

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

gcloud compute instances add-metadata INSTANCE_ID \
    --project PROJECT_ID \
    --metadata osconfig-log-level=debug

סקריפטים לעזרה

בקטע הזה מופיע מידע נוסף על סקריפטים של עזרה שמתוארים במסמך הזה:

הסקריפט prepare-for-ops-agents-policies.sh

אחרי שמורידים את הסקריפט prepare-for-ops-agents-policies.sh, אפשר להשתמש בו כדי לבצע את הפעולות הבאות, על סמך הארגומנטים שמספקים:

  • מפעילים בפרויקט את Cloud Logging API, את Cloud Monitoring API ואת OS Config API.

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

  • מקצים את התפקידים Logs Writer (כותב יומנים) (roles/logging.logWriter) וMonitoring Metric Writer (כותב מדדים ב-Monitoring) (roles/monitoring.metricWriter) בניהול הזהויות והרשאות הגישה (IAM) לחשבון השירות שמוגדר כברירת מחדל ב-Compute Engine, כדי שהסוכנים יוכלו לכתוב יומנים ומדדים ב-Logging API וב-Cloud Monitoring API.

  • מפעילים את המטא-נתונים של OS Config בפרויקט כדי שהסוכן של OS Config בכל מכונה וירטואלית יהיה פעיל.

  • נותנים למשתמשים או לחשבונות השירות שאינם בעלים את אחד מתפקידי ה-IAM הבאים שנדרשים ליצירה ולניהול של מדיניות. לבעלי הפרויקט יש גישה מלאה ליצירה ולניהול של מדיניות. כל שאר המשתמשים או חשבונות השירות צריכים לקבל אחד מהתפקידים הבאים:

    כשמריצים את הסקריפט, אפשר לציין את התפקידים של OSPolicyAssignment בתור admin, ‏editor או viewer. הסקריפט ממפה את הערכים האלה לשמות התפקידים roles/osconfig.osPolicyAssignment*.

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

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

bash prepare-for-ops-agents-policies.sh --project=PROJECT_ID

כדי להעניק בנוסף אחד מהתפקידים של OS Config למשתמש שאין לו את התפקיד Owner ‏ (roles/owner) בפרויקט, מריצים את הסקריפט באופן הבא:

bash prepare-for-ops-agents-policies.sh --project=PROJECT_ID \
  --iam-user=USER_EMAIL \
  --iam-policy-access=[admin|editor|viewer]

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

bash prepare-for-ops-agents-policies.sh --project=PROJECT_ID \
  --iam-service-account=SERVICE_ACCT_EMAIL \
  --iam-policy-access=[admin|editor|viewer]

הסקריפט diagnose_policies.sh

בהינתן מזהה פרויקט, מזהה מכונה ב-Compute Engine, אזור ב-Compute Engine ומזהה מדיניות הסוכן, הסקריפט diagnose_policies.sh אוסף באופן אוטומטי את המידע הדרוש כדי לאבחן בעיות במדיניות:

  • הגרסה של סוכן OS Config
  • הקצאת מדיניות מערכת ההפעלה הבסיסית
  • הקצאות של מדיניות מערכת ההפעלה שרלוונטיות למכונה הזו ב-Compute Engine
  • תיאור של מכונת Compute Engine

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

bash diagnose_policies.sh --project-id=PROJECT_ID \ 
  --gce-instance-id=INSTANCE_ID \
  --policy-id=POLICY_ID \
  --zone=ZONE

תמחור

הפקודות gcloud compute instances ops-agents policies מיושמות באמצעות משאבי הקצאת מדיניות מערכת הפעלה מ-VM Manager. הסקריפט prepare-for-ops-agents-policies.sh, שמתואר בקטע לפני שמתחילים, מגדיר את VM Manager במצב עם תכונות מוגבלות (OSCONFIG_B), שמתאים ליצירה ולניהול של מדיניות סוכנים. אין עלות לשימוש ב-VM Manager במצב מוגבל.

אם הגדרתם את VM Manager במצב עם כל התכונות (OSCONFIG_C), יכול להיות שתחויבו בעלויות.