אחסון מצבי Terraform בקטגוריה של Cloud Storage

במדריך הזה תלמדו איך לאחסן מצבי Terraform בקטגוריות של Cloud Storage.

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

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

מטרות

במדריך הזה מוסבר איך:

• שימוש ב-Terraform כדי להקצות קטגוריה של Cloud Storage לאחסון מצב של Terraform.
• מוסיפים תבניות לקובץ ההגדרות של Terraform כדי להעביר את המצב מהקצה העורפי המקומי לקטגוריה של Cloud Storage.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Cloud Storage

כדי להעריך את ההוצאות בהתאם לתחזית השימוש שלכם, אתם יכולים להיעזר במחשבון העלויות.

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

כשמסיימים את המשימות שמתוארות במסמך הזה אפשר למחוק את המשאבים שיצרתם כדי להימנע מחיובים נוספים. מידע נוסף זמין בקטע הסרת המשאבים.

השימוש ב-Cloud Storage כרוך בעלויות של פעולות אחסון, קריאה וכתיבה, של תעבורת נתונים יוצאת (egress) ברשת ושל יצירת רפליקות.

במדריך הזה, החלוקה לגרסאות אובייקטים פועלת בקטגוריה של Cloud Storage, כדי לשמור את היסטוריית הפריסות. הפעלת החלוקה לגרסאות אובייקטים מייקרת את עלויות השימוש באחסון, אבל אפשר להוזיל אותן על ידי הגדרת ניהול מחזור החיים של אובייקטים כדי למחוק גרסאות ישנות של מצבים.

לפני שמתחילים

1. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

   ‫Terraform מותקן מראש ב-Cloud Shell.

2. אם אתם משתמשים במעטפת מקומית, מבצעים את הפעולות הבאות:

   • מתקינים את Terraform.

   • יוצרים פרטי כניסה לאימות מקומי עבור חשבון המשתמש:

     gcloud auth application-default login

     אם מוחזרת שגיאת אימות ואתם משתמשים בספק זהויות חיצוני (IdP), ודאו ש נכנסתם ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

3. יוצרים או בוחרים Google Cloud פרויקט.

   תפקידים שנדרשים כדי לבחור או ליצור פרויקט

   • Select a project: כדי לבחור פרויקט לא צריך תפקיד IAM ספציפי – אפשר לבחור כל פרויקט שקיבלתם בו תפקיד.
   • יצירת פרויקט: כדי ליצור פרויקט, צריך את התפקיד Project Creator (יצירת פרויקטים) (roles/resourcemanager.projectCreator), שכולל את ההרשאה resourcemanager.projects.create. איך מקצים תפקידים
   הערה: אם אתם לא מתכננים לשמור את המשאבים שתיצרו בתהליך הזה, תוכלו ליצור פרויקט חדש במקום לבחור באחד מהפרויקטים הקיימים. בסיום התהליך תוכלו למחוק את הפרויקט ולהסיר את כל המשאבים שמשויכים אליו.

   • יוצרים Google Cloud פרויקט:

     gcloud projects create PROJECT_ID

     מחליפים את PROJECT_ID בשם של פרויקט Google Cloud שיוצרים.

   • בוחרים את הפרויקט שיצרתם: Google Cloud

     gcloud config set project PROJECT_ID

     מחליפים את PROJECT_ID בשם הפרויקט ב- Google Cloud .

4. מוודאים שהחיוב מופעל בפרויקט Google Cloud .

5. מפעילים את Cloud Storage API:

   תפקידים שנדרשים להפעלת ממשקי API

   כדי להפעיל ממשקי API, נדרשת ההרשאה serviceusage.services.enable. אם יצרתם את הפרויקט, סביר להניח שכבר יש לכם את ההרשאה הזו דרך התפקיד 'בעלים' (roles/owner). אחרת, תוכלו לקבל את ההרשאה הזו דרך התפקיד 'אדמין של Service Usage' (roles/serviceusage.serviceUsageAdmin). איך מקצים תפקידים

   gcloud services enable storage.googleapis.com

6. מעניקים תפקידים לחשבון המשתמש. מריצים את הפקודה הבאה לכל אחד מהתפקידים הבאים ב-IAM: roles/storage.admin

   gcloud projects add-iam-policy-binding PROJECT_ID --member="user:USER_IDENTIFIER" --role=ROLE

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫PROJECT_ID: מזהה הפרויקט.
   • ‫USER_IDENTIFIER: המזהה של חשבון המשתמש חשבון. דוגמאות מופיעות במאמר ייצוג המשתמשים במאגרי כוח עבודה בכללי מדיניות IAM.
   • ‫ROLE: תפקיד ה-IAM שאתם מקצים לחשבון המשתמש.

   לחלופין, אפשר ליצור תפקיד IAM בהתאמה אישית שכולל את ההרשאות הבאות:

   • storage.buckets.create
   • storage.buckets.list
   • storage.objects.get
   • storage.objects.create
   • storage.objects.delete
   • storage.objects.update

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

