הגדרה של VM Manager בארגון באמצעות Terraform

כדי לאכוף הגדרות עקביות של מערכת ההפעלה ולבצע אוטומציה של התאימות בהיררכיית המשאבים של Google Cloud , משתמשים ב-Terraform כדי להגדיר את VM Manager ברמת הארגון.

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

סקירה כללית של משאבי Terraform שזמינים ל-VM Manager מופיעה במאמר הקצאת משאבים של VM Manager באמצעות Terraform.

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

  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא תהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים הבאות:

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של Terraform שבדף הזה, מתקינים ומפעילים את ה-CLI של gcloud, ואז מגדירים את Application Default Credentials באמצעות פרטי הכניסה של המשתמש.

    1. התקינו את ה-CLI של Google Cloud.

    2. אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

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

      gcloud auth application-default login

      אם אתם משתמשים ב-Cloud Shell, אין צורך לבצע את הפעולה הזו.

      אם מוחזרת שגיאת אימות ואתם משתמשים בספק זהויות חיצוני (IdP), ודאו ש נכנסתם ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף זמין במאמר הגדרת אימות לסביבת פיתוח מקומית.

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

הרשאות IAM נדרשות

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

הרשאות בפרויקט היעד

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

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

התפקידים המוגדרים מראש האלה כוללים את ההרשאות שנדרשות להפעלת שירות VM Manager ולהגדרת מטא-נתונים של פרויקט. כדי לראות בדיוק אילו הרשאות נדרשות, אפשר להרחיב את הקטע ההרשאות הנדרשות:

ההרשאות הנדרשות

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

  • serviceusage.services.enable
  • compute.projects.setCommonInstanceMetadata

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

הגדרת חשבון שירות ותפקיד בהתאמה אישית

‫Google ממליצה ליצור חשבון שירות ייעודי כדי להריץ את האוטומציה המרכזית של Terraform.

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

  1. יוצרים תפקיד בהתאמה אישית ברמת הארגון שכולל את ההרשאות serviceusage.services.enable ו-compute.projects.setCommonInstanceMetadata.
  2. מקצים את התפקיד בהתאמה אישית לחשבון השירות בהיקף הנמוך ביותר הרלוונטי, למשל ברמת הארגון או התיקייה. לדוגמה, אם כל פרויקטי היעד נמצאים בתיקייה ספציפית, צריך להעניק את התפקיד ברמת התיקייה.

הפעלת VM Manager באמצעות Terraform

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

שימוש בתבניות פרויקט מוכנות

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

כדי להפעיל את VM Manager, צריך לכלול את משאבי השירות והמטא-נתונים הבאים:

# Enable the OS Config API
resource "google_project_service" "osconfig" {
  service            = "osconfig.googleapis.com"
  disable_on_destroy = false
}

# Set project metadata to enable VM Manager
resource "google_compute_project_metadata_item" "enable_osconfig" {
  key   = "enable-osconfig"
  value = "TRUE"
}

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

resource "google_os_config_os_policy_assignment" "base_security_policy" {
  name        = "base-security-ospolicy"
  description = "Ensure baseline security agent is installed and operational"
  location    = var.zone

  os_policies {
    id   = "no-op-policy"
    mode = "ENFORCEMENT"

    resource_groups {
      resources {
        id = "sample"
        exec {
          validate {
            interpreter = "SHELL"
            script      = "exit 100"
          }
          enforce {
            interpreter = "SHELL"
            script      = "exit 100"
          }
        }
      }
    }
  }

  os_policies {
    id   = "install-security-agent"
    mode = "ENFORCEMENT"

    resource_groups {
      resources {
        id = "install-agent"
        pkg {
          desired_state = "INSTALLED"
          apt {
            name = "security-agent"
          }
          yum {
            name = "security-agent"
          }
        }
      }
    }
  }

  instance_filter {
    all = true
  }

  rollout {
    disruption_budget {
      percent = 10
    }
    min_wait_duration = "3.5s"
  }
}

ניהול מרכזי של כל הפרויקטים

אם אי אפשר לשנות את תוכנית האב של פרויקט הזהב, אפשר לנהל באופן מרכזי את ההפעלה של VM Manager ואת הקצאות מדיניות מערכת ההפעלה בכמה פרויקטים קיימים באמצעות הארגומנט for_each של Terraform.

כדי להפעיל את VM Manager בפרויקטים של היעד, משתמשים בארגומנט for_each כדי לחזור על מיפוי הפרויקט:

