התחברות לשירותים מקומיים בארגון באמצעות Networking היברידי באמצעות Private Service Connect ו-Hybrid NEG עם מאזן עומסים פנימי של HTTP(s)

1. מבוא

Cloud Load Balancing תומך במאזן עומסים של תעבורת נתונים לנקודות קצה (endpoints) שפועלות מחוץ ל-Google Cloud, כמו מרכזי נתונים בארגון ועננים ציבוריים אחרים שאפשר להשתמש בהם בקישוריות היברידית כדי להגיע אליהם.

אסטרטגיה היברידית היא פתרון פרגמטי שיעזור לכם להתאים את האפליקציות שלכם לדרישות השוק המשתנות ולשדרג אותן בהדרגה. יכול להיות שמדובר בפריסה היברידית זמנית שמאפשרת העברה לפתרון מודרני מבוסס-ענן, או ברכיב קבוע בתשתית ה-IT של הארגון.

הגדרת איזון עומסים היברידי מאפשרת גם ליהנות מהיתרונות של יכולות הרשת של Cloud Load Balancing בשירותים שפועלים בתשתית הקיימת שלכם מחוץ ל-Google Cloud.

אם רוצים שהשירות ההיברידי יהיה זמין ברשתות VPC אחרות, אפשר להשתמש ב-Private Service Connect כדי לפרסם את השירות. מיקום קובץ מצורף של שירות לפני מאזן העומסים הפנימי של HTTP(s) מאפשר ללקוחות ברשתות VPC אחרות להגיע ל שירותים היברידיים שפועלים בסביבות ענן מקומיות או אחרות.

מה תפַתחו

בקודלאב הזה תלמדו ליצור מאזן עומסים פנימי מסוג HTTP(S) עם קישוריות היברידית לשירות מקומי באמצעות קבוצת נקודות קצה ברשת. רשת ה-VPC של הצרכן תוכל לתקשר עם השירות המקומי באמצעות יציאות 80. יציאה 443 לא נכללת בהיקף הקודלאב.

הערה: ב-Codelab יש שלבי הגדרה ואימות שמבוססים על הטופולוגיה המודגמת. אפשר לשנות את התהליך לפי הצורך כדי לעמוד בדרישות הארגון. ה-Codelab לא חל על הרשאות IAM.

מה תלמדו

• איך יוצרים מאזן עומסים פנימי מסוג HTTP(S) עם קצה עורפי של NEG היברידי
• איך ליצור מפיק שירות פרטי (Private Service Connect) (קובץ מצורף לשירות) וצרכן (כלל העברה)

הערה: ה-Codelab הזה מתמקדת במאזן עומסים פנימי מסוג HTTP(S). באמצעות PSC . הגדרת הרשתות ההיברידיות לא מתועדת, אבל כן מוצגים מסמכים תומכים וצילומי מסך.

מה צריך להכין

• רשתות היברידיות מבוססות, למשל HA VPN,‏ Interconnect,‏ SW-WAN
• פרויקט ב-Google Cloud

יצירת קישוריות היברידית

צריך לחבר את Google Cloud לסביבות מקומיות או לסביבות ענן אחרות באמצעות קישוריות היברידית, באמצעות צירופי VLAN של Cloud Interconnect או מנהרות Cloud VPN עם Cloud Router. מומלץ להשתמש בחיבור עם זמינות גבוהה.

נתב Cloud Router שמופעל באמצעות ניתוב דינמי גלובלי לומד על נקודת הקצה הספציפית באמצעות BGP ומתכנת אותה ברשת Google Cloud VPC. אין תמיכה בניווט דינמי אזורי. אין גם תמיכה בנתיבים סטטיים.

רשת Google Cloud VPC שבה אתם משתמשים כדי להגדיר את Cloud Interconnect או Cloud VPN היא אותה רשת שבה אתם משתמשים כדי להגדיר את הפריסה של איזון העומסים ההיברידית. יש לוודא שטווחי ה-CIDR של רשת ה-VPC לא מתנגשים עם טווחי ה-CIDR המרוחקים שלכם. כשיש חפיפה בין כתובות IP, נתיבי תת-רשת מקבלים עדיפות על פני קישוריות מרחוק.

להוראות, אפשר לעיין במאמרים הבאים:

• מאמרי העזרה של Cloud VPN
• מסמכי העזרה של Cloud Interconnect

מודעות נתיב בהתאמה אישית

