יצירת הגדרות אישיות ל-Terraform

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

במדריך הזה משתמשים ב-Cloud Build כדי להריץ פקודות Terraform בגרסה העדכנית של קובץ האימג' של Terraform Docker, וב-Cloud Storage כדי לאחסן ולנהל משאבי Terraform כמו מודולים וקבצים של מצב.

לקבלת משאבים והנחיות לשימוש ב-Terraform, אפשר לעיין במאמר שימוש ב-Terraform עם Google Cloud.

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

• אתם צריכים את התפקידים הבאים ב-IAM:

  • אדמין של קטלוג או מנהל קטלוג בארגוןGoogle Cloud שמשויך לפרויקט Google Cloud שבו הופעל Service Catalog. אם לא הוקצה לכם התפקיד הזה, פנו לאדמין הארגוני כדי לבקש גישה.
  • Storage Admin בפרויקט שבו רוצים ליצור את הפתרון. Google Cloud אם הגדרות ה-Terraform שלכם נמצאות בפרויקט אחר, צריך גם את התפקיד Storage Admin בפרויקט שמכיל את הגדרות ה-Terraform.
  • ‫Cloud Build Editor לפרויקט Google Cloud שבו רוצים ליצור את הפתרון.

  אם אתם מתכננים להשתמש בחשבון שירות משלכם, אתם צריכים גם את התפקיד Service Account User בפרויקט Google Cloud שכולל את חשבון השירות שבו אתם מתכננים להשתמש.

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

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

  • Storage Admin בפרויקט שבו רוצים ליצור את הפתרון. Google Cloud אם ההגדרות של Terraform נמצאות בפרויקט אחר, לחשבון השירות צריך להיות גם התפקיד צפייה באובייקט אחסון בפרויקט שמכיל את ההגדרות של Terraform.
  • ‫Logs Writer (כתיבת יומנים) עבור הפרויקטGoogle Cloud שבו רוצים ליצור את הפתרון.

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

• מגדירים את Cloud Build בפרויקט שבו יוצרים את ההגדרה:

  1. מפעילים את Cloud Build API.

     תפקידים שנדרשים להפעלת ממשקי API

     כדי להפעיל ממשקי API, צריך את תפקיד ה-IAM 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin), שכולל את ההרשאה serviceusage.services.enable. איך מקצים תפקידים

     להפעלת ה-API

     הפעלת ה-API יוצרת באופן אוטומטי חשבון שירות של Cloud Build שבו משתמשים בשלב הבא.
  2. עוברים לדף Cloud Build.
  3. בחלונית הימנית, לוחצים על הגדרות.
  4. משתמשים בחשבון השירות שמופיע בקטע כתובת האימייל בחשבון השירות.
  5. אם אתם לא משתמשים בחשבון שירות משלכם, צריך להקצות לחשבון השירות את התפקידים הבאים ב-IAM. הוראות למתן תפקידים מפורטות במאמר הגדרת גישה לחשבון השירות של Cloud Build.
     • עריכת פרויקטים (roles/editor)
     • אדמין באחסון (roles/storage.admin)

העלאת קובצי התצורה ל-Cloud Storage

אתם משתמשים ב-Cloud Storage כדי לנהל את קובצי התצורה של Terraform עבור Service Catalog.

יצירת קטגוריה של Cloud Storage

כדי להגדיר את Cloud Storage, יוצרים קטגוריה באותו פרויקט שבו הפעלתם את Service Catalog בארגון:

1. במסוף Google Cloud , נכנסים לדף Buckets של Cloud Storage.

   כניסה לדף Buckets

