נבדק לאחרונה: מאי 2026
מדריך מקוצר ובר-סריקה לדפוסי ארכיטקטורה שמבחן 004 בודק. קראו מלמעלה למטה, או דלגו לסעיף.
צוות מבצע פעולות ידניות במסופי ענן; אף אחד לא יודע איך הייצור אמור היה להיראות.
אמץ IaC. התצורות נשמרות בקבצים מנוהלי גרסאות - הקבצים הם מקור האמת הסמכותי, לא קונסולת הענן.
למה: תיעוד ביקורת, ביקורת עמיתים, יכולת חזרה לאחור ושכפול, כולם נובעים מבקרת גרסאות. הקצאה ידנית אינה כוללת אף אחד מאלה.
בחר בין תיאור המצב הסופי הרצוי לבין כתיבת סקריפט של השלבים להשגתו.
Terraform היא דקלרטיבית. אתה מתאר את היעד; Terraform מבין את קריאות ה-API. Ansible, Bash scripts, custom SDKs הן אימפרטיביות.
למה: תצורות דקלרטיביות הן אידמפוטנטיות ומתכנסות ללא תלות במצב ההתחלתי. סקריפטים אימפרטיביים חייבים לדון בכל מעבר.
מהנדס רוצה שאותו `terraform apply` יהיה בטוח להפעלה חוזרת מבלי להכפיל משאבים.
אידמפוטנטי על פי תכנון. יישום אותה תצורה שוב ושוב מתכנס לאותו מצב - ללא כפילויות, ללא סחף.
זיהוי מתי המציאות חרגה ממה שהתצורה קובעת (מישהו לחץ בקונסולה).
`terraform plan -refresh-only` קורא את מצב הענן הנוכחי ומדווח על הבדלים מול ה-state מבלי להציע שינויים.
הבחנה בין הקצאה ראשונית לפעולות מתמשכות.
יום 0 = תכנון ועיצוב. יום 1 = הקצאה ראשונית (apply ראשון). יום 2 = פעולות מתמשכות: תיקון, סקאלינג, סיבוב תעודות, תיקון סחף.
למה: רוב העבודה בפרודקשן היא יום 2. כלי IaC חייבים לתמוך באיטרציה, לא רק בפריסה ראשונה.
הפחתת הסיכון של סחף בקונסולה; דרישה שכל שינויי התשתית יעברו בדיקה.
GitOps עם IaC: Git הוא מקור האמת, בקשות משיכה (PRs) מפעילות תכנונים, מיזוגים מפעילים יישומים. חסימת גישה ישירה לקונסולה באמצעות SCP/IAM.
עומס עבודה משתרע על פני AWS ו-GCP; הצוות רוצה כלי אחד, זרימת עבודה אחת.
Terraform עם מספר ספקים בתצורה אחת: `hashicorp/aws` + `hashicorp/google`. פלטים מספק אחד מזינים קלטים של ספק אחר.
למה: ליבה אגנוסטית לספק; SDKs ספציפיים לענן חיים בספקים הניתנים להוספה. CloudFormation/ARM הם חד-ענן.
שלבי מחזור חיים סטנדרטיים של Terraform.
`init` (הורדת ספקים + backend) ← `plan` (תצוגה מקדימה) ← `apply` (ביצוע) ← `destroy` (הסרה). `plan` הוא לקריאה בלבד ובטוח.
מדוע Terraform זקוק לקובץ state במקום לשאול את הענן בכל הרצה?
State ממפה כתובות תצורה (`aws_instance.web`) למזהי משאבים אמיתיים, עוקב אחר תלויות, ומטמון מטא-דאטה. בלעדיו, Terraform לא יכול לדעת אילו משאבי ענן הוא מנהל לעומת אילו נוצרו במקום אחר.
בחר בין CLI קוד פתוח לבין HCP Terraform.
צוות יחיד/קטן/ללא אכיפת מדיניות ← OSS CLI עם backend מרוחק. מספר צוותים / מדיניות Sentinel/OPA / הרצות מונחות VCS / אישורים דינמיים ← HCP Terraform.
למה: שניהם מריצים את אותו בינארי Terraform; HCP מוסיף שיתוף פעולה, ממשל ותשתית מריץ מרוחק.
הקצאת VMs לעומת הגדרת תוכנה בתוכם.
Terraform מקצה משאבי ענן (VMs, רשתות, IAM). Ansible/Chef/Puppet מגדירים תוכנה בתוך ה-VMs. הם משלימים, לא מתחרים.
חברה המשתמשת ב-AWS בלבד דנה בין CloudFormation ל-Terraform.
ל-CloudFormation אינטגרציה הדוקה יותר עם AWS, rollback מובנה ואפס ניהול קבצי state. Terraform מנצח במולטי-קלאוד, מערכת אקולוגית מודולים גדולה יותר וארגונומיית HCL. בחר CFN אם AWS בלבד ו-rollback חשוב ביותר; אחרת Terraform.
קביעת מקור וגרסת ספק עבור התקנות ניתנות לשחזור.
הצהר ב-`terraform { required_providers { aws = { source = "hashicorp/aws", version = "~> 5.0" } } }`.
למה: ללא `required_providers` מפורש, Terraform מניח namespaces של רשומות מדור קודם ועשוי לבחור גרסאות לא תואמות.
לתצורה יש `required_providers` עבור AWS אך אין לה בלוק `provider "aws"`.
Terraform יוצר תצורת ספק ריקה כברירת מחדל. ספק ה-AWS קורא אז את `AWS_ACCESS_KEY_ID`/`AWS_PROFILE`/IMDS בסדר הקדימות הסטנדרטי שלו.
למה: בלוק `provider` מפורש הוא אופציונלי; הוא נדרש רק כדי לעקוף ברירות מחדל או לכנות מופעים מרובים.
החלט באיזה אופרטור של מגבלת גרסה להשתמש.
`~> 5.0` מאפשר `>= 5.0, < 6.0` (כל 5.x). `~> 5.0.1` מאפשר `>= 5.0.1, < 5.1.0` (רק עדכוני patch). `>= 5.0` ללא גבול עליון. `= 5.2.0` מדויק. `!= 5.3.0` אי הכללה.
למה: האופרטור הפסימי `~>` מאפשר רק לרכיב הגרסה הימני ביותר לגדול.
מה `terraform init` עושה בפועל?
מוריד ספקים לפי `required_providers`, מאתחל את ה-backend, מוריד מקורות מודולים, וכותב `.terraform/` בתוספת `.terraform.lock.hcl`. נדרש לפני `plan` או `apply`.
קובץ `.terraform.lock.hcl` הופיע לאחר `init`. האם לבצע לו commit או gitignore?
בצע לו commit. קובץ הנעילה מתעד גרסאות ספק מדויקות + סכומי בדיקה קריפטוגרפיים. מבטיח שכל משתף פעולה ורץ CI יתקינו ספקים זהים.
למה: בלעדיו, `terraform init` עשוי לבחור גרסה תואמת חדשה יותר במכונה אחרת, מה שיכול להציג הבדלים מפתיעים.
סטנדרטיזציה של רווחים, יישור והזחה בכל קבצי `.tf`.
`terraform fmt` משכתב קבצי `.tf` במקום לסגנון קנוני. הפעל ב-pre-commit hooks וב-CI.
תפוס שגיאות תחביר ואי התאמות סוגים מבלי לפנות לממשקי API של הענן.
`terraform validate` בודק תחביר HCL, עקביות סוגים, ארגומנטים נדרשים והפניות פנימיות. מקומי בלבד, ללא צורך באימות ספק.
למה: לא תופס בעיות בצד הספק (אימות, משאבים חסרים) - אלה מופיעות רק ב-`plan`.
ה-CI מריץ `terraform init` שוב ושוב על פני פרויקטים רבים, כשכל אחד מהם מוריד את אותם ספקים מאפס.
הגדר `TF_PLUGIN_CACHE_DIR` (או `plugin_cache_dir` בקובץ התצורה של ה-CLI). ספקים מורדים פעם אחת ומקושרים (symlinked) לתוך ספריות `.terraform/` ספציפיות לכל פרויקט.
כתובות מקור של ספקים עוקבות אחר איזה פורמט?
`<hostname>/<namespace>/<type>` - לדוגמה `registry.terraform.io/hashicorp/aws`. שם המארח מושמט כברירת מחדל ל-Terraform Registry הציבורי. Namespace = ספק. Type = שם הספק.
מנע ממשתפי פעולה להפעיל גרסת CLI של Terraform שאינה תואמת.
`terraform { required_version = ">= 1.5, < 2.0" }`. ה-CLI מסרב לפעול אם הגרסה הרצה אינה תואמת.
בחר אימות ספק עבור רץ CI/CD.
הטוב ביותר: אישורים דינמיים קצרי חיים (OIDC trust ל-AWS/Azure/GCP, HCP Terraform dynamic provider creds). מקובל: משתני סביבה (`AWS_ACCESS_KEY_ID`). הימנע מ: אישורי בלוק `provider` מקודדים קשה.
למה: סודות סטטיים ארוכי טווח בתצורה הם הגורם העיקרי לאירועי דליפת אישורים.
היכן הגדרות ברמה העליונה ממוקמות?
בלוק `terraform { ... }` מכיל `required_version`, `required_providers`, `backend`, `cloud`, ו-experiments. מספר בלוקי `terraform` על פני קבצים מתמזגים.
משאב קיים ב-state אך לא אמור להיות מנוהל על ידי Terraform יותר; משאב הענן חייב להמשיך לפעול.
`terraform state rm <addr>`. מסיר מה-state מבלי להרוס את משאב הענן.
שינוי שם של משאב או העברתו למודול; רוצה להימנע מהרס/יצירה מחדש.
`terraform state mv <old> <new>`. מעדכן את מיפוי ה-state מבלי לגעת במשאבי הענן.
למה: ב-Terraform 1.1 ואילך, העדף את הבלוק `moved` ב-HCL - הוא ניתן לביקורת, מנוהל גרסאות, ועובד בתוכניות PR.
כתובת ה-URL של רישום ספק פנימי השתנתה; ה-state הקיים עדיין מפנה לכתובת המקור הישנה.
`terraform state replace-provider <old-source> <new-source>`. משכתב הפניות ספק ב-state.
ה-apply קרס באמצע הריצה; נעילת DynamoDB תקועה ומהנדסים אחרים חסומים.
`terraform force-unlock <LOCK_ID>` (מזהה הנעילה מופיע בהודעת השגיאה). ודא שאף אחד אחר לא רץ לפני פתיחת הנעילה.
למה: נעילות אינן משתחררות אוטומטית בעת קריסה מכיוון ששלב הניקוי מעולם לא בוצע.
דלי S3 קיימים שנוצרו ידנית צריכים להיות מנוהלים על ידי Terraform ללא יצירה מחדש.
כתוב את בלוק המשאב, ואז `terraform import aws_s3_bucket.legacy legacy-bucket-name`. ה-state מתעד כעת את הדלי הקיים; תוכניות עוקבות מציגות רק סחף.
צריך לייבא משאבים רבים באופן שניתן לשחזור דרך CI ולא באמצעות פקודות CLI אד-הוק.
השתמש בבלוק `import` (Terraform 1.5+): `import { to = aws_s3_bucket.legacy, id = "legacy-bucket-name" }`. הייבוא מתרחש במהלך `apply`, מנוהל גרסאות ועובד בפלט ה-plan.
ניפוי שגיאת ספק מסתורית; זקוק למעקבי HTTP מלאים.
`TF_LOG=TRACE` (מפורט ביותר). `TF_LOG_PATH=./tf.log` כותב לקובץ. רמות אחרות: DEBUG, INFO, WARN, ERROR.
בדוק ביטוי כמו `merge()` או `cidrsubnet()` מול המצב הנוכחי מבלי לבצע apply.
`terraform console` פותח REPL אינטראקטיבי עם התצורה וה-state הנוכחיים ב-scope. שימושי ליצירת אבות טיפוס עבור locals ו-outputs.
הצג את DAG התלויות של תצורה מורכבת.
`terraform graph | dot -Tsvg > graph.svg` מייצר ויזואליזציית Graphviz של תלויות משאבים.
קרא פלט Terraform מסקריפט CI.
`terraform output -json <name>` פולט JSON בטוח לפירוס `jq`. `terraform output` רגיל מעוצב לקריאת אדם ואינו בטוח לסקריפטים.
כפה על משאב בודד להיווצר מחדש ב-apply הבא.
`terraform apply -replace=aws_instance.web` (Terraform 1.x). הפקודה `terraform taint` המורשת הוצאה משימוש.
למה: `-replace` ניתן לביקורת בפלט ה-plan; `taint` שינה את ה-state בשקט לפני ה-plan הבא.
בדוק מה מתועד כעת ב-state.
`terraform state list` מציג את כל כתובות המשאבים. `terraform state show <addr>` מציג תכונות עבור משאב אחד. עבור משאבים עם אינדקס השתמש במרכאות: `terraform state show 'aws_instance.web[0]'`.
בחר מקור מודול.
נתיב מקומי → `./modules/vpc`. רישום ציבורי → `terraform-aws-modules/vpc/aws`. Git → `git::https://github.com/org/repo.git//path?ref=v1.0`. S3/HTTP/Mercurial נתמכים גם.
קבע מודול רישום כך שיאפשר רק עדכוני patch.
`version = "~> 3.5.2"` מאפשר `>= 3.5.2, < 3.6.0`. לסבילות לעדכוני minor, השתמש ב-`~> 3.0` (כל 3.x). מודולי נתיב מקומי אינם תומכים ב-`version`.
מודולים פנימיים בלבד עם נראות כלל-ארגונית.
HCP Terraform Private Module Registry. כתובת: `app.terraform.io/<org>/<name>/<provider>`. גרסאות מזוהות מתגי Git העוקבים אחר semver (`v1.2.0`).
גם הרישום הציבורי וגם הרישום הפרטי של HCP Terraform מזהים גרסאות מודולים באמצעות איזה מנגנון?
תגי Git העוקבים אחר גרסאות סמנטיות (`v1.2.0` או `1.2.0`). דחוף תג חדש ← גרסה חדשה זמינה.
חשוף ARN של דלי שנוצר לתצורה הקוראת.
בתוך המודול: `output "bucket_arn" { value = aws_s3_bucket.this.arn }`. הקורא קורא אותו כ-`module.<name>.bucket_arn`.
הגדר פרמטרים למודול כך שהקוראים יוכלו לספק CIDR, שם, תגים.
בלוקי `variable` בשורש המודול מגדירים קלטים. הקוראים מעבירים אותם inline: `module "vpc" { source = "...", cidr = "10.0.0.0/16" }`.
מודול מקבל סיסמת מסד נתונים כקלט; הערך לעולם לא אמור להופיע בפלט ה-CLI.
סמן את המשתנה `sensitive = true`. פלט apply/plan מציג `(sensitive value)`. הערה: עדיין מאוחסן ב-plaintext ב-state.
בנה מודול "פלטפורמה" שקורא באופן פנימי למודולי VPC + EKS + RDS.
מודול יכול לקרוא למודולים אחרים. חבר פלטים מאחד כקלטים לבא אחריו: `eks_subnet_ids = module.vpc.private_subnet_ids`.
צור N מופעים של אותו מודול עם קלטים שונים (לדוגמה, אחד לכל אזור).
`module "regional" { for_each = toset(["us-east-1", "eu-west-1"]), source = "...", region = each.key }`. הפניה באמצעות `module.regional["us-east-1"].output_name`.
מודול זקוק לספק בעל alias (לדוגמה, עבור אזור שאינו ברירת מחדל).
הקורא מעביר את הבלוק `providers = { aws = aws.us_west }` בקריאת המודול. המודול מצהיר על `configuration_aliases = [aws.us_west]` ב-`required_providers`.
כתובת מודול רישום ציבורי.
`<NAMESPACE>/<NAME>/<PROVIDER>` - לדוגמה `terraform-aws-modules/vpc/aws`. תגי Git מניעים גרסאות.
שימוש חוזר באותו מודול על פני dev/staging/prod.
שתי תבניות: (1) Workspaces עם תצורת שורש אחת + `*.tfvars` לכל workspace. (2) תצורות שורש לכל סביבה (`envs/dev/main.tf`, `envs/prod/main.tf`) שכל אחת מהן קוראת למודולים משותפים. תבנית 2 נפוצה יותר עבור בידוד מרובה צוותים.
ודא ש-CI מיישם בדיוק את מה שנבדק ב-plan, ללא סחף בין השלבים.
`terraform plan -out=tfplan` שומר את ה-plan. ואז `terraform apply tfplan` מיישם את ה-plan המדויק הזה. סירוב לתכנן מחדש מבטל סיכון של זמן בדיקה/זמן שימוש.
פענוח סמלי פלט ה-plan: `+`, `-`, `~`, `-/+`, `<=`.
`+` יצירה. `-` הרס. `~` עדכון במקום. `-/+` הרס ואז יצירה (החלפה). `<=` קריאה (data source). סמל ההחלפה פירושו שתכונה `forces replacement` השתנתה.
תקן במהירות משאב אחד שבור מבלי לגעת בשאר התצורה.
`terraform apply -target=aws_instance.web`. השתמש במשורה - עוקף מעקב תלויות ועלול להשאיר את ה-state לא עקבי. תעד מדוע כל `-target` שימש.
למה: HashiCorp מציינת במפורש ש-`-target` מיועד לפתרון בעיות חריג, לא לזרימת עבודה רגילה.
כפה על משאב ספציפי להיווצר מחדש.
`terraform apply -replace=aws_instance.web`. מחליף את זרימת העבודה המיושנת `terraform taint`.
הרוס הכל בתצורה הנוכחית.
`terraform destroy` (או `terraform apply -destroy`). מתכנן את ההיפוך של התצורה. דורש אישור אלא אם כן `-auto-approve`.
הרוס משאב אחד מבלי להשפיע על אחרים.
`terraform destroy -target=aws_instance.web`. אותן אזהרות לגבי `-target` כמו ב-apply - השתמש במשורה.
זיהוי סחף מבלי להציע שינויים.
`terraform plan -refresh-only`. מרענן את ה-state ממשאבים אמיתיים ומדווח על הבדלים אך אינו מייצר תוכנית לשינוי משאבים.
למה: מחליף את הפקודה העצמאית המיושנת `terraform refresh`.
משאב A חייב להתקיים לפני משאב B, אך B אינו מפנה לתכונות של A.
הוסף `depends_on = [resource_a.name]` ל-B. השתמש רק כאשר הפניות תכונה מרומזות אינן יכולות לבטא את התלות (לדוגמה, מדיניות IAM חייבת להתפשט לפני ש-EC2 משתמש בה).
החלף משאב ללא השבתה.
`lifecycle { create_before_destroy = true }`. Terraform יוצר את המשאב החדש תחילה, מפנה הפניות, ואז הורס את הישן.
למה: ברירת המחדל היא destroy-then-create, מה שגורם להשבתה. הערה: משאבים תלויים חייבים גם לתמוך בשינוי.
מניעת הרס מקרי של מסד הנתונים בפרודקשן באמצעות `terraform destroy`.
`lifecycle { prevent_destroy = true }`. גורם ל-`terraform plan` להיכשל אם הרס מוצע עבור משאב זה.
למה: קו הגנה אחרון - אינו מגן מפני `terraform state rm` ואחריו destroy.
היישום קובע תג בזמן ריצה ש-Terraform ממשיך לבטל.
`lifecycle { ignore_changes = [tags["LastDeployed"]] }`. Terraform מתעלם מסחף בתכונות אלו.
החלף מופע EC2 בכל פעם שתבנית הפעלה קשורה משתנה (מבלי לשנות את ה-EC2 ישירות).
`lifecycle { replace_triggered_by = [aws_launch_template.web.latest_version] }` (Terraform 1.2+). המופע מוחלף כאשר כל ערך רשום משתנה.
צינור CI/CD מיישם לאחר עבודת plan מוצלחת; אין אדם ליד המקלדת.
`terraform apply -auto-approve` מדלג על אישור אינטראקטיבי. שלב עם קובץ plan שמור (`terraform apply tfplan`) כדי להפוך את ה-CI לדטרמיניסטי.
ספק הענן מפעיל הגבלת קצב על Terraform; יצירות משאבים רבות נכשלות לסירוגין.
`terraform apply -parallelism=5` (ברירת מחדל 10) מגביל פעולות משאבים מקבילות.
לשני משאבים אין תלות זה בזה.
Terraform יוצר אותם במקביל. ה-DAG אוכף רצף רק לאורך קצוות התייחסות.
למה: משאבים באותה עומק DAG רצים במקביל עד ל-`-parallelism`.
משתנה שהוגדר ב-`terraform.tfvars`, משתנה סביבה `TF_VAR_region`, וגם דגל CLI `var=region=...`.
הגבוה ביותר מנצח: CLI `-var` / `-var-file` > `*.auto.tfvars` (סדר לקסיקלי) > `terraform.tfvars` > `TF_VAR_*` env > ברירת מחדל משתנה.
העברת ערכי משתנים ספציפיים לסביבה מבלי לבדוק סודות לתוך Git.
`terraform apply -var-file=prod.tfvars`. קבצי `*.auto.tfvars` נטענים אוטומטית. `terraform.tfvars` נטען גם הוא אוטומטית.
שינוי שם/נתיב של משאב ב-HCL ללא הרס/יצירה מחדש.
`moved { from = aws_instance.old_web; to = aws_instance.new_web }` (Terraform 1.1+). ניתן לביקורת ב-PR plan; מחליף `terraform state mv` אד-הוק.
למה: שוכן ב-HCL, מנוהל גרסאות, אידמפוטנטי בין משתפי פעולה. `state mv` הוא אפקט צד CLI חד-פעמי.
הסר משאב מהתצורה מבלי להרוס אותו.
`removed { from = aws_instance.legacy; lifecycle { destroy = false } }` (Terraform 1.7+). מחליף `terraform state rm` אד-הוק. הגדר `destroy = true` כדי להרוס גם.
ה-CI צריך לדעת אם ל-plan יש שינויים מבלי לנתח טקסט.
`terraform plan -detailed-exitcode`. 0 = ללא שינויים, 1 = שגיאה, 2 = שינויים קיימים. מניע עבודות PR "plan-only".
מה ה-state מכיל בפועל?
מיפוי כתובת משאב ← מזהה משאב ענן, תמונות מצב של תכונות, מטא-דאטה של גרף תלויות, והפניות למודולים/ספקים. משמש לתכנון diffs וזיהוי סחף.
מהנדס יחיד מפתח אב טיפוס מקומי - האם state מקומי בסדר?
כן לעבודת זריקה חד פעמית סולו. Terraform כותב `terraform.tfstate` ליד התצורה. עבור ל-backend מרוחק ברגע שמעורב אדם שני, רץ CI, או סביבת פרודקשן.
צוות זקוק ל-state משותף בין מהנדסים, עם נעילה + ניהול גרסאות, מתארח ב-AWS.
backend מסוג S3. הגדר `bucket`, `key`, `region`. הוסף `dynamodb_table` לנעילת state. אפשר ניהול גרסאות דלי + הצפנת שרת SSE-KMS.
למה: S3 + DynamoDB הוא ה-backend המרוחק הקנוני המתארח ב-AWS. ניהול גרסאות מתאושש ממצב state פגום או שנכתב בטעות.
state משותף מתארח ב-Azure ללא אישורים סטטיים ב-CI.
סוג Backend `azurerm`. הגדר `use_msi = true` (Managed Identity) או `use_oidc = true` כך שהרץ יאומת באמצעות זהותו. Native blob lease מטפל בנעילה.
state משותף מתארח ב-GCP עם ניהול גרסאות אובייקטים.
סוג Backend `gcs`. הגדר `bucket` + `prefix`. ל-GCS יש יצירות אובייקטים מובנות (ניהול גרסאות); נעילה באמצעות GCS object lock.
שני מהנדסים מריצים apply בו זמנית מול אותו state מגובה S3.
טבלת נעילה של DynamoDB מונעת כתיבה מקבילה. הראשון רוכש את הנעילה, השני רואה שגיאת `state lock failed` וחייב לחכות או לבצע `force-unlock` אם תקוע.
למה: ללא DynamoDB, applies מקבילים עלולים לפגום בקובץ ה-state של S3.
HCP Terraform - האם עלי להגדיר DynamoDB?
לא. HCP Terraform מטפל ב-state, נעילה והצפנה באופן טבעי. אתה רק מצהיר על `cloud { ... }` במקום backend.
העברה מ-state מקומי ל-backend של S3.
הוסף את הבלוק `backend "s3"`. הפעל `terraform init -migrate-state`. Terraform מעתיק את ה-state המקומי ל-S3 ומבקש אישור.
תצורת ה-backend השתנתה (לדוגמה, דלי חדש) אך אינך רוצה להעביר state קיים.
`terraform init -reconfigure`. מאתחל מחדש את ה-backend ומתעלם מהמטמון המקומי הקיים. השתמש כאשר אתה מתחיל בכוונה מחדש.
ניהול dev / staging / prod עם תצורת שורש אחת.
Workspaces - `terraform workspace new staging`, `terraform workspace select prod`. לכל אחד קובץ state משלו. התייחסות באמצעות `terraform.workspace` ב-HCL.
למה: אופציה קלה. לבידוד אמיתי (IAM שונה, חשבונות נפרדים), העדף תצורות שורש לכל סביבה.
היכן ה-backend המקומי מאחסן את ה-state של ה-workspace?
`default` workspace ← `terraform.tfstate` בשורש הפרויקט. Workspaces אחרים ← `terraform.tfstate.d/<NAME>/terraform.tfstate`.
הפעל `terraform workspace select prod` בזמן שמשאבי staging קיימים.
משאבי Staging אינם מושפעים. החלפת workspaces רק משנה איזה קובץ state Terraform קורא בהמשך - זהו שינוי מצביע מקומי.
ראה workspaces זמינים ואת הפעיל.
`terraform workspace list` (כוכבית מסמנת את הנוכחי). `terraform workspace show` מדפיס את השם הנוכחי בלבד.
צוות האבטחה שואל כיצד Terraform מטפל בסיסמאות RDS ב-state.
ערכים רגישים מאוחסנים **בטקסט רגיל** ב-state. אמצעי הפחתה: הצפן את ה-backend במנוחה (S3 SSE-KMS, HCP native), הגבל גישת IAM לדלי ה-state, והימנע מהכנסת סודות ל-Terraform במידת האפשר.
למה: הדגל `sensitive = true` מסתיר ערכים רק מפלט ה-CLI, לא מה-state.
תאימות דורשת הצפנה במנוחה (encryption-at-rest) ב-state.
S3: אפשר SSE-KMS בדלי. Azure: הצפנת חשבון אחסון (מופעלת כברירת מחדל). GCS: מפתחות הצפנה מנוהלים על ידי לקוח. HCP Terraform: מוצפן באופן טבעי במנוחה.
מהנדס הפעיל בטעות `terraform destroy` נגד פרודקשן. ה-state כעת ריק.
שחזר את הגרסה הקודמת של קובץ ה-state מניהול גרסאות S3, ואז הפעל `terraform plan` כדי לראות מה Terraform חושב כעת שצריך ליצור/לייבא. שלב עם שחזור צד ענן (תמונות מצב, `aws backup`) עבור המשאבים שנהרסו.
קובץ ה-state נראה שגוי; מתפתה לערוך אותו ישירות.
אל תעשה זאת. השתמש בפקודות המשנה `terraform state` (`mv`, `rm`, `replace-provider`, `pull`, `push`). עריכות JSON ידניות מדלגות על בדיקות תקינות ומשחיתות את המקור.
בדוק JSON state מרוחק גולמי, או דחוף קובץ state ששוחזר.
`terraform state pull` כותב את ה-state המרוחק הנוכחי ל-stdout. `terraform state push <file>` דורס את המרוחק עם הקובץ הנתון. Push הוא הרסני - גבה תחילה.
העברת אסימון API זמני דרך Terraform מבלי שהוא ינחת ב-state.
סמן את המשתנה `ephemeral = true` (Terraform 1.10+). ערכים זמניים לעולם אינם נשמרים ב-state או בקבצי plan. כדי לייצא דרך פלט מודול, סמן גם את הפלט `ephemeral = true`.
למה: `sensitive` מוסתר ב-CLI אך מאוחסן ב-state בטקסט רגיל. `ephemeral` באמת לעולם אינו מאוחסן.
ההבדל בין ארגומנט `sensitive` לארגומנט write-only (לדוגמה, `password_wo`).
`sensitive` מאוחסן ב-state בטקסט רגיל, רק מוצפן ב-CLI. Write-only **לעולם** אינו מאוחסן ב-state. כדי לזהות שינויים בתכונות write-only, Terraform משתמש בשדה גרסה נלווה (לדוגמה, `password_wo_version`).
הצג אלמנט אחד של משאב `count` ב-state.
צטט את הכתובת: `terraform state show 'aws_instance.web[0]'`. ללא מרכאות, ה-shell עשוי לפרש את הסוגריים.
צוותים שונים צריכים לפעול באופן עצמאי מבלי לדרוס זה את ה-state של זה.
קובץ state אחד לכל צוות (או לכל סביבה לכל צוות). backends/buckets נפרדים. השתמש במקור נתונים `terraform_remote_state` כדי לקרוא state אחר בגישת קריאה בלבד.
צוות הרשת מנהל VPC; צוות היישומים זקוק למזהה ה-VPC.
`data "terraform_remote_state" "network" { backend = "s3"; config = { bucket = "...", key = "network/terraform.tfstate" } }`. הפניות לפלטים כ-`data.terraform_remote_state.network.outputs.vpc_id`.
למה: קריאה בלבד - ה-state של צוות הרשת אינו נעול או משתנה.
תצורה שנכתבה מול Terraform 0.13; רוצה להשתמש ב-1.x.
קבצי State הם forward-compatible: 1.x קורא state של 0.13. HashiCorp ממליצה על שדרוגים מצטברים (0.13 ← 0.14 ← … ← 1.x) והרצת כל גרסה מול ה-state.
מישהו שינה קבוצת אבטחה דרך הקונסולה; רוצה ש-Terraform יאשר מחדש או יקבל את המצב החדש.
אישור מחדש: `terraform apply` - Terraform חוזר לתצורה. קבלה: עדכן את ה-HCL כדי להתאים למציאות, ואז בצע apply (אין diff). זיהוי ראשוני באמצעות `terraform plan -refresh-only`.
הקלדה חזקה של משתנה.
פרימיטיבים: `string`, `number`, `bool`. אוספים: `list(<type>)`, `set(<type>)`, `map(<type>)`. מבניים: `object({...})`, `tuple([...])`. השתמש ב-`any` רק כאשר פולימורפי באמת.
הגבלת `environment` ל-dev/staging/prod.
`variable "environment" { validation { condition = contains(["dev","staging","prod"], var.environment); error_message = "..." } }`. מותרים מספר בלוקי `validation`; כולם חייבים לעבור.
הוצאת סיסמת מסד נתונים מבלי שהיא תופיע ב-`terraform output`.
`output "db_password" { value = ...; sensitive = true }`. ה-CLI מציג `(sensitive value)`. עדיין קריא באמצעות `terraform output db_password` או `-json` (בכוונה - עבור סקריפטים).
חשב ערך פעם אחת ורב השתמש בו על פני משאבים רבים.
`locals { common_tags = merge(var.tags, { Project = var.project }) }`. הפניה כ-`local.common_tags`. לא ניתן לעקוף מבחוץ למודול.
חפש AMI קיים מבלי לנהל אותו.
`data "aws_ami" "ubuntu" { most_recent = true; filter { ... } }`. קריאה בלבד. תכונות הפניה כ-`data.aws_ami.ubuntu.id`.
צור N משאבים דומים - בחר `count` או `for_each`.
`for_each` (עם map או set) כאשר לפריטים יש זהות יציבה (שמות אזורים, מפתחות סביבה). `count` עבור "אני צריך N עותקים, הסדר לא משנה, הזהות היא רק אינדקס". הוספה/הסרה באמצע `count` גורמת להרס/יצירה מחדש; `for_each` שומרת על זהות.
צור משאב אחד לכל פריט ברשימת מחרוזות.
`for_each = toset(["a", "b", "c"])`. `each.key` ו-`each.value` שניהם נותנים את המחרוזת. עבור מפות: `for_each = var.users` - `each.key` = מפתח מפה, `each.value` = ערך מפה.
יצירת מספר משתנה של בלוקים מקוננים (לדוגמה, כללי ingress).
`dynamic "ingress" { for_each = var.rules; content { from_port = ingress.value.from; ... } }`. הארגומנט `iterator` יכול לשנות את שם האיטרטור במידת הצורך.
קבל רשימה של תכונות על פני כל המופעים של משאב `count`.
`aws_instance.web[*].id` מחזיר רשימת מזהים. עובד עם `count` ו-`for_each` (אבל `for_each` מייצר מפה לא מסודרת, אז `values(aws_instance.web)[*].id`).
הגדר ערך בהתבסס על תנאי.
תנאי משולש: `var.is_prod ? 5 : 1`. שני הענפים חייבים לייצר את אותו סוג.
שלב שתי מפות; ערכי המפה השנייה מנצחים בהתנגשות מפתחות.
`merge(local.defaults, local.overrides)`. המפה הימנית ביותר מנצחת. שימושי לקומפוזיציית תגים.
קרא ערך מפה עם ברירת מחדל אם המפתח חסר.
`lookup(var.config, "region", "us-east-1")`. מחזיר את ברירת המחדל כאשר המפתח אינו קיים. עבור מבנים אופציונליים עמוקים, העדף את ה-`try()` האופציונלי.
מזג רשימות מקוננות לרשימה שטוחה.
`flatten([["a","b"], ["c"], [["d","e"]]])` → `["a","b","c","d","e"]`. משטח רשימות באופן רקורסיבי; שומר על הסדר.
הטמעת מפת Terraform למסמך מדיניות IAM.
`jsonencode({Version = "2012-10-17", Statement = [...]})`. מייצר מחרוזת JSON. הפוך: `jsondecode()`.
רנדר סקריפט user-data מבוסס תבנית עם ערכים ממשתנים.
`templatefile("init.sh.tpl", { region = var.region, env = var.env })`. התבנית משתמשת בתחביר `${region}`. חלופה חדשה יותר לרינדור סטטי: `file()` + `format()`.
חתוך CIDRs של subnet מתוך טווח VPC.
`cidrsubnet("10.0.0.0/16", 8, 0)` → `10.0.0.0/24`. ארגומנט ראשון = הורה, שני = סיביות להרחבה, שלישי = מספר subnet.
קרא ערך שאולי לא קיים; חזור לברירת מחדל.
`try(yamldecode(file("config.yaml")), { defaults = true })`. מעריך משמאל לימין; מחזיר את הביטוי הראשון שאינו גורם לשגיאה.
בצע איטרציה על קבצים התואמים ל-glob.
`fileset(path.module, "configs/*.json")` מחזיר סט של נתיבים. שלב עם `for_each` כדי לנהל משאב אחד לכל קובץ.
אותו ספק בשני אזורים (לדוגמה, AWS us-east-1 + us-west-2).
שני בלוקי `provider "aws" { alias = "..." }`. משאבים בוחרים באמצעות `provider = aws.us_west`. מודולים מקבלים aliases באמצעות `configuration_aliases`.
הפעל פקודת shell על VM שנוצר לאחרונה.
`remote-exec` provisioner בתוך משאב. כלי מוצא אחרון - העדף cloud-init, user data, או configuration management. Provisioners אינם מתועדים ב-state ואינם רצים שוב בעת סחף.
הפעל פקודה שאינה תואמת למשאב ענן (לדוגמה, קריאת CLI).
`resource "null_resource" "trigger" { triggers = { sha = sha1(file(".")) }; provisioner "local-exec" { command = "..." } }`. רץ מחדש כאשר `triggers` משתנים.
אמת באופן רציף אינווריאנט בזמן ריצה (לדוגמה, נקודת קצה בריאותית מחזירה 200) מבלי לחסום apply.
`check "endpoint" { data "http" "h" { url = "..." }; assert { condition = data.http.h.status_code == 200; error_message = "..." } }`. רץ ב-plan/apply; כישלון הוא אזהרה, לא שגיאה חמורה.
למה: `check` מאפשר מקורות נתונים בעלי scope שניתן להשתמש בהם רק בתוך הבדיקה. `precondition`/`postcondition` הם שגיאות חמורות ב-plan/apply.
כשל את ה-plan אם AMI ישן מדי.
`lifecycle { precondition { condition = data.aws_ami.x.creation_date > "2024-01-01"; error_message = "..." } }`. כשל חמור, מוערך לפני/אחרי לפי הצורך.
משתנה עם ערך מיקום בצורה קבועה.
`type = tuple([string, number, bool])` דורש בדיוק שלושה אלמנטים בסדר זה. שונה מרשימה (הומוגנית, אורך משתנה).
הקלדה חזקה של קלט מובנה (לדוגמה, `database = { instance_class = string, allocated_storage = number }`).
`type = object({ instance_class = string, allocated_storage = number, multi_az = optional(bool, false) })`. `optional(<type>, <default>)` הופך תכונות לאופציונליות.
כיצד נטענים קבצי `*.tfvars`?
`terraform.tfvars` ו-`*.auto.tfvars` נטענים אוטומטית (סדר לקסיקלי עבור `auto`). שמות אחרים דורשים `-var-file=path.tfvars`.
כתוב בדיקות אוטומטיות עבור מודול Terraform.
קבצי `.tftest.hcl` עם `run "name" { command = plan|apply, assert { condition = ..., error_message = ... } }`. `command = plan` הוא ללא תופעות לוואי; `command = apply` אכן יוצר משאבים.
העבר משתנים להרצות בדיקה.
בלוק `variables { ... }` ברמת הקובץ חל על כל ההרצות. בלוק `variables { ... }` לכל הרצה עוקף עבור הרצה זו בלבד.
בחר מצב ביצוע workspace ב-HCP Terraform.
מונע VCS (תכנון אוטומטי בדחיפת Git, הנפוץ ביותר). מונע CLI (מפתח מריץ `terraform plan/apply` מקומית, HCP מחזיק ב-state). מונע API (הרצות Terraform מופעלות על ידי API, משמשות מערכות אוטומציה/CD).
סדר השלבים בריצת HCP Terraform.
plan ← אומדן עלות (אם מופעל) ← בדיקת מדיניות (Sentinel/OPA) ← apply ידני או אוטומטי. כשלי מדיניות חובה או כשלי run-task עוצרים את הצינור.
אכוף שכל דליי ה-S3 יהיו מוצפנים, חוסם apply אם מופר.
מדיניות Sentinel עם אכיפה קשיחה-חובה. בודקת את ה-plan; כישלון חוסם apply. מדיניות רכה-חובה מאפשרת עקיפה על ידי מנהל. מדיניות ייעוצית רק מתעדת אך לעולם אינה חוסמת.
שלב סורק אבטחה של צד שלישי בצינור הריצה של HCP Terraform.
Run task בשלב ה-post-plan. HCP שולח POST את ה-plan לנקודת הקצה שלך; נקודת הקצה משיבה pass/fail. אכיפה חובה חוסמת apply בכישלון; ייעוצי רק מזהיר.
הצג את ההשפעה של בקשת משיכה (pull request) לפני מיזוג.
Speculative plans רצים על PRs (או ענפים), מגיבים את התוצאות בחזרה ל-PR, ולעולם אינם מיישמים. מופעלים אוטומטית כאשר אינטגרציית VCS מופעלת.
הימנע מאחסון מפתחות גישה ל-AWS כסודות סטטיים במשתני HCP Terraform.
אישורי ספק דינמיים. HCP Terraform מבקש אישורים קצרי חיים באמצעות OIDC trust ל-AWS/Azure/GCP. אין מפתחות סטטיים; זהויות לכל הרצה; ידידותי לביקורת.
למה: מפתחות סטטיים דולפים. OIDC trust קושר אישורים ל-workspace + run, פג תוך שעה.
שתף את אותם אישורי ספק על פני workspaces רבים.
Variable sets. הגדר פעם אחת ברמת הארגון/פרויקט, חבר ל-workspaces רבים. עדכונים מתפשטים ללא עריכות לכל workspace.
מהו הפרויקט המוגדר כברירת מחדל ב-HCP Terraform?
פרויקט מובנה הקיים בכל ארגון ולא ניתן למחוק אותו (שינוי שם מותר). כל ה-workspaces שייכים אליו אלא אם כן הוקצו במפורש לפרויקט אחר.
הפעל workspace downstream בכל פעם ש-workspace upstream מסיים apply מוצלח.
Run triggers. הגדר workspaces מקור ב-workspace התלוי; HCP מכניס לתור הרצה ב-dependent לאחר כל apply מוצלח של upstream.