הגדרת CI/CD לאחסון הגדרות Terraform כקוד

במדריך הזה נסביר איך לנהל את התשתית כקוד באמצעות Terraform ו-Cloud Build, עם השיטה הפופולרית GitOps. את המונח GitOps טבעו במקור ב-Weaveworks, והעיקרון הראשי שלו הוא שימוש במאגר של Git לאחסון מצב הסביבה שרוצים. ‫Terraform הוא כלי בקוד פתוח של HashiCorp שמאפשר ליצור, לשנות ולשפר בצורה חזויה את תשתית הענן באמצעות קוד. במדריך הזה נלמד איך נעזרים ב-Cloud Build, שירות Google Cloud אינטגרציה רציפה (CI), כדי ליישם אוטומטית מניפסטים של Terraform בסביבה שלכם.

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

בדוחות של State of DevOps מפורטות יכולות שמשפרות את הכנת התוכנות להפצה. במדריך הזה תלמדו על היכולות הבאות:

• ניהול הגרסאות
• אינטגרציה רציפה (CI)
• פיתוח רציף (continuous delivery)
• בדיקות רציפות

ארכיטקטורה

במדריך הזה אנחנו משתמשים בשיטות של GitOps לניהול פעולות של Terraform. שימו לב שהשתמשנו בהסתעפויות של Secure Source Manager – dev ו-prod – כדי לייצג את הסביבות בפועל. הסביבות האלה מוגדרות על ידי רשתות של ענן וירטואלי פרטי (VPC) – dev ו-prod, בהתאמה – בGoogle Cloud פרויקט.

התהליך מתחיל כשדוחפים את הקוד של Terraform להסתעפות dev או prod. במקרה הזה, מפעילים את Cloud Build ומיישמים מניפסטים של Terraform כדי להגיע למצב הרצוי בסביבה הרלוונטית. מנגד, כשדוחפים קוד של Terraform לכל הסתעפות אחרת, למשל הסתעפות של מאפיין, Cloud Build פועל כדי לבצע את terraform plan אבל שום דבר לא מיושם על אף סביבה.

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

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

מטרות

• מגדירים את המאגר ואת מופע Secure Source Manager.
• הגדרת Terraform לאחסון מצבים בקטגוריות של Cloud Storage.
• מתן הרשאות לחשבון השירות ב-Cloud Build.
• חיבור של Cloud Build למאגר שלכם ב-Secure Source Manager.
• שינוי התצורה של הסביבה בסביבה נפרדת (feature branch).
• ליישם שינויים בסביבת הפיתוח.
• ליישם שינויים בסביבת הייצור.

עלויות

במסמך הזה משתמשים ברכיבים הבאים של Google Cloud, והשימוש בהם כרוך בתשלום:

• Cloud Build
• Cloud Storage
• Compute Engine

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

משתמשים חדשים של Google Cloud ? יכול להיות שאתם זכאים לתקופת ניסיון בחינם.

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

לפני שמתחילים

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

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

Roles required to select or create a project

• Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
• Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

Go to project selector

Verify that billing is enabled for your Google Cloud project.

1. במסוף Google Cloud , מפעילים את Cloud Shell.

   הפעלת Cloud Shell

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

2. מאתרים ב-Cloud Shell את המזהה של הפרויקט שבחרתם:
   ‫

   gcloud config get-value project

   אם הפקודה לא מחזירה את מזהה הפרויקט, מגדירים את Cloud Shell להשתמש בפרויקט. מחליפים את PROJECT_ID במזהה הפרויקט.

   gcloud config set project PROJECT_ID

3. מפעילים את ממשקי ה-API הנדרשים:

   gcloud services enable cloudbuild.googleapis.com compute.googleapis.com securesourcemanager.googleapis.com

   השלב הזה עשוי להימשך כמה דקות.
4. אם עדיין לא השתמשתם ב-Git ב-Cloud Shell, תצטרכו להגדיר את Git עם השם וכתובת האימייל שלכם:

   git config --global user.email "YOUR_EMAIL_ADDRESS"
   git config --global user.name "YOUR_NAME"
   

   המידע הזה ישמש את Git לזיהוי כשאתם יוצרים התחייבויות ב-Cloud Shell.

הגדרת מאגר Secure Source Manager

במדריך הזה נשתמש במאגר אחד של Secure Source Manager כדי להגדיר את תשתית הענן שלכם. מתזמרים את התשתית הזו באמצעות הסתעפויות שונות שמתאימות לסביבות השונות:

• ההסתעפות dev כוללת את השינויים האחרונים שבוצעו בסביבת הפיתוח.
• ההסתעפות prod כוללת את השינויים האחרונים שבוצעו בסביבת הייצור.
• ענפים של תכונות, בדומה ל-feature_x, משמשים לביצוע שינויים לפני שמעבירים אותם לענפים dev או prod.

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

1. יוצרים מאגר ריק ב-Secure Source Manager – לא מאתחלים את המאגר.

2. מריצים את הפקודה הבאה כדי להוסיף את כלי העזר לאימות של Secure Source Manager ל-git config הגלובלי:

   git config --global credential.'https://*.*.sourcemanager.dev'.helper gcloud.sh
   

   עוזר האימות משתמש ב-CLI של gcloud כדי לאחזר את פרטי הכניסה שלכםGoogle Cloud כשמשתמשים בפקודות Git עם Secure Source Manager.

3. כדי לבצע אימות מחדש אחרי ההגדרה הראשונית של פרטי הכניסה, מריצים ב-CLI של gcloud את הפקודה הבאה:

   gcloud auth login
   

4. משכפלים את המאגר solutions-terraform-cloudbuild-gitops אל מעטפת מקומית או סביבת עבודה:

   git clone https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git
   

5. מוסיפים את המאגר של Secure Source Manager כמאגר במעלה הזרם.

   git remote add google HTTPS_REPO_URL
   

   כאשר HTTPS_REP_URL היא כתובת ה-URL של ה-HTTPS למאגר Secure Source Manager. כתובת ה-URL מופיעה בחלק העליון של דף המאגר בממשק האינטרנט של Secure Source Manager.

6. יוצרים את הענף dev ועוברים אליו.

   git checkout dev
   

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

   git push -u google --all
   

8. חוזרים על שני השלבים הקודמים עבור הענף prod.

כך בנוי הקוד במאגר הזה:

• התיקייה environments/ מכילה תיקיות משנה שמייצגות סביבות, כמו dev או prod, כדי לאפשר הפרדה לוגית בין עומסי עבודה (workloads) בשלבים שונים של ותק, פיתוח וייצור. מומלץ להגדיר את הסביבות האלה בצורה דומה ככל האפשר, אבל לכל תיקיית משנה יכולות להיות הגדרות ייחודיות משלה ב-Terraform, לפי הצורך.

• התיקייה modules/ מכילה מודולים מוטבעים של Terraform, שמייצגים קבוצות לוגיות של מקורות קשורים, ומשמשים לשיתוף הקוד בסביבות השונות.

• cloudbuild.yaml הוא קובץ תצורה של build שמכיל הוראות ל-Cloud Build, כמו סדרת פעולות לביצוע משימות. הקובץ הזה מציין שההפעלה מותנית בהתאם להסתעפות של Cloud Build שממנה הקוד נלקח. לדוגמה:

  • להסתעפויות dev ו-prod, מבצעים את הפעולות הבאות:

    1. terraform init
    2. terraform plan
    3. terraform apply

  • בכל הסתעפות אחרת, מבצעים את הפעולות הבאות:

    1. terraform init בכל environments תיקיות המשנה
    2. terraform plan בכל environments תיקיות המשנה

כדי לוודא שהשינויים המוצעים מתאימים לכל סביבה, terraform init ו-terraform plan פועלים בכל environments תיקיות המשנה. כך למשל, לפני מיזוג בקשת המשיכה תוכלו לבדוק את התוכניות כדי לוודא שלא ניתנה גישה לישות לא מורשית.

שינוי קובץ תצורת ה-build

כדי שקובץ התצורה לדוגמה של ה-build יפעל עם Secure Source Manager, צריך לבצע את השינויים הבאים:

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

עורכים את קובץ תצורת ה-build בענף dev:

1. עוברים לענף dev:

   git checkout dev
   

