1. מבוא
למה כדאי להעביר אפליקציה מונוליתית לארכיטקטורה של מיקרו-שירותים? לפירוק אפליקציה למיקרו-שירותים יש את היתרונות הבאים. רובם נובעים מהעובדה שמיקרו-שירותים הם בעלי צימוד חלש.
- אפשר לבדוק ולפרוס את המיקרו-שירותים בנפרד. ככל שיחידת הפריסה קטנה יותר, כך הפריסה קלה יותר.
- אפשר להטמיע אותם בשפות ובמסגרות שונות. לכל מיקרו-שירות, אתם יכולים לבחור את הטכנולוגיה הכי טובה לתרחיש השימוש הספציפי שלו.
- צוותים שונים יכולים לנהל אותם. הגבול בין מיקרו-שירותים מקל על הקצאת צוות למיקרו-שירות אחד או לכמה מיקרו-שירותים.
- מעבר למיקרו-שירותים מאפשר להפחית את התלות בין הצוותים. כל צוות צריך להתייחס רק לממשקי ה-API של המיקרו-שירותים שהוא תלוי בהם. הצוות לא צריך לחשוב על האופן שבו המיקרו-שירותים האלה מיושמים, על מחזורי ההפצה שלהם וכן הלאה.
- קל יותר לתכנן מראש את התרחישים שבהם משהו עלול להשתבש. הגבולות הברורים בין השירותים מאפשרים לקבוע בקלות מה צריך לעשות אם שירות מסוים לא פועל.
אלה כמה מהחסרונות בהשוואה לאפליקציות מונוליטיות:
- אפליקציה שמבוססת על מיקרו-שירותים היא רשת של שירותים שונים, שלעתים קרובות מתקשרים ביניהם בדרכים לא ברורות, ולכן המורכבות הכוללת של המערכת נוטה לגדול.
- בניגוד למבנה הפנימי של מערכת מונוליתית, מיקרו-שירותים מתקשרים דרך רשת. בנסיבות מסוימות, זה יכול להיחשב כבעיה אבטחתית. Istio פותר את הבעיה הזו על ידי הצפנה אוטומטית של התנועה בין המיקרו-שירותים.
- יכול להיות שיהיה קשה להשיג את אותה רמת ביצועים כמו בגישה מונוליטית, בגלל השהיות בין השירותים.
- ההתנהגות של המערכת לא נובעת משירות אחד, אלא משירותים רבים ומהאינטראקציות ביניהם. לכן קשה יותר להבין איך המערכת מתנהגת בסביבת הייצור (היכולת שלה לספק תובנות). Istio הוא פתרון נוסף לבעיה הזו.
בשיעור ה-Lab הזה נריץ מיקרו-שירותים ב-Google Kubernetes Engine (GKE). Kubernetes היא פלטפורמה לניהול, לאירוח, להרחבה ולפריסה של קונטיינרים. קונטיינרים הם דרך ניידת לארוז ולהריץ קוד. הם מתאימים מאוד לתבנית של מיקרו-שירותים, שבה כל מיקרו-שירות יכול לפעול בקונטיינר משלו.
במעבדה הזו נלמד איך לפרוס אפליקציה מונוליתית קיימת באשכול Google Kubernetes Engine, ואז נפרק אותה למיקרו-שירותים.
תרשים הארכיטקטורה של המיקרו-שירותים שלנו
נתחיל בפירוק המונולית לשלושה מיקרו-שירותים, אחד בכל פעם. המיקרו-שירותים כוללים את Orders, Products ו-Frontend. אנחנו יוצרים קובץ אימג' של Docker לכל מיקרו-שירות באמצעות Cloud Build, שאותו אנחנו מפעילים מתוך Cloud Shell. לאחר מכן נבצע פריסה ונחשוף את המיקרו-שירותים שלנו ב-Google Kubernetes Engine (GKE) באמצעות איזון עומסים מסוג שירות Kubernetes. אנחנו נעשה את זה לכל שירות, ובמקביל נבצע רפקטורינג כדי להוציא אותם מהמונוליט שלנו. במהלך התהליך, גם המונוליט וגם המיקרו-שירותים יפעלו עד הסוף, ואז נוכל למחוק את המונוליט.
מה תלמדו
- איך לפרק מונולית למיקרו-שירותים
- איך יוצרים אשכול Google Kubernetes Engine
- איך יוצרים קובץ אימג' של Docker
- איך פורסים קובצי אימג' של Docker ב-Kubernetes
דרישות מוקדמות
- חשבון ב-Google Cloud Platform עם הרשאת אדמין ליצירת פרויקטים, או פרויקט עם התפקיד 'Project Owner'
- הבנה בסיסית של Docker ו-Kubernetes
2. הגדרת הסביבה
הגדרת סביבה בקצב אישי
אם עדיין אין לכם חשבון Google (Gmail או Google Apps), אתם צריכים ליצור חשבון. נכנסים ל-Google Cloud Platform Console ( console.cloud.google.com) ויוצרים פרויקט חדש:
חשוב לזכור את מזהה הפרויקט, שהוא שם ייחודי בכל הפרויקטים ב-Google Cloud (השם שלמעלה כבר תפוס ולא יתאים לכם, מצטערים!). בהמשך ה-codelab הזה נתייחס אליו כאל PROJECT_ID.
לאחר מכן, תצטרכו להפעיל את החיוב ב-Developers Console כדי להשתמש במשאבי Google Cloud ולהפעיל את Container Engine API.
העלות של ה-Codelab הזה לא אמורה להיות גבוהה, אבל היא יכולה להיות גבוהה יותר אם תחליטו להשתמש ביותר משאבים או אם תשאירו אותם פועלים (ראו את הקטע 'ניקוי נתונים' בסוף המסמך הזה). כאן מפורט המחירון של Google Kubernetes Engine.
משתמשים חדשים ב-Google Cloud Platform זכאים לתקופת ניסיון בחינם בשווי 300$.
Google Cloud Shell
אפשר להפעיל את Google Cloud ואת Kubernetes מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.
המכונה הווירטואלית הזו מבוססת על Debian, וטעונים בה כל הכלים הדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות של הרשת. כלומר, כל מה שצריך כדי לבצע את ההדרכה הזו הוא דפדפן (כן, היא פועלת ב-Chromebook).
- כדי להפעיל את Cloud Shell ממסוף Cloud, פשוט לוחצים על הפעלת 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 Console:
ב-Cloud Shell מוגדרים גם כמה משתני סביבה כברירת מחדל, שיכולים להיות שימושיים כשמריצים פקודות בעתיד.
echo $GOOGLE_CLOUD_PROJECT
פלט הפקודה
<PROJECT_ID>
- לבסוף, מגדירים את אזור ברירת המחדל ואת הגדרת הפרויקט.
gcloud config set compute/zone us-central1-f
אפשר לבחור מתוך מגוון אזורים שונים. מידע נוסף זמין במאמר בנושא אזורים ותחומים.
3. שכפול מאגר המקור
אנחנו משתמשים באפליקציה מונוליטית קיימת של אתר מסחר אלקטרוני דמיוני, עם דף פשוט של ברוכים הבאים, דף מוצרים ודף היסטוריית הזמנות. אנחנו רק צריכים לשכפל את המקור ממאגר ה-Git שלנו, כדי שנוכל להתמקד בפירוק שלו למיקרו-שירותים ובפריסה ב-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 שלנו לצורך המעבדה הזו:
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).
אמור להופיע דף הפתיחה של האתר המונוליטי, כמו בתמונה שלמעלה. דף הפתיחה הוא דף סטטי שיוצג על ידי המיקרו-שירות של חזית האתר בהמשך. עכשיו המונוליט שלכם פועל באופן מלא ב-Kubernetes.
6. העברת הזמנות למיקרו-שירות
עכשיו, כשהאתר המונוליתי הקיים שלנו פועל ב-GKE, אנחנו יכולים להתחיל לפצל כל שירות למיקרו-שירות. בדרך כלל, צריך לתכנן אילו שירותים לחלק לחלקים קטנים יותר, בדרך כלל סביב חלקים ספציפיים של האפליקציה, כמו דומיין עסקי. לצורך הדגמה, יצרנו דוגמה פשוטה וחילקנו כל שירות לפי הדומיין העסקי, הזמנות, מוצרים וחלק הקצה. הקוד כבר הועבר, ונתמקד בפיתוח ובפריסה של השירותים ב-Google Kubernetes Engine (GKE).
יצירת מיקרו-שירות חדש של הזמנות
השירות הראשון שנפרט הוא שירות ההזמנות. נשתמש בבסיס הקוד הנפרד שסיפקתם וניצור קונטיינר Docker נפרד לשירות הזה.
יצירת קונטיינר Docker באמצעות Google Cloud Build
מכיוון שכבר העברנו את בסיס הקוד בשבילכם, השלב הראשון יהיה ליצור קונטיינר Docker של שירות ההזמנות באמצעות Google Cloud Build.
בדרך כלל צריך לבצע גישה בשני שלבים שכוללת בניית קונטיינר Docker והעברה שלו למרשם כדי לאחסן את קובץ האימג' שממנו GKE ימשוך את הקובץ. אבל אפשר להקל על החיים, אפשר להשתמש ב-Google Cloud Build כדי ליצור את קונטיינר Docker ולהכניס את האימג' ל-Google Cloud Container Registry באמצעות פקודה אחת! כך אפשר להריץ פקודה אחת כדי ליצור את קובץ האימג' ולהעביר אותו ל-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. לוחצים על לחצן התפריט בפינה הימנית העליונה וגוללים למטה אל Tools (כלים) → Cloud Build (גרסת Cloud Build) ולוחצים על History (היסטוריה). כאן תוכלו לראות רשימה של כל הגרסאות הקודמות שלכם. אמורה להיות רק גרסה אחת שיצרתם עכשיו.
אם לוחצים על מזהה ה-build, אפשר לראות את כל הפרטים של ה-build הזה, כולל פלט היומן.
בדף פרטי הבנייה, אפשר לראות את קובץ האימג' של הקונטיינר שנוצר בלחיצה על שם האימג' בקטע פרטי הבנייה.
פריסת קונטיינר ב-GKE
אחרי שיצרנו קונטיינר לאתר שלנו והעלינו אותו ל-Google Container Registry, הגיע הזמן לפרוס אותו ב-Kubernetes.
ב-Kubernetes, אפליקציות מיוצגות כPods, שהן יחידות שמייצגות קונטיינר (או קבוצה של קונטיינרים עם צימוד הדוק). Pod היא היחידה הקטנה ביותר שניתנת לפריסה ב-Kubernetes. במדריך הזה, כל Pod מכיל רק את קובץ ה-container של המיקרו-שירותים שלכם.
כדי לפרוס אפליקציות באשכול 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 יהיה Running:
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 עם מספר הפודים הרצוי שהוא 1, ואת הפוד שפועל. נראה שהכול נוצר בהצלחה!
חשיפת קונטיינר GKE
פרסנו את האפליקציה שלנו ב-GKE, אבל אין לנו דרך לגשת אליה מחוץ לאשכול. כברירת מחדל, אי אפשר לגשת לאינטרנט מהקונטיינרים שמופעלים ב-GKE, כי אין להם כתובות IP חיצוניות. אתם צריכים לחשוף את האפליקציה שלכם לתנועה מהאינטרנט באופן מפורש באמצעות משאב Service. שירות מספק תמיכה ברשת וב-IP לפודים של האפליקציה. GKE יוצר כתובת IP חיצונית ומאזן עומסים ( בכפוף לחיוב) לאפליקציה.
כשפרסנו את שירות ההזמנות שלנו, חשפנו אותו בפורט 8081 באופן פנימי באמצעות פריסת Kubernetes. כדי לחשוף את השירות הזה באופן חיצוני, צריך ליצור שירות Kubernetes מסוג LoadBalancer כדי לנתב תנועה מיציאה 80 באופן חיצוני ליציאה 8081 באופן פנימי עבור שירות ההזמנות. מריצים את הפקודה הבאה כדי לחשוף את האתר לאינטרנט:
kubectl expose deployment orders --type=LoadBalancer --port 80 --target-port 8081
גישה לשירות
GKE מקצה את כתובת ה-IP החיצונית למשאב Service ולא למשאב Deployment. כדי לגלות את כתובת ה-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 החיצונית של האפליקציה, מעתיקים את כתובת ה-IP. שומרים אותו לשלב הבא, שבו נשנה את המונוליט כך שיצביע על שירות ההזמנות החדש שלנו.
הגדרה מחדש של Monolith
מאחר שהסרנו את שירות ההזמנות מהמונוליט, נצטרך לשנות את המונוליט כך שיצביע על מיקרו-שירות ההזמנות החיצוני החדש.
כשמפרקים מונוליט, אנחנו מסירים קטעי קוד מבסיס קוד יחיד למספר בסיסי קוד ומפרידים את הפריסה שלהם. מכיוון שהמיקרו-שירות פועל בשרת אחר, אנחנו כבר לא יכולים להפנות לכתובות ה-URL של השירות שלנו כנתיבים מוחלטים, אלא אנחנו צריכים להפנות לכתובת השרת החדשה של המיקרו-שירות Order. שימו לב: כדי לעדכן את כתובת ה-URL של כל שירות שהופרד, יהיה צורך בהשבתה זמנית של שירות המונולית. חשוב לקחת את זה בחשבון כשמתכננים להעביר את המיקרו-שירותים והמונוליט לסביבת הייצור במהלך תהליך ההעברה של המיקרו-שירותים.
אנחנו צריכים לעדכן את קובץ ההגדרות במונולית כדי שיצביע על כתובת ה-IP החדשה של המיקרו-שירותים של ההזמנות. משתמשים בעורך nano כדי להחליף את כתובת ה-URL המקומית בכתובת ה-IP של המיקרו-שירות החדש של ההזמנות. מריצים את הפקודה הבאה כדי לערוך את
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 של מיקרו-שירות ההזמנות, כך שהיא תהיה זהה לכתובת שמופיעה למטה:
REACT_APP_ORDERS_URL=http://<ORDERS_IP_ADDRESS>/api/orders REACT_APP_PRODUCTS_URL=/service/products
מקישים על CTRL+O, על ENTER ואז על CTRL+X כדי לשמור את הקובץ בעורך nano.
כדי לבדוק את המיקרו-שירות החדש, עוברים לכתובת ה-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, כמו שמוצג בהמשך:
7. העברת מוצרים למיקרו-שירותים
יצירת מיקרו-שירות חדש של מוצרים
אנחנו יכולים להמשיך לפצל את השירותים שלנו על ידי העברת שירות המוצרים בשלב הבא. נפעל לפי אותו תהליך כמו בשלב הקודם. מריצים את הפקודות הבאות כדי ליצור קונטיינר 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 לשלב הבא, שבו נגדיר מחדש את המונוליט כך שיפנה למיקרו-שירות המוצרים החדש.
הגדרה מחדש של Monolith
משתמשים בעורך nano כדי להחליף את כתובת ה-URL המקומית בכתובת ה-IP של המיקרו-שירותים החדשים של המוצרים:
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 של מיקרו-שירות המוצרים, כך שהיא תתאים לפורמט הבא:
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 כדי לשמור את הקובץ בעורך nano.
כדי לבדוק את המיקרו-שירות החדש, עוברים לכתובת ה-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
כדי לוודא שהאפליקציה שלכם מגיעה עכשיו למיקרו-שירות החדש של מוצרים, עוברים לאפליקציית המונוליט בדפדפן ועוברים לדף המוצרים. לכל שמות המוצרים צריך להוסיף את הקידומת MS-, כמו שמוצג בהמשך:
8. העברת קצה קדמי למיקרו-שירות
השלב האחרון בתהליך ההעברה הוא להעביר את קוד ה-Frontend למיקרו-שירות ולהשבית את המונוליט. אחרי השלמת השלב הזה, נסיים בהצלחה את העברת המונוליט לארכיטקטורת מיקרו-שירותים.
יצירת מיקרו-שירות חדש של קצה קדמי
נפעל לפי אותה פרוצדורה כמו בשני השלבים האחרונים כדי ליצור מיקרו-שירות (microservice) חדש של קצה קדמי.
בעבר, כשבנינו מחדש את המונוליט, עדכנו את ההגדרות כך שיצביעו על המונוליט, אבל עכשיו אנחנו צריכים להשתמש באותן הגדרות עבור המיקרו-שירות של הקצה הקדמי. מריצים את הפקודות הבאות כדי להעתיק את קובצי ההגדרות של כתובות ה-URL של המיקרו-שירותים אל בסיס הקוד של המיקרו-שירות 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 וכו', כדי ששמות הדומיינים הקיימים שלנו יצביעו על המיקרו-שירותים החדשים של קצה קדמי של האפליקציה שלנו. מריצים את הפקודות הבאות כדי למחוק את המונוליט:
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 החיצונית של המיקרו-שירות של הקצה הקדמי, מעתיקים את כתובת ה-IP. כדי לבדוק אם אפשר לגשת לקצה הקדמי של האתר, מצביעים בדפדפן על כתובת ה-URL הזו (למשל http://203.0.113.0). האתר שלכם צריך להיות זהה לאתר שהיה לפני שפירקנו את המונוליט למיקרו-שירותים.
9. הסרת המשאבים
כשהפרויקט מוכן, הדרך הקלה ביותר לנקות את כל הפעילויות שבוצעה היא למחוק אותו. מחיקת הפרויקט תמחק את כל המשאבים שנוצרו במסגרת ה-Codelab הזה, כדי שלא יחולו חיובים חוזרים לא צפויים. מריצים את הפקודה הבאה ב-Cloud Shell, כאשר PROJECT_ID הוא מזהה הפרויקט המלא ולא רק שם הפרויקט.
gcloud projects delete [PROJECT_ID]
כשמוצגת בקשה לאישור המחיקה, מקלידים Y.
10. מעולה!
הצלחתם לפרק את האפליקציה המונוליתית למיקרו-שירותים ולפרוס אותם ב-Google Kubernetes Engine.
השלבים הבאים
כדי לקבל מידע נוסף על Kubernetes, אפשר לעיין ב-codelabs הבאים:
- פריסה, התאמה לעומס ועדכון של האתר באמצעות Google Kubernetes Engine
- פיתוח בוט ל-Slack באמצעות Node.js ב-Kubernetes
- פיתוח רציף (CD) ב-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/
- Google Container Registry – https://cloud.google.com/container-registry/docs/
- העברת אפליקציות מונוליתיות למיקרו-שירותים – https://cloud.google.com/solutions/migrating-a-monolithic-app-to-microservices-gke