שאלות נפוצות בנושא 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:

• HashiCorp Terraform Registry: Terraform Registry הרשמי של 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? האם זה ישפיע על היכולת שלי להשתמש ב-Managed Service for Apache Spark?

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

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

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

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

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

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

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

למה מופיעות שגיאות שקשורות למכסה (429 יותר מדי בקשות או 403 חריגה מהמכסה)?

שגיאות שקשורות למכסה מתרחשות כשהפרויקט מנסה לצרוך יותר משאבים או לשלוח יותר בקשות ל-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 או Managed Service for Apache Airflow.

מה קורה כש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 . האפשרות הזו מועדפת בדרך כלל לשירותים קריטיים שאסור להשבית או למחוק בטעות.