2. פותחים את הקובץ cloudbuild.yaml ומחליפים את התוכן שלו בתוכן הבא:

   # Copyright 2019 Google LLC
   #
   # Licensed under the Apache License, Version 2.0 (the "License");
   # you may not use this file except in compliance with the License.
   # You may obtain a copy of the License at
   #
   #     https://www.apache.org/licenses/LICENSE-2.0
   #
   # Unless required by applicable law or agreed to in writing, software
   # distributed under the License is distributed on an "AS IS" BASIS,
   # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   # See the License for the specific language governing permissions and
   # limitations under the License.
   
   
   steps:
   - id: 'clone repository'
     name: 'gcr.io/cloud-builders/git'
     args:
     - clone
     - '${_REPO_URL}'
     - .
   - id: 'branch name'
     name: gcr.io/cloud-builders/git
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         git checkout ${branch}
         echo "***********************"
         git branch --show-current
         echo "***********************"
   
   - id: 'tf init'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
      branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform init
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFORM INIT ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform init || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi
   
   - id: 'tf apply'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform apply -auto-approve
         else
           echo "***************************** SKIPPING APPLYING *******************************"
           echo "Branch '${branch}' does not represent an official environment."
           echo "*******************************************************************************"
         fi

3. בודקים שהקובץ שונה.

   git status
   

4. שומרים ודוחפים את השינויים:

   git add --all
   git commit -m "Modify build config file."
   git push google dev
   

5. פותחים בקשת משיכה כדי לקדם במהירות את השינויים שלכם לענף prod.

   1. בממשק האינטרנט של Secure Source Manager, עוברים למאגר.
   2. לוחצים על הכרטיסייה Pull requests.
   3. לוחצים על New pull request.
   4. בשדה merge into:, בוחרים את הענף prod.
   5. בשדה pull from:, בוחרים את הענף dev.
   6. בודקים את השינויים ולוחצים על New pull request (בקשת מיזוג חדשה).
   7. לוחצים על Create pull request.
   8. לוחצים על Merge pull request.

   9. לוחצים שוב על Merge pull request.

      השינויים ימוזגו עם הענף prod.

הגדרת Terraform לאחסון מצבים בקטגוריות של Cloud Storage

כברירת מחדל, המצבים של Terraform נשמרים מקומית בקובץ בשם terraform.tfstate. ברירת המחדל הזו עלולה להקשות על צוותים להשתמש ב-Terraform, במיוחד כשהרבה אנשים משתמשים ב-Terraform במקביל, וכל מכונה רואה את התשתית הקיימת בדרך משלה.

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

# Copyright 2019 Google LLC
#
# Licensed under the Apache License, Version 2.0 (the "License");
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
#     https://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an "AS IS" BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.


terraform {
  backend "gcs" {
    bucket = "PROJECT_ID-tfstate"
    prefix = "env/dev"
  }
}

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

1. יוצרים את הקטגוריה של Cloud Storage ב-Cloud Shell:

   PROJECT_ID=$(gcloud config get-value project)
   gcloud storage buckets create gs://${PROJECT_ID}-tfstate
   

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

   gcloud storage buckets update gs://${PROJECT_ID}-tfstate --versioning
   

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

3. יוצרים ענף cloud-storage-bucket חדש כדי לבצע בו את השינויים:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout -b cloud-storage-bucket
   

4. מחליפים את ה-placeholder הזה PROJECT_ID במזהה הפרויקט בקובץ terraform.tfvars וגם בקובץ backend.tf:

   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

   ב-OS X או ב-macOS, יכול להיות שתצטרכו להוסיף שתי מירכאות ("") אחרי sed -i, באופן הבא:

   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
   sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf
   

5. בודקים אם כל הקבצים עודכנו:

   git status
   

   הפלט אמור להיראות כך:

   On branch cloud-storage-bucket
   Changes not staged for commit:
   (use "git add ..." to update what will be committed)
   (use "git restore ..." to discard changes in working directory)
          modified:   environments/dev/backend.tf
          modified:   environments/dev/terraform.tfvars
          modified:   environments/prod/backend.tf
          modified:   environments/prod/terraform.tfvars
   no changes added to commit (use "git add" and/or "git commit -a")
   

6. שומרים ודוחפים את השינויים:

   git add --all
   git commit -m "Update project IDs and buckets"
   git push google -u cloud-storage-bucket
   

   הענף החדש cloud-storage-bucket נדחף למאגר.

7. כדי למזג את השינויים ב-cloud-storage-bucket עם הענפים dev ו-prod, פותחים בקשות מיזוג לכל ענף ושולחים אותן.

מתן הרשאות לחשבון השירות ב-Cloud Build

