אחסון מצבי 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. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

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

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

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

   • Create local authentication credentials for your user account:

     gcloud auth application-default login

     If an authentication error is returned, and you are using an external identity provider (IdP), confirm that you have signed in to the gcloud CLI with your federated identity.

3. Create or select a Google Cloud project.

   Roles required to select or create a project

   • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
   • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.
   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   • Create a Google Cloud project:

     gcloud projects create PROJECT_ID

     Replace PROJECT_ID with a name for the Google Cloud project you are creating.

   • Select the Google Cloud project that you created:

     gcloud config set project PROJECT_ID

     Replace PROJECT_ID with your Google Cloud project name.

4. Verify that billing is enabled for your Google Cloud project.

5. Enable the Cloud Storage API:

   Roles required to enable APIs

   To enable APIs, you need the Service Usage Admin IAM role (roles/serviceusage.serviceUsageAdmin), which contains the serviceusage.services.enable permission. Learn how to grant roles.

   gcloud services enable storage.googleapis.com

6. Grant roles to your user account. Run the following command once for each of the following IAM roles: roles/storage.admin

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

   Replace the following:

   • PROJECT_ID: Your project ID.
   • USER_IDENTIFIER: The identifier for your user account. For examples, see Represent workforce pool users in IAM policies.
   • ROLE: The IAM role that you grant to your user account.

   לחלופין, אפשר ליצור תפקיד 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 כדי להבטיח שם ייחודי לקטגוריה של 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
   • אימות המדיניות