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

רגילה

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

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

1. סקירה כללית
2. הסבר על המונולית
3. הפיכת המונוליט למודולרי
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 שם השירות במניפסט זהה לשם שמשמש בנקודת הקצה של המודול: http://book-details-service. כשהאפליקציה פועלת ב-Kubernetes, המערכת משתמשת בשמות השירות האלה כדי לנתב בקשות למודולים הנכונים.

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

סיכום

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

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

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