פיתוח רציף (continuous delivery) בסגנון GitOps באמצעות Cloud Built

שימו לב: החל מ-17 ביוני 2024, שירות Cloud Source Repositories לא זמין ללקוחות חדשים. אם הארגון שלכם לא השתמש בעבר ב-Cloud Source Repositories, לא תוכלו להשתמש ב-Cloud Source Repositories כדי להגדיר אספקה רציפה בסגנון GitOps. אתם יכולים להשתמש במדריך הזה כדי להגדיר CI/CD עם מערכת אחרת לניהול קוד מקור, כמו GitHub,‏ Bitbucket או Gitlab. ארגונים שהשתמשו ב-Cloud Source Repositories לפני 17 ביוני 2024 לא יושפעו מהשינוי הזה.

בדף הזה מוסבר איך ליצור צינור עיבוד נתונים לאינטגרציה רציפה ופיתוח רציף (CI/CD) ב- Google Cloud באמצעות מוצרים מתארחים בלבד והשיטה הפופולרית GitOps.

מהנדסי Google מאחסנים קובצי הגדרה ופריסה במאגר קודי המקור הראשי שלנו כבר הרבה זמן. המתודולוגיה הזו מתוארת בספר Site Reliability Engineering, Chapter 8 (Beyer et. al., ‫2016), והוצג על ידי קלסי הייטאואר במהלך הנאום המרכזי שלו ב-Google Cloud Next '17.

חלק מרכזי ב-GitOps הוא הרעיון של 'סביבות כקוד': תיאור הפריסות באופן הצהרתי באמצעות קבצים (לדוגמה, מניפסטים של Kubernetes) שמאוחסנים במאגר Git.

במדריך הזה יוצרים פייפליין של CI/CD שמבצע באופן אוטומטי את הפעולות הבאות: בניית קובץ אימג' של קונטיינר מקוד מחויב, אחסון התמונה ב-Artifact Registry, עדכון מניפסט של Kubernetes במאגר Git ופריסת האפליקציה ב-Google Kubernetes Engine‏ (GKE) באמצעות המניפסט הזה.

במדריך הזה נשתמש בשני מאגרי Git:

• מאגר האפליקציות: מכיל את קוד המקור של האפליקציה עצמה
• env repository: מכיל את המניפסטים של Kubernetes Deployment

כשמעבירים בדחיפה שינוי למאגר האפליקציה, צינור הנתונים של Cloud Build מריץ בדיקות, יוצר קובץ אימג' בקונטיינר ומעביר אותו בדחיפה ל-Artifact Registry. אחרי שמעבירים בדחיפה את קובץ האימג', Cloud Build מעדכן את מניפסט הפריסה ומעביר אותו בדחיפה למאגר env. הפעולה הזו מפעילה צינור עיבוד נתונים נוסף של Cloud Build שמחיל את המניפסט על אשכול GKE, ואם הפעולה מצליחה, מאחסן את המניפסט בענף אחר של מאגר env.

אנחנו שומרים את מאגרי האפליקציות והסביבות בנפרד כי יש להם מחזורי חיים ושימושים שונים. המשתמשים העיקריים במאגר האפליקציה הם בני אדם, והמאגר הזה מוקדש לאפליקציה ספציפית. המשתמשים העיקריים במאגר env הם מערכות אוטומטיות (כמו Cloud Build), ויכול להיות שמאגר זה משותף לכמה אפליקציות. מאגר env יכול לכלול כמה ענפים, שכל אחד מהם ממופה לסביבה ספציפית (במדריך הזה משתמשים רק בסביבת הייצור) ומפנה לקובץ אימג' של קונטיינר ספציפי, בעוד שמאגר app לא יכול לכלול כמה ענפים.

בסיום המדריך הזה, תהיה לכם מערכת שבה תוכלו בקלות:

• כדי להבחין בין פריסות שנכשלו לבין פריסות שהצליחו, אפשר לעיין בהיסטוריה של Cloud Build.
• כדי לגשת למניפסט שבו נעשה שימוש כרגע, צריך לעיין בענף production במאגר env,
• אפשר לחזור לכל גרסה קודמת על ידי הפעלה מחדש של גרסת ה-build המתאימה ב-Cloud Build.

מידע על המדריך הזה

