מעבדה מעשית — 004 HashiCorp Terraform Associate

סקירה כללית

דרישות קדם

שלבים

1. 1.הצמד את Terraform ומשוך שני ספקים שאינם דורשים אישורים

   משאבים:

   • Terraform CLI
   • random provider
   • local provider

   לפני שכל דבר פועל, אנו מצהירים איזו גרסת Terraform אנו מצפים ועל אילו ספקים אנו תלויים. הצמדה היא נושא אהוב בבחינה — תחומי יסודות Terraform ו-זרימת עבודה מרכזית בודקים שאתם מבינים את required_version, את בלוק required_providers, ואת תפקידו של terraform init בהורדת תוספי ספק לתוך .terraform/.

   אנו בוחרים בכוונה ב-random וב-local. אף אחד מהם אינו זקוק להתחברות לענן, כך שהמעבדה כולה נשארת חינמית וניתנת לשחזור, ובכל מקרה הבחינה לעולם אינה שואלת על ענן ספציפי — היא שואלת על Terraform. הטמיעו זאת לקובץ main.tf חדש והריצו terraform init; תראו כיצד Terraform פותר ונועל את שני הספקים לקובץ .terraform.lock.hcl, שהוא עצמו נקודת דיון בתחום היסודות (בצעו commit לקובץ הנעילה כך שכל הפעלה תשתמש בגרסאות תוספים זהות).

   העתק

   terraform {
     required_version = ">= 1.5"
   
     required_providers {
       random = {
         source  = "hashicorp/random"
         version = "~> 3.6"
       }
       local = {
         source  = "hashicorp/local"
         version = "~> 2.5"
       }
     }
   }
   
   # Both providers run locally and need no "provider" configuration
   # block at all - a useful reminder that providers are just plugins.

2. 2.הפעל את זרימת העבודה המרכזית: כתוב משאב, ואז init, plan, apply

   משאבים:

   • random provider
   • local provider

   כעת אנו מתרגלים את ליבת תחום שימוש בזרימת העבודה המרכזית של Terraform (18% מהבחינה). אנו מצהירים על random_pet שממציא שם ידידותי, ולאחר מכן על local_file שכותב את השם הזה לדיסק. המשאב local_file.greeting מפנה אל random_pet.name.id, והפניה זו היא שאומרת ל-Terraform שהקובץ תלוי בחיה — סדר תלות מרומז, אין צורך ב-depends_on.

   הריצו את זרימת העבודה לפי הסדר: terraform plan מראה לכם הבדל של מה שישתנה לפני שכל דבר קורה, ו-terraform apply הופך את זה למציאות ומתעד את התוצאה ב-terraform.tfstate. הריצו terraform apply פעם שנייה מבלי לשנות דבר ותראו No changes — זוהי אידמפוטנטיות, והבחינה אוהבת לשאול מדוע apply שני הוא פעולה ללא שינוי. עם משאב עובד וקובץ מצב טרי ביד, נוכל להתחיל להפוך את התצורה לגמישה.

   העתק

   resource "random_pet" "name" {
     length    = 2
     separator = "-"
   }
   
   resource "local_file" "greeting" {
     filename = "${path.module}/hello.txt"
     content  = "Hello from ${random_pet.name.id}!\n"
   }

3. 3.הפוך אותו לגמיש עם משתנים, locals ותפוקות

   משאבים:

   • Terraform CLI

   ערכים מקודדים קשיח מתאימים להדגמה, אך תחום קריאה, יצירה ושינוי תצורה (19%) מצפה מכם לפרמטריזציה. אנו מוסיפים variable קלט עם type, default, ובלוק validation שדוחה כל דבר מחוץ לסביבות המותרות שלנו — בדיקת תקינות פועלת בזמן התכנון והיא שאלה נפוצה בבחינה. אנו מחשבים מפת locals פעם אחת ומשתמשים בה שוב, ואנו חושפים תוצאות עם בלוקי output כך שתצורות אחרות (ו-terraform output) יוכלו לקרוא אותן.

   שימו לב לשכבות שהבחינה בודקת: variable הוא קלט, locals הוא ערך נגזר/ביניים, ו-output הוא התוצאה המפורסמת. בצעו apply שוב ונסו terraform output pet_name כדי לקרוא ערך יחיד, או terraform output -json כדי לתסרטט מולו. כשהקלטים והפלטים מחוברים, אנו מוכנים להפסיק לכתוב משאב אחד בכל פעם ולייצר קבוצה שלמה.

   העתק

   variable "environment" {
     description = "Deployment environment label."
     type        = string
     default     = "dev"
   
     validation {
       condition     = contains(["dev", "staging", "prod"], var.environment)
       error_message = "environment must be one of: dev, staging, prod."
     }
   }
   
   locals {
     common_tags = {
       environment = var.environment
       managed_by  = "terraform"
     }
   }
   
   output "pet_name" {
     description = "The generated pet name."
     value       = random_pet.name.id
   }
   
   output "tags" {
     value = local.common_tags
   }

