שאלות נפוצות בנושא Terraform ב-Google Cloud

בדף הזה מופיעות תשובות לשאלות נפוצות שמתעוררות כשמשתמשים ב-Terraform כדי לנהל משאבים ב- Google Cloud, במיוחד בנוגע לאינטראקציות עם API ותחילת העבודה.

תחילת העבודה עם Terraform

בקטע הזה מוסברים מושגי יסוד ומתוארים השלבים הראשונים למשתמשים חדשים ב-Terraform.

מהי תשתית כקוד (IaC) ולמה כדאי להשתמש ב-Terraform?

תשתית כקוד (IaC) היא שיטה לניהול ולהקצאה של תשתית מחשוב באמצעות קובצי הגדרה שניתנים לקריאה על ידי מכונה. סקירה כללית מלאה של המושגים והיתרונות של IaC זמינה במאמר מהי תשתית כקוד?

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

איך מתקינים את Terraform ומריצים את ההגדרה הראשונה?

כדי להתחיל לעבוד עם Terraform, קודם צריך להוריד ולהתקין את Terraform CLI במחשב המקומי. הוראות זמינות באתר HashiCorp Terraform. אחרי ההתקנה, אפשר ליצור קובץ תצורה של Terraform, להגדיר משאב (כמו קטגוריית Cloud Storage), ואז להשתמש בפקודה terraform init כדי לאתחל את ספריית העבודה, בפקודה terraform plan כדי לראות תצוגה מקדימה של השינויים ובפקודה terraform apply כדי להחיל אותם.

מהי שפת ההגדרה של HashiCorp‏ (HCL) ואיפה אפשר לקבל מידע על התחביר שלה?

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

איפה אפשר למצוא דוגמאות להגדרות של משאבי Google Cloud ב-Terraform?

תוכלו למצוא דוגמאות רבות להגדרות של Terraform עבור Google Cloud:

  • מאגר Terraform של HashiCorp: מאגר Terraform הרשמי של ספק Google Cloud מכיל תיעוד ודוגמאות לכל משאב ומקור נתונים.

  • Google Cloud דוגמאות ל-Terraform: Google מספקת מגוון דוגמאות ל-Terraform שמדגימות איך לפרוס ולנהל משאבים נפוצים של Google Cloud .

  • מאגרי GitHub: מאגרים רבים בקוד פתוח, כולל ארגון GitHub‏ terraform-google-modules, מציעים דוגמאות ומודולים לשימוש חוזר.

איך אפשר לנהל ולבדוק הגדרות מורכבות של Terraform, במיוחד כשעובדים עם הרבה משאבים?

במקרים של הגדרות מורכבות, כדאי להשתמש בתכונות של Terraform שנועדו להרחבה ולתחזוקה:

  • מודולים: מאפשרים להשתמש מחדש בתבניות נפוצות של תשתית.

  • סביבות עבודה: ניהול של כמה מקרים נפרדים של הגדרה אחת.

  • ‫terraform plan ו-terraform validate: כדאי להשתמש בפקודות האלה לעיתים קרובות כדי לאמת את התחביר ולראות תצוגה מקדימה של השינויים בלי לפרוס אותם בפועל.

  • משאבי טירגוט (שימוש זהיר): כדי לבדוק חלקים ספציפיים, אפשר להשתמש באופן זמני ב--target עם terraform apply או terraform destroy, אבל בדרך כלל לא מומלץ להשתמש בשיטה הזו לפעולות שגרתיות בגלל המורכבות של ניהול המצב.

  • סביבות ייעודיות: פריסה לסביבות פיתוח או Staging לצורך בדיקה לפני הייצור.

Google Cloud שאלות לגבי API

השאלות האלה מתייחסות לשאלות נפוצות לגבי האינטראקציה של Terraform עםGoogle Cloud ממשקי API, כולל ממשקי API ציבוריים ופרטיים.

האם אפשר להשתמש ב-Terraform כדי לנהל או לייבא ממשקי API פנימיים או פרטיים של Google Cloud , כמו dataproc-control.googleapis.com?

לא. ממשקי API פנימיים או פרטיים Google Cloud הם חלק מ-Service Infrastructure המנוהלת של Google, והם לא חשופים לניהול ישיר, להפעלה או לייבוא על ידי לקוחות באמצעות Terraform. מערכת Google Cloudמטפלת בממשקי ה-API האלה באופן אוטומטי. ניסיון לנהל אותם ישירות באמצעות Terraform יוביל לשגיאות.

הסבר מקיף מופיע במדריך להבנת ממשקי API של Google Cloud Terraform.

מה ההבדל בין הפעלה של API לבין ייבוא של משאב ב-Terraform?

  • הפעלה של API: הפעלה של שירות ספציפי Google Cloud בפרויקט, ומתן ההרשאות הנדרשות לפרויקט כדי להשתמש בשירות הזה. כשמשתמשים ב-Terraform ב- Google Cloud, בדרך כלל עושים את זה באמצעות המשאב google_project_service. זוהי דרישה מוקדמת ליצירת משאבים שמסתמכים על ה-API הזה.

  • ייבוא משאב: הכוונה היא להעברת משאב קיים Google Cloud (לדוגמה, מכונה ב-Compute Engine, קטגוריה של Cloud Storage) שנוצר מחוץ ל-Terraform לניהול של Terraform. אתם מייבאים משאבים, ולא ממשקי API.

מידע נוסף מופיע במדריך להבנת ממשקי API של Google Cloud ו-Terraform.

