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

1. מבוא ל-CFT 101

ea557448aaa1fffc.png

עדכון אחרון:3 במרץ 2020

מהו Cloud Fundamentals Toolkit?

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

מה צריך להכין

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

מה תפַתחו

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

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

3. מאגר GCS של Fork CFT

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

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

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

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

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

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

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

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

e3894c6de6a732b4.png

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

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

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

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

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

3bfa87b9f7f01f61.png

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

dbf3682d004e0ee0.png

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

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

  • לשליחת בקשות להוספת תכונות: 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 organizations add-iam-policy-binding ${TF_VAR_org_id} \
  --member="serviceAccount:${SERVICE_ACCOUNT}" \
  --role="roles/resourcemanager.organizationViewer"

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

4. מקצים את התפקיד 'משתמש בחשבון לחיוב' במשאב של החשבון לחיוב

4.1 אחזור מדיניות ה-IAM של החשבון לחיוב

הורדת קישורי מדיניות ה-IAM הקיימים בחשבון לחיוב

gcloud beta billing accounts get-iam-policy ${TF_VAR_billing_account} | tee policy.yml

4.2 מעדכנים את המדיניות כך שתכלול את חשבון השירות

כדי להוסיף קישור חדש לחשבון השירות עם התפקיד roles/billing.user, צריך לעדכן את הקובץ policy.yml

bindings:
- members:
  - serviceAccount:cft-onboarding@<YOUR_PROJECT_ID>.iam.gserviceaccount.com
  role: roles/billing.user

4.3 עדכון המדיניות בנושא חשבון לחיוב

החלת השינויים בחשבון לחיוב

gcloud beta billing accounts set-iam-policy ${TF_VAR_billing_account} policy.yml

5. הכנת פרטי כניסה ל-Terraform

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

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

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

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

5.2 הגדרת פרטי כניסה ל-Terraform

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

export SERVICE_ACCOUNT_JSON=$(< cft.json)

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

17f2d3b9893be853.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(element(var.names, count.index))}", ".", "-") }, { "silly" = var.silly_label })
 force_destroy = lookup(
 <...>
}

בשלב הזה עליכם להוסיף את המשתנה silly_label בקובץ המשתנים.tf שמוצג במבנה של התיקיות שלמעלה.

מעתיקים את הקוד שבהמשך ומדביקים אותו בשורה 29 ב-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/ , כפי שמוצג במבנה התיקייה:

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

את הבדיקות החדשות תוסיפו בקובץ gsutil.rb שנמצא במבנה התיקיות הבא:

b2bfeb203477e0c8.png

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

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

terraform-google-cloud-storage/test/integration/multiple-buckets/controls/gsutil.rb

control "gsutil" do
 <..>

# CODELAB: Copy paste the below test in gsutil.rb to test silly_label feature.

# command to get the labels for bucket_1
describe command("gsutil label get gs://#{attribute("names_list")[0]}") do
   //check if the command gave a valid response
   its(:exit_status) { should eq 0 }
   its(:stderr) { should eq "" }

   //parse the command's output into JSON
   let!(:data) do
     if subject.exit_status == 0
         JSON.parse(subject.stdout)
     else
         {}
     end
   end

   # check if bucket_1 has the new "silly" label with the value "awesome"
   describe "bucket_1" do
   it "has label" do
       data.each do |bucket|
           expect(data["silly"]).to include("awesome")
       end
     end
   end
 end

8. ביצוע בדיקות אינטגרציה ב-CFT

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

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

בדיקות השילוב מריצים באמצעות Kitchen, Kitchen-Terraform ו-InSpec. הכלים האלו נארזים בתוך קובץ אימג' של Docker לנוחותכם.

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

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

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

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

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

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

Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
  1. מריצים את הפקודה kitchen_do list כדי להציג את רשימת כל המכונות בסביבת העבודה שמכילות בדיקות שילוב.
     You will see the below output in your terminal.

[root@<CONTAINER_ID> workspace]# kitchen_do list
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
Instance                  Driver     Provisioner  Verifier   Transport  Last Action  Last Error
multiple-buckets-default  Terraform  Terraform    Terraform  Ssh        Verified     <None>
  1. מריצים את הפקודה kitchen_do create <EXAMPLE_NAME> כדי לאתחל את ספריית העבודה של מודול לדוגמה.