במדריך הזה נעשה שימוש ב-Cloud Source Repositories לאירוח מאגרי Git, אבל אפשר להשיג את אותן תוצאות גם באמצעות מוצרים אחרים של צד שלישי, כמו GitHub, ‏ Bitbucket או GitLab.

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

מומלץ להשתמש ב-Spinnaker אם רוצים להטמיע דפוסי פריסה מתקדמים (כחול/ירוק, ניתוח קנרי, ריבוי עננים וכו'), אבל יכול להיות שאין צורך בתכונות האלה כדי ליצור אסטרטגיית CI/CD מוצלחת בארגונים ובפרויקטים קטנים יותר. במדריך הזה נסביר איך ליצור צינור עיבוד נתונים של CI/CD שמתאים לאפליקציות שמארחות ב-GKE באמצעות כלי פיתוח.

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

מטרות

• יוצרים מאגרי Git ב-Cloud Source Repositories.
• יצירת קובץ אימג' של קונטיינר באמצעות Cloud Build ואחסון שלו ב-Artifact Registry.
• יוצרים צינור CI.
• יצירת צינור עיבוד נתונים של CD.
• בודקים את צינור ה-CI/CD.

עלויות

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

• GKE
• Cloud Source Repositories
• Artifact Registry
• Cloud Build

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

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

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

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

1. בוחרים או יוצרים Google Cloud פרויקט.

   מעבר לניהול משאבים

2. מפעילים את החיוב בפרויקט.

   הפעלת החיוב

3. פותחים את Cloud Shell כדי להריץ את הפקודות שמפורטות במדריך הזה. ‫Cloud Shell היא סביבת מעטפת אינטראקטיבית של Google Cloud שמאפשרת לכם לנהל את הפרויקטים והמשאבים שלכם מדפדפן האינטרנט.

   כניסה ל-Cloud Shell

4. אם הפקודה gcloud config get-value project לא מחזירה את המזהה של הפרויקט שבחרתם, צריך להגדיר את Cloud Shell לשימוש בפרויקט.

   gcloud config set project [PROJECT_ID]
   

5. ב-Cloud Shell, מפעילים את ממשקי ה-API הנדרשים.

   gcloud services enable container.googleapis.com \
       cloudbuild.googleapis.com \
       sourcerepo.googleapis.com \
       artifactregistry.googleapis.com
   

6. יוצרים מאגר Docker ב-Artifact Registry בשם my-repository באזור us-central1 כדי לאחסן את קובצי האימג' של הקונטיינרים.

   gcloud artifacts repositories create my-repository \
     --repository-format=docker \
     --location=us-central1
   

7. ב-Cloud Shell, יוצרים אשכול GKE שבו תשתמשו כדי לפרוס את האפליקציה לדוגמה של המדריך הזה.

   טייס אוטומטי

   יוצרים אשכול Autopilot בשם hello-cloudbuild:

   gcloud container clusters create-auto hello-cloudbuild \
       --location us-central1
   

   רגילה

   יוצרים אשכול רגיל עם צומת אחד בשם hello-cloudbuild:

   gcloud container clusters create hello-cloudbuild \
       --num-nodes 1 --location us-central1
   

8. אם עדיין לא השתמשתם ב-Git ב-Cloud Shell, תצטרכו להגדיר את Git עם השם וכתובת האימייל שלכם. הפרטים האלה ישמשו את Git לזיהוי כשאתם יוצרים התחייבויות ב-Cloud Shell.

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

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

יצירת מאגרי Git ב-Cloud Source Repositories

בקטע הזה יוצרים את שני מאגרי ה-Git‏ (app ו-env) שבהם נעשה שימוש במדריך הזה, ומפעילים את מאגר app עם קוד לדוגמה.

1. יוצרים את שני מאגרי ה-Git ב-Cloud Shell.

   gcloud source repos create hello-cloudbuild-app
   gcloud source repos create hello-cloudbuild-env
   

2. משכפלים את הקוד לדוגמה מ-GitHub.

   cd ~
   git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   

3. הגדרת Cloud Source Repositories כמיקום מרוחק.

   PROJECT_ID=$(gcloud config get-value project)
   git remote add google \
       "https://source.developers.google.com/p/${PROJECT_ID}/r/hello-cloudbuild-app"
   

הקוד ששיבטתם מכיל אפליקציית Hello World.

from flask import Flask
app = Flask('hello-cloudbuild')

@app.route('/')
def hello():
  return "Hello World!\n"

if __name__ == '__main__':
  app.run(host = '0.0.0.0', port = 8080)

יצירת קובץ אימג' של קונטיינר באמצעות Cloud Build

הקוד ששיבטתם מכיל את קובץ ה-Dockerfile הבא.

FROM python:3.13-slim
RUN pip install flask
WORKDIR /app
COPY app.py /app/app.py
ENTRYPOINT ["python"]
CMD ["/app/app.py"]

בעזרת קובץ Dockerfile הזה, אפשר ליצור קובץ אימג' של קונטיינר באמצעות Cloud Build ולאחסן אותו ב-Artifact Registry.

1. ב-Cloud Shell, יוצרים גרסת build של Cloud Build על סמך הקומיט האחרון באמצעות הפקודה הבאה.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   COMMIT_ID="$(git rev-parse --short=7 HEAD)"
   gcloud builds submit --tag="us-central1-docker.pkg.dev/${PROJECT_ID}/my-repository/hello-cloudbuild:${COMMIT_ID}" .
   

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

2. אחרי שגרסת ה-build מסתיימת, מוודאים שקובץ אימג' של קונטיינר חדש זמין ב-Artifact Registry.

   כניסה ל-Artifact Registry

   

יצירת צינור עיבוד נתונים של אינטגרציה רציפה

בקטע הזה מגדירים את Cloud Build כך שיריץ באופן אוטומטי בדיקת יחידה קטנה, ייצור את קובץ האימג' של הקונטיינר ואז יעביר אותו בדחיפה ל-Artifact Registry. העברת קומיט חדש אל Cloud Source Repositories מפעילה את צינור העברת הנתונים הזה באופן אוטומטי. קובץ cloudbuild.yaml שכלול בקוד הוא ההגדרה של צינור עיבוד הנתונים.

steps:
# This step runs the unit tests on the app
- name: 'python:3.13-slim'
  id: Test
  entrypoint: /bin/sh
  args:
  - -c
  - 'pip install flask && python test_app.py -v'

# This step builds the container image.
- name: 'gcr.io/cloud-builders/docker'
  id: Build
  args:
  - 'build'
  - '-t'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'
  - '.'

# This step pushes the image to Artifact Registry
# The PROJECT_ID and SHORT_SHA variables are automatically
# replaced by Cloud Build.
- name: 'gcr.io/cloud-builders/docker'
  id: Push
  args:
  - 'push'
  - 'us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:$SHORT_SHA'

1. פותחים את הדף Triggers (טריגרים) של Cloud Build.

   כניסה לדף Triggers

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

3. ממלאים את האפשרויות הבאות:

   • בשדה שם, מקלידים hello-cloudbuild.
   • בקטע Event, בוחרים באפשרות Push to a branch.
   • בקטע Source, בוחרים באפשרות hello-cloudbuild-app בתור Repository ובאפשרות ^master$ בתור Branch.
   • בקטע תצורת build, בוחרים באפשרות Cloud Build configuration file.
   • בשדה Cloud Build configuration file location, מקלידים cloudbuild.yaml אחרי /.

4. לוחצים על יצירה כדי לשמור את טריגר לפיתוח גרסת Build.

   טיפ: אם אתם צריכים ליצור טריגרים של Build עבור הרבה פרויקטים, אתם יכולים להשתמש ב-Build Triggers API.

5. ב-Cloud Shell, מעבירים בדחיפה את קוד האפליקציה אל Cloud Source Repositories כדי להפעיל את צינור ה-CI ב-Cloud Build.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git push google master
   

6. פותחים את מסוף Cloud Build.

   כניסה ל-Cloud Build

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

יצירת צינור עיבוד הנתונים לפיתוח רציף

משתמשים ב-Cloud Build גם לצינור העיבוד של פיתוח רציף (CD). הצינור מופעל בכל פעם ששולחים commit לענף candidate במאגר hello-cloudbuild-env. תהליך הצינור מחיל את הגרסה החדשה של המניפסט על אשכול Kubernetes, ואם הפעולה מצליחה, מעתיק את המניפסט אל הענף production. לתהליך הזה יש את המאפיינים הבאים:

• הסתעפות candidate היא היסטוריה של ניסיונות הפריסה.
• הסתעפות הייצור היא היסטוריה של הפריסות שבוצעו בהצלחה.
• אתם יכולים לראות את הפריסות שבוצעו בהצלחה ואת הפריסות שנכשלו ב-Cloud Build.
• אפשר לחזור לכל פריסה קודמת על ידי הפעלה מחדש של ה-build המתאים ב-Cloud Build. בנוסף, ביצוע Rollback מעדכן את הענף production כדי לשקף באופן מדויק את היסטוריית הפריסות.

תשנו את צינור עיבוד הנתונים של האינטגרציה הרציפה כדי לעדכן את ענף המועמד של מאגר hello-cloudbuild-env, וכך תפעילו את צינור עיבוד הנתונים של הפיתוח הרציף.

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

מתן גישה ל-Cloud Build ל-GKE

כדי לפרוס את האפליקציה באשכול Kubernetes, ל-Cloud Build צריך להיות תפקיד ניהול זהויות והרשאות גישה של מפתח Kubernetes Engine.

מעטפת

ב-Cloud Shell, מריצים את הפקודה הבאה:

PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} --format='get(projectNumber)')"
gcloud projects add-iam-policy-binding ${PROJECT_NUMBER} \
    --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
    --role=roles/container.developer