כדי לאפשר לחשבון השירות של Cloud Build להריץ סקריפטים של Terraform לניהול משאבי Google Cloud , צריך לתת לו את הרשאת הגישה המתאימה לפרויקט. כדי לשמור על הסבר פשוט, במדריך נתנו גישה לעורך הפרויקטים. בסביבות ייצור, חשוב להקפיד על נוהלי אבטחת IT של החברה שלכם, ובדרך כלל לתת הרשאות גישה מינימליות.

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

1. כדי למצוא את כתובת האימייל בחשבון השירות ב-Cloud Build, עוברים לדף Settings בדף Cloud Build.

   כניסה להגדרות של Cloud Build

2. מעתיקים את הערך של כתובת האימייל בחשבון השירות.

3. נותנים לחשבון השירות ב-Cloud Build את הרשאת הגישה הנדרשת:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member serviceAccount:CLOUDBUILD_SA --role roles/editor
   

   מחליפים את מה שכתוב בשדות הבאים:

   • PROJECT_ID במזהה הפרויקט.
   • ‫CLOUDBUILD_SA מחליפים בכתובת האימייל של חשבון השירות ב-Cloud Build.

חיבור ל-Cloud Build

כדי להפעיל את Cloud Build כשמעבירים בדחיפה לכל ענף, צריך להגדיר webhook של Secure Source Manager. קובץ הגדרות ה-build יבדוק את שם הענף כדי לקבוע אם צריך לבצע שינויים בסביבות dev או prod.

1. מפעילים ומגדירים את Cloud Build בפרויקט.

2. פותחים את הדף Triggers במסוף Google Cloud .

   פתיחת הדף Triggers

3. בוחרים את הפרויקט מהתפריט הנפתח לבחירת פרויקט בחלק העליון של הדף.

4. לוחצים על פתיחה.

5. לוחצים על Create trigger (יצירת ביטוי להפעלה).

6. מזינים את הגדרות הטריגר הבאות:

   • Name (שם): trigger-on-push

   • אזור: בוחרים את האזור של הטריגר. אם בקובץ הגדרות ה-build שמשויך לטריגר מוגדר מאגר פרטי, האזור שבוחרים לטריגר צריך להיות זהה לאזור של המאגר הפרטי.

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

     אם בוחרים באפשרות global כאזור, Cloud Build משתמש באזור שצוין בקובץ הגדרות ה-build כדי להריץ את ה-build. האזור הזה יכול להיות האזור של המאגר הפרטי, אם מציינים מאגר פרטי בקובץ תצורת build, או מאגר ברירת המחדל הגלובלי אם לא מציינים מאגר פרטי.

   • תיאור (אופציונלי): מזינים תיאור להפעלה.

   • אירוע: בוחרים באפשרות אירוע של פעולה מאתר אחר (webhook) כאירוע המאגר להפעלת הטריגר.

     אם Secret Manager לא מותקן, תופיע בקשה להפעיל אותו.

   • Webhook URL (כתובת ה-URL של ה-webhook): בוחרים באחת מהאפשרויות הבאות:

     • שימוש בסוד חדש אם רוצים ליצור סוד חדש באמצעות Cloud Build. לוחצים על יצירת Secret כדי ליצור את ה-Secret.
     • משתמשים בסוד קיים או יוצרים סוד משלכם אם רוצים להשתמש בסוד קיים. מזינים את הסוד ואת הגרסה בתיבות הבחירה בתפריט הנפתח.

     אם משתמשים בסוד קיים, יכול להיות שיהיה צורך להקצות ידנית את התפקיד Secret Manager Secret Accessor לסוכן השירות של Cloud Build ‏[e-mail].

     מידע נוסף זמין במאמר הענקת תפקיד לסוכן השירות של Cloud Build.

7. לוחצים על הצגת תצוגה מקדימה של כתובת ה-URL ורושמים את כתובת ה-URL. תצטרכו את כתובת ה-URL הזו כדי להגדיר את ה-webhook ב-Secure Source Manager.

   • Configuration (הגדרה): בType (סוג) בוחרים באפשרות Cloud Build configuration file (YAML or JSON) (קובץ הגדרות של Cloud Build‏ (YAML או JSON)), ובLocation (מיקום) בוחרים באפשרות Inline (בתוך השורה).

8. לוחצים על הלחצן Open Editor (פתיחת העורך) כדי לערוך את קובץ הגדרות ה-build.

