מבוא לערכת הכלים של Google Cloud Fundamentals

1. מבוא ל-CFT 101

b1d2ab0f35bb62a8.png

העדכון האחרון: 11 בפברואר 2022

מה זה Cloud Foundation Toolkit?

במילים אחרות, CFT מספקת תבניות של שיטות מומלצות כדי להתחיל במהירות ב-Google Cloud Platform. במדריך הזה תלמדו איך לתרום ל-Cloud Foundation Toolkit.

מה צריך

  • חשבון ב-GitHub.
  • ‫Docker מותקן במחשב או שמשתמשים ב-Cloud Shell ( התקנה ב-Mac, התקנה ב-Windows)
  • עורך קוד לעריכת קוד (דוגמה: Visual Studio Code)
  • היכרות בסיסית עם Git ו-GitHub
  • ניסיון מסוים עם Terraform ותשתית כקוד
  • הרשאה להקצות את התפקיד 'יצירת פרויקט' לחשבון שירות
  • ארגון ב-Google Cloud, תיקיית בדיקה וחשבון לחיוב

מה תפַתחו

ב-codelab הזה תלמדו איך לתרום ל-Cloud Foundation Toolkit ‏ (CFT).

תצטרכו:

  • הגדרת סביבת פיתוח לתרומה ל-CFT
  • הוספת תכונה למודול CFT
  • הוספת בדיקות לתכונה החדשה
  • הרצת בדיקות שילוב ב-CFT
  • ביצוע בדיקות Lint
  • ביצוע Commit של קוד ל-GitHub ושליחת בקשת משיכה (PR)

כדי לבצע את כל השלבים שלמעלה, מוסיפים תכונה חדשה למודול CFT של Google Cloud Storage. תוסיפו תווית בשם "silly_label" שתתווסף באופן אוטומטי לכל הדליים שנוצרו באמצעות מודול GCS CFT. בנוסף, תוכלו לכתוב בדיקות כדי לאמת את התכונה ולוודא שהשילוב מושלם מקצה לקצה.

2. הגדרת סביבת פיתוח

אם רוצים, אפשר להשתמש ב-Cloud Shell למטרות פיתוח. אם אתם לא רוצים להשתמש ב-Cloud Shell כדי לתרום ל-CFT, אתם יכולים להגדיר את סביבת הפיתוח במחשב שלכם.

הגדרת Git

‫GitHub מבוססת על מערכת לניהול גרסאות (VCS) בקוד פתוח שנקראת Git. ‫Git אחראי לכל מה שקשור ל-GitHub שקורה באופן מקומי במחשב או ב-Cloud Shell.

  1. כשמשתמשים ב-Cloud Shell, לא צריך להתקין את Git כי הוא מותקן מראש.
$ git --version
# This will display the git version on the Cloud Shell.

אם אתם מגדירים את סביבת הפיתוח במחשב שלכם, אתם צריכים להתקין את Git.

הגדרת שם המשתמש וכתובת האימייל ב-Git

מערכת Git משתמשת בשם משתמש כדי לשייך קומיטים לזהות. שם המשתמש ב-Git לא זהה לשם המשתמש ב-GitHub.

אפשר לשנות את השם שמשויך להתחייבויות שלכם ב-Git באמצעות הפקודה git config. שינוי השם שמשויך להתחייבויות ל-Git באמצעות git config ישפיע רק על התחייבויות עתידיות, ולא ישנה את השם ששימש להתחייבויות קודמות.

הגדרתם את Git בהצלחה ואתם יכולים ליצור עותק (fork), ליצור ולשכפל ענפים. נשתמש ב-Git באופן נרחב ב-Codelab הזה.

3. Fork CFT's GCS Repository

יצירת עותק של מאגר CFT

בשלב הקודם הגדרתם את Git במחשב המקומי או ב-Cloud Shell. עכשיו צריך ליצור Fork למאגר CFT של Google Cloud Storage כדי להתחיל לתרום.

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

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

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

  • מבצעים Fork למאגר.
  • מבצעים את התיקון.
  • שולחים בקשת משיכה לבעלי הפרויקט.

