אשכול EKS נוצר דרך קונסולת AWS לפני זמן מה. RDS, VPC, קבוצות אבטחה—הכל נעשה ידנית. Terraform רק הופיע בחברה שלך, והמשימה היא להביא הכל לניהול ללא זמן השבתה וללא יצירת משאבים מחדש. כאן terraform import הופך לכלי המפתח.
המלאי לעיתים קרובות חושף עשרות משאבים שלא תועדו: שערי NAT שנשכחו, כרכי EBS שאינם בשימוש, קבוצות אבטחה מיושנות. ייבוא ידני של כל משאב דורש תצורה מדויקת ואימות. המהנדסים שלנו ביצעו למעלה מ-500 ייבואים מוצלחים, וחסכו ללקוחות בממוצע 40% מעלויות ניהול התשתית, כאשר עלויות פרויקט טיפוסיות מתחילות ב-$1,500 עבור תשתיות קטנות. נעזור לך לבצע תהליך זה במפתח מלא: ממלאי ועד מעבר מלא ל-IaC, עם אחריות לאפס סטיות ב-terraform plan. עמלת הביקורת החד-פעמית שלנו היא $500, ותקוזז מעלות הפרויקט אם תמשיך איתנו. אנו מתמחים בהגירה ל-terraform, ייבוא תשתית terraform, וניהול מצב terraform מקיף. צור קשר להערכה.
כיצד פועל ייבוא Terraform
terraform import לוקח משאב ענן קיים ומתעד אותו במצב תחת כתובת המשאב שצוינה. יש לכתוב את התצורה ידנית מראש.
גישה קלאסית שלב אחר שלב (Terraform < 1.5)
- כתוב את בלוק תצורת המשאב בקבצי
terraform import aws_security_group.main sg-0abc1234def567890(לדוגמה,terraform plan). - הרץ
No changesכדי לאתחל את ספריית העבודה. - בצע
planכדי לייבא את המשאב. - הרץ
import { to = aws_vpc.main id = "vpc-0abc1234" } resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16" enable_dns_hostnames = true tags = { Name = "main-vpc" } }כדי לוודא שלא מתגלים שינויים. - אם מופיעים שינויים, התאם את התצורה עד ש-
terraform planמציגterraform apply.
terraform import aws_security_group.main sg-0abc1234def567890 לאחר הייבוא, import אמור להציג terraform plan -generate-config-out=generated.tf—זה אומר שהתצורה מתארת במדויק את המשאב האמיתי. אם terraform plan מציג שינויים, התצורה חורגת מהמציאות, ויש לתקן את התצורה או לקבל את השינויים.
בלוקי ייבוא ב-Terraform 1.5+
החל מגרסה 1.5, ניתן לתאר ייבוא ישירות בתצורה:
import {
to = aws_vpc.main
id = "vpc-0abc1234"
}
resource "aws_vpc" "main" {
cidr_block = "10.0.0.0/16"
enable_dns_hostnames = true
tags = {
Name = "main-vpc"
}
}terraform import מציג מה ייובא, -generate-config-out מבצע את הייבוא. לאחר ייבוא מוצלח, ניתן להסיר את בלוק terraform refresh מהתצורה.
Terraform 1.5 הוסיף גם plan—יצירת תצורה עבור משאבים מיובאים. זהו טיוטה שיש לסקור ולבנות, אך הוא חוסך זמן בהשוואה לכתיבה מאפס.
הבטחת ייבוא מוצלח
ייבוא מוצלח רק כאשר aws_instance אינו מציג שינויים. זה מאשר שהתצורה שלך תואמת לחלוטין למשאב האמיתי. אם התוכנית מציגה שינויים (לדוגמה, תגים נוספים או CIDR שגוי), התצורה אינה מתארת את המשאב במדויק. תקן את התצורה, אל תקבל את השינויים—אחרת אתה מסתכן בביצוע שינויים בלתי צפויים בייצור.
טעויות ייבוא טיפוסיות
- אי-התאמה במזהה המשאב: בעת ייבוא, יש לציין את המזהה המדויק מ-API של הענן. שגיאה במזהה מובילה לכישלון.
- מאפיינים אופציונליים חסרים: אם התצורה אינה מציינת מאפיינים שקיימים במשאב האמיתי,
subnet_idיציג שינויים. - ייבוא משאבים עם תלות: הסדר חשוב—ייבא תחילה משאבי בסיס (VPC, רשתות), ולאחר מכן משאבים תלויים.
- התעלמות מתלויות מרומזות: חלק מהמשאבים (לדוגמה,
aws_iam_access_keyעםplan) תלויים במרומז באחרים. ודא שמשאבי האב כבר נמצאים במצב.
משאבים שלא ניתן לייבא
חלק מהמשאבים אינם תומכים בייבוא כלל—לדוגמה, משאבים עם פלט סודי חד-פעמי (מפתחות, סיסמאות) ש-AWS מחזיר רק בעת היצירה. terraform plan—ה-secret_key אינו זמין לאחר היצירה, כך שהמצב יהיה ריק ו-Terraform תמיד יציג אותו ב-plan כשינוי.
עבור משאבים כאלה, הדרך היחידה היא ליצור אותם מחדש עם Terraform ולעדכן שירותים תלויים.
מתי ליצור משאב מחדש במקום לייבא?
אם למשאב יש נתוני פלט סודיים או שהתצורה שלו שונה מאוד ממה שאתה רוצה, קל יותר ליצור אותו מחדש עם Terraform. זה מהיר יותר מאשר להתמודד עם ייבוא ותיקונים לאחר מכן.
תהליך ולוחות זמנים
אוטומציה של ייבוא למאות משאבים
בעת ייבוא של 200+ משאבים, יש צורך בסיסטמטיזציה. התהליך שלנו כולל אוטומציה מלאה של ייבוא משאבים. השווה בין גישות:
| כלי | זמן עבור 200 משאבים | בקרת איכות | עידון ידני |
|---|---|---|---|
terraform import ידני |
2-4 שבועות | מלאה | רק כתיבת תצורות |
בלוקי ייבוא + -generate-config-out |
1-2 שבועות | גבוהה | סקירת קוד שנוצר |
| Terraformer | 3-5 ימים | נמוכה | תיקון משמעותי (50-70%) |
הניסיון שלנו מראה: התוצאה הטובה ביותר מגיעה משילוב של terraformer ליצירה ראשונית ואימות ידני של תצורות עם ייבוא דרך בלוקי ייבוא. זה מפחית את ה-MTTR פי 2-3 בהשוואה לגישה ידנית טהורה. אנו מספקים ניהול תשתית devops מקיף.
בנוסף, ניתן להשתמש ב-terraform refresh כדי לסנכרן מצב, אך הוא אינו יוצר תצורה—רק מעדכן מאפיינים. לכן, להגירה מלאה ל-terraform, עדיף לשלב כלים.
הערכות לוחות זמנים
| גודל תשתית | מספר משאבים | לוח זמנים משוער | מורכבות |
|---|---|---|---|
| קטן | עד 50 | שבוע אחד | נמוכה |
| בינוני | 50 – 200 | 2 – 4 שבועות | בינונית |
| גדול | 200 – 500 | 1 – 2 חודשים | גבוהה |
| ארגוני | 500+ | החל מ-2 חודשים | גבוהה מאוד |
מה כלול בעבודה
- מלאי של כל המשאבים דרך API של הענן או Terraform Cloud
- כתיבת תצורות וייבוא לפי שכבות (רשת, מחשוב, מסדי נתונים)
- אימות של כל משאב דרך
terraform plan - תיעוד קבצי מצב והתהליך
- העברת ידע לצוות שלך
לוחות זמנים
תלויים במספר המשאבים ובמורכבותם. פרויקט קטן (50-100 משאבים של ספק ענן אחד) — 1-2 שבועות. תשתית הטרוגנית גדולה עם מספר עננים, משאבים legacy ותצורות לא סטנדרטיות — 1-2 חודשים. העלות מחושבת לאחר המלאי. קבל ייעוץ—נעריך את הפרויקט שלך תוך יום אחד. הזמן ביקורת תשתית—נציע אסטרטגיית ייבוא אופטימלית.
לפרטים נוספים, עיין ב-תיעוד ייבוא Terraform. Terraform import — תיעוד רשמי.