resource "google_project_service" "osconfig" {
  for_each           = var.target_projects
  project            = each.key
  service            = "osconfig.googleapis.com"
  disable_on_destroy = false
}

resource "google_compute_project_metadata_item" "enable_osconfig" {
  for_each = var.target_projects
  project  = each.key
  key      = "enable-osconfig"
  value    = "TRUE"
}

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

resource "google_os_config_os_policy_assignment" "observability_agent_policy" {
  for_each    = var.target_projects
  project     = each.key
  name        = "observability-agent-ospolicy"
  description = "Install Google Cloud Observability agent on CentOS VMs across target projects"
  location    = var.zone

  os_policies {
    id   = "setup-repo-and-install-package-policy"
    mode = "ENFORCEMENT"

    resource_groups {
      inventory_filters {
        os_short_name = "centos"
        os_version    = "8"
      }

      resources {
        id = "setup-repo"
        repository {
          yum {
            id           = "google-cloud-ops-agent"
            display_name = "Google Cloud Ops Agent Repository"
            base_url     = "https://packages.cloud.google.com/yum/repos/google-cloud-ops-agent-el8-x86_64-all"
            gpg_keys = [
              "https://packages.cloud.google.com/yum/doc/yum-key.gpg",
              "https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg",
            ]
          }
        }
      }

      resources {
        id = "install-pkg"
        pkg {
          desired_state = "INSTALLED"
          yum {
            name = "google-cloud-ops-agent"
          }
        }
      }
    }
  }

  instance_filter {
    all = true
  }

  rollout {
    disruption_budget {
      percent = 10
    }
    min_wait_duration = "3.5s"
  }
}

הגדרת פרויקטים ליעד

אפשר לספק את מפת var.target_projects להגדרת Terraform באמצעות היקף קבוע או היקף דינמי:

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

     data "google_projects" "in_folder" {
     filter = "parent.id:${local.folder_id}"
     }
    

    כדי לטפל בחריגים, מסננים פרויקטים שמכילים תוויות החרגה ספציפיות. אפשר גם להריץ סקריפטים חיצוניים באמצעות local_exec שמריצים פקודות של Google Cloud CLI (כמו gcloud asset search-all-resources) כדי ליצור רשימות דינמיות של יעדים.

יצירת תהליך עבודה אוטומטי ללא שמירת מצב

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

כדי לנהל את ההיקף הדינמי בצורה יעילה, צריך להטמיע תהליך עבודה אוטומטי בלי שמירת מצב באמצעות Cloud Build:

  1. מפעילים את Terraform. מריצים את terraform init באמצעות קצה עורפי מקומי זמני ולא קבוע.
  2. חיפוש פרויקטים תייצר את הרשימה הנוכחית של פרויקטים לטירגוט על סמך קריטריונים דינמיים להיקף.
  3. ייבוא של משאבים קיימים מריצים את הפקודה terraform import כדי למשוך את המשאבים הקיימים google_project_service, google_compute_project_metadata_item ו-google_os_config_os_policy_assignment למצב המקומי.
  4. החלת ההגדרה. מריצים פקודות רגילות של Terraform (terraform plan ו-terraform apply) ומעבירים את רשימת הפרויקטים שנמצאו להצהרות.
  5. פריטי מידע שנוצרו בתהליך פיתוח (Artifact) של הפעלת החנות. אפשר גם לשמור את הפלט של התוכנית, את תמונות המצב ואת סיכומי ההעתקה בקטגוריה של Cloud Storage לצורכי ביקורת.

כדאי לתזמן את צינור הנתונים של Cloud Build להפעלה במועדים קבועים (למשל פעם ביום או פעם בשבוע) כדי לזהות באופן אוטומטי שינויים בהגדרות ולאכוף את התאימות בכל הארגון.

הצגת הסטטוס של VM Manager ברמת הארגון

אחרי שמגדירים את VM Manager בכל הארגון, אפשר לראות דוחות על ההפעלה ועל סטטוס מערכת ההפעלה בכל הפרויקטים בהיררכיה. כשמייצאים נתונים ממאגר משאבי ענן ל-BigQuery, אפשר להריץ שאילתות SQL כדי לבדוק אם VM Manager מופעל, לבדוק את הגרסאות של סוכן OS Config ולבדוק את פרטי מערכת ההפעלה בכל הפרויקטים בארגון.

במאמר איך משתמשים במאגר משאבי ענן וב-BigQuery כדי לראות את הסטטוס של VM Manager בארגון מוסבר איך לייצא נתונים ולהריץ שאילתות של דוחות סטטוס.

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