ניהול התשתית כקוד באמצעות Terraform, ‏Cloud Build ו-GitOps

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

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

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

ארכיטקטורה

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

.תשתית עם סביבות לפיתוח וייצור

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

במקרה האידיאלי, המפתחים או המפעילים צריכים להציע הצעות לתשתית להסתעפות לא מוגנת, ואז לשלוח אותן באמצעות בקשות משיכה (pull requests). אפליקציית Cloud Build GitHub, כמו שנסביר מאוחר יותר במדריך, מפעילה באופן אוטומטי את משימות ה-build ומקשרת את הדוחות של terraform plan לבקשות המשיכה האלה. כך תוכלו לדון בשינויים האפשריים ולבדוק אותם עם אנשים אחרים ולהוסיף התחייבויות נוספות לפני שהשינויים ימוזגו להסתעפות הבסיסית.

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

מטרות

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

עלויות

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

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

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

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

דרישות מוקדמות

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

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

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

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

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

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

    הפעלת Cloud Shell

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

  7. מאתרים ב-Cloud Shell את המזהה של הפרויקט שבחרתם:
    ‫
    gcloud config get-value project
     אם הפקודה לא מחזירה את מזהה הפרויקט, מגדירים את Cloud Shell להשתמש בפרויקט. מחליפים את PROJECT_ID במזהה הפרויקט. 
    gcloud config set project PROJECT_ID
  8. מפעילים את ממשקי ה-API הנדרשים:
    gcloud services enable cloudbuild.googleapis.com compute.googleapis.com
     השלב הזה עשוי להימשך כמה דקות.
  9. אם עדיין לא השתמשתם ב-Git ב-Cloud Shell, תצטרכו להגדיר את Git עם השם וכתובת האימייל שלכם: 
    git config --global user.email "YOUR_EMAIL_ADDRESS"
git config --global user.name "YOUR_NAME"
    המידע הזה ישמש את Git לזיהוי כשאתם יוצרים התחייבויות ב-Cloud Shell.

הגדרת מאגר משלכם ב-GitHub

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

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

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

בתור התחלה, תצטרכו לחבר את המאגר solutions-terraform-cloudbuild-gitops.

  1. ב-GitHub, עוברים אל https://github.com/GoogleCloudPlatform/solutions-terraform-cloudbuild-gitops.git.

  2. לוחצים על Fork בפינה הימנית העליונה של הדף.

    חיבור מאגר.

    עכשיו יש לכם עותק של המאגר solutions-terraform-cloudbuild-gitops עם קובצי המקור.

  1. משכפלים ב-Cloud Shell את המאגר שחובר ומחליפים את YOUR_GITHUB_USERNAME בשם המשתמש שלכם ב-GitHub:

    cd ~
git clone https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops.git
cd ~/solutions-terraform-cloudbuild-gitops

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

  • התיקייה 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 תיקיות המשנה. כך למשל, לפני מיזוג בקשת המשיכה תוכלו לבדוק את התוכניות כדי לוודא שלא ניתנה גישה לישות לא מורשית.

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

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

