שירותי תשתית כקוד: אוטומציה, מודולים ו-Terraform

תשתית כקוד: ניהול תשתית באמצעות קוד עם Terraform, Pulumi ו-Ansible

לעתים קרובות אנו רואים ש-terraform apply נתקע על aws_db_instance.main: Still modifying... — ואף אחד לא יודע אם בטוח לבטל. מכיוון שהמצב (state) מאוחסן מקומית ב-terraform.tfstate, שלושת המהנדסים האחרונים עבדו איתו ברצף, ועכשיו שניים הריצו apply בו-זמנית. המצב התפצל. זה לא מצב היפותטי — כך מתחילות מחצית מבדיקות ה-IaC. רק ברבעון האחרון פתרנו שבעה מקרים כאלה, עם MTTR ממוצע של 4 שעות. המהנדסים המוסמכים שלנו מתמודדים עם בעיות אלה מדי חודש, ומאיצים את ההתאוששות פי שלושה בהשוואה לחיפוש ידני. עם ניסיון של למעלה מ-5 שנים באוטומציה של ניהול תשתית באמצעות קוד, אנו מבטיחים לא יותר מאירוע סחיפה (drift) אחד לא מתוכנן ברבעון לאחר המעבר.

מדוע Terraform State הוא הפגיע ביותר?

Terraform מאחסן את מפת העולם האמיתי ב-terraform.tfstate. אם המצב שגוי, Terraform או שייצור מחדש משאב שכבר קיים או שלא יזהה סחיפת תצורה. שני המצבים רעים: הראשון גורם לזמן השבתה, השני מביא לשינויים לא מתוכננים. בממוצע, בפרויקט עם 200 משאבים, סחיפה מתגלה פעם בשבועיים, ופתרונה אורך עד 8 שעות.

מצב מרוחק עם נעילה (locking) הוא הדבר הראשון שמוגדר בכל פרויקט:

terraform { backend "s3" { bucket = "company-terraform-state" key = "production/eks/terraform.tfstate" region = "eu-west-1" encrypt = true dynamodb_table = "terraform-state-lock" } } 

טבלת DynamoDB עם התכונה terraform { backend "s3" { bucket = "company-terraform-state" key = "production/eks/terraform.tfstate" region = "eu-west-1" encrypt = true dynamodb_table = "terraform-state-lock" } } (מסוג String) מספקת נעילה: LockID שני יקבל את השגיאה terraform apply ולא ירוץ. ב-GCP, אותו דבר נעשה באמצעות GCS backend עם נעילת אובייקטים מובנית. ב-Azure, באמצעות azurerm backend עם Storage Account.

רמה שנייה של בעיות היא Error acquiring the state lock עבור משאבי legacy. כאשר תשתית נוצרה ידנית בקונסולה ומאוחר יותר התקבלה החלטה "לעבור ל-IaC", יש לייבא כל משאב: terraform import. זהו תהליך איטרטיבי הנמשך מספר ימים עבור סביבות גדולות. חלופה היא terraform import aws_security_group.web sg-0abc123def או terraformer ליצירת תצורה מתשתית קיימת, אך התוצאה תמיד דורשת כוונון ידני. בפרויקט אחד, ייבוא 150 משאבים ארך 3 ימים, וחידוד המודולים ארך שבוע נוסף.

סחיפת מצב — כאשר מישהו משנה משאב מחוץ ל-Terraform (דרך הקונסולה, CLI או כלי אחר). former2 יציג את הסחיפה, אבל לא תמיד ברור אם לשחזר את המצב מהתצורה או לעדכן את התצורה מהמצב. עבור תשתית production, אנו מגדירים terraform plan על משאבים קריטיים — RDS, VPC, אשכול EKS. זה מונע מחיקה מקרית.

ארכיטקטורת מודולים ב-Terraform

קובץ lifecycle { prevent_destroy = true } שטוח עם 3000 שורות הוא הטעות הנפוצה ביותר. אחרי שישה חודשים, אף אחד לא מבין את התלויות, וכל main.tf אורך 10 דקות. לאחר פיצול למודולים, זמן ה-plan קטן פי 3–5.

המבנה הנכון הוא מודולרי:

infrastructure/ modules/ eks-cluster/ # переиспользуемый модуль main.tf variables.tf outputs.tf rds-postgres/ vpc/ environments/ production/ main.tf # вызывает модули с prod-параметрами backend.tf variables.tf staging/ main.tf # те же модули, другие размеры 