2. לוחצים על add_box יצירה.
3. ממלאים את פרטי הקטגוריה בדף Create a bucket. כדי לעבור לשלב הבא לוחצים על Continue.
   1. בקטע Get started (תחילת העבודה), מבצעים את הפעולות הבאות:
      • מזינים שם ייחודי בהיקף גלובלי שעומד בקריטריונים לשמות של קטגוריות.
      • כדי להוסיף תווית לדלי, מרחיבים את הקטע Labels (תוויות) (expand_more), לוחצים על add_box Add label (הוספת תווית) ומציינים key ו-value בשביל התווית.
   2. בקטע Choose where to store your data, מבצעים את הפעולות הבאות:
      1. בוחרים סוג מיקום.
      2. בתפריט הנפתח Location type, בוחרים מיקום שבו יישמרו נתוני הקטגוריה באופן קבוע.
         • אם בוחרים את סוג המיקום בשני אזורים, אפשר גם להפעיל רפליקציה בקצב טורבו באמצעות תיבת הסימון הרלוונטית.
      3. כדי להגדיר שכפול בין מאגרי מידע, בוחרים באפשרות הוספת שכפול בין מאגרי מידע באמצעות Storage Transfer Service ופועלים לפי השלבים הבאים:

         הגדרה של רפליקציה בין מאגרי מידע

         1. בתפריט Bucket, בוחרים באפשרות הרצויה.

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

            מופיעה החלונית Configure cross-bucket replication.

            • כדי לסנן אובייקטים לשכפול לפי קידומת של שם האובייקט, מזינים קידומת שרוצים לכלול או להחריג אובייקטים ממנה, ואז לוחצים על add הוספת קידומת.
            • כדי להגדיר סוג אחסון לאובייקטים המשוכפלים, בוחרים סוג אחסון בתפריט סוג אחסון. אם מדלגים על השלב הזה, האובייקטים המשוכפלים ישתמשו בסוג האחסון של קטגוריית היעד כברירת מחדל.
            • לוחצים על סיום.
   3. בקטע Choose how to store your data, מבצעים את הפעולות הבאות:
      1. בוחרים default storage class לקטגוריה או Autoclass לניהול אוטומטי של סוג האחסון (storage class) של נתוני הקטגוריה.
      2. כדי להפעיל מרחב שמות היררכי, בקטע Optimize storage for data-intensive workloads, בוחרים באפשרות Enable hierarchical namespace on this bucket.
   4. בקטע Choose how to control access to objects, בוחרים אם הקטגוריה אוכפת public access prevention או לא, ואז בוחרים שיטת בקרת גישה לאובייקטים של הקטגוריה.
   5. בקטע Choose how to protect object data, מבצעים את הפעולות הבאות:
      • בוחרים באחת מהאפשרויות בקטע הגנה על נתונים שרוצים להגדיר לקטגוריה.
        • כדי להפעיל מחיקה עם יכולת שחזור, מסמנים את התיבה מדיניות מחיקה עם יכולת שחזור (לשחזור נתונים) ומציינים את מספר הימים שבהם רוצים לשמור אובייקטים אחרי המחיקה.
        • כדי להגדיר ניהול גרסאות של אובייקטים, מסמנים את התיבה ניהול גרסאות של אובייקטים (לשליטה בגרסאות) ומציינים את מספר הגרסאות המקסימלי לכל אובייקט ואת מספר הימים שאחריהם הגרסאות הלא עדכניות יפוגו.
        • כדי להפעיל את מדיניות שמירת הנתונים על אובייקטים וקטגוריות, לוחצים על תיבת הסימון שמירת נתונים (לצורך תאימות), ואז מבצעים את הפעולות הבאות:
          • כדי להפעיל את הנעילה של שמירת אובייקטים, מסמנים את התיבה הפעלת שמירת אובייקטים.
          • כדי להפעיל את נעילת הקטגוריה, מסמנים את תיבת הסימון הגדרת מדיניות שמירת נתונים בקטגוריה ובוחרים יחידת זמן ואת משך הזמן של תקופת השמירה.
      • כדי לבחור איך להצפין את נתוני האובייקט, מרחיבים את הקטע Data encryption (expand_more) ובוחרים Data encryption method.
4. לוחצים על יצירה.

הפעלת ניהול גרסאות של אובייקטים

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

מתן גישה לקטגוריה

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

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

• מעניקים את התפקיד צפייה באובייקט אחסון (roles/storage.objectViewer) לחשבונות השירות של Cloud Build של המשתמשים, או למשאב Google Cloud שבו המשתמשים פורסים את תצורות Terraform, כמו פרויקט, תיקייה או ארגון.

• משתמשים ברשימה של בקרת גישה (ACL) כדי לנהל את הגישה לקטגוריה.

לפרטים על ניהול הגישה לקטגוריות, ראו סקירה כללית על בקרת הגישה ב-Cloud Storage.

יצירה והעלאה של מודול Terraform

אחרי שמגדירים את הקטגוריה של Cloud Storage, צריך ליצור ולהעלות מודול של Terraform, שהוא קונטיינר של כל קובצי התצורה. ‫Service Catalog משתמש במודול כדי ליצור באופן אוטומטי קובץ סכימת JSON להגדרת המשתנים של התצורה.