Enabling Object Versioning increases
[storage costs](https://cloud.google.com/storage/pricing){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" },
which you can mitigate by configuring
[Object Lifecycle Management](/storage/docs/lifecycle){: track-type="tutorial" track-name="internalLink" track-metadata-position="body" } 
to delete old state versions.

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

      cd ~/solutions-terraform-cloudbuild-gitops
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, באופן הבא:

      cd ~/solutions-terraform-cloudbuild-gitops
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/terraform.tfvars
sed -i "" s/PROJECT_ID/$PROJECT_ID/g environments/*/backend.tf

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

      git status

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

      On branch dev
Your branch is up-to-date with 'origin/dev'.
Changes not staged for commit:
 (use "git add <file>..." to update what will be committed)
 (use "git checkout -- <file>..." 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")

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

      git add --all
git commit -m "Update project IDs and buckets"
git push origin dev

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

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

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

    1. ב-Cloud Shell, מוצאים את כתובת האימייל של חשבון השירות ב-Cloud Build שמשויך לפרויקט:

      CLOUDBUILD_SA="$(gcloud projects describe $PROJECT_ID \
    --format 'value(projectNumber)')@cloudbuild.gserviceaccount.com"

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

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

    חיבור Cloud Build ישירות למאגר שלכם ב-GitHub

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

    ההוראות הבאות הן להתקנת האפליקציה רק למאגר של solutions-terraform-cloudbuild-gitops, אבל תוכלו להתקין את האפליקציה לכמה מאגרים נוספים שתרצו.

    1. נכנסים לדף של אפליקציית Cloud Build ב-GitHub Marketplace:

      לפתיחת הדף של אפליקציית Cloud Build

      • אם זו הפעם הראשונה שאתם מגדירים אפליקציה ב-GitHub: לוחצים על Setup with Google Cloud Build בתחתית הדף. אחר כך לוחצים על Grant this app access to your GitHub account.
      • אם זו לא הפעם הראשונה: לוחצים על Configure access. הדף Applications ייפתח בחשבון האישי שלכם.

    2. לוחצים על Configure בשורה של Cloud Build.

    3. לוחצים על Only select repositories ואז על solutions-terraform-cloudbuild-gitops כדי להתחבר למאגר.

    4. לוחצים על Save או על Install (הכיתוב בלחצן משתנה בהתאם לתהליך העבודה). תועברו אל Google Cloud להמשך ההתקנה.

    5. נכנסים לחשבון Google Cloud . אם צריך, מאשרים את השילוב של Cloud Build עם GitHub.

    6. בדף Cloud Build, בוחרים את הפרויקט. ייפתח אשף.

    7. בקטע Select repository, בוחרים את החשבון ב-GitHub ואת המאגר solutions-terraform-cloudbuild-gitops.

    8. מאשרים את התנאים וההגבלות ולוחצים על Connect.

    9. בקטע Create a trigger, לוחצים על Create a trigger:

      1. נותנים שם לטריגר, למשל push-to-branch. חשוב לזכור את השם שנותנים לטריגר, כי תצטרכו להשתמש בו בהמשך.
      2. בקטע Event, בוחרים באפשרות Push to a branch.
      3. בקטע Source, בוחרים באפשרות .* בשדה Branch.
      4. לוחצים על יצירה.

    זהו! הגדרתם את אפליקציית Cloud Build GitHub והמאגר שלכם ב-GitHub מקושר לפרויקט Google Cloud . מעכשיו, כל שינוי במאגר ב-GitHub יגרום לפעולות של Cloud Build, והתוצאות ידווחו בחזרה ל-GitHub באמצעות GitHub Checks.

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

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

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

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

    3. כדי לפתוח את הקובץ לעריכה, עוברים לקובץ modules/firewall/main.tf ולוחצים על סמל העיפרון.

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

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

    5. מוסיפים הודעת הסבר בתחתית הדף, למשל 'תיקון יעד חומת האש http' ולוחצים על Create a new branch for this commit and start a pull request.

    6. לוחצים על Propose changes.

    7. בדף הבא, לוחצים על Create pull request כדי ליצור בקשת משיכה חדשה עם השינוי.

      אחרי שתיצרו את בקשת המשיכה, המשימה תתחיל אוטומטית ב-Cloud Build.

    8. לוחצים על Show all checks ומחכים עד שהצבע יהפוך לירוק.

      הצגת כל הבדיקות בבקשת משיכה.

    9. לוחצים על Details כדי להציג פרטים נוספים, כולל את הפלט של terraform plan בקישור View more details on Google Cloud Build.

    עדיין לא ממזגים את בקשת המשיכה.

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

    - id: 'tf plan'
  name: 'hashicorp/terraform:1.0.0'
  entrypoint: 'sh'
  args: 
  - '-c'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME
        terraform plan
      else
        for dir in environments/*/
        do 
          cd ${dir}   
          env=${dir%*/}
          env=${env#*/}  
          echo ""
          echo "*************** TERRAFORM 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'
  - | 
      if [ -d "environments/$BRANCH_NAME/" ]; then
        cd environments/$BRANCH_NAME      
        terraform apply -auto-approve
      else
        echo "***************************** SKIPPING APPLYING *******************************"
        echo "Branch '$BRANCH_NAME' does not represent an official environment."
        echo "*******************************************************************************"
      fi

    איך מוודאים שהפעולות בוצעו ב-Cloud Build לפני מיזוג ההסתעפויות

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

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

    2. מתחת לשם המאגר, לוחצים על Settings.

    3. בתפריט הימני, לוחצים על Branches.

    4. בקטע Branch protection rules, לוחצים על Add rule.

    5. בשדה Branch name pattern, כותבים dev.

    6. בקטע Protect matching branches בוחרים באפשרות Require status checks to pass before merging.

    7. מחפשים את שם הטריגר שיצרתם ב-Cloud Build.

    8. לוחצים על Create.

    9. חוזרים על שלבים 3 עד 7 ומגדירים את Branch name pattern בתור prod.

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

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

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

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

    2. מתחת לשם המאגר, לוחצים על Pull requests.

    3. לוחצים על בקשת המשיכה שיצרתם.

    4. לוחצים על Merge pull requestואז על Confirm merge.

      אישור המיזוג

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

      כניסה לדף Cloud Build

    6. פותחים את ה-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

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

      http://EXTERNAL_IP_VALUE

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

    8. מנווטים לקובץ המצב של Terraform בקטגוריה של Cloud Storage.

      https://storage.cloud.google.com/PROJECT_ID-tfstate/env/dev/default.tfstate

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

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

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.

      https://github.com/YOUR_GITHUB_USERNAME/solutions-terraform-cloudbuild-gitops

    2. מתחת לשם המאגר, לוחצים על Pull requests.

    3. לוחצים על New pull request.

    4. בוחרים את המאגר שחובר מקודם בתור base repository.

    5. בתור base, בוחרים את prod ממאגר הבסיס שלכם. בתור compare בוחרים את dev.

      השוואת השינויים.

    6. לוחצים על Create pull request.

    7. ממלאים שם בשדה title, למשל Promoting networking changes, ולוחצים על Create pull request.

    8. בודקים את השינויים המוצעים, כולל את הפרטים של terraform plan מ-Cloud Build, ולוחצים על Merge pull request.

    9. לוחצים על Confirm merge.

    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. מנווטים לקובץ המצב של Terraform בקטגוריה של Cloud Storage.

      https://storage.cloud.google.com/PROJECT_ID-tfstate/env/prod/default.tfstate

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

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

    הסרת המשאבים

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

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

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

      כניסה לדף Manage resources

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

    מחיקת המאגר ב-GitHub

    כדי לא לחסום בקשות משיכה חדשות במאגר ב-GitHub, אתם יכולים למחוק את ככלי ההגנה על ההסתעפות:

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.
    2. מתחת לשם המאגר, לוחצים על Settings.
    3. בתפריט הימני, לוחצים על Branches.
    4. בקטע Branch protection rules לוחצים על הלחצן Delete לשורה dev ולשורה prod.

    אם אתם רוצים, תוכלו להסיר לגמרי את אפליקציית Cloud Build מ-GitHub:

    1. נכנסים להגדרות של Applications ב-GitHub.

      כניסה לדף האפליקציות ב-GitHub

    2. בכרטיסייה Installed GitHub Apps, לוחצים על Configure בשורה של Cloud Build. לאחר מכן, בקטע Danger Zone, לוחצים על Uninstall בשורה Uninstall Google Cloud Builder.

      ההודעה הבאה תופיע בחלק העליון של הדף" "You're all set. A job has been queued to uninstall Google Cloud Build.‎"

    3. בכרטיסייה Authorized GitHub Apps, לוחצים על הלחצן Undo בשורה של Google Cloud Build ואז על understand, revoke access בחלון הקופץ.

    אם אתם לא רוצים להשאיר את המאגר שלכם ב-GitHub:

    1. עוברים לדף הראשי של המאגר המחובר ב-GitHub.
    2. מתחת לשם המאגר, לוחצים על Settings.
    3. גוללים למטה אל Danger Zone.
    4. לוחצים על Delete this repository ומבצעים את השלבים כדי לאשר.

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