המסוף

1. במסוף Google Cloud , עוברים לדף GKE Permissions:

   עוברים אל הרשאות

2. מגדירים את הסטטוס של התפקיד Kubernetes Engine Developer לEnable (הפעלה).

אתחול המאגר hello-cloudbuild-env

צריך לאתחל את מאגר hello-cloudbuild-env עם שני ענפים (production ו-candidate) וקובץ הגדרות של Cloud Build שמתאר את תהליך הפריסה.

1. ב-Cloud Shell, משכפלים את המאגר hello-cloudbuild-env ויוצרים את הענף production.

   cd ~
   gcloud source repos clone hello-cloudbuild-env
   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git checkout -b production
   

2. מעתיקים את הקובץ cloudbuild-delivery.yaml שזמין במאגר hello-cloudbuild-app ושומרים את השינוי.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp ~/hello-cloudbuild-app/cloudbuild-delivery.yaml ~/kubernetes-engine-samples/management/gitops-style-delivery/cloudbuild.yaml
   git add .
   git commit -m "Create cloudbuild.yaml for deployment"
   

   בקובץ cloudbuild-delivery.yaml מתואר תהליך הפריסה שיופעל ב-Cloud Build. התהליך כולל שני שלבים:

   1. ‫Cloud Build מחיל את המניפסט על אשכול GKE.

   2. אם הפעולה תצליח, Cloud Build יעתיק את המניפסט אל ההסתעפות production.

   steps:
   # This step deploys the new version of our container image
   # in the hello-cloudbuild Kubernetes Engine cluster.
   - name: 'gcr.io/cloud-builders/kubectl'
     id: Deploy
     args:
     - 'apply'
     - '-f'
     - 'kubernetes.yaml'
     env:
     - 'CLOUDSDK_COMPUTE_REGION=us-central1'
     - 'CLOUDSDK_CONTAINER_CLUSTER=hello-cloudbuild'
   
   # This step copies the applied manifest to the production branch
   # The COMMIT_SHA variable is automatically
   # replaced by Cloud Build.
   - name: 'gcr.io/cloud-builders/git'
     id: Copy to production branch
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       # Configure Git to create commits with Cloud Build's service account
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)') && \
       # Switch to the production branch and copy the kubernetes.yaml file from the candidate branch
       git fetch origin production && git checkout production && \
       git checkout $COMMIT_SHA kubernetes.yaml && \
       # Commit the kubernetes.yaml file with a descriptive commit message
       git commit -m "Manifest from commit $COMMIT_SHA
       $(git log --format=%B -n 1 $COMMIT_SHA)" && \
       # Push the changes back to Cloud Source Repository
       git push origin production