הכנת הסביבה

1. משכפלים את מאגר GitHub שמכיל דוגמאות ל-Terraform:

   git clone https://github.com/terraform-google-modules/terraform-docs-samples.git --single-branch
   

2. עוברים לספריית העבודה:

   cd terraform-docs-samples/storage/remote_terraform_backend_template
   

בדיקת קובצי Terraform

1. בודקים את הקובץ main.tf:

   cat main.tf
   

   הפלט אמור להיראות כך:

   resource "random_id" "default" {
     byte_length = 8
   }
   
   resource "google_storage_bucket" "default" {
     name     = "${random_id.default.hex}-terraform-remote-backend"
     location = "US"
   
     force_destroy               = false
     public_access_prevention    = "enforced"
     uniform_bucket_level_access = true
   
     versioning {
       enabled = true
     }
   }
   
   resource "local_file" "default" {
     file_permission = "0644"
     filename        = "${path.module}/backend.tf"
   
     # You can store the template in a file and use the templatefile function for
     # more modularity, if you prefer, instead of storing the template inline as
     # we do here.
     content = <<-EOT
     terraform {
       backend "gcs" {
         bucket = "${google_storage_bucket.default.name}"
       }
     }
     EOT
   }

   בקובץ הזה מתוארים המשאבים הבאים:

   • ‫random_id: התוסף הזה מצורף לשם הקטגוריה של Cloud Storage כדי להבטיח שהשם יהיה ייחודי.
   • ‫google_storage_bucket: הקטגוריה של Cloud Storage שבה יישמר קובץ המצב. הקטגוריה הזו מוגדרת עם המאפיינים הבאים:
     • הערך של force_destroy מוגדר ל-false כדי לוודא שהקטגוריה לא תימחק אם יש בה אובייקטים. כך אפשר לוודא שפרטי המצב בדלי לא יימחקו בטעות.
     • האילוץ public_access_prevention מוגדר לערך enforced כדי לוודא שהתוכן של הקטגוריה לא ייחשף בטעות לציבור.
     • הערך של uniform_bucket_level_access מוגדר כ-true כדי לאפשר שליטה בגישה לקטגוריה ולתוכן שלה באמצעות הרשאות IAM במקום רשימות של בקרת גישה.
     • ‫versioning מופעל כדי להבטיח שגרסאות קודמות של המצב יישמרו בקטגוריית הקצה העורפי.
   • local_file: קובץ מקומי. התוכן של הקובץ הזה מורה ל-Terraform להשתמש בקטגוריה של Cloud Storage כבק-אנד מרוחק אחרי שהקטגוריה נוצרת.

הקצאת קטגוריה של Cloud Storage

1. מאתחלים את Terraform:

   terraform init
   

   כשמריצים את הפקודה terraform init בפעם הראשונה, הקטגוריה של Cloud Storage שצוינה בקובץ main.tf עדיין לא קיימת, ולכן Terraform מאתחל קצה עורפי מקומי כדי לאחסן את המצב במערכת הקבצים המקומית.

2. מחילים את התצורה כדי להקצות את המשאבים שמתוארים בקובץ main.tf:

   terraform apply
   

   כשתופיע בקשה, כותבים yes.

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

העברת מצב לקטגוריה של Cloud Storage

1. מעבירים את המצב של Terraform אל קצה העורפי המרוחק של Cloud Storage:

   terraform init -migrate-state
   

   מערכת Terraform תזהה שכבר קיים קובץ מצב מקומי, ותוצג שאלה אם אתם רוצים להעביר את המצב לקטגוריה החדשה של Cloud Storage. כשמופיעה בקשה, כותבים yes.

אחרי הרצת הפקודה הזו, המצב של Terraform יאוחסן בקטגוריה החדשה של Cloud Storage. לפני הרצת פקודות, המצב העדכני של Terraform יישלף מהקטגוריה הזו, ואחרי הרצת פקודות המצב העדכני יישמר בקטגוריה.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים, או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

מחיקת הפרויקט

כדי לא לצבור חיובים בחשבון Google Cloud על המשאבים שבהם השתמשתם בדף הזה, פועלים לפי השלבים הבאים.

1. פותחים את הקובץ main.tf.

2. במשאב google_storage_bucket.default, מעדכנים את הערך של force_destroy ל-true.

3. החלת ההגדרות המעודכנות:

   terraform apply
   

   כשתופיע בקשה, כותבים yes.

4. מחיקת קובץ המצב:

   rm backend.tf
   

5. הגדרת הקצה העורפי כך שיהיה מקומי:

   terraform init -migrate-state
   

   כשתופיע בקשה, כותבים yes.

6. מריצים את הפקודה הבאה כדי למחוק את משאבי Terraform:

   terraform destroy
   

   כשתופיע בקשה, כותבים yes.

המאמרים הבאים

• ניהול התשתית כקוד באמצעות Terraform, ‏Cloud Build ו-GitOps
• אימות המדיניות