מודול plan מקבל פרמטרים דרך infrastructure/ modules/ eks-cluster/ # переиспользуемый модуль main.tf variables.tf outputs.tf rds-postgres/ vpc/ environments/ production/ main.tf # вызывает модули с prod-параметрами backend.tf variables.tf staging/ main.tf # те же модули, другие размеры : גרסת K8s, סוגי nodes, מספר אזורי זמינות. סביבת production קוראת לו עם eks-cluster, staging עם variables.tf. קוד אחד, פרמטרים שונים.

ניהול גרסאות של מודולים באמצעות Git tags חשוב לשחזוריות:

module "eks" { source = "git::https://github.com/company/tf-modules.git//eks-cluster?ref=v2.3.0" ... } 

עדכון מודול הוא פעולה מכוונת עם tag, לא איסוף מקרי של שינויים מ-instance_types = ["m5.xlarge"].

Terragrunt הוא wrapper סביב Terraform לתצורות DRY. הוא מבטל שכפול של בלוקי backend ו-providers בין סביבות. ["t3.medium"] — מציג את ה-plan עבור כל המודולים בבת אחת. זה מוצדק עבור 5+ סביבות או אזורים. אנו משתמשים ב-Terragrunt בפרויקטים עם ארכיטקטורה רב-אזורית שבהם מספר הסביבות עולה על 6.

איך לבחור בין Terraform ל-Pulumi?

Terraform HCL הוא DSL הצהרתי עם מגבלות: לולאות דרך module "eks" { source = "git::https://github.com/company/tf-modules.git//eks-cluster?ref=v2.3.0" ... } ו-main, תנאים באמצעות ביטויים טרנריים, ואין פונקציות מתאימות. Pulumi פותר זאת באופן קיצוני — כותבים ב-TypeScript, Python, Go או C#.

import * as aws from "@pulumi/aws"; import * as eks from "@pulumi/eks"; const cluster = new eks.Cluster("production", { instanceType: "m5.xlarge", desiredCapacity: 3, minSize: 2, maxSize: 10, deployDashboard: false, }); // Нормальный TypeScript: массивы, функции, условия const apps = ["api", "worker", "scheduler"]; apps.forEach(app => { new aws.ecr.Repository(app, { imageTagMutability: "IMMUTABLE", imageScanningConfiguration: { scanOnPush: true }, }); }); 

Pulumi מאחסן את המצב ב-Pulumi Cloud (מנוהל) או ב-S3/Azure Blob/GCS (באחסון עצמי). עבור צוותים ללא ניסיון ב-TypeScript/Python, חסם הכניסה גבוה יותר מאשר ב-Terraform. עבור צוותים עם מפתחים חזקים, Pulumi מנצח בתרחישים מורכבים. השוואה: Pulumi עם TypeScript יכול להפחית את נפח הקוד ב-30% בהשוואה ל-HCL בעבודה עם משאבים מחזוריים.

Ansible מכסה את מה ש-Terraform לא יכול: תצורה בתוך השרת. Terraform יצר את מופע ה-EC2, Ansible הגדיר את nginx, התקין תלויות ופרס תצורות.

אידמפוטנטיות (Idempotency) היא התכונה המרכזית. ניתן להריץ playbook 10 פעמים, והתוצאה תהיה זהה. terragrunt run-all plan מציג שינויים ספציפיים בקבצי התצורה לפני היישום.

ארגן roles דרך Ansible Galaxy או מאגר פנימי. ה-for_each role — הגדרות בסיסיות לכל השרתים: משתמשים, SSH, NTP, fail2ban. ה-count role — הגדרות kernel עבור צמתי K8s: import * as aws from "@pulumi/aws"; import * as eks from "@pulumi/eks"; const cluster = new eks.Cluster("production", { instanceType: "m5.xlarge", desiredCapacity: 3, minSize: 2, maxSize: 10, deployDashboard: false, }); // Нормальный TypeScript: массивы, функции, условия const apps = ["api", "worker", "scheduler"]; apps.forEach(app => { new aws.ecr.Repository(app, { imageTagMutability: "IMMUTABLE", imageScanningConfiguration: { scanOnPush: true }, }); }); , ansible-playbook -i inventory/production site.yml --diff, ביטול swap.

Ansible Vault לסודות — משתנים מוצפנים ישירות במאגר:

ansible-vault encrypt_string 'super_secret_password' --name 'db_password' 

התוצאה היא מחרוזת מוצפנת ב-common, המפוענחת בזמן ריצה דרך kubernetes-node.