3. יוצרים ענף מועמד ומעבירים בדחיפה את שני הענפים כדי שהם יהיו זמינים ב-Cloud Source Repositories.

   git checkout -b candidate
   git push origin production
   git push origin candidate
   

4. מקצים לחשבון השירות של Cloud Build את התפקיד Source Repository Writer (כתיבה במאגר קוד) ב-IAM עבור מאגר הקוד hello-cloudbuild-env.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   cat >/tmp/hello-cloudbuild-env-policy.yaml <<EOF
   bindings:
   - members:
     - serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com
     role: roles/source.writer
   EOF
   gcloud source repos set-iam-policy \
       hello-cloudbuild-env /tmp/hello-cloudbuild-env-policy.yaml
   

יצירת הטריגר לצינור העברת נתונים רציפה

בקטע הזה, מגדירים את Cloud Build כך שיופעל על ידי פעולת push להסתעפות candidate במאגר hello-cloudbuild-env.

1. פותחים את הדף Triggers של Cloud Build.

   כניסה לדף Triggers

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

3. ממלאים את האפשרויות הבאות:

   • בשדה שם, מקלידים hello-cloudbuild-deploy.
   • בקטע Event, בוחרים באפשרות Push to a branch.
   • בקטע Source, בוחרים באפשרות hello-cloudbuild-env בתור Repository ובאפשרות ^candidate$ בתור Branch.
   • בקטע Configuration, בוחרים באפשרות Cloud Build configuration file (yaml or json).
   • בשדה Cloud Build configuration file location, מקלידים cloudbuild.yaml אחרי /.

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

