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

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

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

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

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

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

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

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

  1. אם עוד לא עשיתם זאת, התקינו את Google Cloud CLI.

    מדיניות הסוכן שמתוארת במסמך הזה משתמשת בקבוצת הפקודות beta.

  2. אם עדיין לא עשיתם זאת, מתקינים את הרכיב beta של ה-CLI של gcloud:

    gcloud components install beta

    כדי לבדוק אם רכיב beta מותקן, מריצים את הפקודה:

    gcloud components list

    אם כבר התקנתם את רכיב beta, צריך לוודא שפועלת אצלכם הגרסה העדכנית ביותר:

    gcloud components update

  3. מורידים את הסקריפט הבא ומשתמשים בו כדי להפעיל את ממשקי ה-API ולהגדיר את ההרשאות המתאימות לשימוש ב-Google Cloud CLI:‏ set-permissions.sh.

    מידע על הסקריפט מופיע במאמר הסקריפט set-permissions.sh.

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

    דוגמאות לפורמט הפקודה מופיעות בקטע דוגמאות במסמכי התיעוד של Google Cloud CLI.

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

שיטות מומלצות לשימוש במדיניות סוכנים

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

זוהי דוגמה לתוכנית השקה מדורגת של מכונות וירטואליות של Debian 11 בפרויקט בשם my_project:

שלב 1: יוצרים מדיניות בשם ops-agents-policy-safe-rollout כדי להתקין את סוכן Logging מדור קודם ואת סוכן הניטור בכל המכונות הווירטואליות עם התוויות env=test ו-app=myproduct.

gcloud beta compute instances \
    ops-agents policies create ops-agents-policy-safe-rollout \
    --agent-rules="type=logging,version=current-major,package-state=installed,enable-autoupgrade=true;type=metrics,version=current-major,package-state=installed,enable-autoupgrade=true" \
    --os-types=short-name=debian,version=11 \
    --group-labels=env=test,app=myproduct \
    --project=my_project

מידע נוסף על ציון מערכת ההפעלה זמין במאמר gcloud beta compute instances ops-agents policies create.

שלב 2: מעדכנים את המדיניות כך שתכוון למכונות וירטואליות באזור אחד עם התוויות env=prod ו-app=myproduct.

gcloud beta compute instances \
    ops-agents policies update ops-agents-policy-safe-rollout \
    --group-labels=env=prod,app=myproduct \
    --zones=us-central1-c \

שלב 3: עדכון המדיניות כדי לנקות את המסנן של האזורים, כך שהיא תופעל באופן גלובלי

gcloud beta compute instances \
    ops-agents policies update ops-agents-policy-safe-rollout \
    --clear-zones

כללי מדיניות במכונות וירטואליות שנוצרו לפני OS Config

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

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

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

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

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

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

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

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

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

מידע נוסף על הסקריפט set-permissions.sh זמין במאמר בנושא הסקריפט set-permissions.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, או להריץ את הסקריפט set-permissions.sh שמתואר במאמר יצירת מדיניות של סוכן כדי להעניק את כל ההרשאות הנדרשות. אם מזינים y בהנחיה בהודעת השגיאה, עדיין צריך להריץ את הסקריפט set-permissions.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 beta compute instances ops-agents policies describe.

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

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

NOT_FOUND: Requested entity was not found

יכול להיות שהשגיאה הזו מציינת שהמדיניות מעולם לא נוצרה, שהמדיניות נמחקה או שמזהה המדיניות שצוין שגוי. חשוב לוודא שהתווית POLICY_ID שבה משתמשים בפקודה gcloud beta compute instances ops-agents policies describe, update או delete תואמת למדיניות קיימת. כדי לראות את רשימת כללי המדיניות של הסוכן, משתמשים בפקודה gcloud beta 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 מותקן, אבל הוא לא מתקין את סוכן Monitoring

כדי לבדוק אם יש שגיאות כשסוכן 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, צריך להריץ את הסקריפט set-permissions.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'

סוכני יכולת הצפייה מותקנים, אבל לא פועלים כמו שצריך

מידע על ניפוי באגים של סוכנים ספציפיים זמין במאמרים הבאים:

הפעלת יומנים ברמת ניפוי הבאגים עבור הסוכן של 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

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

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

הסקריפט set-permissions.sh

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

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

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

bash set-permissions.sh --project=PROJECT_ID

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

bash set-permissions.sh --project=PROJECT_ID \
  --iam-user=USER_EMAIL \
  --iam-permission-role=guestPolicy[Admin|Editor|Viewer]

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

bash set-permissions.sh --project=PROJECT_ID \
  --iam-service-account=SERVICE_ACCT_EMAIL \
  --iam-permission-role=guestPolicy[Admin|Editor|Viewer]

הסקריפט diagnose.sh

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

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

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

bash diagnose.sh --project-id=PROJECT_ID \ 
  --gce-instance-id=INSTANCE_ID \
  --policy-id=POLICY_ID

שילוב של Terraform

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

התמיכה ב-Terraform במדיניות של סוכנים מבוססת על פקודות Google Cloud CLI. כדי ליצור מדיניות של סוכן באמצעות Terraform, פועלים לפי ההוראות במודול Terraform‏ agent-policy. אפשר למצוא מדיניות לדוגמה גם בספרייה examples.