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

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

המדריך מיועד למפתחים ולמפעילים שמחפשים דרך לבצע שינויים חזויים בתשתית באמצעות אסטרטגיה אלגנטית. הוא מתבסס על ההנחה שאתם מכירים את 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. במסוף Google Cloud, בדף לבחירת הפרויקט בוחרים פרויקט או לוחצים על create a Google Cloud project.

    כניסה לדף לבחירת הפרויקט

  3. הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud.

  4. במסוף Google Cloud, בדף לבחירת הפרויקט בוחרים פרויקט או לוחצים על create a Google Cloud project.

    כניסה לדף לבחירת הפרויקט

  5. הקפידו לוודא שהחיוב מופעל בפרויקט שלכם ב-Cloud.

  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 עם קובצי המקור.

  3. משכפלים ב-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)
    gsutil mb gs://${PROJECT_ID}-tfstate
    
  2. כדי לשמור את היסטוריית הפריסות, צריך להפעיל את החלוקה הגרסאות של האובייקטים:

    gsutil versioning set on gs://${PROJECT_ID}-tfstate
    

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

  3. מחליפים את ה-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
    
  4. בודקים אם כל הקבצים עודכנו:

    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")
    
  5. שומרים ודוחפים את השינויים:

    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. לוחצים על Create.

זהו! הגדרתם את אפליקציית 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 "*************** 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'
  - |
      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 ומבצעים את השלבים כדי לאשר.

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