4. 4.צור משאבים רבים בבת אחת עם for_each ופונקציות

   משאבים:

   • random provider
   • local provider

   תצורות אמיתיות ממעטות להצהיר על כל דבר בנפרד. כאן אנו מתעמקים בתחום קריאה, יצירה ושינוי תצורה על ידי הנעת יצירת משאבים מאוסף. משתנה set(string) מפרט שירותים לוגיים; for_each מטביע אז random_string אחד ו-local_file אחד לכל שירות, הניתנים לגישה כ-random_string.suffix["api"] וכן הלאה.

   שלב זה מציג גם ביטויים ופונקציות מובנות שהבחינה מצפה שתכירו: each.key עבור האלמנט הנוכחי, אינטרפולציית מחרוזת לבניית שם דלי לכל שירות, ו-jsonencode() להפיכת אובייקט HCL לקובץ JSON בדיסק. אנו משתמשים מחדש ב-var.environment וב-local.common_tags משלב 3 כך שכל קובץ שנוצר נושא מטא-נתונים עקביים. השאלה הבאה המתבקשת — זה נהיה חוזרני, איך אני אורז את זה? — היא בדיוק מה שמודולים עונים עליה.

   העתק

   variable "services" {
     description = "Logical services to generate a config file for."
     type        = set(string)
     default     = ["api", "web", "worker"]
   }
   
   resource "random_string" "suffix" {
     for_each = var.services
   
     length  = 6
     special = false
     upper   = false
   }
   
   resource "local_file" "service_config" {
     for_each = var.services
   
     filename = "${path.module}/config/${each.key}.json"
     content = jsonencode({
       service     = each.key
       environment = var.environment
       bucket      = "${each.key}-${random_string.suffix[each.key].result}"
       tags        = local.common_tags
     })
   }

5. 5.ארזו את החזרתיות למודול לשימוש חוזר

   משאבים:

   • Terraform CLI

   תחום אינטראקציה עם מודולי Terraform רוצה שתחברו מודול, תקראו לו, ותעבירו ערכים פנימה והחוצה. אנו מעבירים את הלוגיקה הספציפית לשירות למודול ילד תחת ./modules/service, מעניקים לו תשומות variable משלו ותפוקה output, ואז קוראים לו מהשורש עם for_each — מופע מודול אחד לכל שירות.

   שני הקבצים שלהלן מראים בבירור את הגבול: מודול הילד אינו יודע דבר על אילו שירותים קיימים (זו העבודה של הקורא באמצעות var.name), והשורש אינו יודע דבר על איך שירות נבנה (זה מקופסל במודול). הריצו terraform init שוב לאחר הוספת מודול — הבחינה בודקת שמקורות מודולים חדשים דורשים אתחול מחדש כדי להתקין אותם. כעת, כשהתצורה שלנו מודולרית, הנושא הגדול האחרון ב-Associate הוא מה ש-Terraform עוקבת אחריו בשקט כל הזמן: מצב (state).

   העתק

   # modules/service/main.tf
   variable "name" {
     type = string
   }
   
   variable "environment" {
     type = string
   }
   
   resource "random_string" "suffix" {
     length  = 6
     special = false
     upper   = false
   }
   
   resource "local_file" "config" {
     filename = "${path.root}/config/${var.name}.json"
     content = jsonencode({
       service     = var.name
       environment = var.environment
       bucket      = "${var.name}-${random_string.suffix.result}"
     })
   }
   
   output "bucket_name" {
     value = "${var.name}-${random_string.suffix.result}"
   }
   
   # main.tf (root) - call the module once per service
   module "service" {
     source   = "./modules/service"
     for_each = var.services
   
     name        = each.key
     environment = var.environment
   }
   
   output "service_buckets" {
     value = { for k, m in module.service : k => m.bucket_name }
   }

