שיטות מומלצות למודולים ברמת הבסיס

במסמך הזה מפורטות הנחיות והמלצות לשימוש במודולים ברמה הבסיסית (root).

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

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

צמצום מספר המשאבים בכל מודול של הרמה הבסיסית

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

שימוש בספריות נפרדות לכל אפליקציה

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

פיצול אפליקציות לספריות משנה ספציפיות לסביבה

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

-- SERVICE-DIRECTORY/
   -- OWNERS
   -- modules/
      -- <service-name>/
         -- main.tf
         -- variables.tf
         -- outputs.tf
         -- provider.tf
         -- README
      -- ...other…
   -- environments/
      -- dev/
         -- backend.tf
         -- main.tf

      -- qa/
         -- backend.tf
         -- main.tf

      -- prod/
         -- backend.tf
         -- main.tf

שימוש בספריות של הסביבה

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

כל ספרייה של סביבה חייבת להכיל את הקבצים הבאים:

  • קובץ backend.tf עם הצהרה על מיקום המצב של הקצה העורפי של Terraform (בדרך כלל ב-Cloud Storage)
  • קובץ main.tf שמייצר את מודול השירות הזה

כל ספרייה של סביבה (dev, ‏qa, ‏prod) מקבילה לסביבת עבודה מוגדרת ב-Terraform. פריסת גרסה של השירות תתבצע לסביבה הזו. בסביבות העבודה האלה מבודדים משאבים ספציפיים לסביבה בהקשרים שלהם. חשוב להשתמש רק בסביבת העבודה המוגדרת.

לא מומלץ שיהיו כמה סביבות עבודה ב-CLI בסביבה מסוימת, מהסיבות האלה:

  • יכול להיות שתתקשו לבדוק את ההגדרות האישיות בכל סביבת עבודה.
  • שימוש בקצה עורפי משותף אחד לכמה סביבות עבודה לא מומלץ כי הקצה העורפי המשותף הופך לנקודת כשל בודדת, אם הוא משמש להפרדה בין סביבות.
  • אומנם אפשר להשתמש שוב בקוד, אבל קשה יותר לקרוא אותו אם צריך לעבור בהתאם למשתנה הנוכחי של סביבת העבודה (לדוגמה terraform.workspace == "foo" ? this : that).

למידע נוסף, קראו את המאמרים הבאים:

חשיפת משתני הפלט באמצעות שמירת המצב ביעד מרוחק

חשוב לוודא שאתם חושפים פלט שימושי של מופעי מודולים ממודול ברמה הבסיסית.

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

# Project root module
terraform {
  backend "gcs" {
    bucket  = "BUCKET"
  }
}

module "project" {
  source  = "terraform-google-modules/project-factory/google"
  ...
}

output "project_id" {
  value       = module.project.project_id
  description = "The ID of the created project"
}

סביבות ואפליקציות אחרות של Terraform יכולות להתייחס רק למשתני פלט של מודולים ברמה הבסיסית.

כששומרים את הפלט ביעד מרוחק, אפשר להפנות לפלט של המודול ברמה הבסיסית. כדי לאפשר לאפליקציות תלויות אחרות להשתמש בפלט לצורך הגדרות, צריך לוודא שמייצאים ליעד המרוחק נתונים שקשורים לנקודות הקצה (endpoints) של השירות.

# Networks root module
data "terraform_remote_state" "network_project" {
  backend = "gcs"

  config = {
    bucket = "BUCKET"
  }
}

module "vpc" {
  source  = "terraform-google-modules/network/google"
  version = "~> 9.0"

  project_id   = data.terraform_remote_state.network_project.outputs.project_id
  network_name = "vpc-1"
  ...
}

במקרים מסוימים, למשל אם מפעילים מודול משותף מתוך הספריות של הסביבה, צריך לייצא מחדש את כל המודול הצאצא באופן הבא:

output "service" {
  value       = module.service
  description = "The service module outputs"
}

הצמדה לגרסאות משניות של ספקים

במודולים ברמה הבסיסית (root), יש להצהיר על כל ספק ולהצמיד לגרסה משנית שלו. כך אפשר לשדרג באופן אוטומטי לגרסאות תיקון חדשות, ועדיין לשמור על יעד יציב. כדי לשמור על עקביות תוכלו לקרוא לקובץ הגרסאות בשם versions.tf.

terraform {
  required_providers {
    google = {
      source  = "hashicorp/google"
      version = "~> 4.0.0"
    }
  }
}

שמירת המשתנים בקובץ tfvars

למודולים ברמה הבסיסית (root) צריך לספק משתנים באמצעות קובץ מסוג .tfvars. מטעמי עקביות, יש לתת לקובצי המשתנים את השם terraform.tfvars.

אין לציין משתנים באמצעות קבצים חלופיים מסוג var-files או באמצעות האפשרות var='key=val' בשורת הפקודה. האפשרויות בשורת הפקודה הן פתרון זמני וקל לשכוח אותן. שימוש בקובץ להגדרת משתני ברירת המחדל הוא פתרון אמין וצפוי יותר.

הכנסת הקובץ .terraform.lock.hcl למערכת בקרת הגרסאות

במודולים ברמה הבסיסית (root), צריך להכניס את קובץ נעילת התלות .terraform.lock.hcl למערכת בקרת הגרסאות. כך ניתן לעקוב אחרי השינויים בהגדרות הספקים.

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