מה קורה אם אני לא מנהל או מייבא באופן מפורש את dataproc-control.googleapis.com? האם השינוי ישפיע על היכולת שלי להשתמש ב-Dataproc?

לא, זה לא ישפיע על היכולת שלכם להשתמש ב-Dataproc. ‫dataproc-control.googleapis.com הוא API פנימי שמשמש את Dataproc לשליטה תפעולית. הפונקציונליות שלו מנוהלת באופן אוטומטי על ידיGoogle Cloud, ולא נדרשת הפעלה, ייבוא או ניהול מפורשים על ידכם באמצעות Terraform. האשכולות והמשימות של Dataproc יפעלו בצורה תקינה ללא צורך בהתערבות ידנית כלשהי בנוגע ל-API הפנימי הזה.

איך פותרים בעיות שקשורות לשגיאות 403 Permission Denied ב-Terraform?

שגיאות 403 Permission Denied בדרך כלל מצביעות על כך שלחשבון השירות או לפרטי הכניסה של המשתמש שמשמשים את Terraform חסרות הרשאות ה-IAM הנדרשות לביצוע פעולה מסוימת במשאב Google Cloud ספציפי. כדי לפתור את הבעיה:

  1. מזהים את המשאב ואת שיטת ה-API שהושפעו: הודעת השגיאה בדרך כלל מציינת את סוג המשאב ואת הקריאה ל-API שנכשלה.

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

  3. מוודאים שהשירות מופעל: מוודאים ששירות ה-API הנדרש של Google Cloud מופעל בפרויקט (לדוגמה, באמצעות gcloud services enable או google_project_service).

  4. בדיקת מדיניות הארגון: צריך לבדוק אם יש מדיניות ארגונית שמגבילה את הפעולה.

שגיאות שקשורות למכסה מתרחשות כשהפרויקט מנסה לצרוך יותר משאבים או לשלוח יותר בקשות ל-API מהמכסות הנוכחיות שלו. כדי לפתור את הבעיה:

  1. מזהים את המכסה הספציפית: בדרך כלל בהודעת השגיאה מצוינים ה-API והמכסה שהחריגה ממנה גרמה לשגיאה.

  2. בדיקת המכסות הנוכחיות: בדף Quotas במסוף Google Cloud אפשר לראות את הניצול והמגבלות הנוכחיים.

  3. לבקש להגדיל את המכסה: אם אתם צריכים קיבולת גדולה יותר, אתם יכולים לבקש להגדיל את המכסה ישירות מהדף Quotas (מכסות).

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

מהו חשבון שירות שמוגדר כברירת מחדל ומנוהל על ידי המשתמש, ואיך אפשר לנהל את ההרשאות שלו באמצעות Terraform?

שירותים מסוימים Google Cloud יוצרים באופן אוטומטי חשבונות שירות בניהול המשתמשים (שנקראים לעיתים קרובות חשבונות שירות שמוגדרים כברירת מחדל) כשיוצרים פרויקט או כשמפעילים שירות. בדרך כלל יש להן הרשאות רחבות. הם מנוהלים על ידי המשתמשים, אבל נוצרים על ידי Google. אפשר לנהל את ההרשאות שלהם באמצעות משאבי IAM כמו google_project_iam_member כדי לשנות את התפקידים שלהם. אם רוצים לבצע פעולות בחשבונות השירות שמוגדרים כברירת מחדל, כמו הסרת תפקידים עם הרשאות גבוהות שמוגדרים כברירת מחדל או מחיקה מלאה של החשבונות, אפשר להשתמש במשאב google_project_default_service_accounts. ‏Google מספקת גם הנחיות לגבי סוגים של חשבונות שירות שמוגדרים כברירת מחדל.

מהו חשבון שירות שמנוהל על ידי Google ואיך מפנים אליו בהגדרות של Terraform?

חשבונות שירות בניהול Google נוצרים ומנוהלים באופן מלא על ידי Google עבור שירותים מסוימים. הם קיימים מחוץ לפרויקטים של משתמשים, ומשתמשים לא יכולים להגדיר אותם ישירות כמו חשבונות שירות בניהול המשתמשים. עם זאת, יכול להיות שתצטרכו להעניק להם הרשאות IAM כדי שיוכלו לבצע אינטראקציה עם המשאבים שלכם. אתם יכולים להפנות לכתובת האימייל של חשבון שירות בניהול Google בשביל שירות ספציפי באמצעות מקור הנתונים google_project_service_identity או המשאב ב-Terraform, כדי להחיל עליו מדיניות IAM. לדוגמה, זה נפוץ בשירותים כמו Cloud Build או Cloud Composer.

מה קורה כשterraform destroy משאב שמוגדר בו disable_on_destroy?

הארגומנט disable_on_destroy ב-google_project_service ובחלק מהמשאבים האחרים (למשל, google_storage_bucket) קובע אם משאב הענן הבסיסי מושבת או נמחק כשמשאב Terraform נמחק.

  • אם disable_on_destroy הוא true (או לא מוגדר, כי זה לרוב ערך ברירת המחדל),‏ terraform destroy ינסה להשבית (עבור ממשקי API) או למחוק (עבור מאגרי מידע) את משאב הענן התואם.

  • אם הערך של disable_on_destroy הוא false,‏ terraform destroy יסיר את המשאב ממצב Terraform, אבל ישאיר את משאב הענן בפועל (למשל, ה-API המופעל או הקטגוריה) ללא שינוי בפרויקט Google Cloud . האפשרות הזו מועדפת בדרך כלל לשירותים קריטיים שלא רוצים להשבית או למחוק בטעות.