6. 6.בדוק ובצע רפקטורינג בטוח למצב מבלי להרוס דבר

   משאבים:

   • Terraform CLI

   תחומי יישום ותחזוקת מצב (19%) ו-שימוש ב-Terraform מחוץ לזרימת העבודה המרכזית (9%) נמצאים שניהם כאן. מצב (State) הוא ספר החשבונות בפורמט JSON הממפה את כתובות התצורה שלכם לאובייקטים אמיתיים; terraform state list מפרט אותו ו-terraform state show <addr> מדפיס רשומה אחת. הבחינה מצפה מכם לדעת ששינוי שם של משאב בתצורה בדרך כלל יהרוס ויצור אותו מחדש — אלא אם תאמרו ל-Terraform שהכתובת זזה.

   בלוק moved עושה בדיוק את זה באופן הצהרתי: שנה את השם של local_file.greeting (משלב 2) ל-local_file.welcome ובלוק moved מעביר את המצב במקום, כך ש-plan מראה העברה, לא הרס ויצירה מחדש. (המקבילה האימפרטיבית היא terraform state mv local_file.greeting local_file.welcome). אנו מציגים גם בלוק import מונחה תצורה — הדרך בגרסה 1.5+ לאמץ אובייקט קיים למצב ללא פקודת ה-CLI הישנה יותר terraform import. עם מצב בשליטה, נותרה יכולת אחת אחרונה לפגוש: הפעלת כל זה מרחוק.

   העתק

   # Renaming a resource? A "moved" block migrates state in place
   # instead of destroying and recreating the object. Replace the
   # Step 2 "greeting" resource with this renamed "welcome" one.
   moved {
     from = local_file.greeting
     to   = local_file.welcome
   }
   
   resource "local_file" "welcome" {
     filename = "${path.module}/hello.txt"
     content  = "Hello from ${random_pet.name.id}!\n"
   }
   
   # Config-driven import (Terraform 1.5+): adopt an object that
   # already exists into state, no "terraform import" CLI command.
   # terraform_data is a built-in resource - nothing to provision.
   import {
     to = terraform_data.tracked
     id = "existing-id"
   }
   
   resource "terraform_data" "tracked" {}

7. 7.כוונו את התצורה ל-HCP Terraform עבור הפעלות מרוחקות

   משאבים:

   • HCP Terraform

   התחום האחרון, הבנת יכולות HCP Terraform (5%), משלים את הבחינה. בלוק cloud יחיד בתוך terraform {} מחליף ביצוע מקומי ב-HCP Terraform: המצב (state) חי מרחוק וננעל במהלך הפעלות, terraform plan/apply מתבצעים על רצי HashiCorp, ותפוקת ההרצה (בתוספת תוכנית שמורה) מופיעה בממשק המשתמש האינטרנטי. זהו גם המקום שבו הבחינה מציגה ניגוד בין תכונות HCP Terraform — מצב מרוחק, היסטוריית הרצות, אכיפת מדיניות עם Sentinel/OPA, ורישום מודולים פרטי — לבין זרימת העבודה המקומית הטהורה שהשתמשנו בה בשלבים 1–6.

   החליפו את my-org בארגון שלכם, הריצו terraform login פעם אחת כדי לאחסן אסימון API, ולאחר מכן terraform init כדי להעביר מצב לסביבת העבודה המרוחקת. כל מה שכתבתם במעבדה זו פועל כעת ללא שינוי — רק היכן הוא פועל השתנה. נסיעה הלוך ושוב זו, מקובץ main.tf חשוף לסביבת עבודה מגובה מרחוק, היא כל מסלול ה-Associate בישיבה אחת.

   העתק

   terraform {
     cloud {
       organization = "my-org"
   
       workspaces {
         name = "terraform-associate-lab"
       }
     }
   }
   
   # Run once to authenticate, then re-init to migrate state:
   #   terraform login
   #   terraform init

ניקוי משאבים