פריסה ב-GKE

בדף הזה מוסבר איך לפרוס אפליקציה ל-Kubernetes באמצעות Cloud Build.

‫Cloud Build מספק gke-deploy כלי ליצירת build שמאפשר לפרוס אפליקציה בקונטיינר לאשכול GKE.

‫gke-deploy הוא wrapper של kubectl, ממשק שורת הפקודה של Kubernetes. הוא מיישם את השיטות המומלצות של Google לפריסת אפליקציות ב-Kubernetes, באמצעות:

• עדכון קובץ משאבי Kubernetes של האפליקציה לשימוש ב-digest של תמונת הקונטיינר במקום בתג.

• הוספת תוויות מומלצות לקובץ המשאבים של Kubernetes.

• שליפת פרטי הכניסה לאשכולות GKE שבהם אתם פורסים את התמונה.

• המערכת ממתינה שקובץ משאב Kubernetes שנשלח יהיה מוכן.

אם אתם רוצים לפרוס את האפליקציות שלכם באמצעות kubectl ישירות ולא צריכים פונקציונליות נוספת, Cloud Build מספק גם kubectl כלי ליצירת build שבו תוכלו להשתמש כדי לפרוס את האפליקציה שלכם לאשכול GKE.

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

• אם עדיין אין לכם אשכול GKE, אתם צריכים ליצור אחד.

• אפליקציה בקונטיינר בצורה של קוד מקור וקובץ Dockerfile מוכן. קוד המקור צריך להיות מאוחסן במאגר, כמו Cloud Source Repositories,‏ GitHub או Bitbucket.

• צריך לפחות קובץ משאבים אחד של Kubernetes שמתאר את משאבי Kubernetes שמשמשים להפעלת האפליקציה. אם אין לכם קובצי משאבים של Kubernetes, אתם יכולים ליצור קובץ כזה לאפליקציה שלכם באמצעות השלבים הבאים:

  1. פותחים את הדף Kubernetes Engine clusters במסוף Google Cloud .
  2. בדף Kubernetes Engine clusters (אשכולות Kubernetes Engine), לוחצים על Deploy (פריסה).
  3. בוחרים את מאגר התגים ולוחצים על המשך. יוצג הקטע Configuration (הגדרה).
  4. בקטע Configuration YAML (קובץ YAML של הגדרות), לוחצים על View YAML (הצגת YAML) כדי לקבל קובץ משאבים לדוגמה של Kubernetes.
  הערה: אם כבר יש לכם קובץ משאבים של Kubernetes עם תבנית, כמו תרשים Helm או משאב בפורמט Kustomize, תוכלו לעיין בכלי ליצירת Helm או בכלי ליצירת Kustomize כדי לראות דוגמאות להגדרות בנייה שאפשר להשתמש בהן לפריסה.

שימו לב: החל מ-17 ביוני 2024, שירות Cloud Source Repositories לא זמין ללקוחות חדשים. אם הארגון שלכם לא השתמש בעבר ב-Cloud Source Repositories, לא תוכלו להפעיל את ה-API או להשתמש ב-Cloud Source Repositories. בפרויקטים חדשים שלא מקושרים לארגון אי אפשר להפעיל את Cloud Source Repositories API. השינוי הזה לא ישפיע על ארגונים שהשתמשו ב-Cloud Source Repositories לפני 17 ביוני 2024.

הרשאות IAM נדרשות

מוסיפים לחשבון את התפקיד 'מפתח Google Kubernetes Engine':

1. במסוף Google Cloud , נכנסים לדף Cloud Build Permissions:

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

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

פריסה של קובץ אימג' של קונטיינר מוכן מראש

כדי לפרוס גרסה מסוימת של האפליקציה באמצעות gke-deploy:

1. מוודאים שקובץ משאבי Kubernetes מפנה לתג או לערך הגיבוב הנכונים של קובץ אימג' של קונטיינר.

2. מוסיפים את השלב gke-deploy לקובץ הגדרות ה-build:

   YAML

   steps:
   ...
   # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=KUBERNETES_RESOURCE_FILE
     - --location=CLUSTER_LOCATION
     - --cluster=CLUSTER
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=KUBERNETES_RESOURCE_FILE",
           "--location=CLUSTER_LOCATION",
           "--cluster=CLUSTER"
         ]
       }
     ]
   }
   

   כאשר:

   • ‫KUBERNETES_RESOURCE_FILE הוא הנתיב של קובץ משאבי Kubernetes או הנתיב של הספרייה שמכילה את קובצי משאבי Kubernetes.
   • ‫CLUSTER_LOCATION הוא האזור של האשכול.
   • ‫CLUSTER הוא שם אשכול ה-GKE שבו האפליקציה תופעל.

   מידע נוסף על הדגלים הזמינים מופיע במאמר בנושא דגלים של gke-deploy run.

   הערה: כשפורסים לכמה אשכולות GKE,‏ Cloud Build שומר את ספריית הבית בכל שלבי הבנייה, מה שאומר שבהגדרת ברירת המחדל, ההקשר kubectl של השלב הקודם ישמש את השלבים הבאים. כדי להימנע מכך, מוסיפים הצהרה על משתנה סביבה, KUBECONFIG=/tmp/kubeconfig, לכל שלב בקובץ ההגדרות של ה-build.

3. מתחילים לבנות:

   gcloud builds submit --region=LOCATION --project=PROJECT --config BUILD_CONFIG
   

   כאשר:

   • ‫LOCATION הוא אחד ממיקומי הבנייה הנתמכים.
   • ‫PROJECT הוא מזהה הפרויקט.
   • ‫BUILD_CONFIG הוא השם של קובץ הגדרות ה-build.

