1. מבוא
למה כדאי לעבור מאפליקציה מונוליתית לארכיטקטורת מיקרו-שירותים (microservices)? פירוק אפליקציה למיקרו-שירותים מציעה את היתרונות הבאים: רובם נובעים מהעובדה שמיקרו-שירותים (microservices) בצימוד חלש.
- אפשר לבדוק ולפרוס את המיקרו-שירותים באופן עצמאי. ככל שיחידת הפריסה קטנה יותר, כך הפריסה קלה יותר.
- אפשר להטמיע אותם בשפות שונות ובמסגרות שונות. לכל מיקרו-שירות (microservice), אתם יכולים לבחור את הטכנולוגיה המתאימה ביותר לתרחיש המסוים שלו.
- אפשר לנהל אותם על ידי צוותים שונים. הגבול בין מיקרו-שירותים (microservices) מקל על הקצאת צוות למיקרו-שירותים (microservices) אחד או יותר.
- מעבר לשימוש במיקרו-שירותים (microservices) משחרר את יחסי התלות בין הצוותים. כל צוות צריך לטפל רק בממשקי ה-API של המיקרו-שירותים (microservices) שבהם הוא תלוי. הצוות לא צריך לחשוב על האופן שבו המיקרו-שירותים האלה מוטמעים, על מחזורי הגרסאות שלהם וכו'.
- קל יותר לתכנן כשלים. כשמגדירים גבולות ברורים בין השירותים, קל יותר לקבוע מה לעשות אם שירות מסוים מושבת.
אלה החסרונות בהשוואה למונוליתים:
- אפליקציה שמבוססת על מיקרו-שירות (microservice) היא רשת של שירותים שונים שבדרך כלל יוצרים אינטראקציה בדרכים שלא ברורות מאליהן, ולכן המורכבות הכוללת של המערכת נוטה לגדול.
- בניגוד לחלק הפנימי של מונולית, מיקרו-שירותים מתקשרים באמצעות רשת. בנסיבות מסוימות, הדבר יכול להיחשב כבעיית אבטחה. Istio פותר את הבעיה הזו על ידי הצפנת תעבורת הנתונים בין מיקרו-שירותים (microservices).
- לפעמים קשה להשיג את אותה רמת ביצועים כמו בגישה מונוליתית בגלל זמני אחזור בין שירותים.
- התנהגות המערכת לא נגרמת על ידי שירות אחד, אלא על ידי רבים מהם והאינטראקציות שלהם. לכן קשה יותר להבין איך המערכת מתנהגת בסביבת הייצור (ניראות (observability)). גם Istio הוא פתרון לבעיה הזו.
בשיעור ה-Lab הזה נריץ מיקרו-שירותים (microservices) ב-Google Kubernetes Engine (GKE). Kubernetes היא פלטפורמה לניהול, לאירוח ולפריסה של קונטיינרים. קונטיינרים הם דרך ניידת לאריזה ולהרצת קוד. הם מתאימים היטב לדפוס מיקרו-שירותים, שבו כל מיקרו-שירות יכול לפעול בקונטיינר משלו.
בשיעור ה-Lab הזה נפרוס אפליקציה מונוליתית קיימת באשכול של Google Kubernetes Engine, ולאחר מכן נפרק אותה למיקרו-שירותים!
תרשים הארכיטקטורה של המיקרו-שירותים שלנו
נתחיל בפיצול המונולית שלנו לשלושה מיקרו-שירותים, אחד בכל פעם. המיקרו-שירותים כוללים: Orders, מוצרים ו-Frontend. אנחנו יוצרים קובץ אימג' של Docker לכל מיקרו-שירות באמצעות Cloud Build, שאותו אנחנו מפעילים מתוך Cloud Shell. לאחר מכן נפרוס ונחשוף את המיקרו-שירותים (microservices) שלנו ב-Google Kubernetes Engine (GKE) באמצעות סוג שירות Load Balancer של Kubernetes. נעשה זאת עבור כל שירות, ובמקביל לארגן אותם מחדש מתוך המונולית שלנו. במהלך התהליך נפעל גם המונולית וגם המיקרו-שירותים שלנו עד לסופה, ואז נוכל למחוק את המונולית.
מה תלמדו
- איך לפרק מונולית למיקרו-שירותים
- איך יוצרים אשכול של Google Kubernetes Engine
- איך יוצרים קובץ אימג' של Docker
- איך פורסים קובצי אימג' של Docker ל-Kubernetes
דרישות מוקדמות
- חשבון Google Cloud Platform עם הרשאת אדמין ליצירת פרויקטים או פרויקט עם תפקיד 'בעלי הפרויקט'
- הבנה בסיסית של Docker ו-Kubernetes
2. הגדרת סביבה
הגדרת סביבה בקצב אישי
אם אין לכם עדיין חשבון Google (Gmail או Google Apps), עליכם ליצור חשבון. נכנסים למסוף Google Cloud Platform ( console.cloud.google.com) ויוצרים פרויקט חדש:
חשוב לזכור את מזהה הפרויקט, שם ייחודי לכל הפרויקטים ב-Google Cloud (השם שלמעלה כבר תפוס ולא מתאים לכם, סליחה). בהמשך ב-Codelab הזה, היא תיקרא PROJECT_ID.
בשלב הבא עליך להפעיל את החיוב ב-Developer Console כדי להשתמש במשאבים של Google Cloud ולהפעיל את Container Engine API.
ההרצה של Codelab הזה לא אמורה לעלות לך יותר מכמה דולרים, אבל זה יכול להיות גבוה יותר אם תחליטו להשתמש ביותר משאבים או אם תשאירו אותם פועלים (עיינו בקטע 'ניקוי' בסוף המסמך). התמחור של Google Kubernetes Engine מופיע כאן.
משתמשים חדשים ב-Google Cloud Platform זכאים לתקופת ניסיון בחינם בשווי 300$.
Google Cloud Shell
אומנם אפשר להפעיל את Google Cloud ואת Kubernetes מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת הפקודה שפועלת ב-Cloud.
המכונה הווירטואלית הזו שמבוססת על Debian נטענת עם כל הכלים למפתחים שדרושים לכם. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר משמעותית את ביצועי הרשת והאימות. כלומר, כל מה שדרוש ל-Codelab הזה הוא דפדפן (כן, הוא פועל ב-Chromebook).
- כדי להפעיל את Cloud Shell ממסוף Cloud, לוחצים על Activate Cloud Shell
(ההקצאה וההתחברות לסביבה אמורות להימשך כמה דקות).
אחרי ההתחברות ל-Cloud Shell, אתם אמורים לראות שכבר בוצע אימות ושהפרויקט כבר מוגדר ל-PROJECT_ID שלכם.
gcloud auth list
פלט הפקודה
Credentialed accounts: - <myaccount>@<mydomain>.com (active)
gcloud config list project
פלט הפקודה
[core] project = <PROJECT_ID>
אם מסיבה כלשהי הפרויקט לא מוגדר, פשוט מריצים את הפקודה הבאה:
gcloud config set project <PROJECT_ID>
רוצה למצוא את ה-PROJECT_ID שלך? אתם יכולים לבדוק באיזה מזהה השתמשתם בשלבי ההגדרה או לחפש אותו במרכז הבקרה של מסוף Cloud:
Cloud Shell גם מגדירה משתני סביבה כברירת מחדל, והוא יכול להיות שימושי כשמריצים פקודות עתידיות.
echo $GOOGLE_CLOUD_PROJECT
פלט הפקודה
<PROJECT_ID>
- בשלב האחרון, מגדירים את ברירת המחדל של האזור והפרויקט.
gcloud config set compute/zone us-central1-f
אפשר לבחור מגוון אזורים שונים. מידע נוסף זמין במאמר אזורים ו אזורים.
3. שכפול מאגר מקור
אנחנו משתמשים באפליקציה מונוליתית קיימת של אתר מסחר אלקטרוני מדומה, עם דף פתיחה פשוט, דף מוצרים ודף היסטוריית הזמנות. נצטרך רק לשכפל את המקור ממאגר ה-Git שלנו, כדי שנוכל להתמקד בפיצול שלו למיקרו-שירותים (microservices) ופריסה ל-Google Kubernetes Engine (GKE).
מריצים את הפקודות הבאות כדי לשכפל את מאגר ה-Git למכונה של Cloud Shell ולהחליף לספרייה המתאימה. בנוסף, נתקין את יחסי התלות של NodeJS כדי שנוכל לבדוק את המונולית שלנו לפני הפריסה. יכול להיות שהסקריפט ירוץ כמה דקות.
cd ~ git clone https://github.com/googlecodelabs/monolith-to-microservices.git cd ~/monolith-to-microservices ./setup.sh
הפעולה הזו תשכפל את המאגר שלנו ב-GitHub, תשנה את הספרייה ותתקין את יחסי התלות שדרושים כדי להפעיל את האפליקציה באופן מקומי. יכול להיות שהסקריפט ירוץ כמה דקות.
4. יצירת אשכול GKE
עכשיו, אחרי שיש לכם סביבת פיתוח עבודה, אנחנו זקוקים לאשכול Kubernetes כדי לפרוס את המונולית שלנו, ובסופו של דבר, את המיקרו-שירותים שלנו. לפני שנוכל ליצור אשכול, אנחנו צריכים לוודא שממשקי ה-API המתאימים מופעלים. מריצים את הפקודה הבאה כדי להפעיל את ממשק ה-API של הקונטיינרים כדי שנוכל להשתמש ב-Google Kubernetes Engine:
gcloud services enable container.googleapis.com
עכשיו אנחנו מוכנים ליצור את האשכול שלנו! מריצים את הפקודה הבאה כדי ליצור אשכול GKE בשם fancy-cluster עם 3 צמתים.
gcloud container clusters create fancy-cluster --num-nodes 3
יכול להיות שיחלפו כמה דקות עד ליצירת האשכול. לאחר השלמת הפקודה, מריצים את הפקודה הבאה ורואים את שלוש מכונות ה-VM של העובדים באשכול:
gcloud compute instances list
פלט:
NAME ZONE MACHINE_TYPE PREEMPTIBLE INTERNAL_IP EXTERNAL_IP STATUS gke-fancy-cluster-default-pool-ad92506d-1ng3 us-east4-a n1-standard-1 10.150.0.7 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4fvq us-east4-a n1-standard-1 10.150.0.5 XX.XX.XX.XX RUNNING gke-fancy-cluster-default-pool-ad92506d-4zs3 us-east4-a n1-standard-1 10.150.0.6 XX.XX.XX.XX RUNNING
אפשר גם להציג את אשכול Kubernetes ומידע קשור במסוף Google Cloud. לוחצים על לחצן התפריט בפינה הימנית העליונה, גוללים למטה אל Kubernetes Engine ולוחצים על Clusters. אתם אמורים לראות את האשכול בשם fancy-cluster.
מעולה! יצרתם עכשיו את האשכול הראשון שלכם ב-Kubernetes!
5. פריסת מונולית קיים
בשיעור ה-Lab הזה תלמדו על פירוק מונולית למיקרו-שירותים, לכן אנחנו צריכים להפעיל יישום מונולית. מריצים את הסקריפט הבא כדי לפרוס אפליקציה מונולית באשכול GKE למטרות של שיעור ה-Lab הזה:
cd ~/monolith-to-microservices ./deploy-monolith.sh
גישה למונולית
כדי למצוא את כתובת ה-IP החיצונית של אפליקציית המונולית שלנו, מריצים את הפקודה הבאה.
kubectl get service monolith
הפלט אמור להיראות כך:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE monolith 10.3.251.122 203.0.113.0 80:30877/TCP 3d
הערה: צריך להקצות לשם כך מאזן עומסים חיצוני וכתובת IP, אז יכול לקחת קצת זמן עד שזה יקרה. אם בפלט מופיעה כתובת ה-IP החיצונית
<pending> צריך להמתין כמה דקות ולנסות שוב.
אחרי שקובעים את כתובת ה-IP החיצונית למונולית, מעתיקים את כתובת ה-IP. מפנים את הדפדפן לכתובת ה-URL הזו (למשל http://203.0.113.0) כדי לבדוק אם ניתן לגשת למונולית.
אתם אמורים לראות את דף הפתיחה של האתר המונוליתי בדיוק כמו בתמונה שלמעלה. דף הפתיחה הוא דף סטטי שיוצג על ידי המיקרו-שירות (microservice) של Frontend בהמשך. המונולית שלך פועל באופן מלא ב-Kubernetes!
6. העברת הזמנות למיקרו-שירות (microservice)
עכשיו, אחרי שאתר המונולית הקיים שלנו פועל ב-GKE, אנחנו יכולים להתחיל לפצל כל שירות למיקרו-שירות (microservice). בדרך כלל צריך לתכנן את השירותים כדי לחלק את השירותים לחלקים קטנים יותר, בדרך כלל סביב חלקים ספציפיים באפליקציה, כמו הדומיין של העסק. למטרות הדגמה, יצרנו דוגמה טריוויאלית וחילקנו את השירותים לפי הדומיין של העסק, הזמנות, מוצרים וממשק קצה. הקוד כבר הועבר ואנחנו נתמקד ביצירה ובפריסה של השירותים ב-Google Kubernetes Engine (GKE).
יצירת מיקרו-שירות (microservice) חדשות להזמנות
השירות הראשון שנציע לו הוא שירות ההזמנות. אנחנו נשתמש ב-codebase הנפרד וניצור קונטיינר נפרד של Docker לשירות הזה.
יצירת קונטיינר Docker באמצעות Google Cloud Build
מכיוון שכבר העברנו את ה-codebase בשבילך, השלב הראשון יהיה יצירת קונטיינר Docker של שירות ההזמנות שלנו באמצעות Google Cloud Build.
בדרך כלל צריך לנקוט גישה דו-שלבית שכוללת פיתוח קונטיינר Docer ודחיפה שלו למרשם כדי לאחסן את התמונה ש-GKE תשלוף ממנה. אבל נוכל לעשות את החיים קלים יותר – אנחנו יכולים להשתמש ב-Google Cloud Build כדי לפתח את הקונטיינר של Docker ולהעביר את קובץ האימג' ל-Google Cloud Container Registry בפקודה אחת! כך אנחנו יכולים להנפיק פקודה אחת לבניית קובץ האימג' שלנו ולהעברה שלו למרשם הקונטיינרים. כאן אפשר לראות את התהליך הידני של יצירת קובץ Docker ודחיפה שלו.
מערכת Google Cloud Build תדחס את הקבצים מהספרייה ותעביר אותם לקטגוריה של Google Cloud Storage. לאחר מכן, תהליך ה-build תיקח את כל הקבצים מהקטגוריה וישתמש בקובץ ה-Docker כדי להריץ את תהליך ה-build של Docker. מכיוון שציינו את הדגל --tag עם המארח כ-gcr.io עבור תמונת ה-Docker, תמונת ה-Docker שתתקבל תועבר ל-Google Cloud Container Registry.
כדי לפתח את הקונטיינר ב-Docker מריצים את הפקודות הבאות ודוחפים אותו ל-Google Container Registry:
cd ~/monolith-to-microservices/microservices/src/orders
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0 .
התהליך הזה יימשך כמה דקות אבל בסיום, הפלט יופיע בטרמינל באופן הבא:
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ID CREATE_TIME DURATION SOURCE IMAGES STATUS 1ae295d9-63cb-482c-959b-bc52e9644d53 2019-08-29T01:56:35+00:00 33S gs://<PROJECT_ID>_cloudbuild/source/1567043793.94-abfd382011724422bf49af1558b894aa.tgz gcr.io/<PROJECT_ID>/orders:1.0.0 SUCCESS
כדי לראות את היסטוריית ה-build או לצפות בתהליך בזמן אמת, אפשר להיכנס למסוף Google Cloud. לוחצים על לחצן התפריט בפינה הימנית העליונה וגוללים למטה אל 'כלים' ← Cloud Build ולוחצים על History (היסטוריה). כאן אפשר לראות רשימה של כל גרסאות ה-build הקודמות שלכם. אתם אמורים לראות רק גרסת build אחת שיצרתם.
כשלוחצים על מזהה ה-build, אפשר לראות את כל הפרטים של ה-build, כולל פלט היומן.
בדף הפרטים של ה-build אפשר לראות את קובץ האימג' בקונטיינר שנוצר בלחיצה על שם התמונה בקטע של פרטי ה-build.
פריסת קונטיינרים ב-GKE
עכשיו, אחרי שיצרנו את האתר שלנו בקונטיינרים והעברנו את הקונטיינר ל-Google Container Registry, זה הזמן לפרוס אותו ב-Kubernetes!
מערכת Kubernetes מייצגת אפליקציות בתור Pods, שהן יחידות שמייצגות קונטיינר (או קבוצה של קונטיינרים בצימוד הדוק). Pod הוא היחידה הקטנה ביותר ב-Kubernetes שאפשר לפרוס. במדריך הזה, כל Pod מכיל רק את קונטיינר המיקרו-שירותים (microservices).
כדי לפרוס אפליקציות ולנהל אותן באשכול GKE, צריך לתקשר עם מערכת ניהול אשכולות Kubernetes. כדי לעשות את זה בדרך כלל משתמשים בכלי שורת הפקודה kubectl מתוך Cloud Shell.
תחילה ניצור משאב Deployment. הפריסה מנהלת עותקים מרובים של האפליקציה, שנקראים רפליקות, ומתזמנת אותם כך שיפעלו בצמתים הנפרדים באשכול. במקרה הזה, הפריסה תריץ רק Pod אחד של האפליקציה. פריסות מבטיחות זאת על ידי יצירת ReplicaSet. ה-ReplicaSet היא האחראית לוודא שמספר הרפליקות שצוין פועל תמיד.
הפקודה kubectl create deployment שבהמשך גורמת ל-Kubernetes ליצור פריסה בשם orders באשכול עם רפליקה 1.
מריצים את הפקודה הבאה כדי לפרוס את האפליקציה:
kubectl create deployment orders --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/orders:1.0.0
אימות הפריסה
כדי לוודא שהפריסה נוצרה בהצלחה, מריצים את הפקודה הבאה. יכול להיות שיחלפו מספר דקות עד שסטטוס ה-Pod יופעל:
kubectl get all
פלט:
NAME READY STATUS RESTARTS AGE pod/monolith-779c8d95f5-dxnzl 1/1 Running 0 15h pod/orders-5bc6969d76-kdxkk 1/1 Running 0 21s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 19d service/monolith LoadBalancer 10.39.241.130 34.74.209.57 80:30412/TCP 15h NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/monolith 1/1 1 1 15h deployment.apps/orders 1/1 1 1 21s NAME DESIRED CURRENT READY AGE replicaset.apps/monolith-779c8d95f5 1 1 1 15h replicaset.apps/orders-5bc6969d76 1 1 1 21s
הפלט הזה מראה לנו כמה דברים. אנחנו יכולים לראות את הפריסה הנוכחית, את ה-ReplicaSet שלנו עם מספר ה-pod הרצוי (1) ואת ה-Pod שרץ. נראה שהכול נוצר בהצלחה!
חשיפת קונטיינר GKE
פרסנו את האפליקציה שלנו ב-GKE, אבל אין לנו דרך לגשת אליה מחוץ לאשכול. כברירת מחדל, הקונטיינרים שאתם מריצים ב-GKE אינם נגישים מהאינטרנט, כי לא משויכים להם כתובות IP חיצוניות. עליכם לחשוף את האפליקציה באופן מפורש לתנועה מהאינטרנט דרך משאב שירות. שירות מספק תמיכה ברשתות וב-IP לקבוצות ה-Pod של האפליקציה. מערכת GKE יוצרת כתובת IP חיצונית ומאזן עומסים ( בכפוף לחיוב) לאפליקציה.
כשפרסנו את שירות ההזמנות שלנו, חשפנו אותו ביציאה 8081 באופן פנימי באמצעות פריסה של Kubernetes. כדי לחשוף את השירות הזה לגורם חיצוני, צריך ליצור שירות Kubernetes מסוג Load Balancer, שינתב תעבורת נתונים ביציאה 80 באופן חיצוני ליציאה הפנימית 8081 של שירות ההזמנות. מריצים את הפקודה הבאה כדי לחשוף את האתר לאינטרנט:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
גישה לשירות
מערכת GKE מקצה את כתובת ה-IP החיצונית למשאב השירות ולא לפריסה. כדי לברר מהי כתובת ה-IP החיצונית ש-GKE הקצה לאפליקציה שלכם, אפשר לבדוק את השירות באמצעות הפקודה kubectl get service:
kubectl get service orders
פלט:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE orders 10.3.251.122 203.0.113.0 80:30877/TCP 3d
אחרי שקובעים את כתובת ה-IP החיצונית של האפליקציה, מעתיקים אותה. כדאי לשמור אותו לשלב הבא כשנחליף את המונולית שלנו לשירות ההזמנות החדש!
הגדרה מחדש של מונולית
מכיוון שהסרנו את שירות ההזמנות מהמונולית, ניאלץ לשנות את המונולית כך שיפנה למיקרו-שירות החיצוני החדש של Orders.
כשמפרקים מונולית, אנחנו מסירים קטעי קוד מבסיס קוד יחיד למספר רב של מונולית ופורסים אותם בנפרד. המיקרו-שירות (microservice) פועל בשרת אחר, ולכן כבר אי אפשר להפנות לכתובות ה-URL של השירותים שלנו כנתיבים מוחלטים, לכן אנחנו צריכים נתיב לכתובת השרת החדשה של המיקרו-שירות (microservice) של ההזמנות. הערה: יש צורך בזמן השבתה של השירות המונולית כדי לעדכן את כתובת ה-URL של כל שירות שלא היה פעיל. חשוב להביא זאת בחשבון כשמתכננים להעביר את המיקרו-שירותים (microservices) והמונולית לסביבת הייצור במהלך תהליך ההעברה של מיקרו-שירותים (microservices).
אנחנו צריכים לעדכן את קובץ התצורה במונולית שלנו כך שיפנה לכתובת ה-IP החדשה של מיקרו-שירותים (microservices) של Orders. אפשר להשתמש בעורך הננו כדי להחליף את כתובת ה-URL המקומית בכתובת ה-IP של מיקרו-שירות (microservice) החדש של Orders. מריצים את הפקודה הבאה כדי לערוך את
cd ~/monolith-to-microservices/react-app nano .env.monolith
כשהעורך נפתח, הקובץ אמור להיראות כך:
REACT_APP_ORDERS_URL=/service/orders REACT_APP_PRODUCTS_URL=/service/products
מחליפים את REACT_APP_ORDERS_URL בפורמט החדש בזמן ההחלפה בכתובת ה-IP של המיקרו-שירות (microservice) של ההזמנות, כדי שהכתובות יהיו תואמות לנתונים הבאים:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
כדי לשמור את הקובץ בעורך הננו, מקישים על CTRL+O, על ENTER ואז על CTRL+X.
כדי לבדוק את המיקרו-שירות (microservice) החדש, אפשר לעבור לכתובת ה-URL שהגדרת עכשיו בקובץ הזה. דף האינטרנט אמור להחזיר תגובת JSON מהמיקרו-שירות של ההזמנות.
בשלב הבא נצטרך לבנות מחדש את הקצה הקדמי המונולית שלנו ולחזור על תהליך ה-build כדי לפתח את הקונטיינר למונולית ולפרוס אותו מחדש באשכול GKE. מריצים את הפקודות הבאות כדי להשלים את השלבים:
בנייה מחדש של קובצי התצורה של Monolith
npm run build:monolith
יצירת קונטיינר Docker באמצעות Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0 .
פריסת קונטיינרים ב-GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:2.0.0
תוכל לוודא שהאפליקציה שלך מגיעה עכשיו למיקרו-שירות (microservice) החדש של Orders על ידי מעבר לאפליקציה המונולית בדפדפן וניווט לדף Orders. כל מזהי ההזמנות צריכים להסתיים בסיומת -MICROSERVICE, כפי שמוצג בהמשך:
7. העברת מוצרים למיקרו-שירות (microservice)
יצירת מיקרו-שירות (microservice) למוצרים חדשים
אנחנו יכולים להמשיך להשיק את השירותים שלנו על ידי העברת השירות 'מוצרים' הבא. נבצע את אותו תהליך כמו בשלב הקודם. מריצים את הפקודות הבאות כדי לפתח קונטיינר ב-Docker, לפרוס את הקונטיינר ולחשוף אותו אליו דרך שירות Kubernetes.
יצירת קונטיינר Docker באמצעות Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/products
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0 .
פריסת קונטיינרים ב-GKE
kubectl create deployment products --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/products:1.0.0
חשיפת קונטיינר GKE
kubectl expose deployment products --type=LoadBalancer --port 80 --target-port 8082
מוצאים את כתובת ה-IP הציבורית של שירותי המוצרים שלנו באותו אופן שבו עשינו את שירות ההזמנות שלנו באמצעות הפקודה הבאה:
kubectl get service products
פלט:
NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE products 10.3.251.122 203.0.113.0 80:30877/TCP 3d
שומרים את כתובת ה-IP לשלב הבא כשנגדיר מחדש את המונולית שלנו כך שיצביע אל מיקרו-שירות (microservice) החדש של 'מוצרים'.
הגדרה מחדש של מונולית
משתמשים בעורך הננו כדי להחליף את כתובת ה-URL המקומית בכתובת ה-IP של המיקרו-שירותים (microservices) החדשים שלנו למוצרים:
cd ~/monolith-to-microservices/react-app nano .env.monolith
כשהעורך נפתח, הקובץ אמור להיראות כך:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
מחליפים את REACT_APP_PRODUCTS_URL בפורמט החדש בזמן ההחלפה בכתובת ה-IP של מיקרו-שירות (microservice) של המוצר, כדי שהכתובת תהיה תואמת לנתונים הבאים:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=http://<PRODUCTS_IP_ADDRESS>/api/products
כדי לשמור את הקובץ בעורך הננו, מקישים על CTRL+O, על ENTER ואז על CTRL+X.
כדי לבדוק את המיקרו-שירות (microservice) החדש, אפשר לעבור לכתובת ה-URL שהגדרת עכשיו בקובץ הזה. דף האינטרנט אמור להחזיר תגובת JSON מהמיקרו-שירות של המוצרים שלנו.
בשלב הבא נצטרך לבנות מחדש את הקצה הקדמי המונולית שלנו ולחזור על תהליך ה-build כדי לפתח את הקונטיינר למונולית ולפרוס אותו מחדש באשכול GKE. מריצים את הפקודות הבאות כדי להשלים את השלבים:
בנייה מחדש של קובצי התצורה של Monolith
npm run build:monolith
יצירת קונטיינר Docker באמצעות Google Cloud Build
cd ~/monolith-to-microservices/monolith
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0 .
פריסת קונטיינרים ב-GKE
kubectl set image deployment/monolith monolith=gcr.io/${GOOGLE_CLOUD_PROJECT}/monolith:3.0.0
כדי לוודא שהאפליקציה שלך מגיעה עכשיו למיקרו-שירות (microservice) החדש 'מוצרים', צריך לעבור לאפליקציית המונולית בדפדפן ולעבור לדף 'מוצרים'. כל שמות המוצרים צריכים להיות בקידומת MS- , כפי שמוצג בהמשך:
8. העברת Frontend ל-Microservice
השלב האחרון בתהליך ההעברה הוא העברת הקוד של הקצה הקדמי למיקרו-שירות (microservice) וכיבוי המונולית! אחרי שהשלב הזה יושלם, נעביר בהצלחה את המונולית שלנו לארכיטקטורת מיקרו-שירותים (microservices).
יצירת מיקרו-שירות (microservice) של Frontend חדש
נבצע את אותו תהליך כמו בשני השלבים האחרונים כדי ליצור מיקרו-שירות (microservice) בממשק קצה חדש.
בעבר כשבנינו מחדש את המונולית, עדכנו את ההגדרה כך שהיא תכוון למונולית שלנו, אבל עכשיו אנחנו צריכים להשתמש באותה הגדרה במיקרו-שירות של הקצה הקדמי. מריצים את הפקודות הבאות כדי להעתיק את קובצי התצורה של כתובות ה-URL של המיקרו-שירותים ל-codebase של מיקרו-שירות (microservice) של Frontend:
cd ~/monolith-to-microservices/react-app cp .env.monolith .env npm run build
לאחר השלמתו, נבצע את אותו תהליך כמו השלבים הקודמים. מריצים את הפקודות הבאות כדי לפתח קונטיינר ב-Docker, לפרוס את הקונטיינר ולחשוף אותו אליו דרך שירות Kubernetes.
יצירת קונטיינר Docker באמצעות Google Cloud Build
cd ~/monolith-to-microservices/microservices/src/frontend
gcloud builds submit --tag gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0 .
פריסת קונטיינרים ב-GKE
kubectl create deployment frontend --image=gcr.io/${GOOGLE_CLOUD_PROJECT}/frontend:1.0.0
חשיפת קונטיינר GKE
kubectl expose deployment frontend --type=LoadBalancer --port 80 --target-port 8080
מחיקת המונולית
עכשיו, כשכל השירותים שלנו פועלים כמיקרו-שירותים, אנחנו יכולים למחוק את אפליקציית המונולית שלנו. חשוב לשים לב שהעברה בפועל תגרום גם לשינויים ב-DNS וכו', שיגרמו לשמות הדומיינים הקיימים שלנו להפנות למיקרו-שירותים (microservices) החדשים של הקצה הקדמי של האפליקציה שלנו. מריצים את הפקודות הבאות כדי למחוק את המונולית שלנו:
kubectl delete deployment monolith kubectl delete service monolith
בודקים את העבודה
כדי לוודא שהכול פועל, כתובת ה-IP הישנה משירות המונולית לא אמורה לפעול, וכתובת ה-IP החדשה משירות הקצה הקדמי אמורה לארח את האפליקציה החדשה. כדי לראות רשימה של כל השירותים וכתובות ה-IP, משתמשים בפקודה הבאה:
kubectl get services
הפלט שלכם אמור להיראות כך:
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE frontend LoadBalancer 10.39.246.135 35.227.21.154 80:32663/TCP 12m kubernetes ClusterIP 10.39.240.1 <none> 443/TCP 18d orders LoadBalancer 10.39.243.42 35.243.173.255 80:32714/TCP 31m products LoadBalancer 10.39.250.16 35.243.180.23 80:32335/TCP 21m
אחרי שקובעים את כתובת ה-IP החיצונית עבור מיקרו-שירות של Frontend, מעתיקים את כתובת ה-IP. מפנים את הדפדפן לכתובת ה-URL הזו (למשל http://203.0.113.0) כדי לבדוק אם יש גישה לקצה הקדמי. האתר שלכם צריך להיות זהה לזה שהיה לפני שפוצלנו את המונולית למיקרו-שירותים!
9. הסרת המשאבים
ברגע שתהיו מוכנים, הדרך הקלה ביותר לנקות את כל הפעילויות שבוצעו היא למחוק את הפרויקט. מחיקת הפרויקט תמחק את כל המשאבים שנוצרו ב-Codelab הזה כדי להבטיח שלא יתבצעו חיובים חוזרים בלתי צפויים. מבצעים את הפעולות הבאות ב-Cloud Shell, כאשר PROJECT_ID הוא מזהה הפרויקט המלא ולא רק שם הפרויקט.
gcloud projects delete [PROJECT_ID]
כדי לאשר את המחיקה, מזינים 'Y'. כשמוצגת הנחיה לעשות זאת.
10. מעולה!
פירטתם את האפליקציה המונוליתית שלכם למיקרו-שירותים (microservices) ופרסתם אותם ב-Google Kubernetes Engine!
השלבים הבאים
כדי לקבל מידע נוסף על Kubernetes, מומלץ לעיין ב-Codelabs הבאים:
- פריסה, התאמה לעומס ועדכון של האתר ב-Google Kubernetes Engine
- יצירת בוט Slack Bot באמצעות Node.js ב-Kubernetes
- פיתוח רציף (continuous delivery) ל-Kubernetes באמצעות Spinnaker
- פריסת אפליקציית Java ב-Kubernetes ב-Google Kubernetes Engine
משאבים נוספים
- Docker – https://docs.docker.com/
- Kubernetes – https://kubernetes.io/docs/home/
- Google Kubernetes Engine (GKE) – https://cloud.google.com/kubernetes-engine/docs/
- Google Cloud Build – https://cloud.google.com/cloud-build/docs/
- Container Registry – https://cloud.google.com/container-registry/docs/
- העברת מונוליתים למיקרו-שירותים – https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke