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

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

1. מבוא ל-CFT 101

תאריך עדכון אחרון: 11 בפברואר 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
ביצוע בדיקות איתור שגיאות בקוד
איך שומרים את הקוד ב-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 של CFT

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

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

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

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

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

יוצרים פורק (fork) של המאגר.
מבצעים את התיקון.
שולחים בקשת משיכה (pull request) לבעלים של הפרויקט.

השלבים ליצירת פורק ממאגר CFT:

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

תוצג לכם אפשרות לבחור איפה תרצו ליצור את ה-fork, בוחרים את הפרופיל וה-repo יפורק.

שכפול המקטע המקומי שלכם

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

השלבים ליצירת עותקים מקוריים של ההסתעפות:

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

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

export SERVICE_ACCOUNT_JSON=$(< cft.json)

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

rm -rf cft.json

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

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

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 שנמצא במבנה התיקיות הבא:

הוספתם את ה-label‏ '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 לנוחות השימוש.

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

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

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

מריצים את הפקודה:

make generate_docs
# This will generate new Inputs and Outputs tables

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

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

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

מריצים את הפקודה:

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

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

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

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

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

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

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

12. מזל טוב

מזל טוב, הוספת תכונה למודול CFT ושלחת בקשת תיקון לבדיקה!

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

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