רשתות המשנה שבהמשך מחייבות מודעות מותאמות אישית מ-Cloud Router לרשת המקומית, שמבטיחות שכללי חומת האש בארגון מתעדכנים.

רשת משנה	תיאור
172.16.0.0/23	תת-רשת של שרת Proxy שמשמש לתקשורת ישירה עם השירות המקומי
22.130.211.0.0/22, 35.191.0.0/16	בדיקת תקינות של Google Cloud

2. לפני שמתחילים

עדכון הפרויקט כך שיתמוך ב-codelab

ב-Codelab הזה נעשה שימוש במשתני $ כדי לעזור בהטמעת הגדרות gcloud ב-Cloud Shell.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. הגדרת המפיק

יצירת VPC של הבעלים של התוכן הדיגיטלי

בתוך Inside Cloud Shell מבצעים את הפעולות הבאות

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

יצירת רשתות המשנה של הכלי להפקת חדשות

בתוך Inside Cloud Shell מבצעים את הפעולות הבאות

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

gcloud compute networks subnets create subnet-202 --project=$psclab --range=10.20.1.0/24 --network=producer-vpc --region=us-central1

שמירת כתובת IP למאזן העומסים הפנימי

Inside Cloud Shell מבצעים את הפעולות הבאות, באמצעות SHARED_VIP אין תמיכה ב-Private Service Connect, צריך להשתמש ב-GCE_ENDPOINT במקום זאת

gcloud compute addresses create lb-ip \
    --region=us-central1 \
    --subnet=subnet-202 \
    --purpose=GCE_ENDPOINT

משתמשים בפקודה לתיאור כתובות המחשוב כדי להציג את כתובת ה-IP שהוקצתה

gcloud compute addresses describe lb-ip  --region=us-central1 | grep address:

יצירת רשתות המשנה של שרתי proxy אזוריים

הקצאת שרת proxy מתבצעת ברמת ה-VPC ולא ברמת מאזן העומסים. צריך ליצור רשת משנה אחת לשרת proxy בלבד בכל אזור של רשת וירטואלית (VPC) שבה משתמשים במאזני עומסים מבוססי Envoy. אם פורסים כמה מאזני עומסים באותו אזור ובאותה רשת VPC, הם חולקים את אותה רשת משנה של שרת proxy בלבד לאיזון עומסים.

1. לקוח יוצר חיבור לכתובת ה-IP וליציאה של כלל ההעברה של מאזן העומסים.
2. כל שרת proxy מאזין לכתובת ה-IP וליציאה שצוינו על ידי כלל ההעברה המתאים של מאזן העומסים. אחד מהשרתים הווירטואליים מקבל את החיבור של הלקוח לרשת ומפסיק אותו.
3. שרת ה-proxy יוצר חיבור למכונה הווירטואלית או לנקודת הקצה (endpoint) המתאימה בקצה העורפי ב-NEG, כפי שנקבע על ידי מפת ה-URL והשירותים לקצה העורפי של מאזן העומסים.

עליך ליצור רשתות משנה לשרת proxy בלבד, גם אם הרשת שלך היא במצב אוטומטי וגם אם היא מותאמת אישית. תת-רשת של שרת proxy בלבד חייבת לספק 64 כתובות IP או יותר. היא מתאימה לקידומת שמכילה עד 26 תווים. הגודל המומלץ של רשת המשנה הוא /23 (512 כתובות לשרת proxy בלבד).

הערה: תת-הרשת לשרת proxy בלבד מחייבת פרסום של BGP של לקוח באופן מקומי, ולכן ניתן לנתב אותה לרשת המקומית שלכם. הגישה לשירות מתאפשרת דרך רשת המשנה של שרת ה-proxy שסופקה.

בתוך Inside Cloud Shell מבצעים את הפעולות הבאות

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

יצירת תת-הרשתות של NAT ב-Private Service Connect

יוצרים רשת משנה ייעודית אחת או יותר לשימוש עם Private Service Connect. אם אתם משתמשים במסוף Google Cloud כדי לפרסם שירות, תוכלו ליצור את תת-הרשתות במהלך התהליך הזה. יוצרים את רשת המשנה באותו אזור שבו נמצא מאזן העומסים של השירות. אי אפשר להמיר תת-רשת רגילה לתת-רשת של Private Service Connect.

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

יצירת כללי חומת האש של הכלי להפקת חדשות

מגדירים כללי חומת אש כדי לאפשר תעבורת נתונים בין נקודות הקצה של Private Service Connect לבין הקובץ המצורף לשירות. ב-Codelab, יצר כלל חומת אש של תעבורת נתונים נכנסת (ingress) שמאפשר לרשת המשנה של NAT 100.100.10.0/24 לגשת לקובץ המצורף לשירות Private Service Connect (מאזן עומסים פנימי).