כשקוראים למודולים מחוץ לספרייה הנוכחית, צריך להשתמש בנתיב מרוחק במקום בנתיב יחסי. לדוגמה, במקום source = "../../", צריך להשתמש ב-source = "GoogleCloudPlatform/cloud-run/google".

למודולים של תרחישי שימוש נפוצים, אפשר לעיין במאמר מודולים ותוכניות לניהול של Terraform ב- Google Cloud. Google Cloud

בדוגמת הקוד הבאה מוצג קובץ הגדרות של Terraform, ‏ main.tf:

variable "machine_type" {
  type    = string
  default = "n1-standard-1"
}

variable "zone" {
  type    = string
  default = "us-central1-a"
}

variable "deployment_identifier" {
  description = "The unique name for your instance"
  type        = string
}

resource "google_compute_instance" "default" {
  name         = "vm-${var.deployment_identifier}"
  machine_type = var.machine_type
  zone         = var.zone

  boot_disk {
    device_name = "boot"
    auto_delete = true
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = "default"
    access_config {
      // Ephemeral IP
    }
  }
}

אחרי שיוצרים את המודול, דוחסים את הקבצים לקובץ ZIP. חשוב לוודא שהמודול מאוחסן בספרייה הראשית של קובץ ה-ZIP.

כדי לוודא שהמודול מאוחסן כמו שצריך כשמכווצים את קובצי Terraform, מריצים את הפקודה הבאה: none zip solution.zip file1.tf file2.tf file3.tf

לאחר מכן מעלים את קובץ ה-ZIP לקטגוריה. הוראות להעלאת קובץ ה-ZIP מופיעות במאמר העלאת אובייקטים במסמכי התיעוד של Cloud Storage.

יצירת ההגדרה ב-Service Catalog

אחרי שמגדירים קטגוריה של Cloud Storage באמצעות מודול Terraform, יוצרים פתרון Service Catalog שכולל את הקטגוריה.

כדי ליצור את ההגדרות של Terraform כפתרון של Service Catalog:

1. נכנסים לדף פתרונות של Service Catalog Admin במסוף Google Cloud .
   כניסה לדף Solutions

2. כדי לבחור את הפרויקט, לוחצים על Select. Google Cloud

3. לוחצים על יצירת פתרון. ברשימה הנפתחת, בוחרים באפשרות יצירת הגדרות Terraform.

4. מזינים שם, תיאור וסיסמה לתצורה של Terraform. הסלוגן הוא תיאור קצר של פתרון שהמשתמשים רואים כשהם מעיינים ב-Service Catalog.

5. בשדה Link to Terraform config (קישור להגדרת Terraform), מציינים את הקישור לקטגוריה של Cloud Storage שמכילה את קובץ ה-ZIP של מודול Terraform, כמו gs://my-terraform-bucket/my-zip-file.zip.

6. אפשר גם להעלות סמל לפתרון. המימדים המומלצים לסמל הם 80x80 פיקסלים.

7. אפשר גם להזין קישור לתמיכה ופרטי קשר של היוצר.

8. אפשר גם להוסיף קישור למסמכים בנושא הפתרון.

9. בוחרים את גרסת Terraform שבה רוצים להשתמש כדי לפרוס את הפתרון.

10. אופציונלי: אפשר לספק חשבון שירות משלכם על ידי לחיצה על תיבת הסימון לצד Select or enter your own service account (בחירה או הזנה של חשבון שירות משלכם). אם חשבון השירות נמצא באותו פרויקט שבו אתם יוצרים את הפתרון, בוחרים באפשרות Select a service account from the current project (בחירת חשבון שירות מהפרויקט הנוכחי) ובוחרים את חשבון השירות מהתפריט הנפתח. Google Cloud אם חשבון השירות נמצא בפרויקט אחר מהפתרון, בוחרים באפשרות Enter a service account email from any project (הזנת כתובת אימייל של חשבון שירות מכל פרויקט) ומזינים את כתובת האימייל בחשבון השירות. Google Cloud

11. לוחצים על יצירה.

הפתרון נוצר ומופיע בדף פתרונות במסוף Admin של Service Catalog.

בצילום המסך הבא מוצגת יצירה של הגדרת Terraform:

השלבים הבאים

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