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

רגילה

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

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

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

במדריך הקודם, Modularize the monolith, ראיתם איך לפצל את אפליקציית Cymbal Books למודולים עצמאיים של Flask. במדריך הזה נסביר על שינוי אחד שצריך לבצע באפליקציה המודולרית כדי להכין אותה להעברה לקונטיינר.

עלויות

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

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

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

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

אם כבר השלמתם את המדריך הראשון, שכפלתם מאגר GitHub. כל שלוש הגרסאות של אפליקציית Cymbal Books נמצאות במאגר הזה, בתוך התיקיות הבאות:

• monolith/
• modular/
• containerized/

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

שינוי הקוד המודולרי

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

בתיקייה modular/, נקודות הקצה מוצפנות ב-home.py, באמצעות localhost, באופן הבא:

BOOK_SERVICE_URL = "http://localhost:8081"     # Book details module listens on port 8081
REVIEW_SERVICE_URL = "http://localhost:8082"   # Book reviews module listens on port 8082
IMAGE_SERVICE_URL = "http://localhost:8083"    # Image module listens on port 8083

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

כדי לוודא שהמודול בדף הבית עדיין יכול לגשת למודולים האחרים, כתובות ה-URL צריכות להשתמש בשמות של שירותי Kubernetes במקום ב-localhost. שם השירות פועל כמו כינוי שמשמש את Kubernetes לניתוב בקשות למודול הנכון – לא משנה איפה הוא פועל. לדוגמה, כשמודול דף הבית שולח בקשה אל http://book-details-service/book/1, ‏ Kubernetes עוזר לוודא שהבקשה מגיעה למודול book-details.

אין צורך לעדכן את כתובות ה-URL האלה בעצמכם. הגרסה של האפליקציה בתיקייה containerized/ כבר כוללת את השינוי הזה: כתובות ה-URL localhost שמוגדרות בהגדרות הקוד הוחלפו בשמות של שירותי Kubernetes. אפשר לראות את הגרסה המעודכנת ב-containerized/home_app/home_app.py:

BOOK_SERVICE_URL = "http://book-details-service"
REVIEW_SERVICE_URL = "http://book-reviews-service"
IMAGE_SERVICE_URL = "http://images-service"

העדכון הזה עוזר לוודא שהאפליקציה תפעל בצורה תקינה כשהיא פועלת בסביבת Kubernetes.

מניפסט Kubernetes

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

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

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

הצגת קובץ המניפסט

בקטע הזה נבדוק איך שירותים מוגדרים במניפסט של Kubernetes שנכתב בשבילכם. קובץ המניפסט, שהוא קובץ YAML, נמצא בתיקייה containerized/ של מאגר GitHub ששיכפלתם במדריך הראשון בסדרה הזו. כדי לראות את הגדרת השירות:

1. במסוף, עוברים לספרייה של הקונטיינר במאגר המשוכפל:

   cd containerized
   

2. פותחים את קובץ המניפסט של Kubernetes בכלי לעריכת טקסט:

   cat kubernetes_manifest.yaml
   

3. מחפשים את הגדרת השירות של המודול book-details. היא תיראה כמו בדוגמה הבאה:

   apiVersion: v1
   kind: Service
   metadata:
   name: book-details-service
   spec:
   selector:
       app: book-details-app
   ports:
       - protocol: TCP
       port: 80  # External traffic on port 80
       targetPort: 8080  # Targeting container port 8080
   type: ClusterIP
   

השם book-details-service Service name במניפסט זהה לשם שמשמש בנקודת הקצה של המודול: http://book-details-service. כשהאפליקציה פועלת ב-Kubernetes, ‏ Kubernetes משתמש בשמות השירות האלה כדי לנתב בקשות למודולים הנכונים.

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

סיכום

במדריך הזה ראיתם איך כתובות ה-URL בקוד המודולרי עודכנו כדי להשתמש בשמות של שירותי Kubernetes, כמו http://book-details-service. שמות השירותים האלה מאפשרים ל-Kubernetes לנתב בקשות בין מודולים גם כשהמיקומים שלהם באשכול משתנים. בדקתם גם את מניפסט Kubernetes וראיתם איך שמות השירותים בקוד המודולרי תואמים לשמות שמוגדרים במניפסט.

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

במדריך הבא, יצירת קונטיינר לאפליקציה מודולרית, נסביר איך ליצור קונטיינר למודול על ידי אריזתו בפריט שנקרא תמונת קונטיינר. בהמשך מוסבר איך להריץ קובץ אימג' של קונטיינר כקונטיינר, לבדוק את התכונות שלו ולהעביר את קובץ האימג' של הקונטיינר אל Artifact Registry של Google.