פרסום אפליקציה פנימית
במעבדה זו ניתן לרכוש את הידע ולהתאמן בנושאים הבאים:
1. עבודה עם Kubernetes בכלל ו-GKE בפרט.
2. Cloud Run.
3. Private Service Connect.
4. GCP Load Balancer.
5. Apigee.
הקדמה:
אחרי שלמדנו להציב אפליקציה בסביבות שונות, נראה איך אנחנו מפרסמים אותה החוצה בצורות שאינן ישירות. בהמשך נשתמש בידע הזה כדי להשתמש במפרקים ובמקטעים בשרשרת הפרסום, כדי להציב הגנות.
בתור התחלה נעמיק מעט את הידע בפניה לשירות Kubernetes ובהגדרות שלו, ואז ניגע על קצה המזלג בעולם של Apigee.
חיבור פנימי לשירות ב-GKE:
במעבדה הקודמת פרשנו את המשחק על אשכול Kubernetes ב-GKE, ומיד חשפנו את השירות לעולם עם כתובת חיצונית. במקרים דומים מציבים על האשכול אפליקציות, API, FrontEnd של אתרי אינטרנט דינאמיים ועוד. במצב כזה נרצה להגן על השירות ככל האפשר מפני מתקפות. לכן לא נחשוף את השירות ישירות לרשת האינטרנט, אלא נעמיד אותו מאחורי מסננים ושירותי אבטחה שיודעים לזהות מתקפות ולסנן תעבורה, ולאחר מכן מעבירים פניות נקיות לשירות.
כאשר רוצים לקבל גישה למשהו שרץ באשכול, יוצרים מה שנקרא Service. זה סוג של Load Balancer פנימי של אשכול Kubernetes. הוא לוקח כתובת בטווח שהגדרנו עבור Services, וממנה מחלק את התעבורה ל-Pods השונים שקיימים בהפצה.
כאשר הקמנו את השירות במעבדה הקודמת, הגדרנו את ה-Service לפי Type Load Balancer. הסוג הזה משתמש ברכיב הבסיסי של Service, ויוצר על גביו Load Balancer שמעביר אליו את הפניות. כברירת מחדל, זה יהיה External Load Balancer. אם נגדיר את ה-Service בתור Type Cluster IP, הוא יקבל כתובת פנימית בלבד מהטווח של Services.
קודם נגדיר Service חדש בתור Cluster IP.
כמו רוב הדברים ב-Kubernetes, נגדיר אותו באמצעות קובץ YAML.
עריכת YAML:
נפתח Notpad++ או עורך קוד כלשהו ונכניס בתוכו את התוכן הבא:
apiVersion: v1
kind: Service
metadata:
name: breakbricks-clusterip
namespace: breakbricks
spec:
selector:
app: breakbricks
type: ClusterIP
ports:
- protocol: TCP
port: 80
הסבר:
נתעכב קצת על הסעיפים, כדי שנבין את המבנה של YAML שמגדיר משהו ב-Kubernetes:
· תמיד יהיה apiVersion. בדרך כלל זה יהיה v1. כדי לשנות צריך תכונה ספציפית שמחפשים בגרסה אחרת.
· Kind – קובע לאיזה סוג של פריט לשייך את ההגדרות. כאן זה Service, במקום אחר זה יהיה Deployment, ReplicaSet, ServiceAccount או NameSpace. ויש עוד הרבה.
· Metadata – חובה. תמיד מכיל את השם ואת המרחב שבו יושב הפריט. לפעמים גם תוויות שנקראות annotations. אלה מכילות שיוכים לקטגוריות. נגיע לזה בהמשך.
· Spec – אזור שמכיל את פריטי ההגדרות עצמן.
הצבה:
אז יש לנו פורמט YAML של Service שאמור להתאים ל-Deployment שפרשנו באשכול, והגדרנו אותו מסוג ClusterIP. עכשיו כדי להחיל את ההגדרות האלה נתחבר באמצעות SSH לשרת kube-managment שהוקם במעבדה הקודמת, ושם נכניס את הפקודה:
nano clusterip.yaml
להדביק שם את התוכן, לשמור ולצאת. ואז להזין את הפקודה הבאה:
kubectl apply -f clusterip.yaml
ועכשיו לראות מה יצא לנו:
kubectl get services -n beakbricks
נקבל משהו שנראה ככה:
– Cluster IP, כשמו כן הוא. זו כתובת פנימית בתוך ה-Cluster, ונסיונות לגשת לכתובת משרת kube-management או כל שרת אחר, לא יזכו למענה. כל זה מכיוון שאין שום ניתוב או שיוך ב-VPC לכיוון הכתובת הזו, והיא איננה מוחצנת או מפורסמת על ידי ה-Cluster לרשת שהוא יושב בה. זו כתובת פנימית בלבד שנועדה לתת לשירותים לדבר ביניהם בתוך האשכול.
– כאשר מגדירים Internal Endpoint עבור האשכול (הגדרות אבטחה, עבור Control Plane), אותה כתובת מהווה שירות מסוג ClustarIP. כתובת זו בלבד תהיה נגישה ל-VPC שבו הוצב האשכול. נגישות זו מתאפשרת מכיוון ש-GCP יוצר Peering בין הרשת הפנימית שבה יושב ה-Control Plane, ל-VPC שבו יושבות המכונות של האשכול. ה-peering מאפשר תקשורת ומגדיר ניתוב בין הרשתות.
LoadBalancer:
בזמן שנוצרה ההפצה, בחרנו לחשוף את האפליקציה באמצעות שירות מסוג LoadBalancer. אבל הוא יצר לנו כתובת IP חיצונית. מה שקורה מאחורי הקלעים זה שנוצר שירות באשכול, ומחוץ לאשכול נוצר LB עם כתובת חיצונית, שמפנה ישירות לכל מכונה באשכול.
אם נרצה ליצור LoadBalancer בעל גישה פנימית בלבד, זה יעבוד בצורה מעט שונה, ויש לנו שתי דרכים לעשות את זה.
Default:
ניצור YAML Manifest עבור השירות בפורמט הבא:
apiVersion: v1
kind: Service
metadata:
name: internal
namespace: breakbricks
annotations:
networking.gke.io/load-balancer-type: "Internal"
spec:
selector:
app: breakbricks
type: LoadBalancer
ports:
- protocol: TCP
port: 80
ניתן לראות שהפעם תחת type שינינו את הסוג, ויש גם annotation שאומר לו שזה פנימי בלבד.
בתצורה זו יווצר LB שמעביר את הפניות ל-Instance Group בכל zone שבו יושבות המכונות של האשכול.
נשתמש בפקודה הבאה:
nano internal
שם נדביק את התוכן של ה-YAML. נשמור וצא.
אז נזין את הפקודה הבאה:
kubectl apply -f internal
ומיד נוצר השירות.
אם נזין פקודה להציג את רשימת השירותים, או אפילו לתת את הפרטים של אותו שירות ספציפי, נראה שהכתובת החיצונית שלו בהמתנה. אבל תוך כמה דקות הוא יסיים ליצור את ה-LB וגם שם תהיה כתובת. אבל כתובת פנימית באותו subnet שבו יושבות המכונות באשכול, וכן kube-managment.
נוכל לוודא זמינות של האפליקציה באמצעות telnet לאותה הכתובת בפורט 80. מי שממש רוצה לוודא עד הסוף, יכול להקים באותה הרשת מכונת ubuntu desktop כפי שהוסבר במעבדה הרביעית. מתוך אותה מכונה לגלוש בדפדפן לכתובת הזו ולוודא שהאפליקציה נטענת.
GKE subsetting:
Kubernetes Engine >> Clusters >> app >> DETAILS >> Networking >> Subsetting for L4 Internal Load Balancers.
הולכים להגדרות האשכול בלשונית DETAILS, יורדים לקטגוריה של רשתות ושם מאפשרים את ההגדרה הנ"ל.
עכשיו ניצור שירות נוסף עם YAML דומה, רק שניתן לו את השם sub:
apiVersion: v1
kind: Service
metadata:
name: sub
namespace: breakbricks
annotations:
networking.gke.io/load-balancer-type: "Internal"
spec:
selector:
app: breakbricks
type: LoadBalancer
ports:
- protocol: TCP
port: 80
ואז נכניס לקובץ, נפעיל באמצעות apply וכו'. אחרי כמה דקות נראה שנוצר LB חדש, הפעם הוא מפנה לאפליקציה דרך Network Endpoint Group.
Ingress:
Ingress מהווה מערך מורכב יותר, שמייצר שער והפניה מחוץ לאשכול אל אותו ClusterIP. כאשר ניצור Ingress, יווצר Network Endpoint Group בכל zone. כל אחד כזה מפנה למכונות שנפרשו באותו zone עבור האשכול.
ההבדלים העיקריים בין Ingress ל-LB הם שנים:
1. LB יוצר הפניה ב-Layer 4. כלומר, זה מה שנקרא Network Load Balancer. בעוד ש-Ingress יוצר הפניה ב-Layer 7. מה שנקרא Application Load Ballancer.
2. LB מפנה לכתובות IP של אפליקציית היעד, בעוד ש-Ingress מפנה ל-Service כיעד. אותו Service יכול להיות גם ClusterIP.
ההבדל הראשון מוביל לשני ונובע מתכליתו של השני – Ingress נועד להיות שער עיקרי עבור אפליקציה שלמה שמורכבת מכמה שירותים. היות והוא Application Load Balancer הוא יכול להפנות בקשות לכל שירות בהתאם לחוקים שעובדים רק ב-Layer 7, כמו הפניה לשירות על בסיס path, header וכו'.
Application Load Balancer עובד כמובן בשיטה מעט שונה מ-Network Load Balancer. כדי ליצור אחד כזה צריך להוסיף לאותו VPC טווח כתובות עבור פרוקסי.
יצירת Proxy Subnet:
1. פותחים את התפריט הראשי.
2. VPC network > VPC networks >> app.
3. אחרי שנכנסנו להגדרות של ה-VPC app, נעבור ללשונית של SUBNETS.
4. ללחוץ על ADD SUBNET.
5. לתת את השם app-proxy, לבחור Region me-west1, לסמן Regional Managed Proxy, ואז למטה לתת את הטווח – 10.0.3.0/24.
6. ללחוץ ADD.
ניצור YAML Manifest:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ing
namespace: breakbricks
annotations:
kubernetes.io/ingress.class: "gce-internal"
spec:
defaultBackend:
service:
name: breakbricks-clusterip
port:
number: 80
יש לשים לב שהפעם השתנה הסעיף apiVersion, ובסעיף של annotation אנחנו מקפידים על הערך שיצור כתובת פנימית.
ניתן גם לשים לב שבמחלקה של spec ישנה הפניה אופיינית ל-Application Load Balancer, שמגדירה יעד ברירת מחדל. והיעד במקרה של Ingress הוא Service. במקרה שלנו, אנחנו מפנים לאותו אחד מסוג ClusterIP שיצרנו קודם.
ניתוב לפי שירות:
כמובן, נוכל להוסיף חוקים לפיהם אותו Application Load Balancer ינתב את הפניות. זה יכול להראות ככה:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: ingress
namespace: breakbricks
annotations:
kubernetes.io/ingress.class: "gce-internal"
spec:
defaultBackend:
service:
name: breakbricks-clusterip
port:
number: 80
rules:
- host: app.example.com
http:
paths:
- path: /index.html
pathType: ImplementationSpecific
backend:
service:
name: internal
port:
number: 80
- path: /differentgame/
pathType: Prefix
backend:
service:
name: internal
port:
number: 80
כפי שניתן לראות, פה נוספה על ברירת המחדל גם תת-מחלקה של חוקי ניתוב. החוקים כולם מתייחסים למקרה שבו הפניה מכילה Hostname ספציפי, ושתי אפשרויות ל-path. אפשר ליצור עוד חוקים עבור Hostname אחר ולהוסיף ל-YAML. ויש גם pathType של Exact שזה אומר שהתנאי יחול רק אם כל ה-Path שעבר בפניה, תואם למה שהוגדר בחוק.
אם נכניס את התוכן הזה לקובץ בשם ing ואז נזין את הפקודה:
Kubectl apply -f ing
אותו Ingress יווצר מיידית, אם כי יקח לו כמה דקות ליצור את כל ההפניות ולקבל כתובת IP.
פרסום פנימי של Cloud Run:
במעבדה הקודמת פרסמנו שירות מתוך GKE ישירות החוצה. כעת למדנו לפרסם אותו בצורה פנימית. כך נלמד כעת לבצע פרסום של שירות מתוך Cloud Run בצורה פנימית.
ההבדל בין Cloud Run ו-GKE הוא ש-GKE אינו לגמרי Serverless. וודאי בתצורה בה עבדנו, אנחנו רואים ברשת שלנו את המכונות שבהן פועל האשכול ואנחנו מנהלים את הרשת שלו בסביבה שלנו. לעומת זאת Cloud Run הוא שירות ענן מלא. אנחנו לא מתקשרים איתו באמצעות כתובת IP ספציפית או טווח שקיים ברשת שלנו, אלא באמצעות API של גוגל לניהול, וצריכת השירות מתבצעת דרך URL שמפנה לרשת הכללית של גוגל. לא משהו שאנחנו שולטים בו.
ועדיין נרצה פעמים רבות להציב שירות פנימי באמצעות Cloud Run. אולי אפילו נרצה להציב אותו בפנים ולפרסם אותו בצורה מבוקרת דרך אמצעים שאנחנו מנהלים. אבל זה לשלב מאוחר יותר.
כעת ניקח את השירות שפרסמנו קודם ונעדכן אותו לתצורה פנימית. מי שמחק אותו, יבנה אותו מחדש עם ההגדרות לפרסום פנימי.
עריכת שירות קיים:
1. ללכת ל-Cloud Run, לעבור ללשונית של Services ולהכנס לשירות של breakbricks.
2. למעלה משמאל נראה את שם השירות. אם הכל תקין, לידו תהיה תגית ירוקה עם V. ליד יש את המיקום וקישור לשירות. מתחת יש לשוניות, נעבור ללשונית NETWORKING.
3. בריבוע של Ingress Control נסמן Internal. מי שמקים את השירות מחדש, מקים כמו בהוראות מהמעבדה השישית, רק שבסעיף של Ingress Control מסמן Internal.
4. כעת תעלה תיבת סימון שניתן לאפשר בה תעבורה מ-External Load Balancer. לא נסמן.
5. ללחוץ SAVE.
– הריבוע של VPC מתייחס לתנועה שיוצאת מתוך Cloud Run לכיוון סביבת רשת פנימית שלנו. ניגע בזה באחת המעבדות הבאות שם נפנה מתוך Cloud Run לכתובת פנימית.
גישה פנימית:
1. בתפריט הראשי של GCP: Network services >> Load balancing.
2. ללחוץ למעלה על CREATE LOAD BALANCER.
3. לבחור בריבוע השמאלי – Application Load Balancer. ללחוץ שם למטה על START CONFIGURATION.
4. בחלק העליון יש לנו בחירה – Internet facing or internal only. לבחור באפשרות התחתונה של Only between my VMs or serverless services.
5. בחלק התחתון לבחור את האפשרות התחתונה – Regional internal Application Load Balancer.
6. ללחוץ CONTINUE.
7. כעת נפתח דף ההגדרות הראשי של ה-Load balancer. ניתן לו שם – breackbricks-run.
8. נשים אותו באזור תל אביב וברשת app.
9. בצד ימין יש לנו Backend configuration. ללחוץ שם על התפריט ונלחץ שם על CREATE BACKEND SERVICE.
10. בחלון שיקפוץ מימין, ניתן לו שם – breakbricks-run.
11. Backend type – לבחור Serverless network endpoint group.
12. אז נרד יותר למטה ותחת New backend נלחץ על התפריט ושם נלחץ על CREATE SERVERLESS NETWORK ENDPOINT GROUP.
13. ניתן לו שוב את השם breakbricks-run.
14. למטה יש Select service. שם נבחר בשירות שהקמנו – breakbricks.
15. לוחצים CREATE. לוחצים שוב CREATE. ואז לוחצים OK.
16. בעמודה האמצעית רואים שנשאר להגדיר Frontend configuration. ללחוץ שם ולעבור להגדרות Frontend.
17. את הפרוטוקול אין צורך לשנות. שישאר HTTP.
18. תחת Subnetwork לבחור main.
19. נשאיר את הפורט על 80.
20. תחת IP address לבחור Ephemeral (Custom). זה אומר שהכתובת לא נעולה, ותשאר תפוסה רק כל עוד ההגדרה של ה-Fronend קיימת. ברגע שנמחק את ה-Fronend הזה (שהוא בעצם Forwarding rule), הכתובת תחזור למאגר ונוכל להשתמש בה לכל מכונה או דבר אחר ברשת. ואז בשדה של הכתובת נשים – 10.0.1.150.
21. ללחוץ CREATE.
יקח כמה דקות עד שהכל יעלה, ואז מי שהקים Ubuntu-desktop יוכל לראות שאם הוא גולש לכתובת הזו, הוא מקבל את המשחק שעובד ב-Cloud Run.
Apigee:
Apigee הוא שירות המאפשר ניהול API ופרסום שלהם לעולם בצורה מאובטחת. זה כולל תצורת פרוקסי וכמה רכיבי הגנה שניתן ליישם בדרך.
סביבת Apigee כפי שאנחנו נשתמש בה (מוכר כ-Apigee X) היא שירות מנוהל שרץ על Kubernetes בפרוייקט וברשת המנוהלים לגמרי על ידי GCP. אנחנו מקבלים גישה לתכונות של השירות ולא לתשתית שלו, ועוברים דרכו באמצעות VPC Peering.
הקמת Apigee:
הכנת רשתות:
1. בתפריט הראשי הולכים ל-VPC network ושם נכנסים להגדרות של הרשת app.
2. עוברים ללשונית של VPC NETWORK PEERING.
3. ללחוץ PRIVATE SERVICES ACCESS.
4. שם למטה יש שתי לשוניות. אנחנו על ALLOCATED IP RANGES FOR SERVICES. ללחוץ שם על ALLOCATE IP RANGE.
5. בחלונית שקופצת לתת את השם apigee peering ואת הטווח – 192.168.8.0/21.
6. ללחוץ ALLOCATE.
יצירת סביבת Apigee:
בתפריט הראשי בצד יורדים למטה עד לקטגוריה של INTEGRATION SERVICES ושם לוחצים על Apigee, או שכותבים למעלה בשורת החיפוש.
בדף Welcome to Apigee API management שיפתח, לבדוק את הריבוע השמאלי העליון. אם יש שם קישור לנסות חינם את Apigee לחודשיים, עדיף. כי זה מוצר שעולה מינימום 300 דולר לחודש ויזלול את התקציב שניתן לכם להתנסות איתו. אם לא, ללחוץ על CUSTOMIZE YOUR SETUP
1. בדף שיפתח, תעלה רשימה של API, ונצטרך לאשר להפעיל אותם אם הם עדיין לא מופעלים. ללחוץ ENABLE APIS.
2. כעת נערוך את networking. ללחוץ EDIT.
3. לבחור Authorized network. זו הרשת שתהיה ממנה גישה ל-Apigee באמצעות Peering. לבחור ברשת app.
4. תחת Allocate peering ranges צריך להגדיר טווחים עבור השיתוף בין הרשת שלנו (app) ל-Apigee. לסמן Select one or more existing IP ranges or create a new one, ואז בתפריט נבחר את הטווח apigee-peering שיצרנו קודם.
5. תחת Select runtime IP range לסמן custom ואז נבחר טווחים עבור המערכת. לבחור 10.200.4.0 עבור טווח קידומת 22, וגם 10.100.0.16 עבור טווח קידומת 28. לשים לב לכתובות, הן מסמלות כמה כתובות הרשתות האלה תופסות.
6. ללחוץ ALLOCATE AND CONNECT.
7. ללחוץ NEXT.
8. כעת ב- Configure hosting and encryptionללחוץ על EDIT.
9. ב-Control Plane לבחור Analytics region – me-west1 ואז ללחוץ CONFIRM.
10. ב-Runtime לבחור Runtime hosting region – me-west1, ואז ללחוץ DONE.
11. ללחוץ NEXT.
12. ללחוץ על SUBMIT.
הערות:
– כשצריך להגדיר טווחים של כתובות, אפשר ללחוץ על Automaticaly allocate IP range כי אנחנו בסביבת מעבדה. אבל מי שמקים בסביבה ארגונית ענפה, צריך לשים לב לבחור טווחים שלא יתנגשו בתקשורת עם רשתות אחרות. אם מקימים את Apigee בתצורה מבודדת, אז אין עם זה בעיה והרשתות לא יתנגשו. בהמשך נבין את המשמעות של הבידוד.
– בסביבת מעבדה אין לנו את הבעיה הזו, אבל בסביבה ארגונית יכול להיות שנצטרך להחריג את הפרויקט מכל מיני Organization Policy שיעצרו את התהליך. לדוגמה – כזה שאוכף Peering לרשתות מסוימות, ימנע את התהליך בגלל יצירת Peering לרשת של Apigee שהיא בפרוייקט של גוגל. כזה שאוכף יצירת External Load Balancer יעצור את התהליך, וגם כזה שמגביל יצירת משאבים בפרויקט מסוים – בגלל שה-Control-Plane עצמו יושב באמריקה. לשים לב לפני כדי לא לעצור את התהליך. אחרת יש משאבים שיווצרו והתהליך יתקע אם לא תדעו מה צריך לנקות כדי לאפשר Retry.
היכרות עם רכיבי השירות:
אז מה מכיל המערך שנוצר? כלומר, מה ניתן לראות בסביבה שלנו?
1. LB חיצוני, עם כתובת חיצונית. ניתן למצוא תחת NETWORK SERVICES >> Load balancing.
2. היעד שלו – NEG, ניתן למצוא תחת Compute Engine >> Network endpoint groups.
3. Instance שהוא קופסה שחורה מבחינתנו שכמעט לא ניתן להגדיר בו שום דבר. ניתן למצוא בתפריט של Apigee תחת Instances.
בהמשך ניצור בסביבה שלנו עוד הגדרות שנוכל להשתמש בהן כדי לקשר כמו שצריך את השירותים שלנו עם Apigee.
מי שרוצה מסיבות שונות ליצור Apigee פנימי שאינו זמין מן החוץ, יכול למחוק את אותו External Load Balancer וליצור במקומו Internal Application Load Balancer, שינתב לאותו NEG.
סביבות שונות:
בתפריט של Apigee נגלול למטה עד לקטגוריה של Management ושם נלחץ על Environments.
ניתן לראות שכברירת מחדל הוקמה סביבת בדיקות. נקראת env-test או eval.
– כאשר מציבים Proxy, מציבים אותו תחת סביבה מסוימת.
– אפשר להציב Proxy אחד ביותר מסביבה אחת.
– כל סביבה שנקים עולה כסף בנפרד, עוד לפני שהצבנו בה אפילו הגדרה אחת.
– כל סביבה יכולה להיות חברה בכמה קבוצות של סביבות.
נראה בראש הדף שיש לנו עוד לשונית, עבור קבוצות של סביבות. נעבור לשם.
כרגע ישנה רק קבוצת ברירת המחדל. והיא מכילה את ה-Hostname שנוצר כברית מחדל. בדרך כלל אותו Hostname מהווה את אותה כתובת IP חיצונית שקיבל אותו External LB, בצירוף הסיומת nip.io.
ללחוץ בצד ימין על שלושת הנקודות תחת Action, ואז Edit.
שם תחת Hostnames נגזור את מה שיש ונדביק בצד בפנקס רשימות, אז נציב שם את השם הבא – breakbricks.example
ואז ללחוץ UPDATE.
מה שיקרה עכשיו זה שכל פניה שתגיע ל-Apigee עם Hostname אחר, הוא יתעלם ממנה. נתעכב על זה עוד קצת בהמשך.
פרסום אפליקציה דרך Apigee:
כדי לפרסם אפליקציה דרך Apigee, צריך להגדיר כמה דברים במקומות שונים.
כפי שהוסבר לעיל, Apigee מקים משאבים בפרוייקט של גוגל. כדי לקשר את הפרוקסי בסביבה של Apigee לשירות שלנו, נצטרך איזה שהוא גשר. הגשר יתבצע באמצעות הוספת רגל ונקודת גישה ל-LB שמוביל לשירות. אותה נקודת גישה תווצר כ-NAT Proxy בתוך Subnet קטן שנקים למטרה זו, ואל אותו Subnet תהיה גישה עבור Apigee שלנו.
פרסום שירות:
1. Network services >> Private Service Connect.
2. נראה בראש הדף שיש כמה לשוניות. אנחנו נעבור ל-PUBLISHED SERVICES.
3. ללחוץ PUBLISH SERVICE.
4. כעת נוכל לבחור את סוג ה-LB שאליו נחבר את Apigee. אם נסמן את הראשון, נוכל להשתמש בשירותים שפרסמנו קודם מסוג Load Balancer. אם נסמן את השלישי, נוכל להשתמש במה שנוצר כשהגדרנו Ingress. בסביבת המעבדה לא יהיה לנו שום דבר זמין באפשרות האמצעית. נשאיר מסומנת את האפשרות הראשונה.
5. כשנלחץ על התפריט שמסומן כ-Internal load balancer, נראה שתי אפשרויות כמעט לא ברורות (צילום למטה). למעשה, אלה השמות שניתנו ל-Load Balancers שיצרנו מתוך Kuectl. כדי לזהות מי זה מה, אפשר ללכת ל-GKE, תחת Workloads להכנס לאפליקציה שלנו, ושם למטה למצוא את ה-Services שפרסמנו ולבדוק בהגדרות של כל אחד מהם מי זה מה. אני אבחר בזה שמפנה ל-internal-sub. אלחץ על השם של השירות שם בתחתית העמוד, ואז יפתח לי הדף של השירות. שם תחת Load Balancer יופיע לי השם שאני צריך לבחור בתפריט.
6. תחת Service name ניתן לו את השם breakbricks.
7. תחת Subnets נצטרך לבחור טווח כתובות שישמש עבור NAT Proxy. נלחץ RESERVE NEW SUBNET.
8. בחלון שיקפוץ ניתן ל-Subnet את השם breakbricks-psc, ואת טווח הכתובות 10.0.250.0/29. לא צריך טווח יותר גדול מזה מכיוון שרק Apigee מתחבר לשם. אז ללחוץ ADD. – מי שמפרסם שירות למטרה אחרת ויש הרבה מקורות שפונים לשירות מכל מיני רשתות ופרוייקטים, יצטרך להקצות טווח יותר גדול.
9. לאחר זמן מה יווצר אותו טווח כתובות, יופיע תחת Subnets ונוכל ללחוץ OK.
10. לוודא שלמטה מסומנת התיבה של Enable connection reconciliation שמאפשרת לנו לבטל חיבורים שאושרו במיידית.
11. ללחוץ ADD SERVICE.
צריכת שירות ב-Apigee:
צריכת שירות ב-Apigee:
כעת נצטרך לחבר את סביבת Apigee לשירות שפרסמנו.
1. בתפריט של Apigee הולכים ל-Endpoint Attachments.
2. לוחצים למעלה על CREATE.
3. בדף שנפתח נותנים את השם – breakbricks.
4. תחת GCP Project ID להזין את שם הפרויקט שבו פורסם השירות.
5. אז נראה תפריט של Service Attachment, שם נוכל לבחור מבין השירותים שפורסמו בפרויקט שכתבנו בסעיף הקודם. במקרה שלנו, צריך לבחור ב-breakbricks.
6. לוחצים NEXT.
7. מסמנים את התיבה של I understand ולוחצים CREATE.
אישור החיבור בין המפרסם והצרכן:
לאחר זמן מה נראה שהחיבור מופיע לנו ברשימה, אבל הוא על מצב Pending. כדי לסיים את התהליך נלך לשירות שפרסמנו קודם תחת Published Services. שם נראה למטה Connected projects ושם החיבור שיצרנו מצד Apigee, במצב Pending.
נוכל לסמן את תיבת הסימון משמאל ויקפצו לנו לחצנים מעל הרשימה,
נוכל ללחוץ על שלושת הנקודות מימין לפריט,
ונוכל להכנס להגדרות של החיבור.
בסופו של דבר, צריך ללחוץ על Accept Project. כרגע אנחנו לא מצפים להרבה חיבורים מאותו פרויקט של Apigee, אז מספר ברירת המחדל שמופיע – 10, זה בסדר.
לאחר זמן קצר החיבור יופיע בתור Accepted בשני הצדדים.
לראות בצד של Apigee שהחיבור קיבל כתובת IP תחת Host. בדרך כלל משהו כמו 7.0.8… לרשום בצד ולשמור את הכתובת, כי זו הכתובת שבה Apigee פונה לאותו שירות שהוצמד לו.
יצירת Proxy:
1. בתפריט של Apigee ללחוץ על API proxies.
2. בראש הדף ללחוץ על CREATE.
3. לתת את השם breakbricks.
4. לוודא שהשדה base path מכיל תוכן כמו השם שבחרנו.
5. תחת target למחוק את מה שיש ולשים את הכתובת – http://game.breakbricks.example
6. ללחוץ NEXT.
7. תחת Deployment environments לבחור בסביבה היחידה שיש לנו – test-env.
8. ללחוץ CREATE.
למעשה, יכולנו לשים כתובת IP תחת הכתובת של יעד החיבור. אבל במקרים רבים נרצה לכוון ליעד שהוא כתובת DNS, בעיקר אם אותו LB שאנחנו מכוונים אליו, מקבל פניות ב-HTTPS ולכן צריך לקבל פניות עם ה-DNS המתאים. לכן נלמד איך לבצע את זה עם DNS.
יצירת DNS Zone פרטי:
בפרויקט שבו יש את Apigee:
1. Network Services >> Cloud DNS.
2. אם נקבל הודעה ש- Data could not be loaded, נלחץ CONTINUE ובדף שיפתח נפעיל את ה-API של Cloud DNS.
3. בדף של Cloud DNS נלחץ למעלה על CREATE ZONE.
4. Zone type – נבחר Private.
5. תחת Zone name נשים את הדומיין שנתנו קודם ליעד של הפרוקסי – breakbricks.example. בגלל שהשם לא יכול להכיל נקודה, נחליף את הנקודה באמצע במקף.
6. תחת DNS name נדביק את אותו הדבר בלי להחליף כלום – breakbricks.example.
7. תחת Networks נצטרך לבחור לאיזה רשתות אותו zone יהיה זמין. נבחר את הרשת שבצמוד אליה הקמנו את Apigee. במקרה שלנו זו תהיה הרשת app.
8. ללחוץ CREATE.
9. בדף של ה-Zone שנפתח, נראה שנוצרו לנו רשימות בסיסיות של NS ו-SOA. מעליהן נלחץ ADD STANDARD.
10. בשדה של DNS name נכתוב game. בצירוף הדומיין שנתנו ל-Zone הזה, זה ירכיב את ה-DNS שנתנו ליעד של הפרוקסי שהקמנו.
11. בשדה של IPv4 Address לשים את הכתובת של אותו Endpoint Attachment שהקמנו קודם ורשמנו בצד – 7.0.8… מה שקיבלנו שם.
DNS Peering:
כעת פניות לכתובת game.breakbricks.example מתוך רשת app מקבלות Resolve של אותה כתובת IP של breakbricks Endpoint Attachment.
אבל Apigee עדיין לא יודע לקבל את אותו Resolve. בשביל זה צריך עוד צעד אחד.
נפתח Cloud Shell ושם נזין את הפקודה הבאה:
gcloud services peered-dns-domains create breakbricks-example –network app –dns-suffix game.breakbricks.example. –project mobile-app-yosi
כעת אותו DNS Zone נותן מענה לא רק לרשת app, אלא לכל הרשתות שיש להן peering איתה. בכללן ובעיקר – הרשת שבה יושבת סביבת Apigee שלנו.
גישה לשירות מהעולם:
במחשב שלנו להכניס רשומה בקובץ הוסט:
34.128.154.189 breakbricks.example
תחת אותה כתובת IP, לשים את הכתובת החיצונית שקיבל אותו External LB של Apigee. ככה שפניות מתוך המחשב הזה ל-breakbricks.example, תגענה ל-Apigee שלנו.
כעת ניתן להזין בדפדפן את הכתובת https://breakbricks.example/breakbricks ונקבל את המשחק שלנו דרך Apigee.
כמובן שנקבל הודעת אזהרה על תעודה. זה בגלל שלא העלינו ל-External LB תעודה מתאימה עבור הדומיין breakbricks.example. כרגע יש שם את תעודת ברירת המחדל שהוא קיבל מגוגל עבור ה-DNS שמכיל את ה-Hostname הראשוני שראינו קודם. בהקמת Apigee בסביבה ארגונית/עסקית, יהיה לנו DNS תקין של הדומיין של הארגון, הפונה לכתובת IP של אותו External IP.
אז נגדיר ב-Environment Group לקבל פניות (רק) תחת אותו שם, ונעלה ל-LB תעודה מתאימה לאותו שם.
הערות:
– אפשר באותה הצורה לפרסם החוצה את השירות של Cloud Run באמצעות פרוקסי שמפנה לכתובת 10.0.1.150, או לכתובת DNS שמפנה לשם. בסביבות ארגוניות ברוב המקרים הפרוקסי לא יפנה לשם ישירות, צריך קודם לפרסם את השירות ב-Private Service Connect ואז כ-Endpoint Attachment. הפרוקסי יפנה ל-Endpoint Attachment. כדאי לתת לו כתובת DNS כפי שתרגלנו קודם.
– פניה לפרוקסי שהעלינו ל-Apigee תכלול כ-Hostname שם שמוגדר ב-Environment Group שבו חברה הסביבה שבה הוצב אותו פרוקסי. לאחר השם מופיע מה שהוגדר בפרוקסי כ- base path. לאחר מכן שמים את הנתיב שבו פונים לאותו קובץ, API, או פונקציה ספציפית באותו API. זה נראה ככה: https://hostname/basepath/target
– אם הצבנו כיעד של הפרוקסי שרת שלם, או path בסיסי שאחריו יש הרבה אפשרויות, נצטרך להמשיך אחרי אותו basepath של הפרוקסי, את כל מה שהיה צריך להמשיך אחרי מה שהוגדר ב-target. לדוגמה, אם יש לנו שירות שניגשים אליו ברשת הפנימית מהכתובת הבאה: https://localserver.local/v1/anothergame/healthcheck ונניח שהגדרנו עבור הפרוקסי בתור target את הכתובת – https://localserver.local/v1 אז הגישה מבחוץ לשירות תצטרך להיות: https://breakbricks.example/breakbricks/anothergame/healthcheck
– כאשר מוגדרים עוד שמות Hostname תחת אותה קבוצה (Environment Group) או בקבוצות אחרות, Apigee יקבל רק את השמות שמוגדרים לו בקבוצות שיש לו.
– לפעמים הסביבה חברה בכמה קבוצות, כאשר לכל קבוצה מוגדר שם שונה. אז אפשר יהיה להגיע ליעד של הפרוקסי עם כל אחד מהשמות שמוגדרים לקבוצות שבהן חברה אותה סביבה.
– אם פרשנו את הפרוקסי בכמה סביבות, תהיה גישה לפרוקסי מכל שם שמקושר לאותן סביבות בהתאם לכלל הקודם.
– לסיכום – Apigee מקבל פניות כ-Application Load Balancer ומנתב את הפניות לסביבות ולפרוקסי השונים בהתאם ל-Hostname וגם בהתאם ל-path.