שינוי צינור עיבוד הנתונים של האינטגרציה הרציפה כדי להפעיל את צינור עיבוד הנתונים של הפיתוח הרציף

בסעיף הזה מוסיפים כמה שלבים לפייפליין של אינטגרציה רציפה שיוצר גרסה חדשה של מניפסט Kubernetes ומעלה אותה למאגר hello-cloudbuild-env כדי להפעיל את פייפליין הפיתוח הרציף.

1. מחליפים את הקובץ cloudbuild.yaml בדוגמה המורחבת בקובץ cloudbuild-trigger-cd.yaml.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   cp cloudbuild-trigger-cd.yaml cloudbuild.yaml
   

   קובץ cloudbuild-trigger-cd.yaml הוא גרסה מורחבת של קובץ cloudbuild.yaml. הוא מוסיף שלבים ליצירת מניפסט Kubernetes חדש ולהפעלת צינור העברת הנתונים הרציפה.

   הערה: בצינור הזה נעשה שימוש ב-sed כדי לעבד את תבנית המניפסט. בפועל, יכול להיות שכדאי להשתמש בכלי ייעודי כמו kustomize או skaffold. הכלים האלה מאפשרים לכם לשלוט יותר טוב בעיבוד של תבניות המניפסט.
   # This step clones the hello-cloudbuild-env repository
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Clone env repository
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       gcloud source repos clone hello-cloudbuild-env && \
       cd hello-cloudbuild-env && \
       git checkout candidate && \
       git config user.email $(gcloud auth list --filter=status:ACTIVE --format='value(account)')
   
   # This step generates the new manifest
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Generate manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
        sed "s/GOOGLE_CLOUD_PROJECT/${PROJECT_ID}/g" kubernetes.yaml.tpl | \
        sed "s/COMMIT_SHA/${SHORT_SHA}/g" > hello-cloudbuild-env/kubernetes.yaml
   
   # This step pushes the manifest back to hello-cloudbuild-env
   - name: 'gcr.io/cloud-builders/gcloud'
     id: Push manifest
     entrypoint: /bin/sh
     args:
     - '-c'
     - |
       set -x && \
       cd hello-cloudbuild-env && \
       git add kubernetes.yaml && \
       git commit -m "Deploying image us-central1-docker.pkg.dev/$PROJECT_ID/my-repository/hello-cloudbuild:${SHORT_SHA}
       Built from commit ${COMMIT_SHA} of repository hello-cloudbuild-app
       Author: $(git log --format='%an <%ae>' -n 1 HEAD)" && \
       git push origin candidate
   

2. שומרים את השינויים ושולחים אותם אל Cloud Source Repositories.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   git add cloudbuild.yaml
   git commit -m "Trigger CD pipeline"
   git push google master
   

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

3. בודקים את ה-build של האינטגרציה הרציפה.

   כניסה ל-Cloud Build

   מופיעים ה-builds שהרצתם לאחרונה והסתיימו במאגר hello-cloudbuild-app. אפשר ללחוץ על build כדי לעקוב אחרי ההרצה שלו ולבדוק את היומנים שלו. בשלב האחרון של צינור העיבוד הזה, המניפסט החדש נדחף למאגר hello-cloudbuild-env, וזה מפעיל את צינור העיבוד של הפיתוח הרציף.