השלב הזה מפעיל את המטבח ומאתחל את טרפורמה בסביבת העבודה.

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

[root@<CONTAINER_ID> workspace]# kitchen_do create multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<PROJECT_ID>.iam.gserviceaccount.com]
-----> Starting Kitchen (v1.24.0)
-----> Creating <multiple-buckets-default>...
       Terraform v0.12.12
       + provider.google v3.10.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from www.terraform.io/downloads.html
$$$$$$ Running command `terraform init -input=false -lock=true -lock-timeout=0s  -upgrade -force-copy -backend=true  -get=true -get-plugins=true -verify-plugins=true` in directory /workspace/test/fi
xtures/multiple_buckets
       Upgrading modules...
       - example in ../../../examples/multiple_buckets
       - example.cloud_storage in ../../..
       
       Initializing the backend...
       
       Initializing provider plugins...
       - Checking for available provider plugins...
       - Downloading plugin for provider "google" (hashicorp/google) 2.18.1...
       - Downloading plugin for provider "random" (hashicorp/random) 2.2.1...
       
       Terraform has been successfully initialized!
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
       Finished creating <multiple-buckets-default> (0m11.01s).
-----> Kitchen is finished. (0m12.62s)
  1. מריצים את הפקודה kitchen_do converge <EXAMPLE_NAME> כדי להחיל את המודול לדוגמה.

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

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

[root@<CONTAINER_ID> workspace]# kitchen_do converge multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [cft@<YOUR_PROJECT_ID>.iam.gserviceaccount.com]
-----> Starting Kitchen (v1.24.0)
-----> Converging <multiple-buckets-default>...
       Terraform v0.12.20
       + provider.google v3.9.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from https://www.terraform.io/downloads.html
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
$$$$$$ Running command `terraform get -update` in directory /workspace/test/fixtures/multiple_buckets
       - example in ../../../examples/multiple_buckets
       - example.cloud_storage in ../../..
$$$$$$ Running command `terraform validate   ` in directory /workspace/test/fixtures/multiple_buckets
       Success! The configuration is valid.
       
