זהו המדריך השלישי בסדרת מדריכים שמסבירים איך להפוך אפליקציה מונוליטית למודולרית ולהעביר אותה לקונטיינר.
תוכנית הלימודים כוללת את המדריכים הבאים:
- סקירה כללית
- הסבר על המונולית
- הפיכת המונוליט למודולרי
- הכנת האפליקציה המודולרית להעברה לקונטיינר (המדריך הזה)
- העברת האפליקציה המודולרית לקונטיינר
- פריסת האפליקציה באשכול 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 ששיכפלתם במדריך הראשון בסדרה הזו. כדי לראות את הגדרת השירות:
במסוף, עוברים לספרייה של הקונטיינר במאגר המשוכפל:
cd containerizedפותחים את קובץ המניפסט של Kubernetes בכלי לעריכת טקסט:
cat kubernetes_manifest.yamlמחפשים את הגדרת השירות של המודול
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.