השלבים ליצירת Fork למאגר CFT:

  1. פותחים דפדפן אינטרנט ועוברים אל מאגר terraform-google-modules/terraform-google-cloud-storage. נשתמש במאגר הזה לאורך כל ה-Codelab.
  2. לוחצים על Fork בפינה הימנית העליונה של הדף.

9dc18f15ca662b56.png

  1. תוצג לכם אפשרות לבחור איפה ליצור את ה-fork. בוחרים את הפרופיל שלכם והמאגר יפוצל.

שיבוט של ה-fork באופן מקומי

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

השלבים לשכפול של ה-fork:

  1. פותחים את דפדפן האינטרנט ועוברים למזלג בכתובת terraform-google-modules/terraform-google-cloud-storage.
  2. בפינה השמאלית העליונה, לוחצים על הלחצן Code (קוד).

98f8be8df319dcd8.png

  1. אחרי שלוחצים על הלחצן Code (קוד), לוחצים על סמל ההעתקה כדי להעתיק את כתובת ה-URL של ה-fork. תשתמשו בכתובת ה-URL הזו כדי לשכפל את הפיצול לסביבה המקומית.

e61e1da6371f2a1d.png

  1. עוברים לטרמינל ב-VSCode או במחשב ומשכפלים את ה-fork.
$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.
  1. אחרי ששיבטתם את ה-fork באופן מקומי, אתם צריכים להיכנס למאגר, ליצור הסתעפות חדשה מה-fork ולבצע שינויים בקוד בהסתעפות הזמנית.

לפי המוסכמה, אפשר לתת לענף את השם הבא:

  • לגבי בקשות להוספת תכונות: feature/feature-name
  • לעדכונים פנימיים, internal/change-name
  • לתיקוני באגים: bugfix/issue-name

מכיוון שאתם מוסיפים תכונה חדשה, אתם יכולים לקרוא לענף הזמני feature/silly_label

$ cd terraform-google-cloud-storage
# This command takes you into the cloned directory on your local machine.

$ git branch
# This command tells your current branch
# When you run this for the first time after you have cloned, your 
# output should say "master", that is your fork.

$ git checkout -b feature/silly_label
# This command creates a new branch on your fork and switches your 
# branch to the newly created branch.

$ git branch
# This command will confirm your current branch to be "feature/silly_label"

ההגדרה הושלמה ואפשר להתחיל לעבוד עם Cloud Foundation Toolkit.

4. יצירת סביבת בדיקה

תהליך הפיתוח הרגיל של CFT מבוסס על שימוש בפרויקט בדיקה מבודד לבדיקות. בשלב הזה תלמדו איך ליצור את פרויקט הבדיקה (על סמך הגדרה רגילה) באמצעות חשבון שירות.

0. התקנת Docker Engine

אם אתם משתמשים במחשב למטרות פיתוח, אתם צריכים להתקין את Docker Engine.

1. התקנת Google Cloud SDK

אם אתם משתמשים ב-Cloud Shell של GCP, אתם לא צריכים להתקין את Google Cloud SDK.

עוברים אל Google Cloud SDK ומורידים את קובץ ההתקנה האינטראקטיבי לפלטפורמה שלכם.

2. הגדרת תצורה

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

export TF_VAR_org_id="your_org_id"
export TF_VAR_folder_id="your_folder_id"
export TF_VAR_billing_account="your_billing_account_id"

3. הגדרת חשבון שירות

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

3.1 יצירה או בחירה של פרויקט GCP ראשוני

לפני שיוצרים חשבון שירות, צריך לבחור פרויקט לאירוח שלו. אפשר גם ליצור פרויקט חדש.

gcloud config set core/project YOUR_PROJECT_ID

‫3.2 הפעלה של Google Cloud APIs

מפעילים את ממשקי ה-API הבאים של Google Cloud בפרויקט המקור:

gcloud services enable cloudresourcemanager.googleapis.com
gcloud services enable iam.googleapis.com
gcloud services enable cloudbilling.googleapis.com

‫3.3 יצירת חשבון שירות

יוצרים חשבון שירות חדש לניהול סביבת הבדיקה:

# Creating a service account for CFT.
gcloud iam service-accounts create cft-onboarding \
  --description="CFT Onboarding Terraform Service Account" \
  --display-name="CFT Onboarding"