4. בודקים את ה-build של הפיתוח הרציף.

   כניסה ל-Cloud Build

   מופיעים ה-builds שהרצתם לאחרונה והסתיימו במאגר hello-cloudbuild-env. אפשר ללחוץ על build כדי לעקוב אחרי ההרצה שלו ולבדוק את היומנים שלו.

בדיקת צינור עיבוד הנתונים המלא

צינור עיבוד הנתונים המלא של CI/CD מוגדר עכשיו. בקטע הזה, תבדקו את התהליך מקצה לקצה.

1. עוברים לדף GKE Services.

   מעבר אל Google Kubernetes Engine Services

   הרשימה מכילה שירות יחיד בשם hello-cloudbuild שנוצר על ידי build של פיתוח רציף שהושלם לאחרונה.

2. לוחצים על נקודת הקצה של השירות hello-cloudbuild. מופיע הטקסט Hello World!‎. אם אין נקודת קצה או שמופיעה שגיאה במאזן העומסים, יכול להיות שתצטרכו להמתין כמה דקות עד שמאזן העומסים יאותחל באופן מלא. אם צריך, לוחצים על רענון כדי לעדכן את הדף.

3. ב-Cloud Shell, מחליפים את Hello World ב-Hello Cloud Build, גם באפליקציה וגם בבדיקת היחידה.

   cd ~/kubernetes-engine-samples/management/gitops-style-delivery/
   sed -i 's/Hello World/Hello Cloud Build/g' app.py
   sed -i 's/Hello World/Hello Cloud Build/g' test_app.py
   

4. שומרים ודוחפים את השינוי ל-Cloud Source Repositories.

   git add app.py test_app.py
   git commit -m "Hello Cloud Build"
   git push google master
   

   הפעולה הזו מפעילה את צינור עיבוד הנתונים המלא של CI/CD.

5. אחרי כמה דקות, טוענים מחדש את האפליקציה בדפדפן. מופיע הכיתוב Hello Cloud Build!.

בדיקת החזרה למצב הקודם

בקטע הזה, מבצעים חזרה לגרסה של האפליקציה שבה מופיע הכיתוב Hello World!‎.

1. פותחים את מסוף Cloud Build למאגר hello-cloudbuild-env.

   כניסה ל-Cloud Build

2. לוחצים על ה-build השני הכי עדכני שזמין.

3. לוחצים על Rebuild.

4. בסיום ה-build, טוענים מחדש את האפליקציה בדפדפן. הטקסט 'Hello World!‎' מופיע שוב.

הסרת המשאבים

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

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

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

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

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

   כניסה לדף Manage resources

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

מחיקת המשאבים

אם רוצים לשמור את Google Cloud הפרויקט שבו השתמשתם במדריך הזה, צריך למחוק את המשאבים הבודדים:

1. מחיקת מאגרי Git מקומיים.

   cd ~
   rm -rf ~/hello-cloudbuild-app
   rm -rf ~/hello-cloudbuild-env
   

2. מוחקים את מאגרי ה-Git ב-Cloud Source Repositories.

   gcloud source repos delete hello-cloudbuild-app --quiet
   gcloud source repos delete hello-cloudbuild-env --quiet
   

3. מוחקים את הטריגרים של Cloud Build.

   1. פותחים את הדף Triggers של Cloud Build.

      כניסה לדף Triggers

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

4. מחיקת מאגר Docker ב-Artifact Registry.

   gcloud artifacts repositories delete my-repository \
       --location=us-central1
   

5. מסירים את ההרשאה שניתנה ל-Cloud Build להתחבר ל-GKE.

   PROJECT_NUMBER="$(gcloud projects describe ${PROJECT_ID} \
       --format='get(projectNumber)')"
   gcloud projects remove-iam-policy-binding ${PROJECT_NUMBER} \
       --member=serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \
       --role=roles/container.developer
   

6. מוחקים את אשכול GKE.

   gcloud container clusters delete hello-cloudbuild \
      --location us-central1
   

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

• כדאי לבדוק את התכונות המתקדמות יותר ב-Cloud Build: הגדרת סדר השלבים של ה-build, יצירה, בדיקה ופריסה של ארטיפקטים, וגם יצירת שלבים מותאמים אישית של build.
• איך משכפלים מאגר GitHub או Bitbucket ל-Cloud Source Repositories
• חיבור Cloud Build ישירות למאגר שלכם ב-GitHub