פיתוח ופריסה של קובץ אימג' חדש של קונטיינר

כדי ליצור קובץ אימג' חדש של קונטיינר ולפרוס אותו:

1. מעדכנים את קובץ המשאבים של Kubernetes באמצעות מאפיין --image עם תמונת הקונטיינר החדשה:

   YAML

   steps:
     # build the container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["build", "-t", "LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG", "."]
     # push container image
   - name: "gcr.io/cloud-builders/docker"
     args: ["push", "LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG"]
     # deploy container image to GKE
   - name: "gcr.io/cloud-builders/gke-deploy"
     args:
     - run
     - --filename=KUBERNETES_RESOURCE_FILE
     - --image=LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG
     - --location=CLUSTER_LOCATION
     - --cluster=CLUSTER
   

   JSON

   {
     "steps": [
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "build",
           "-t",
           "LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG",
           "."
         ]
       },
       {
         "name": "gcr.io/cloud-builders/docker",
         "args": [
           "push",
           "LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG"
         ]
       },
       {
         "name": "gcr.io/cloud-builders/gke-deploy",
         "args": [
           "run",
           "--filename=KUBERNETES_RESOURCE_FILE",
           "--image=LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG",
           "--location=CLUSTER_LOCATION",
           "--cluster=CLUSTER"
         ]
       }
     ]
   }
   

   כאשר:

   • ‫LOCATION הוא אחד ממיקומי הבנייה הנתמכים.
   • ‫PROJECT הוא מזהה הפרויקט.
   • ‫IMAGE_NAME הוא השם שרוצים לתת לתמונת הקונטיינר, בדרך כלל שם האפליקציה.
   • ‫TAG הוא התג של קובץ אימג' של קונטיינר.
     • אם אתם יוצרים קובץ אימג' של קונטיינר חדש בכל קומיט, מומלץ להשתמש ב-SHA הקצר של הקומיט כתג. ‫Cloud Build מספק את זה כהחלפה שמוגדרת כברירת מחדל, $SHORT_SHA.
   • ‫KUBERNETES_RESOURCE_FILE הוא הנתיב של קובץ משאבי Kubernetes או הנתיב של הספרייה שמכילה את קובצי משאבי Kubernetes.
   • ‫CLUSTER הוא שם אשכול ה-GKE שבו האפליקציה תופעל.
   • ‫CLUSTER_LOCATION הוא האזור שבו יופעל האשכול.
   הערה: אפשר להפנות באמצעות gke-deploy רק לתמונה אחת בקובץ תצורת build. אם קובצי המשאבים של Kubernetes מכילים כמה הפניות לתמונות, רק התמונות שמתחילות ב-LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG יעודכנו כך שיפנו לתג שצוין.

2. מתחילים לבנות:

   gcloud builds submit --region=LOCATION --project=PROJECT --config BUILD_CONFIG
   

   כאשר:

   • ‫LOCATION הוא אחד מאזורי הבנייה הנתמכים.
   • ‫PROJECT הוא מזהה הפרויקט.
   • ‫BUILD_CONFIG הוא השם של קובץ הגדרות ה-build.

אוטומציה של פריסות

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

כדי ליצור טריגר לפיתוח גרסת Build:

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

   פתיחת הדף Triggers

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

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

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

   בדף Create trigger, מזינים את ההגדרות הבאות:

   1. מזינים שם לטריגר.

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

   3. בוחרים את המאגר שמכיל את קובץ קוד המקור ואת קובץ הגדרות הבנייה.

   4. מציינים את הביטוי הרגולרי לשם הענף או התג שיפעיל את הטריגר.

   5. בוחרים הגדרה לטריגר.

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

      YAML

      steps:
      ...
      # deploy container image to GKE
      - name: "gcr.io/cloud-builders/gke-deploy"
        args:
        - run
        - --filename=KUBERNETES_RESOURCE_FILE
        - --image=LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG
        - --location=${_CLOUDSDK_COMPUTE_ZONE}
        - --cluster=${_CLOUDSDK_CONTAINER_CLUSTER}
      

      JSON

      {
        "steps": [
          {
            "name": "gcr.io/cloud-builders/gke-deploy",
            "args": [
              "run",
              "--filename=KUBERNETES_RESOURCE_FILE",
              "--image=LOCATION-docker.pkg.dev/PROJECT/REPOSITORY/IMAGE_NAME:TAG",
              "--location=${_CLOUDSDK_COMPUTE_ZONE}",
              "--cluster=${_CLOUDSDK_CONTAINER_CLUSTER}"
            ]
          }
        ]
      }
      

      כאשר:

      • ‫KUBERNETES_RESOURCE_FILE הוא הנתיב של קובץ התצורה של Kubernetes או נתיב הספרייה שמכילה את קובצי המשאבים של Kubernetes.
      • ‫PROJECT הוא מזהה הפרויקט.
      • ‫IMAGE_NAME הוא השם שרוצים לתת לקובץ אימג' של קונטיינר, בדרך כלל שם האפליקציה.
      • ‫TAG הוא התג של קובץ אימג' של קונטיינר.

      מידע נוסף על הגדרת החלפות לקובצי תצורת build זמין במאמר שימוש בהחלפות שהוגדרו על ידי המשתמש.

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

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

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

• איך מגדירים פריסות אוטומטיות לעומסי עבודה ב-GKE
• איך יוצרים צינור עיבוד נתונים של CI/CD בסגנון GitOps לפריסה ב-GKE באמצעות Cloud Build
• gke-deployמידע נוסף על אפשרויות
• איך מבצעים פריסות כחולות-ירוקות ב-Compute Engine
• מידע נוסף על Cloud builders
• איך פותרים בעיות שקשורות לבנייה