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

במדריך הזה מוסבר איך לנהל את כללי איכות הנתונים של Knowledge Catalog (לשעבר Dataplex Universal Catalog) כקוד באמצעות Terraform, ‏Cloud Build ו-GitHub.

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

אם יש לכם גרסאות שונות של קבוצת נתונים לכמה סביבות, כמו סביבות dev ו-prod, ‏ Terraform מספקת דרך אמינה להקצאת כללים לאיכות הנתונים לגרסאות ספציפיות לסביבה של קבוצות נתונים.

בנוסף, ב-DevOps מומלץ להשתמש בניהול גרסאות. ניהול כללי איכות הנתונים כקוד מספק לכם גרסאות של כללי איכות הנתונים שזמינות בהיסטוריה שלכם ב-GitHub. ‫Terraform יכול גם לשמור את המצב שלו ב-Cloud Storage, שבו אפשר לאחסן גרסאות קודמות של קובץ המצב. מצב Terraform משמש למיפוי משאבים להגדרות, למעקב אחרי מטא-נתונים ולשיפור הביצועים בתשתיות גדולות.

מידע נוסף על Terraform, ‏Cloud Build וכללים אוטומטיים לאיכות הנתונים זמין במאמרים סקירה כללית של Terraform Google Cloud, ‏Cloud Build וסקירה כללית של איכות נתונים אוטומטית.

ארכיטקטורה

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

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

התהליך מתחיל כשדוחפים את הקוד של 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.
• הגדרת כללים לאיכות הנתונים ב-Knowledge Catalog.
• שינוי התצורה של הסביבה בסביבה נפרדת (feature branch) ובדיקה.
• ליישם שינויים בסביבת הפיתוח.
• ליישם שינויים בסביבת הייצור.

עלויות

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

• BigQuery
• Cloud Build
• Cloud Storage
• Compute Engine
• Knowledge Catalog

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

משתמשים חדשים של 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 bigquery.googleapis.com cloudbuild.googleapis.com compute.googleapis.com dataplex.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.

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

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

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

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

כדי להתחיל, יוצרים Fork של המאגר terraform-google-dataplex-auto-data-quality.

1. ב-GitHub, עוברים אל https://github.com/GoogleCloudPlatform/terraform-google-dataplex-auto-data-quality.git.

2. לוחצים על Fork.

   עכשיו יש לכם עותק של המאגר terraform-google-dataplex-auto-data-quality עם קובצי המקור.

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

   cd ~
   git clone https://github.com/GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality.git
   cd ~/terraform-google-dataplex-auto-data-quality
   

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

   • ‫GITHUB_USERNAME: שם המשתמש שלכם ב-GitHub

4. יצירת ענפים dev ו-prod:

   git checkout -b prod
   git checkout -b dev
   

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

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

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

• בתוך modules/deploy/:

  • התיקייה rule/ מכילה yaml קבצים עם כללים לאיכות נתונים. קובץ אחד מייצג קבוצה של כללים לאיכות הנתונים של טבלה אחת. הקובץ הזה נמצא בשימוש בסביבות dev ו-prod.

  • התיקייה schemas/ מכילה את סכימת הטבלה של טבלה ב-BigQuery שנפרסה בתשתית הזו.

  • הקובץ bigquery.tf מכיל את התצורה של טבלאות BigQuery שנוצרו בפריסה הזו.

  • הקובץ dataplex.tf מכיל סריקת נתונים של Knowledge Catalog לצורך בדיקת איכות הנתונים. הקובץ הזה משמש בשילוב עם rules_file_parsing.tf כדי לקרוא כללים לאיכות הנתונים מקובץ yaml אל הסביבה.

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

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

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

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

# Copyright 2024 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-dev"
  }
}

קובץ backend.tf נפרד קיים בכל אחת מהסביבות dev ו-prod. השיטה המומלצת היא להשתמש בקטגוריית Cloud Storage שונה לכל סביבה.

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

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

   DEV_BUCKET=gs://PROJECT_ID-tfstate-dev
   gcloud storage buckets create ${DEV_BUCKET}
   
   PROD_BUCKET=gs://PROJECT_ID-tfstate-prod
   gcloud storage buckets create ${PROD_BUCKET}
   

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

   gcloud storage buckets update ${DEV_BUCKET} --versioning
   gcloud storage buckets update ${PROD_BUCKET} --versioning
   

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

3. בכל סביבה, בקבצים main.tf ו-backend.tf , מחליפים את PROJECT_ID במזהה הפרויקט:

   cd ~/terraform-google-dataplex-auto-data-quality
   sed -i s/PROJECT_ID/PROJECT_ID/g environments/*/main.tf
   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/*/main.tf
   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/main.tf
          modified:   environments/prod/backend.tf
          modified:   environments/prod/main.tf
   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.

ההוראות הבאות הן להתקנת האפליקציה רק למאגר של terraform-google-dataplex-auto-data-quality, אבל תוכלו להתקין את האפליקציה לכמה מאגרים נוספים שתרצו.

1. ב-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 ואז על terraform-google-dataplex-auto-data-quality כדי להתחבר למאגר.

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

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

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

7. בקטע Select repository, בוחרים את החשבון ב-GitHub ואת המאגר terraform-google-dataplex-auto-data-quality.

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/terraform-google-dataplex-auto-data-quality
   

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

3. כדי לפתוח את הקובץ לעריכה, עוברים לקובץ modules/deploy/dataplex.tf.

4. בשורה 19, משנים את התווית the_environment ל-environment.

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

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

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

   אחרי שתיצרו את בקשת המשיכה, המשימה תתחיל אוטומטית ב-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.9.8'
  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.9.8'
  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/terraform-google-dataplex-auto-data-quality
   

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/terraform-google-dataplex-auto-data-quality
   

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

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

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

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

   כניסה לדף Cloud Build

6. פותחים את ה-build ובודקים את היומנים. יוצגו כל המשאבים ש-Terraform יוצר ומנהל.

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

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

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

   https://github.com/YOUR_GITHUB_USERNAME/terraform-google-dataplex-auto-data-quality
   

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

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

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

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

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

7. ממלאים שם בשדה title, למשל Changing label name, ולוחצים על Create pull request.

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

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

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

    כניסה לדף Cloud Build

הגדרתם בהצלחה כללים לאיכות הנתונים שמנוהלים באמצעות Terraform ו-Cloud Build.

הסרת המשאבים

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

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

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

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

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

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. ב-GitHub, עוברים אל דף האפליקציות ב-GitHub.

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

   ההודעה הבאה תופיע בחלק העליון של הדף" "You're all set. העבודה הוכנסה לתור להסרת Google Cloud Build".

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

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

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

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

• מידע נוסף על איכות נתונים אוטומטית
• מידע נוסף על DevOps ועל שיטות מומלצות ל-DevOps
• ב-Cloud Foundation Toolkit יש עוד תבניות של Terraform.