ב-Cloud Shell, מבצעים את הפעולות הבאות:

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

ב-Cloud Shell, יוצרים את הכלל fw-allow-health-check כדי לאפשר לבדיקות התקינות של Google Cloud להגיע לשירות המקומי (שירות לקצה העורפי) ביציאת ה-TCP 80.

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

יצירת כלל של תעבורת נתונים נכנסת (ingress) שמאפשר לחומת אש עבור רשת המשנה לשרת proxy בלבד, כדי לאפשר למאזן העומסים לתקשר עם מכונות לקצה העורפי ביציאת TCP 80

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

הגדרת ה-NEG של הקישוריות ההיברידית

כשיוצרים את ה-NEG,צריך להשתמש בתחום שמצמצם את המרחק הגיאוגרפי בין Google Cloud לבין סביבת הענן המקומית או סביבת ענן אחרת. לדוגמה, אם אתם מארחים שירות בסביבה מקומית בפרנקפורט שבגרמניה, תוכלו לציין את התחום europe-west3-a במהלך יצירת ה-NEG.

בנוסף, אם אתם משתמשים ב-Cloud Interconnect, ה-ZONE ששימש ליצירת ה-NEG צריך להיות באותו אזור שבו הוגדר הקובץ המצורף Cloud Interconnect.

כדי לראות אילו אזורים ותחומים זמינים, אפשר לעיין במאמרי העזרה של Compute Engine: אזורים ותחומים זמינים.

Inside Cloud Shell יוצרים קישוריות היברידית NEG באמצעות הפקודה gcloud compute network-endpoint-groups create

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

ב-Cloud Shell, מוסיפים את נקודת הקצה IP:Port המקומית ל-NEG ההיברידי.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

הגדרת מאזן העומסים

בשלבים הבאים צריך להגדיר את מאזן העומסים (כלל ההעברה) שיוך לקבוצת נקודות הקצה ברשת

יוצרים ב-Cloud Shell את בדיקת התקינות האזורית שמועברת לשירות המקומי

gcloud compute health-checks create http http-health-check \
    --region=us-central1 \
    --use-serving-port

יוצרים ב-Cloud Shell את השירות לקצה העורפי של קצה העורפי המקומי שמשתמש ב-NEG היברידי

 gcloud compute backend-services create on-premise-service-backend \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --protocol=HTTP \
      --health-checks=http-health-check \
      --health-checks-region=us-central1 \
      --region=us-central1

Inside Cloud Shell מוסיפים את הקצה העורפי NEG ההיברידי לשירות לקצה העורפי. בשדה RATE, מזינים את הערך המקסימלי של RATE שמערכת הקצה העורפי צריכה לטפל בו.

gcloud compute backend-services add-backend on-premise-service-backend \
    --region=us-central1 \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=100 \
    --network-endpoint-group=on-prem-service-neg \
    --network-endpoint-group-zone=us-central1-a

יוצרים את מפת כתובות ה-URL ב-Cloud Shell כדי לנתב בקשות נכנסות לשירות הקצה העורפי

gcloud compute url-maps create on-prem-svc-url-map \
    --default-service on-premise-service-backend \
    --region=us-central1

יצירת שרת ה-proxy היעד של HTTP

gcloud compute target-http-proxies create proxy-subnet-us-central\
    --url-map=on-prem-svc-url-map \
    --url-map-region=us-central1 \
    --region=us-central1

אפשר ליצור כלל העברה כדי לנתב בקשות נכנסות לשרת ה-proxy. אל תשתמשו ברשת המשנה לשרת proxy בלבד כדי ליצור את כלל ההעברה.

 gcloud compute forwarding-rules create http-hybrid-neg-fwd-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=subnet-202 \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=proxy-subnet-us-central \
      --target-http-proxy-region=us-central1

4. אימות מאזן העומסים

במסוף Cloud, עוברים אל Network Services → Load Balancing → Load Balancers. שימו לב, ה-NEG 1 הוא 'ירוק' ציון של בדיקת תקינות של השירות במקום

בחירה באפשרות ‘on-premise-svc-url-map' יוצרת את כתובת ה-IP של ממשק הקצה ומזהה את השירות לקצה העורפי

5. הצגת המסלולים שנלמדו מהארגון