$$$$$$ Running command `terraform apply -lock=true -lock-timeout=0s -input=false -auto-approve=true  -parallelism=10 -refresh=true  ` in directory /workspace/test/fixtures/multiple_buckets
       random_pet.main: Creating...
       random_pet.main: Creation complete after 0s [id=<BUCKET-ID>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Creating...
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Creating...
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Creation complete after 3s [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Creation complete after 3s [id=<BUCKET-ID-02>]
       
       Apply complete! Resources: 3 added, 0 changed, 0 destroyed.
       
       Outputs:
       
       names = {
         "one" = "<BUCKET-ID-01>"
         "two" = "<BUCKET-ID-02>"
       }
       names_list = [
         "<BUCKET-NAME-01>",
         "<BUCKET-NAME-02>",
       ]
       project_id = ci-cloud-storage-ae79
       Finished converging <multiple-buckets-default> (0m7.17s).
-----> Kitchen is finished. (0m8.77s)
  1. מריצים את הפקודה kitchen_do verify <EXAMPLE_NAME> כדי לבדוק את המודול לדוגמה.

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

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

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

multiple_buckets local: Verifying

Profile: multiple_buckets
Version: (not specified)
Target:  local://

  ✔  gsutil: gsutil
     ✔  Command: `gsutil ls -p <PROJECT_ID>` exit_status should eq 0
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stderr should eq ""
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stdout should include "multiple-buckets-mzgy-eu-one"
     ✔  Command: `gsutil ls -p <PROJECT_ID>` stdout should include "<BUCKET-ID-01>"
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-01>` stdout should include "Enabled: True"
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` stderr should eq ""
     ✔  Command: `gsutil bucketpolicyonly get gs://<BUCKET-ID-02>` stdout should include "Enabled: False"
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil label get gs://<BUCKET-ID-01>` bucket_1 has label
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` stderr should eq ""
     ✔  Command: `gsutil label get gs://<BUCKET-ID-02>` bucket_2 has label
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq "NEARLINE"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq "SetStorageClass"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq 10
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq false
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` should eq ["MULTI_REGIONAL", "STANDARD", "DURABLE_REDUCED_AVAILABILITY"]
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` exit_status should eq 0
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-01>` stderr should eq ""
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq "NEARLINE"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq "SetStorageClass"
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq 10
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq false
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` should eq ["MULTI_REGIONAL", "STANDARD", "DURABLE_REDUCED_AVAILABILITY"]
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` exit_status should eq 0
     ✔  Command: `gsutil lifecycle get gs://<BUCKET-ID-02>` stderr should eq ""


Profile Summary: 1 successful control, 0 control failures, 0 controls skipped
Test Summary: 30 successful, 0 failures, 0 skipped
       Finished verifying <multiple-buckets-default> (0m8.83s).
-----> Kitchen is finished. (0m16.61s)
  1. מריצים את הפקודה kitchen_do destroy <EXAMPLE_NAME> כדי להשמיד את מצב המודול לדוגמה.

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

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

[root@<CONTAINER_ID> workspace]# kitchen_do destroy multiple-buckets-default
Automatically setting inputs from outputs of test/setup
Found test/source.sh. Using it for additional explicit environment configuration.
Activated service account credentials for: [ci-cloud-storage@ci-cloud-storage-54ab.iam.gserviceaccount.com]
-----> Starting Kitchen (v1.24.0)
-----> Destroying <multiple-buckets-default>...
       Terraform v0.12.12
       + provider.google v3.10.0
       
       Your version of Terraform is out of date! The latest version
       is 0.12.21. You can update by downloading from www.terraform.io/downloads.html
$$$$$$ Running command `terraform init -input=false -lock=true -lock-timeout=0s  -force-copy -backend=true  -get=true -get-plugins=true -verify-plugins=true` in directory /workspace/test/fixtures/mu
ltiple_buckets
       Initializing modules...
       
       Initializing the backend...
       
       Initializing provider plugins...
       
       Terraform has been successfully initialized!
$$$$$$ Running command `terraform workspace select kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
$$$$$$ Running command `terraform destroy -auto-approve -lock=true -lock-timeout=0s -input=false  -parallelism=10 -refresh=true  ` in directory /workspace/test/fixtures/multiple_buckets
       random_string.prefix: Refreshing state... [id=mzgy]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Refreshing state... [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Refreshing state... [id=<BUCKET-ID-02>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Destroying... [id=<BUCKET-ID-01>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Destroying... [id=<BUCKET-ID-02>]
       module.example.module.cloud_storage.google_storage_bucket.buckets[0]: Destruction complete after 1s
       module.example.module.cloud_storage.google_storage_bucket.buckets[1]: Destruction complete after 2s
       random_string.prefix: Destroying... [id=mzgy]
       random_string.prefix: Destruction complete after 0s
       
       Destroy complete! Resources: 3 destroyed.
$$$$$$ Running command `terraform workspace select default` in directory /workspace/test/fixtures/multiple_buckets
       Switched to workspace "default".
$$$$$$ Running command `terraform workspace delete kitchen-terraform-multiple-buckets-default` in directory /workspace/test/fixtures/multiple_buckets
       Deleted workspace "kitchen-terraform-multiple-buckets-default"!
       Finished destroying <multiple-buckets-default> (0m6.49s).
-----> Kitchen is finished. (0m8.10s)

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

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

הפעלה:

make generate_docs
# This will generate new Inputs and Outputs tables

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

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

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

הפעלה:

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

11. שליחת PR ב-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/controls/gsutil.rb
# 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 master
# Pushes the changes in your local repository up to the remote
# repository you specified as the origin

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

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

  1. בדפדפן האינטרנט, עוברים לדף הראשי של המאגר.
  2. בתפריט Branch, בוחרים את המזלג שמכיל את ההתחייבויות שלכם.
  3. מימין ל'הסתעפות' לוחצים על New pull request.

40087ce52ee5ed35.png

  1. שימוש בבסיס הבסיס כדי לבחור את ההסתעפות שאליה ברצונך למזג את השינויים. בדרך כלל זה ה'ראשי' הסתעפות, כי ביצעתם שינויים בקוד במזלג.
  2. מזינים שם ותיאור לבקשת המשיכה שמתארים את השינויים בקוד. התשובה צריכה להיות ספציפית ככל האפשר ותמציתית.
  3. כדי ליצור בקשת משיכה שמוכן לבדיקה, לוחצים על Create Pull Request.

a9e70a2ec9653cd7.png

  1. יוצגו טריגרים של Cloud Build שמופעלים בגלל ה-PR.

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

12. מזל טוב

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

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

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