# Assign SERVICE_ACCOUNT environment variable for later steps
export SERVICE_ACCOUNT=cft-onboarding@$(gcloud config get-value core/project).iam.gserviceaccount.com

מוודאים שחשבון השירות נוצר:

gcloud iam service-accounts list --filter="EMAIL=${SERVICE_ACCOUNT}"

‫3.4 מקצים לחשבון השירות את התפקידים 'יצירת פרויקטים', 'משתמש בחשבון לחיוב' ו'צפייה בארגון':

gcloud resource-manager folders add-iam-policy-binding ${TF_VAR_folder_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.projectCreator"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud beta billing accounts add-iam-policy-binding ${TF_VAR_billing_account} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/billing.user"
gcloud organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

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

4. הכנת פרטי הכניסה של Terraform

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

4.1 מפתח לחשבון שירות

יצירה והורדה של מפתח לחשבון שירות עבור Terraform

gcloud iam service-accounts keys create cft.json --iam-account=${SERVICE_ACCOUNT}

4.2 הגדרת אישורים ל-Terraform

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

export SERVICE_ACCOUNT_JSON=$(< cft.json)

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

rm -rf cft.json

5. יצירת פרויקט בדיקה לפריסות של Terraform

אחרי שסיימתם להכין את הכול, אתם יכולים ליצור את פרויקט הבדיקה באמצעות פקודה אחת. מריצים את הפקודה הבאה מהספרייה הראשית של terraform-google-cloud-storage:

make docker_test_prepare

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

macbookpro3:terraform-google-cloud-storage user$ make docker_test_prepare
docker run --rm -it \
                -e SERVICE_ACCOUNT_JSON \
                -e TF_VAR_org_id \
                -e TF_VAR_folder_id \
                -e TF_VAR_billing_account \
                -v /Users/cft/terraform-google-cloud-storage:/workspace \
                gcr.io/cloud-foundation-cicd/cft/developer-tools:0.8.0 \
                /usr/local/bin/execute_with_credentials.sh prepare_environment
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Activated service account credentials for: [cft-onboarding@<project_id>.iam.gserviceaccount.com]
Initializing modules...

Initializing the backend...

Initializing provider plugins...

The following providers do not have any version constraints in configuration,
so the latest version was installed.

To prevent automatic upgrades to new major versions that may contain breaking
changes, it is recommended to add version = "..." constraints to the
corresponding provider blocks in configuration, with the constraint strings
suggested below.

* provider.google-beta: version = "~> 3.9"
* provider.null: version = "~> 2.1"
* provider.random: version = "~> 2.2"

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
module.project.module.project-factory.null_resource.preconditions: Refreshing state... [id=8723188031607443970]
module.project.module.project-factory.null_resource.shared_vpc_subnet_invalid_name[0]: Refreshing state... [id=5109975723938185892]
module.project.module.gsuite_group.data.google_organization.org[0]: Refreshing state...
module.project.module.project-factory.random_id.random_project_id_suffix: Refreshing state... [id=rnk]
module.project.module.project-factory.google_project.main: Refreshing state... [id=<project-id>]
module.project.module.project-factory.google_project_service.project_services[0]: Refreshing state... [id=<project-id>/storage-api.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[1]: Refreshing state... [id=<project-id>/cloudresourcemanager.googleapis.com]
module.project.module.project-factory.google_project_service.project_services[2]: Refreshing state... [id=<project-id>/compute.googleapis.com]
module.project.module.project-factory.data.null_data_source.default_service_account: Refreshing state...
module.project.module.project-factory.google_service_account.default_service_account: Refreshing state... [id=projects/ci-cloud-storage-ae79/serviceAccounts/project-service-account@<project-id>.iam.gserv
iceaccount.com]
module.project.module.project-factory.google_project_service.project_services[3]: Refreshing state... [id=<project-id>/serviceusage.googleapis.com]
module.project.module.project-factory.null_resource.delete_default_compute_service_account[0]: Refreshing state... [id=3576396874950891283]
google_service_account.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_service_account_key.int_test: Refreshing state... [id=projects/<project-id>/serviceAccounts/cft-onboarding@<project-id>.iam.gserviceaccount.com/keys/351009a1e011e88049ab2097994d1c627a61
6961]
google_project_iam_member.int_test[1]: Refreshing state... [id=<project-id>/roles/iam.serviceAccountUser/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]
google_project_iam_member.int_test[0]: Refreshing state... [id=<project-id>/roles/storage.admin/serviceaccount:cft-onboarding@<project-id>.iam.gserviceaccount.com]

Apply complete! Resources: 0 added, 0 changed, 0 destroyed.

Outputs:

project_id = <test-project-id>
sa_key = <sensitive>
Found test/setup/make_source.sh. Using it for additional explicit environment configuration.

יצרתם פרויקט בדיקה שאליו מתייחסים באמצעות project_id, כפי שאפשר לראות בפלט של המסוף. סביבת הפיתוח והבדיקה שלכם מוגדרת.

5. הוספת תכונה חדשה למודול CFT

עכשיו, כשסיימתם להגדיר את סביבת הפיתוח והבדיקה, אפשר להתחיל להוסיף את התכונה silly_label למודול google-cloud-storage CFT.

מוודאים שאתם בתיקייה terraform-google-cloud-storage ופותחים את הקובץ main.tf כמו שמופיע במבנה התיקיות שלמטה.

ac1dba25408abd09.png

מכיוון ש-silly_label היא תווית, מוסיפים את התכונה בשורה 27 במשתנה labels בקובץ main.tf, כמו שמוצג בהמשך:

terraform-google-cloud-storage/main.tf

resource "google_storage_bucket" "buckets" {
 <...>
 storage_class = var.storage_class
 // CODELAB:Add silly label in labels variable
 labels        = merge(var.labels, { name = replace("${local.prefix}${lower(each.value)}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

עכשיו מוסיפים את המשתנה silly_label בקובץ variables.tf שמופיע במבנה התיקיות שלמעלה.

מעתיקים את הקוד שלמטה ומדביקים אותו בשורה 31 בקובץ variables.tf. מוודאים שיש תו של שורה חדשה מעל ומתחת לבלוק המשתנים שמוסיפים.

terraform-google-cloud-storage/variables.tf

variable "names" {
 description = "Bucket name suffixes."
 type        = list(string)
}

// CODELAB: Add "silly_label" variable to variables.tf between "names" and "location"
variable "silly_label" {
 description = "Sample label for bucket."
 type        = string
}

variable "location" {
 description = "Bucket location."
 default     = "EU"
}

6. הוספת תכונה חדשה לדוגמה של קטגוריית אחסון

הוספתם את התכונה לקובץ main.tf של המודול ועכשיו תבדקו את התכונה שהוספתם באמצעות דוגמה.

צריך להוסיף את התווית silly_label לקובץ examples/multiple-buckets/main.tf

בדוגמה הזו נשתמש בשלב הבא כדי לבצע בדיקות שילוב.

מעתיקים ומדביקים את שורת המשתנה silly_label שלמטה לשורה 27 בקובץ main.tf בנתיב terraform-google-cloud-storage/examples/multiple-buckets/, כמו שמופיע במבנה התיקיות:

5224fefbbcc61d89.png

terraform-google-cloud-storage/examples/multiple-buckets/main.tf

module "cloud_storage" {
 <...>
 // CODELAB: Add "silly_label" as an example to main.tf.
 silly_label        = "awesome"

 <..>
}

7. עדכון בדיקת תוכנית אב כדי לבדוק תכונה

הוספתם את התכונה לקובץ main.tf של המודול, ואז הוספתם את התכונה לדוגמה multiple_buckets. עכשיו צריך לבדוק את התכונה באמצעות בדיקת שילוב של תוכנית אב טיפוס שנכתבה ב-Golang.

מוסיפים את הבדיקות החדשות לקובץ multiple_buckets_test.go שנמצא במבנה התיקיות הבא:

72ea272d4792405.png

הוספתם את התווית silly_label לכל הדליים שנוצרו באמצעות המודול multiple_buckets, ועכשיו אתם צריכים לכתוב בדיקות כדי לבדוק את התכונה החדשה.

בדוגמת הקוד הבאה, מקבלים את התווית של כל דלי באמצעות הפקודה gcloud alpha storage, ואז בודקים את הפלט שמוחזר מהפקודה.

test/integration/multiple_buckets/multiple_buckets_test.go

func TestMultipleBuckets(t *testing.T) {
 <..>
op := gcloud.Run(t, fmt.Sprintf("alpha storage ls --buckets gs://%s", bucketName), gcloudArgs).Array()[0]

// verify silly label on each bucket
assert.Equal("awesome", op.Get("metadata.labels.silly").String(), "should have silly label set to awesome")

// verify lifecycle rules
...
}

8. הרצת בדיקות שילוב ב-CFT

בדיקת אינטגרציה

בדיקות שילוב משמשות לאימות ההתנהגות של מודול הבסיס, מודולי המשנה והדוגמאות. צריך לצרף בדיקות לכל תוספת, שינוי או תיקון.

בדיקות האינטגרציה נכתבות באמצעות מסגרת הבדיקה של התוכנית ומופעלות באמצעות CFT CLI. כדי שיהיה לכם נוח, הכלים האלה ארוזים בתמונת Docker.

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

בביצוע אינטראקטיבי, אתם מריצים כל שלב באמצעות כמה פקודות.

  1. מריצים את הפקודה make docker_run כדי להפעיל את קונטיינר הבדיקה של Docker במצב אינטראקטיבי.

‫Make הוא כלי לאוטומציה של בנייה, שבונה באופן אוטומטי תוכניות וספריות הפעלה מקוד מקור על ידי קריאת קבצים שנקראים Makefiles, שמציינים איך להפיק את תוכנית היעד. כשמבצעים שינויים בקובץ, קונטיינר ה-Docker צריך להתעדכן באופן אוטומטי.

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

הפלט הבא יופיע בטרמינל:

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
  1. מריצים את הפקודה module-swapper -registry-prefix=terraform-google-modules כדי לשנות את קובצי הדוגמה main.tf כך שהמודולים יובאו מהקבצים המקומיים ולא מהמודולים שפורסמו.

במסוף אמור להופיע פלט כמו זה:

[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules
2025/08/04 19:26:29 Module name set from remote to cloud-storage
2025/08/04 19:26:29 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:26:29 --- Original
+++ Modified
@@ -21,7 +21,7 @@
 }
 
 module "cloud_storage" {
-  source = "terraform-google-modules/cloud-storage/google"
+  source = "../.."
   # [restore-marker]   version = "~> 10.0"
 
   project_id = var.project_id
  1. מריצים את הפקודה cft test list כדי לראות רשימה של כל הבדיקות של תוכניות הבנייה בסביבת העבודה.

הפלט הבא יופיע בטרמינל:

[root@CONTAINER_ID workspace]# cft test list
 NAME                           | CONFIG                    | LOCATION                                                   
--------------------------------+---------------------------+------------------------------------------------------------
 TestAll/examples/simple_bucket | examples/simple_bucket    | test/integration/discover_test.go                          
 TestMultipleBuckets            | examples/multiple_buckets | test/integration/multiple_buckets/multiple_buckets_test.go 

  1. מריצים את הפקודה cft test run <EXAMPLE_NAME> --stage init כדי לאתחל את הדוגמה. במקרה הזה, כדי לאתחל את TestMultipleBuckets הרצת הבדיקה, cft test run TestMultipleBuckets --stage init. בנוסף, אפשר להשתמש בדגל --verbose כדי לקבל מידע נוסף כשמריצים בדיקות.

בשלב ההפעלה הזה, מפעילים את דוגמת Terraform.

הפלט הבא יופיע בטרמינל.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage init --verbose
INFO[02-09|08:24:31] using test-dir: test/integration 
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:179: Terraform has been successfully initialized!
...
TestMultipleBuckets 2022-02-09T08:24:35Z command.go:100: Running command terraform with args [validate]
TestMultipleBuckets 2022-02-09T08:24:36Z command.go:179: Success! The configuration is valid.
...
--- PASS: TestMultipleBuckets (4.05s)
  1. מריצים את הפקודה cft test run <EXAMPLE_NAME> --stage apply כדי להחיל את מודול הדוגמה.

בשלב הזה, הדוגמה שאותחלה בשלב הקודם מוחלת על פרויקט GCP שנוצר קודם לכן ב-Codelab.

הפלט הבא יופיע בטרמינל.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage apply --verbose
INFO[02-09|08:28:11] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Apply complete! Resources: 6 added, 0 changed, 0 destroyed.
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: Outputs:
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: 
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179: names = {
TestMultipleBuckets 2022-02-09T08:28:19Z command.go:179:   "one" = "multiple-buckets-erp1-eu-one"
...
--- PASS: TestMultipleBuckets (6.51s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.548s
  1. מריצים את הפקודה cft test run <EXAMPLE_NAME> --stage verify כדי לוודא שהתשתית שנוצרה היא התשתית הצפויה.

בשלב הזה תופעל פונקציית האימות ב-TestMultipleBuckets. בדרך כלל, האימות מתבצע באמצעות הפעלת פקודת gcloud כדי לאחזר פלט JSON של המצב הנוכחי של משאב, ולוודא שהמצב הנוכחי הוא כמו זה שמוצהר בדוגמה.

אם מופיעות שגיאות, תוכלו לראות מה היה צפוי ומה התקבל בפקודה לבדיקה.

הפלט הבא יופיע בטרמינל.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage verify --verbose
INFO[02-09|08:30:19] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command terraform with args [output -no-color -json names_list]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:179: ["multiple-buckets-erp1-eu-one","multiple-buckets-erp1-eu-two"]
TestMultipleBuckets 2022-02-09T08:30:27Z command.go:100: Running command gcloud with args [alpha storage ls --buckets gs://multiple-buckets-erp1-eu-one --project ci-cloud-storage-8ce9 --json]
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: [
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179: {
TestMultipleBuckets 2022-02-09T08:30:28Z command.go:179:   "url": "gs://multiple-buckets-erp1-eu-one/",
...
TestMultipleBuckets 2022-02-09T08:30:33Z command.go:179: ]
2022/02/09 08:30:33 RUN_STAGE env var set to verify
2022/02/09 08:30:33 Skipping stage teardown
--- PASS: TestMultipleBuckets (12.32s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    12.359s
  1. מריצים את הפקודה cft test run <EXAMPLE_NAME> --stage teardown כדי לפרק את הדוגמה.

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

אפשר לראות את הפלט הבא בטרמינל.

[root@<CONTAINER_ID> workspace]# cft test run TestMultipleBuckets --stage teardown --verbose
INFO[02-09|08:36:02] using test-dir: test/integration
...
TestMultipleBuckets 2022-02-09T08:36:06Z command.go:100: Running command terraform with args [destroy -auto-approve -input=false -lock=false]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: module.cloud_storage.random_id.bucket_suffix: Refreshing state... [id=mNA]
TestMultipleBuckets 2022-02-09T08:36:07Z command.go:179: random_string.prefix: Refreshing state... [id=erp1]
TestMultipleBuckets 2022-02-09T08:36:08Z command.go:179: module.cloud_storage.google_storage_bucket.buckets["two"]: Refreshing state... [id=multiple-buckets-erp1-eu-two]
...
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: Destroy complete! Resources: 6 destroyed.
TestMultipleBuckets 2022-02-09T08:36:10Z command.go:179: 
--- PASS: TestMultipleBuckets (6.62s)
PASS
ok      github.com/terraform-google-modules/terraform-google-cloud-storage/test/integration/multiple_buckets    6.654s
  1. מריצים את הפקודה module-swapper -registry-prefix=terraform-google-modules -restore כדי לבטל את השינויים שבוצעו בקבצים לדוגמה main.tf מהפעם האחרונה שהרצתם את module-swapper.
[root@<CONTAINER_ID> workspace]# module-swapper -registry-prefix=terraform-google-modules -restore
2025/08/04 19:30:41 Module name set from remote to cloud-storage
2025/08/04 19:36:32 Modifications made to file /workspace/examples/multiple_buckets/main.tf
2025/08/04 19:36:32 --- Original
+++ Modified
@@ -21,8 +21,8 @@
 }
 
 module "cloud_storage" {
-  source = "../.."
-   version = "~> 10.0"
+  source  = "terraform-google-modules/cloud-storage/google"
+  version = "~> 10.0"
 
   project_id = var.project_id
 
  1. מריצים את הפקודה exit כדי לצאת ממאגר הבדיקה.

9. יצירת תיעוד של קלטים ופלטים

טבלאות הקלט והפלט בקובצי ה-README של מודול השורש, מודולי המשנה ומודולי הדוגמה נוצרות באופן אוטומטי על סמך variables ו-outputs של המודולים המתאימים. אם משנים את ממשקי המודולים, צריך לרענן את הטבלאות האלה.

הפעלה:

make generate_docs
# This will generate new Inputs and Outputs tables

10. הרצת בדיקות lint ב-CFT

כלי Linter מנתח קוד מקור כדי לסמן שגיאות תכנות, באגים, שגיאות סגנוניות ומבנים חשודים.

אפשר להריץ בדיקת קוד (linting) או לעצב הרבה מהקבצים במאגר כדי לשמור על רמת איכות. כדי להבטיח איכות ב-CFT, תשתמשו בבדיקת lint.

הפעלה:

make docker_test_lint
# This will run all lint tests on your repo

11. שליחת בקשת משיכה ב-GitHub

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

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

כשיוצרים בקשת משיכה, אדמין המאגר מקבל הודעה לבדיקת השינויים המוצעים בקוד. בנוסף, אפשר להוסיף משתמשים אחרים כבודקים כדי לקבל משוב על שינויי הקוד. בקשת ה-PR תפעיל את Cloud Build, שיריץ בדיקות במאגר.

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

כדי לבצע קומיט של קוד להסתעפות המפוצלת ולדחוף קוד להסתעפות המפוצלת, מבצעים את השלבים הבאים:

  1. השלב הראשון הוא להוסיף את הקבצים ששונו למאגר המקומי.
$ git add main.tf
$ git add README.md
$ git add variables.tf
$ git add examples/multiple-buckets/main.tf
$ git add test/integration/multiple_buckets/multiple_buckets_test.go
# The ‘git add' command adds the file in the local repository and 
# stages the file for commit. To unstage a file, use git reset HEAD YOUR-FILE
  1. הקבצים שלכם נמצאים עכשיו בשלב ההכנה, ועכשיו תבצעו את השינויים.
$ git commit -m "First CFT commit"
# This will commit the staged changes and prepares them to be pushed 
# to a remote repository. To remove this commit and modify the file, 
# use 'git reset --soft HEAD~1' and commit and add the file again.
  1. מעלים את השינויים שבוצעו במאגר המקומי ל-GitHub כדי ליצור בקשת משיכה (PR).
$ git push -u origin feature/silly_label
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

השינויים בקוד מוכנים עכשיו לשליחת בקשת משיכה.

כדי ליצור בקשת משיכה (PR) אל המאגר terraform-google-modules/terraform-google-cloud-storage , מבצעים את השלבים הבאים:

  1. בדפדפן האינטרנט, עוברים לדף הראשי של repo.
  2. יוצג באנר עם הצעה לפתוח בקשת מיזוג מהמזלג. לוחצים על 'השוואה ובקשת משיכה'.

60e7ae0cbc11588e.png

  1. מזינים כותרת ותיאור לבקשת משיכת השינויים כדי לתאר את השינויים בקוד. התשובה צריכה להיות ספציפית ככל שניתן, אבל גם תמציתית.

f4302385e9e1776a.png

  1. כדי ליצור בקשת משיכה שמוכנה לבדיקה, לוחצים על 'יצירת בקשת משיכה'.
  2. יוצגו טריגרים של Cloud Build שמופעלים בגלל ה-PR.
  3. אם נתקלתם בבעיות, תוכלו לעיין במסמכים הרשמיים של GitHub בנושא פתיחת בקשות משיכה ממזלגות.

העברת בהצלחה את שינוי הקוד הראשון שלך לענף המפוצל ויצרת את בקשת ה-PR הראשונה של CFT לענף הראשי.

12. מזל טוב

מזל טוב, הוספת תכונה למודול CFT והגשת בקשת מיזוג לבדיקה.

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

עכשיו אתם יודעים מהם השלבים החשובים להתחלת העבודה עם Cloud Foundation Toolkit.