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 עם הרשאת אדמין ליצירת פרויקטים, או פרויקט עם התפקיד 'בעלים של הפרויקט'
- הבנה בסיסית של 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 מרחוק מהמחשב הנייד, אבל בסדנת הקוד הזו נשתמש ב-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 המתאימים מופעלים. מריצים את הפקודה הבאה כדי להפעיל את containers api כדי שנוכל להשתמש ב-Google Kubernetes Engine:
gcloud services enable container.googleapis.com
עכשיו אפשר ליצור את האשכול. מריצים את הפקודה הבאה כדי ליצור אשכול GKE בשם fancy-cluster עם 3 צמתים.
gcloud container clusters create fancy-cluster --num-nodes 3
יכול להיות שיחלפו כמה דקות עד שהאשכול ייווצר. אחרי שהפקודה מסתיימת, מריצים את הפקודה הבאה ורואים את שלוש מכונות ה-VM של ה-worker באשכול:
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 יכווץ את הקבצים מהספרייה ויעביר אותם לקטגוריה של Cloud Storage ב-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 ליצור פריסת Deployment בשם 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 ולא לפריסה. כדי לגלות את כתובת ה-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. שומרים אותו לשלב הבא, שבו נשנה את המונוליט כך שיצביע על שירות ההזמנות החדש שלנו.
הגדרה מחדש של מונולית
מאחר שהסרנו את שירות ההזמנות מהמונוליט, נצטרך לשנות את המונוליט כך שיצביע על שירות המיקרו החדש של ההזמנות.
כשמפרקים מונוליט, אנחנו מסירים קטעי קוד מבסיס קוד יחיד למספר בסיסי קוד ומפרידים ביניהם. מכיוון שהמיקרו-שירות פועל בשרת אחר, אנחנו כבר לא יכולים להפנות לכתובות ה-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 לשלב הבא, שבו נגדיר מחדש את המונוליט כך שיצביע על שירות המיקרו החדש של המוצרים.
הגדרה מחדש של מונולית
משתמשים בעורך 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. העברת הקצה הקדמי למיקרו-שירות
השלב האחרון בתהליך ההעברה הוא להעביר את קוד הקצה הקדמי למיקרו-שירות (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
Delete The Monolith
עכשיו, כשכל השירותים שלנו פועלים כמיקרו-שירותים, אפשר למחוק את האפליקציה המונוליתית! הערה: בהעברה בפועל, זה יכלול גם שינויים ב-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 הבאים:
- Deploy, Scale and Update Your Website on Google Kubernetes Engine
- Build a Slack Bot with Node.js on 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