9. מעתיקים את התוכן של קובץ cloudbuild.yaml לעורך.

   כמו שהסברנו קודם, לצינור עיבוד הנתונים האלה יש התנהגויות שונות בהתאם להסתעפות שמאוחזרת. ה-build בודק אם המשתנה ${branch} תואם לתיקייה כלשהי בסביבה. אם כן, Cloud Build יריץ את terraform plan עבור הסביבה הזו. אם לא, Cloud Build יריץ את terraform plan לכל הסביבות כדי לוודא שהשינוי המוצע מתאים לכולם. אם אחת מהתוכניות לא מצליחה לפעול, ה-build ייכשל.

   - id: 'tf plan'
     name: 'hashicorp/terraform:1.0.0'
     entrypoint: 'sh'
     args:
     - '-c'
     - |
         branch=$(basename "$_REF")
         if [ -d "environments/${branch}/" ]; then
           cd environments/${branch}
           terraform plan
         else
           for dir in environments/*/
           do
             cd ${dir}
             env=${dir%*/}
             env=${env#*/}
             echo ""
             echo "*************** TERRAFOM PLAN ******************"
             echo "******* At environment: ${env} ********"
             echo "*************************************************"
             terraform plan || exit 1
             cd ../../
           done
         fi

   הפקודה terraform apply פועלת להסתעפויות בסביבה, אבל בכל מקרה אחר מתעלמים ממנה.

10. לוחצים על + הוספת משתנה ומוסיפים את שני משתני ההחלפה הבאים:

    • משתנה: _REPO_URL, ערך:$(body.repository.clone_url)
    • משתנה: _REF, ערך:$(body.ref)

11. לוחצים על יצירה.

הגדרת webhook ב-Secure Source Manager

יוצרים webhook כדי להפעיל בנייה כשמבצעים push לענפים dev או prod.

1. בממשק האינטרנט של Secure Source Manager, עוברים אל המאגר שרוצים ליצור בשבילו webhook.
2. לוחצים על הגדרות.
3. לוחצים על Webhooks (הודעות webhook) ואז על Add webhook (הוספת הודעת webhook).

4. בשדה Hook ID (מזהה ה-webhook), מזינים מזהה ל-webhook.

   הערה: מזהי Hook צריכים לפעול בהתאם למוסכמות מתן השמות של משאבים. הם חייבים לכלול רק אותיות קטנות, מספרים או מקפים, להתחיל באות ולא ניתן לשנות אותם אחרי יצירת התגובה לפעולה מאתר אחר (webhook).

5. בשדה כתובת URL של יעד, מזינים את כתובת ה-URL של ה-Webhook שהעתקתם כשהגדרתם טריגר של Webhook ב-Cloud Build.

   כדי למצוא את כתובת ה-Webhook URL:

   1. פותחים את הדף Triggers במסוף Google Cloud .

      פתיחת הדף Triggers

   2. לוחצים על הטריגר.

   3. בקטע Webhook URL (כתובת URL של webhook), לוחצים על Show URL preview (הצגת תצוגה מקדימה של כתובת ה-URL) ומעתיקים את כתובת ה-URL.

6. כתובת ה-URL של ה-webhook מכילה את הערכים של המפתח והסוד שהזנתם כש יצרתם את הטריגר של Cloud Build. כדי למנוע דליפה של הערכים האלה, צריך להסיר אותם מסוף כתובת היעד ולהעתיק אותם לשדה מחרוזת שאילתה רגישה.

   כדי למצוא את המפתח והסוד בכתובת ה-URL של ה-webhook, מחפשים את הטקסט שמתחיל ב-key=

   לדוגמה, אם כתובת ה-URL היא: https://cloudbuild.googleapis.com/v1/projects/my-project/triggers/test-trigger:webhook?key=eitIfKhYnv0LrkdsyHqIros8fbsheKRIslfsdngf&secret=Hello%20Secret%20Manager

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

7. לוחצים על Add webhook (הוספת webhook).

8. התגובה לפעולה מאתר אחר (webhook) מוצגת בדף Webhooks.

   הערה: כשמוסיפים או עורכים webhook, יכול להיות שאורך המחרוזת Sensitive Query String לא יהיה זהה למה שהוזן. זה צפוי כי נעשה שימוש במחרוזות placeholder כדי להבטיח אבטחה.

שינוי ההגדרה של הסביבה בהסתעפות של פיצ'ר חדש

1. חשוב לוודא שנמצאים בהסתעפות dev:

   cd ~/solutions-terraform-cloudbuild-gitops
   git checkout dev
   

2. משיכת השינויים האחרונים:

   git pull
   

3. יוצרים סביבה נפרדת (branch) בשם bug-fix כדי לשנות את הגדרות הסביבה.

   git checkout -b bug-fix
   

4. פותחים את modules/firewall/main.tf כדי לערוך.

5. מתקנים את שגיאת ההקלדה "http-server2" בשדה target_tags בשורה 30.

   הערך חייב להיות "http-server".

6. שומרים ודוחפים את השינויים:

   git add --all
   git commit -m "Fix typo."
   git push google -u bug-fix
   

7. פותחים את הדף History של Cloud Build במסוף Google Cloud :

   פתיחת הדף 'היסטוריה'

8. לוחצים על Build כדי לראות מידע נוסף, כולל הפלט של terraform plan.

שימו לב שהמשימה ב-Cloud Build הריצה את צינור עיבוד הנתונים שהוגדר בקובץ cloudbuild.yaml. כמו שהסברנו קודם, לצינור עיבוד הנתונים האלה יש התנהגויות שונות בהתאם להסתעפות שמאוחזרת. ה-build בודק אם המשתנה ${branch} תואם לתיקייה כלשהי בסביבה. אם כן, Cloud Build יריץ את terraform plan עבור הסביבה הזו. אם לא, Cloud Build יריץ את terraform plan לכל הסביבות כדי לוודא שהשינוי המוצע מתאים לכולם. אם אחת מהתוכניות לא מצליחה לפעול, ה-build ייכשל.

- id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args:
  - '-c'
  - |
      branch=$(basename "$_REF")
      if [ -d "environments/${branch}/" ]; then
        cd environments/${branch}
        terraform plan
      else
        for dir in environments/*/
        do
          cd ${dir}
          env=${dir%*/}
          env=${env#*/}
          echo ""
          echo "*************** TERRAFOM PLAN ******************"
          echo "******* At environment: ${env} ********"
          echo "*************************************************"
          terraform plan || exit 1
          cd ../../
        done
      fi

באותו האופן, הפקודה terraform apply פועלת להסתעפויות בסביבה, אבל בכל מקרה אחר מתעלמים ממנה. בחלק הזה שלחתם בקשה לשינוי קוד להסתעפות חדשה, אז לא בוצעו פריסות בתשתית בפרויקט שלכם ב- Google Cloud .

‪- id: 'tf apply' ‪ name: 'hashicorp/terraform:1.0.0' ‪ entrypoint: 'sh' ‪ args: ‪ - '-c' ‪ - | ‪ branch=$(basename "$_REF") ‪ if [ -d "environments/${branch}/" ]; then ‪ cd environments/${branch} ‪ terraform apply -auto-approve ‪ else ‪ echo "***************************** SKIPPING APPLYING *******************************" ‪ echo "Branch '${branch}' does not represent an official environment." echo "*******************************************************************************" fi

יישום השינויים בסביבת הפיתוח

זה הזמן ליישם את המצב שאתם רוצים בסביבת dev.

1. בממשק האינטרנט של Secure Source Manager, עוברים למאגר.
2. לוחצים על New pull request (בקשת מיזוג חדשה).
3. בשדה merge into:, בוחרים את הענף dev.
4. בשדה pull from:, בוחרים את הענף bug-fix.
5. לוחצים על New pull request.
6. לוחצים על Create pull request.
7. לוחצים על Merge pull request (מיזוג בקשת משיכה) ואז שוב על Merge pull request (מיזוג בקשת משיכה).

8. בודקים שבוצעה הפעלה חדשה של Cloud Build:

   כניסה לדף Cloud Build

9. פותחים את ה-build ובודקים את היומנים.

   בסיום ה-build יופיע משהו כזה:

   Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
   Step #3 - "tf apply": firewall_rule = dev-allow-http
   Step #3 - "tf apply": instance_name = dev-apache2-instance
   Step #3 - "tf apply": network = dev
   Step #3 - "tf apply": subnet = dev-subnet-01
   

10. מעתיקים את EXTERNAL_IP_VALUE ופותחים את הכתובת בדפדפן אינטרנט.

    http://EXTERNAL_IP_VALUE
    

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

11. עוברים אל Cloud Storage:

    כניסה לדף Cloud Storage

12. בוחרים את הפרויקט הרצוי.

13. לוחצים על הקטגוריה של Cloud Storage שבה מאוחסן מצב Terraform. שם הקטגוריה נראה כך:

    PROJECT_ID-tfstate
    

14. לוחצים על env ואז על dev כדי לראות את קובץ המצב של Terraform.

יישום השינויים בסביבת הייצור

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

1. בממשק האינטרנט של Secure Source Manager, עוברים למאגר.
2. לוחצים על הכרטיסייה Pull requests.
3. לוחצים על New pull request.
4. בתור merge into:, בוחרים את הענף prod במאגר.
5. בקטע pull from:‎, בוחרים את הענף dev במאגר.
6. לוחצים על New pull request.
7. ממלאים שם בשדה title, למשל "Promoting networking changes", ולוחצים על Create pull request.

8. בודקים את השינויים המוצעים ולוחצים על Merge pull request.

   התאריך וכתובת ה-URL של המאגר מתווספים לשדה התגובה.

9. לוחצים שוב על Merge pull request כדי לאשר את הפעולה.

10. פותחים את הדף Build History במסוף Google Cloud כדי לראות את השינויים שבוצעו בסביבת הייצור:

    כניסה לדף Cloud Build

11. מחכים לסיום ה-build ובודקים את היומנים.

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

    Step #3 - "tf apply": external_ip = EXTERNAL_IP_VALUE
    Step #3 - "tf apply": firewall_rule = prod-allow-http
    Step #3 - "tf apply": instance_name = prod-apache2-instance
    Step #3 - "tf apply": network = prod
    Step #3 - "tf apply": subnet = prod-subnet-01
    

12. מעתיקים את EXTERNAL_IP_VALUE ופותחים את הכתובת בדפדפן אינטרנט.

    http://EXTERNAL_IP_VALUE
    

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

13. עוברים אל Cloud Storage:

    כניסה לדף Cloud Storage

14. בוחרים את הפרויקט הרצוי.

15. לוחצים על הקטגוריה של Cloud Storage שבה מאוחסן מצב Terraform. שם הקטגוריה נראה כך:

    PROJECT_ID-tfstate
    

16. לוחצים על env ואז על prod כדי לראות את קובץ המצב של Terraform.

זהו! הגדרתם צינור עיבוד נתונים ללא שרת כקוד ב-Cloud Build. בעתיד, מומלץ לנסות את הפעולות הבאות:

• הוספת פריסות לתרחישים שונים לדוגמה.
• יצירת סביבות נוספות בהתאם לצרכים שלכם.
• שימוש בפרויקט לכל סביבה ולא בענן ווירטואלי פרטי (VPC) לכל סביבה.

הסרת המשאבים

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

מחיקת הפרויקט

זהירות: כשמוחקים פרויקט:

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

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

1. במסוף Google Cloud , נכנסים לדף Manage resources.

   כניסה לדף Manage resources

2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

המאמרים הבאים

• כדאי להשתמש בתבניות של Cloud Foundation Toolkit כדי ליצור במהירות ב-Google Cloudתשתיות לארגון שתוכלו לשכפל.
• תוכלו לצפות בהרצאה Repeatable Google Cloud Environments at Scale With Cloud Build Infra-As-Code Pipelines מ-Next' 19 בקשר לתהליך העבודה של GitOps שתואר במדריך הזה.
• מומלץ לקרוא את המדריך בנושא פיתוח רציף (continuous delivery) בסגנון GitOps באמצעות Cloud Build.
• כדאי לבדוק את התכונות המתקדמות יותר ב-Cloud Build: הגדרת סדר השלבים של ה-build, יצירה, בדיקה ופריסה של ארטיפקטים, וגם יצירת שלבים מותאמים אישית של build.
• תוכלו לקרוא בבלוג איך מוודאים שהפריסה של Terraform תואמת ובגדול הנכון באמצעות Cloud Build.
• אפשר גם לקרוא את המשאבים שלנו בנושא DevOps.
• תוכלו להרחיב על היכולות של DevOps שקשורות למדריך הזה:
  • ניהול הגרסאות
  • אינטגרציה רציפה (CI)
  • פיתוח רציף (continuous delivery)
  • בדיקות רציפות
• אתם יכולים לעשות את הבדיקה המהירה של DevOps כדי להבין מה מצבכם בהשוואה לשאר האנשים בתחום.