תוכנית לימודים: הפיכת מונוליט לאפליקציית GKE – פריסת האפליקציה באשכול GKE

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

תוכנית הלימודים כוללת את המדריכים הבאים:

  1. סקירה כללית
  2. הסבר על המונולית
  3. הפיכת המונוליט למודולרי
  4. הכנת האפליקציה המודולרית להעברה לקונטיינר
  5. העברת האפליקציה המודולרית לקונטיינר
  6. פריסת האפליקציה באשכול GKE (המדריך הזה)

במדריך הקודם, Containerize the modular app, הכנתם את אפליקציית Cymbal Books המודולרית לפריסה. העברתם את המודולים של האפליקציה לקונטיינרים, בדקתם את הקונטיינרים שנוצרו והעברתם את קובצי האימג' של הקונטיינרים אל Artifact Registry.

במדריך הזה תלמדו איך לפרוס את האפליקציה בקונטיינר באשכול Google Kubernetes Engine. בשלב הזה הושלם השינוי של אפליקציית Cymbal Books למערכת מודולרית וניתנת להרחבה שפועלת באשכול Kubernetes.

עלויות

ביצוע השלבים במדריך הזה כרוך בחיובים בחשבון Google Cloud שלכם. העלויות מתחילות כשמפעילים את GKE ומפריסים את אפליקציית הדוגמה Cymbal Books. העלויות האלה כוללות חיובים לכל אשכול ב-GKE, כפי שמפורט בדף התמחור, וחיובים על הפעלת מכונות וירטואליות ב-Compute Engine.

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

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

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

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

הגדרת אשכול GKE

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

במדריך הזה משתמשים ב-CLI של gcloud כדי ליצור את האשכול. לחלופין, אפשר להשתמש בGoogle Cloud מסוף, שמספק ממשק משתמש גרפי (GUI) ליצירה ולניהול של משאבים כמו אשכולות GKE. Google Cloud

יצירה ואימות של אשכול GKE

אשכול GKE מספק את משאבי המחשוב שנדרשים להפעלת הקונטיינרים ב-Kubernetes. כדי ליצור אשכול באמצעות ה-CLI של gcloud, פועלים לפי השלבים הבאים.

  1. עוברים אל Google Cloud המסוף.

  2. במסוף, לוחצים על הלחצן Activate Cloud Shell: הפעלת Cloud Shell

    בחלק התחתון של המסוף ייפתח סשן של Cloud Shell בתוך מסגרת.

  3. מגדירים את פרויקט ברירת המחדל ב-Google Cloud CLI:

    gcloud config set project PROJECT_ID

    מחליפים את PROJECT_ID במזהה הפרויקט שיצרתם או בחרתם בקטע בחירה או יצירה של פרויקט Google Cloud במדריך הקודם. מזהה פרויקט הוא מחרוזת ייחודית שמבדילה את הפרויקט שלכם מכל הפרויקטים האחרים ב- Google Cloud. כדי לאתר את מזהה הפרויקט, עוברים אל בורר הפרויקטים. בדף הזה אפשר לראות את מזהי הפרויקטים של כל אחד מהפרויקטים שלכם ב- Google Cloud.

  4. יוצרים אשכול GKE:

    gcloud container clusters create CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION \
    --num-nodes=2

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

    • ‫CLUSTER_NAME: שם לאשכול, למשל cymbal-cluster.

    • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או תחום לאשכולות אזוריים, כמו us-central1 או europe-west1-b.

  5. מאחזרים את פרטי הכניסה של האשכול כדי ש-CLI של kubectl יוכל להתחבר לאשכול:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

    הפקודה הזו מעדכנת את קובץ התצורה של Kubernetes, שמאוחסן כברירת מחדל ב-~/.kube/config. קובץ התצורה הזה מכיל את פרטי הכניסה שנדרשים ל-kubectl כדי ליצור אינטראקציה עם אשכול GKE.

  6. כדי לוודא ש-kubectl מחובר לאשכול, מציגים את רשימת הצמתים של האשכול:

    kubectl get nodes

    אם ההגדרה מצליחה, הפקודה הזו מציגה את הצמתים באשכול GKE. מכיוון שיצרתם את האשכול באמצעות --num-nodes=2, אמור להופיע מידע על שני צמתים, בדומה למידע הבא:

    NAME                                         STATUS    ROLES    AGE    VERSION
