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

Standard

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

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

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

במדריך הקודם, יצירת קונטיינר לאפליקציה מודולרית, הכנתם את האפליקציה המודולרית 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) ליצירה ולניהול Google Cloud של משאבים כמו אשכולות GKE.

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

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

1. נכנסים למסוףGoogle Cloud .

2. במסוף, לוחצים על הכפתור Activate 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, אתם יכולים לפרוס בו את האפליקציה Cymbal Books. כדי לפרוס אפליקציה באשכול, צריך להחיל את מניפסט 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.

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

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

מה זה Kubernetes Pod?

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

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

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

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

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

אימות הפריסה

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

בדיקת ה-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

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

kubectl get pods

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

עיון ביומנים של Pod

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

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.

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

למידע נוסף על יצירת אשכולות, ראו את הסדרה תוכנית לימודים: אפליקציות שניתנות להתאמה לעומס (scalable).