דף זה תורגם על ידי Cloud Translation API.

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

1. מבוא ל-CFT 101

עדכון אחרון:11.02.2022

מהו Cloud Fundamentals Toolkit?

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

מה צריך להכין

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

מה תפַתחו

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

אתם:

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

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

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

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

הגדרת Git

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

כשמשתמשים ב-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 ותהיה לך אפשרות לפצל, ליצור ולשכפל הסתעפויות. אנחנו נשתמש ב-Git באופן נרחב ב-Codelab הזה.

3. מאגר GCS של Fork CFT

פיצול מאגר של CFT

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

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

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

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

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

השלבים לחיבור מאגר CFT:

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

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

שכפול המזלג באופן מקומי

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

שלבים לשכפול המזלג:

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

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

נכנסים לטרמינל ב-VSCode או במכונה ומשכפלים את המזלג.

$ git clone <url>
# This command will clone your fork locally.
# Paste the copied URL from the previous step.

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

המוסכמה הבאה היא לתת לסניף שלך שם:

לשליחת בקשות להוספת תכונות: 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.

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, ומגדירים את הערך ל-contents של המפתח של חשבון השירות.

export SERVICE_ACCOUNT_JSON=$(< cft.json)

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

rm -rf cft.json

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

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

make docker_test_prepare

הפלט הבא יופיע כשמריצים את הפקודה make docker_test_prepare. בסוף יתקבל הפרמטר project_id לבדיקה שנוצר , שבו תפרסו ותבדקו את המודול של 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" למודול ה-CFT google-cloud-storage.

מוודאים שנמצאים בקובץ terraform-google-cloud-storage ופותחים את הקובץ main.tf כפי שמוצג בהמשך, במבנה התיקייה.

מאז "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 בקובץ המשתנים.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" צריך להוסיף אותו לדוגמאות/multi-buckets/main.tf

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

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

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 של המודול, ולאחר מכן הוספתם את התכונה לדוגמה multi_buckets. עכשיו צריך לבדוק את התכונה באמצעות בדיקת שילוב של תוכנית שכתובה ב-Golang.

יש להוסיף את הבדיקות החדשות בקובץ Multiple_buckets_test.go שנמצא במבנה התיקיות הבא:

הוספת את התווית '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

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

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

בדיקות השילוב נכתבות באמצעות התוכנית לבדיקת ה-framework ומופעלות באמצעות CFT CLI. הכלים האלו נארזים בתוך קובץ אימג' של Docker לנוחותכם.

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

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

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

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

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

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

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]

מריצים את הפקודה 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

כדי לאתחל את הדוגמה, מריצים את הפקודה 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)

מריצים את הפקודה 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

מריצים את הפקודה cft test run <EXAMPLE_NAME> --stage verify כדי לוודא שהדוגמה יצרה את התשתית הצפויה.

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

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

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

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

מריצים את הפקודה 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

מריצים את הפקודה exit כדי לצאת ממאגר התגים.

9. יצירת מסמכים לקלט ולפלט

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

הפעלה:

make generate_docs
# This will generate new Inputs and Outputs tables

10. ביצוע בדיקות לאיתור שגיאות בקוד ב-CFT

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

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

הפעלה:

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

11. שליחת PR ב-GitHub

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

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

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

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

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

השלב הראשון הוא להוסיף קבצים שהשתנו למאגר המקומי.

$ 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

הקבצים שלך מוכנים עכשיו בשלבי הכנה, ואז עליך לשמור את השינויים.

$ 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.

מעבירים את השינויים שבוצעו במאגר המקומי ל-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

השינויים בקוד שלך מוכנים עכשיו לבקשת משיכה!

מבצעים את השלבים הבאים כדי ליצור יחסי ציבור למאגר terraform-google-Modules/terraform-google-cloud-storage :

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

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

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

העברתם בהצלחה את שינוי הקוד הראשון להסתעפות המחוברת, והגדלתם את ה-CFT הראשון שלכם ביחס להסתעפות הראשית!

12. מזל טוב

כל הכבוד! הוספתם בהצלחה תכונה למודול CFT ושלחתם יחסי ציבור לבדיקה!

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

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