gke-nov18-default-pool-6a8f9caf-bryg   Ready     <none>   30s    v1.30.8-gke.1128000
gke-nov18-default-pool-6a8f9caf-ut0i   Ready     <none>   30s    v1.30.8-gke.1128000

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

פריסת האפליקציה

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

החלת מניפסט Kubernetes

ב-Cloud Shell, פורסים את האפליקציה לאשכול GKE על ידי הרצת הפקודות הבאות:

  1. מנווטים לספריית הבסיס של האפליקציה בקונטיינרים:

    cd kubernetes-engine-samples/quickstarts/monolith-to-microservices/containerized/

  2. הפעלת מניפסט Kubernetes:

    kubectl apply -f kubernetes_manifest.yaml

הפקודה הקודמת מורה ל-Kubernetes ליצור את המשאבים שצוינו בקובץ kubernetes-manifest.yaml. המקורות האלה כוללים שירותים, פריסה ו-Pods.

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

פריסה היא אובייקט Kubernetes API שמאפשר להריץ כמה עותקים של Pods שמפוזרים בין הצמתים באשכול. בקטע הבא מוסבר מהם פודים.

מה זה Pod ב-Kubernetes?

במדריך הקודם יצרתם קובץ אימג' של קונטיינר לכל מודול באפליקציית Cymbal Books. לדוגמה, יצרתם קובצי אימג' של קונטיינר שמבוססים על המודולים home_app ו-book_details_app.

כשמשתמשים בפקודה kubectl apply כדי לפרוס את מניפסט Kubernetes, מערכת Kubernetes מושכת את קובצי האימג' של הקונטיינרים מ-Artifact Registry אל האשכול. באשכול, קובצי האימג' של הקונטיינרים הופכים לקונטיינרים, והקונטיינרים פועלים בתוך Pods.

‫Pod היא סביבה מבודדת שבה פועלים קונטיינרים, והיא מבצעת את המשימות הבאות:

  • הקצאת מעבד (CPU) וזיכרון: פוד מספק את המשאבים שקונטיינרים צריכים כדי לפעול.
  • מספק רשת: לכל Pod יש כתובת IP משלו. כך ה-Pod יכול לתקשר עם Pods אחרים.

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

אימות הפריסה

אחרי שמחילים את מניפסט Kubernetes באמצעות הפקודה kubectl apply, מוודאים שהאפליקציה נפרסה באשכול בהצלחה. כדי לוודא שהפריסה תקינה, בודקים שה-Pods והשירותים פועלים בצורה תקינה.

בדיקת ה-Pods

כדי לראות את ה-Pods באשכול, מריצים את הפקודה הבאה:

kubectl get pods

הפקודה הזו מציגה רשימה של ה-Pods והסטטוס הנוכחי שלהם. בעמודה STATUS (סטטוס) צריך לוודא שכל ה-Pods מסומנים בסימן Running, שמציין שהם פועלים בהצלחה ומוכנים לטפל בבקשות. הפלט הצפוי אמור להיראות כך:

NAME                             READY   STATUS    RESTARTS   AGE
home-app-67d59c6b6d-abcde        1/1     Running   0          30s
book-details-app-6d8bcbc58f-xyz  1/1     Running   0          30s
book-reviews-app-75db4c4d7f-def  1/1     Running   0          30s
images-app-7f8c75c79c-ghi        1/1     Running   0          30s

הסטטוס של Pod מופיע בהתחלה כ-Pending בזמן היצירה שלו, והקונטיינרים שלו נמצאים בתהליך של הפעלה. אם מצב ה-Pod נשאר Pending למשך זמן ממושך, יכול להיות שאין מספיק משאבים באשכול כדי שה-Pod יעבור למצב תקין Running. אם הסטטוס של ה-Pod הוא CrashLoopBackOff, יכול להיות שיש בעיה עם הקונטיינר. בהמשך המדריך מפורטים שלבים לפתרון בעיות.

בדיקת השירותים

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

kubectl get services

הפלט של הפקודה הזו אמור להיראות כך:

NAME               TYPE           CLUSTER-IP      EXTERNAL-IP       PORT(S)        AGE
home-app-service   LoadBalancer   10.12.3.4       35.185.1.2        80:30837/TCP   30s
details-service    ClusterIP      10.12.3.5       <none>            80/TCP         30s
reviews-service    ClusterIP      10.12.3.6       <none>            80/TCP         30s
images-service     LoadBalancer   10.12.3.7       34.125.6.3        80:32014/TCP   30s

השדות העיקריים שצריך לשים לב אליהם בפלט הם:

  • ‫TYPE: בשדה הזה מצוין איך השירות נחשף. שירותים מסוג LoadBalancer מספקים גישה חיצונית לאפליקציה.
  • ‫EXTERNAL-IP: בשירות מסוג LoadBalancer, השדה EXTERNAL-IP מציג את כתובת ה-IP הציבורית שהמשתמשים יכולים להזין בדפדפן האינטרנט כדי לגשת לאפליקציה. בשירות מסוג ClusterIP, השדה הזה ריק כי אפשר לגשת לשירותים מסוג ClusterIP רק בתוך האשכול.

בדיקת הפריסה

אחרי שפורסים את אפליקציית Cymbal Books באשכול GKE, צריך לוודא שהאפליקציה נגישה ושהקונטיינרים יכולים לתקשר ביניהם.

גישה לאפליקציה

כדי לוודא שיש גישה לאפליקציה, פועלים לפי השלבים הבאים:

  1. מאחזרים את כתובת ה-IP החיצונית של home-app-service:

    kubectl get services

    חפשו את העמודה **EXTERNAL-IP** בפלט ורשמו את כתובת ה-IP שמשויכת ל-home-app-service.

  2. פותחים דפדפן אינטרנט ומזינים את כתובת ה-URL הבאה:

    http://EXTERNAL-IP

    מחליפים את EXTERNAL-IP בכתובת ה-IP שמצאתם בשלב הקודם.

  3. מוודאים שדף הבית של אפליקציית Cymbal Books נטען בצורה תקינה.

אימות של תקשורת בין שירותים

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

  1. מאחזרים את כתובת ה-IP החיצונית של home-app-service כמו שמתואר למעלה.

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

    • בודקים את תמונות עטיפות הספרים: מוודאים שתמונות עטיפות הספרים נטענות בצורה תקינה גם בדף הבית וגם בדף הפרטים של הספר. אם הם תואמים, מאגרי התגים home_app ו-book_details_app מתקשרים בהצלחה עם מאגר התגים images_app.
    • הצגת פרטי הספר: מעבר לדף פרטי הספר מדף הבית. אם אתם רואים את פרטי הספר, סימן שהקשר בין מאגר התגים home_app לבין book_details_app תקין.
    • צפייה בביקורות על ספרים: לוחצים על קישור לביקורת על ספר כדי לוודא שהמאגר home_app יכול לתקשר עם המאגר book_reviews_app.

האפליקציה שלכם פועלת עכשיו באשכול GKE!

כל הכבוד! במאמר הזה ראינו איך להפוך אפליקציה מונוליטית למערכת מודולרית שמבוססת על קונטיינרים ופועלת באשכול GKE פעיל. במהלך התהליך למדתם איך לחלק קוד עם תלות הדדית למודולים עצמאיים, ליצור קובצי אימג' בקונטיינרים ולהעביר אותם למאגר, להגדיר מניפסטים של Kubernetes ולפרוס את האפליקציה מהמאגר ל-GKE. זהו הישג משמעותי, והוא משקף את הצעדים שצוותים נוקטים בעולם האמיתי כדי לבצע מודרניזציה של אפליקציות לענן.

פתרון בעיות

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

בדיקת הסטטוס של ה-Pods

מתחילים בהכנת רשימה של כל ה-Pods באשכול כדי לבדוק אם הם פועלים כמצופה:

kubectl get pods

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

בדיקת יומנים של Pod

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

kubectl logs POD_NAME

מחליפים את POD_NAME בשם של ה-Pod שרוצים לבדוק. הפקודה הזו שימושית לזיהוי בעיות בהפעלה או שגיאות בזמן ריצה.

תיאור של Pod לקבלת מידע מפורט