Ansible מול Terraform: הם לא מתחרים אלא משלימים. Terraform — אספקת תשתית (VPC, מופעים, שירותים מנוהלים). Ansible — תצורת מערכת הפעלה ויישומים. ב-Kubernetes, Ansible משמש פחות — Helm ו-Operators מטפלים בניהול התצורה.

CloudFormation: מתי יש צורך באינטגרציה מקורית של AWS

CloudFormation הוא כלי ה-IaC של AWS. יתרון אחד, אבל משמעותי: מקוריות (nativity). שירות AWS חדש מופיע ב-CloudFormation ביום ההשקה או למחרת. ב-Terraform, ה-provider של aws לפעמים מפגר בשבועות.

AWS CDK (Cloud Development Kit) הוא סוכר תחבירי מעל CloudFormation: כותבים ב-TypeScript/Python, ומייצרים תבניות CloudFormation. אותו היגיון כמו Pulumi, אבל פורמט הפלט הוא CloudFormation JSON/YAML.

עבור סביבות AWS טהורות ללא תוכניות multicloud, CDK הוא בחירה סבירה. עבור סביבות הטרוגניות (AWS + חלקית GCP או Azure, או on-premise), Terraform מספק ערכת כלים אחידה.

מה כולל יישום IaC מלא?

כאשר אתם שוכרים את הצוות שלנו, אתם מקבלים:

• מצב מרוחק עם נעילה מוגדר על פי בחירתכם ב-S3+GCS או Azure Blob — מבטל סיכוני השחתת מצב.
• מבנה Terraform מודולרי עם מודולים לשימוש חוזר לרשת, מחשוב ומסדי נתונים — מפחית את זמן vm.swappiness=0 פי 3–5.
• ייבוא של 50–200 משאבים קיימים לקוד, עם net.bridge.bridge-nf-call-iptables=1 ו-ansible-vault encrypt_string 'super_secret_password' --name 'db_password' שעברו.
• צינור CI/CD (GitLab CI/GitHub Actions) שמריץ group_vars/production/vault.yml על כל PR ו---vault-password-file רק לאחר אישור — מונע שגיאות ידניות.
• Ansible roles לתצורת שרתים (משתמשים, אבטחה, תלויות) — אידמפוטנטיים ומבוקרי גרסאות.
• תיעוד (runbook לשחזור מצב, דוגמאות שימוש במודולים, הוראות גישה).
• תמיכה ל-30 יום לאחר הפריסה — אנו מטפלים בכל סחיפה או בעיות ייבוא שעולות.

המהנדסים שלנו השלימו למעלה מ-50 פרויקטים כאלה, עם ממוצע של 4 שבועות לאוטומציה מלאה. דו"ח State of Infrastructure Strategy של HashiCorp לשנת 2023 קובע שארגונים המשתמשים ב-IaC מפחיתים את זמן הפריסה פי 3–4 ומקצצים בעלויות הקשורות לתקלות ב-60%.

איך לאוטמט ייבוא של תשתית קיימת?

לייבוא מהיר, אנו משתמשים ב-terraform plan (מ-Google) או ב-apply — הם מייצרים קוד Terraform ממשאבים קיימים. עם זאת, התוצאה תמיד דורשת רפקטורינג ידני: קיבוץ למודולים, הסרת תלויות מיותרות, התאמה לסטנדרטים ארגוניים. כיסוי מלא של 50–200 משאבים אורך 1–2 שבועות. לאחר הייבוא, אנו מריצים אוטומטית terraform plan ו-apply לבדיקת איכות הקוד.

השוואת כלי IaC

Ansible לא מתחרה אלא משלים — לתצורה לאחר אספקה.

לוחות זמנים אופייניים

חיסכון בזמן למהנדסים — עד 40% בחודש, והפחתת אירועי סחיפת תצורה — עד 70%. פנו לצוות שלנו כדי לדון בצרכי ה-IaC שלכם — אנו מספקים הערכת פרויקט חינמית ופתרון אופטימלי המותאם למחסן הטכנולוגי שלכם. הזמינו ביקורת תשתית היום, ואנו נראה לכם בדיוק כמה זמן וכסף תחסכו.

קבלו ייעוץ עכשיו: כתבו לנו בטלגרם או השאירו בקשה באתר שלנו. אנו עובדים turnkey — מביקורת ועד אוטומציה מלאה. המהנדסים המוסמכים שלנו בעלי ניסיון מעשי של 5+ שנים ורקורד מוכח באספקת פתרונות IaC שמפחיתים עומס תפעולי ב-60%.