עוברים אל VPC Network → Routes. הערה: רשת המשנה של השירות המקומי שנלמדה 192.168.1.0/27

6. אימות הקישוריות לשירות המקומי

מה-VPC של Producers אנחנו ניצור מכונה וירטואלית כדי לבדוק את הקישוריות לשירות המקומי. בסיום ההגדרה הבאה, ה-Service Attachment (קובץ מצורף) יהיה זמין.

יוצרים ב-Cloud Shell את מכונה לבדיקה ב-VPC של הבעלים

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש שמאפשר:

• רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
• הכלל מאפשר תעבורת נתונים נכנסת (ingress) מטווח כתובות ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות להעברת TCP באמצעות IAP.

יוצרים את מכונה לבדיקה ב-VPC של הבעלים ב-Cloud Shell

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

התחברות לתיבת הבדיקה-us-central1 באמצעות IAP ב-Cloud Shell כדי לאמת את הקישוריות לשירות המקומי על ידי ביצוע curl על כתובת ה-IP של מאזן העומסים. אם חלף זמן קצוב לתפוגה, צריך לנסות שוב.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

מבצעים בדיקת קישוריות באמצעות curl לשירות המקומי. אחרי האימות, יוצאים מהמכונה הווירטואלית וחוזרים להנחיה של Cloud Shell. מחליפים את כתובת ה-IP של מאזן העומסים הפנימי על סמך הפלט שזוהה בשלב 4.