אם חבילת ה-Pod נשארת במצב שאינו Running למשך יותר מחמש דקות – למשל, במצב Pending, ContainerCreating או CrashLoopBackOff – אפשר להשתמש בפקודה הבאה כדי לראות מידע מפורט על הסטטוס והאירועים של ה-Pod:

kubectl describe pod POD_NAME

מחליפים את POD_NAME בשם של ה-Pod שרוצים לקבל עליו מידע מפורט.

הקטע Events בפלט עשוי להצביע על כך שמגבלות משאבים או בעיות בשליפת תמונות מונעות את ההפעלה התקינה של ה-Pod.

אימות הגדרות השירות

חשוב לוודא שהשירותים מוגדרים בצורה נכונה, במיוחד השירות שחושף את מודול הבית עם כתובת IP חיצונית. מריצים את הפקודה הבאה כדי להציג את השירותים:

kubectl get services

אם שמתם לב שבמודול Service for the home (שירות לבית) יש כתובת EXTERNAL-IP שמופיעה כ-Pending, מריצים את הפקודה הבאה:

kubectl describe service SERVICE_NAME

מחליפים את SERVICE_NAME בשם של מודול הבית Service.

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

בדיקת אירועים באשכול

אתם יכולים לבדוק את האירועים של האשכול כדי לראות אם בעיה משפיעה על כמה רכיבים של האשכול:

kubectl get events

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

פינוי משאבים

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

מחיקת אשכול GKE

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

gcloud container clusters delete CLUSTER_NAME
    --location=CONTROL_PLANE_LOCATION

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

  • ‫CLUSTER_NAME: השם של האשכול שיצרתם, למשל cymbal-cluster.

  • ‫CONTROL_PLANE_LOCATION: המיקום של מישור הבקרה של האשכול ב-Compute Engine. מציינים אזור לאשכולות אזוריים או אזור זמין לאשכולות אזוריים.

כשמופיעה בקשת אישור, מאשרים את המחיקה.

בדיקה שהאשכול נמחק

כדי לוודא שהאשכול נמחק, מריצים את הפקודה הבאה:

gcloud container clusters list

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

(אופציונלי) מחיקת הפרויקט Google Cloud

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

  1. במסוף Google Cloud , פותחים את הדף Manage Resources.
  2. בוחרים את הפרויקט שרוצים למחוק.
  3. לוחצים על Delete Project ופועלים לפי ההנחיות כדי לאשר.

סיכום הסדרה

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

  1. הסבר על המונולית

    • הסבר על המבנה של אפליקציית Cymbal Books המונוליטית.
    • הגדרת סביבת Python מקומית להרצת המונוליט ובדיקת נקודות הקצה שלו.
    • הבנתם את ה-codebase של האפליקציה כדי להכין אותה למודולריזציה.

  2. הפיכת המונוליט למודולרי

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

  3. הכנת הקוד המודולרי להעברה לקונטיינר

    • הבנתי שצריך לעדכן את כתובות ה-URL ב-home.py כדי להשתמש בשמות שירותים במקום ב-localhost.
    • הסבר על האופן שבו מניפסט Kubernetes מגדיר שירותים שמאפשרים למודולים של האפליקציה, שכבר מתקשרים ביניהם, למצוא אחד את השני בהקשר של אשכול Kubernetes.

  4. העברת האפליקציה המודולרית לקונטיינר

    • הגדרתם Google Cloud פרויקט ושיבטתם את האפליקציה מ-GitHub ל-Cloud Shell.
    • יצרו קובצי אימג' של קונטיינרים לכל מודול באמצעות Docker ובדקו את הקונטיינרים באופן מקומי.
    • העברתם בדחיפה את קובצי האימג' של הקונטיינרים אל Artifact Registry כדי להכין את האפליקציה לפריסה באשכול.
    • עדכנו את מניפסט Kubernetes כך שיפנה לנתיבי קובצי האימג' של הקונטיינרים ב-Artifact Registry.

  5. פריסת האפליקציה באשכול GKE (המדריך שאתם קוראים עכשיו):

    • יצירת אשכול GKE.
    • פריסת קובצי האימג' של הקונטיינרים מ-Artifact Registry לאשכול GKE.
    • בדקנו את הגרסה הסופית של האפליקציה, שניתן להרחיב אותה והיא פועלת בסביבת Kubernetes.

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

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