user@test-box-us-central1:~$ curl -v 10.20.1.2
* Expire in 0 ms for 6 (transfer 0x55b7725c10f0)
*   Trying 10.20.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b7725c10f0)
* Connected to 10.20.1.2 (10.20.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.20.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< content-type: text/html; charset=utf-8
< accept-ranges: bytes
< etag: "3380914763"
< last-modified: Mon, 05 Dec 2022 15:10:56 GMT
< expires: Mon, 12 Dec 2022 03:17:20 GMT
< cache-control: max-age=0
< content-length: 37
< date: Mon, 12 Dec 2022 03:17:20 GMT
< server: lighttpd/1.4.53
< via: 1.1 google
< 
Welcome to my on-premise service!!

7. יצירת הקובץ המצורף של שירות Private Service Connect

בשלבים הבאים ניצור את Service Attachment. לאחר ההתאמה עם נקודת קצה של צרכן, תהיה גישה לשירות המקומי בלי צורך בקישור VPC.

יצירת צירוף השירות

יוצרים את הקובץ המצורף לשירות ב-Cloud Shell

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

אופציונלי: אם משתמשים ב-VPC משותף, יוצרים את הצירוף לשירות בפרויקט השירות.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=http-hybrid-neg-fwd-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

אימות הקובץ המצורף לשירות ה-TCP

gcloud compute service-attachments describe service-1 --region us-central1

אופציונלי: עוברים אל שירותי רשת ← Private Service Connect כדי להציג את הקובץ המצורף לשירות החדש שיצרתם.

אם בוחרים באפשרות Service-1, מקבלים פרטים נוספים, כולל ה-URI של קובץ מצורף לשירות שבו הצרכן משתמש כדי ליצור חיבור לשירות פרטי. חשוב לשים לב למזהה ה-URI כי תצטרכו להשתמש בו בשלב מאוחר יותר.

פרטי הצירוף לשירות: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

8. הגדרת הצרכן

יצירת ה-VPC לצרכנים

בתוך Inside Cloud Shell מבצעים את הפעולות הבאות

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

יצירת רשתות המשנה לצרכנים

יצירת רשת משנה של GCE באמצעות Inside Cloud Shell

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

יצירת רשת משנה של נקודת קצה (endpoint) לצרכנים באמצעות Inside Cloud Shell

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

יצירת נקודת הקצה לצרכנים (כלל העברה)

יוצרים ב-Inside Cloud Shell את כתובת ה-IP הסטטית שתשמש כנקודת קצה (endpoint) של צרכנים

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

נשתמש במזהה ה-URI של Service Attachment שנוצר קודם כדי ליצור את נקודת הקצה של הצרכן.

יוצרים את נקודת הקצה של הצרכן ב-Cloud Shell

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

9. אימות הקישור לשירות הפרטי של הצרכן – VPC של הצרכן

מה-VPC של הצרכן מאמתים חיבורים מוצלחים לשירות Private Service על ידי מעבר אל שירותי רשת ← Private Service Connect ← נקודות קצה מחוברות. יש לשים לב לחיבור psc-consumer-1 ולכתובת ה-IP המתאימה שיצרנו קודם.

כשבוחרים ב-psc-consumer-1, מוצגים פרטים כולל ה-URI של צירוף השירות

10. אימות Private Service Connect של צרכן – VPC של הבעלים

ב-VPC של הבעלים, מוודאים שהחיבור ל-Private Service Connect הצליח. עוברים אל Network Services → Private Service Connect → Published Service. לתשומת ליבכם, חיבור service-1 שפורסם מציין עכשיו כלל העברה אחד (נקודת קצה של חיבור).

11. יצירת אזור DNS פרטי רשומת A

יוצרים את תחום ה-DNS הפרטי שממופה לנקודת הקצה של חיבור ה-PSC, ומאפשר גישה חלקה ל-Producer מכל מארח ב-VPC.

הערה: אין תמיכה בגישה לנקודת קצה של צרכן דרך קישור VPC

מ-Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

12. אימות הגישה של צרכנים לשירות המפיקים באמצעות VM

מה-VPC של הצרכנים ניצור מכונה וירטואלית כדי לבדוק את הקישוריות לשירות המקומי באמצעות גישה לנקודת הקצה לצרכנים service1.codelabs.net

Inside Cloud Shell יוצרים את מכונת הבדיקה ב-vpc לצרכנים

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

כדי לאפשר ל-IAP להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש שמאפשר:

• רלוונטי לכל מכונות ה-VM שרוצים לגשת אליהן באמצעות IAP.
• תעבורת נתונים נכנסת (ingress) מטווח ה-IP 35.235.240.0/20. הטווח הזה מכיל את כל כתובות ה-IP שמשמשות להעברת TCP באמצעות IAP.

Inside Cloud Shell יוצרים את מכונת הבדיקה ב-vpc לצרכנים

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

מתחברים למכונה הווירטואלית של הצרכן באמצעות IAP ב-Cloud Shell כדי לאמת את החיבור לשירות המקומי. לשם כך, מבצעים קריאה ל-curl נגד כתובת ה-FQDN של ה-DNS service1.codelab.net. אם חל תוקף זמן קצוב, מנסים שוב.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

מבצעים אימות curl לאימות קישוריות לשירות המקומי. לאחר האימות, היציאה מה-VM וחזרה להנחיה של Cloud Shell

ביצוע הפקודה curl ב-Cloud Shell

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

למטה מוצגת דוגמה לתיעוד של השירות המקומי. שימו לב שכתובת ה-IP של המקור 172.16.0.13 היא מטווח רשת המשנה של שרת ה-proxy 172.16.0.0/23

13. ניקוי נתונים מהמפיק

מחיקת רכיבים של יוצרים

מחיקת המכונות לבדיקה ב-Producer VPC בעזרת Inside Cloud Shell נמחקת

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete http-hybrid-neg-fwd-rule --region=us-central1 --quiet

gcloud compute target-http-proxies delete proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute url-maps delete on-prem-svc-url-map --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute addresses delete lb-ip --region=us-central1 --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 subnet-202 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete http-health-check --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

14. ניקוי נתונים לצרכנים

מחיקת רכיבי צרכן

מחיקת המכונות לבדיקה ב-VPC של הצרכן בעזרת Inside Cloud Shell

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

15. מזל טוב

סיימתם להגדיר ולאמת את Private Service Connect עם מאזן עומסים פנימי מסוג HTTP(S).

יצרתם את התשתית של היצרן, והוספתם קובץ מצורף של שירות ב-VPC של היצרן שמפנה לשירות מקומי. למדתם איך ליצור נקודת קצה לצרכנים ב-VPC לצרכן שאפשרה קישוריות לשירות בארגון.

מה השלב הבא?

כדאי לעיין בחלק מהקורסים האלה ב-Codelab…

• שימוש ב-Private Service לפרסום ולצריכה של שירותים באמצעות GKE
• שימוש ב-Private Service Connect כדי לפרסם ולצרוך שירותים
• התחברות לשירותים מקומיים באמצעות Networking היברידי באמצעות Private Service Connect ומאזן עומסים פנימי של TCP Proxy

קריאה נוספת וסרטונים

• סקירה כללית על Private Service Connect
• מהו Private Service Connect?
• סוגי מאזני העומסים הנתמכים

מסמכי עזר

• סקירה כללית בנושא מאזן עומסים פנימי מסוג HTTP(s)
• סקירה כללית של בדיקות התקינות
• איך לפרסם שירות באמצעות Private Service Connect