התחברות לשירותים מקומיים בארגון באמצעות 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 אחרות להגיע ל שירותים היברידיים שפועלים בסביבות ענן מקומיות או אחרות.

מה תפַתחו

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

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

מה תלמדו

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

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

מה צריך להכין

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

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

עליכם לחבר בין Google Cloud לסביבות המקומיות או סביבות ענן אחרות באמצעות קישוריות היברידית, באמצעות קבצים מצורפים של Cloud Interconnect VLAN או מנהרות 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 הזה נעשה שימוש ב-$variables כדי לעזור בהטמעת ההגדרות של gcloud ב-Cloud Shell.

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

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

3. הגדרה של הכלי להפקת חדשות

יצירת ה-Producer 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 וליציאה שצוינו בכלל ההעברה של מאזן העומסים המתאים. אחד משרתי ה-proxy מקבל ומסיים את החיבור לרשת של הלקוח.
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

יצירת רשתות המשנה של Private Service Connect NAT

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

בתוך Inside 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 (מאזן עומסים פנימי).

בתוך Inside 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

Inside 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

מוסיפים את נקודת הקצה המקומית של יציאה (IP:Port) ל-NEG המשולב באמצעות Inside Cloud Shell.

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

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

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

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

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

Inside 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 של כתובות ה-URL ב-Inside 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 ← מאזני עומסים. שימו לב, ה-NEG 1 הוא 'ירוק' ציון של בדיקת תקינות של השירות במקום

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

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

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

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

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

Inside Cloud Shell יוצרים את מכונת הבדיקה ב-Producer 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 להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש:

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

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

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 לאימות קישוריות לשירות המקומי. לאחר האימות, היציאה מה-VM חזרה להנחיה של 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

בשלבים הבאים ניצור את הקובץ המצורף לשירות, ולאחר הצמדה לנקודת קצה (endpoint) של הצרכן תושג גישה לשירות המקומי ללא צורך בקישור בין רשתות שכנות (peering) ב-VPC.

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

יצירת הקובץ המצורף לשירות ב-Inside 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 של קובץ מצורף לשירות שנוצר בעבר כדי ליצור את נקודת הקצה לצרכן

יצירת נקודת הקצה לצרכנים באמצעות Inside 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. אימות הקישור לשירות הפרטי של הצרכן – Producer VPC

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

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

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

הערה: אין תמיכה בגישה לנקודת קצה (endpoint) של צרכנים באמצעות קישור בין רשתות שכנות (peering) ב-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 להתחבר למכונות הווירטואליות, יוצרים כלל של חומת אש:

• המדיניות חלה על כל מכונות וירטואליות שרוצים לגשת אליהן באמצעות 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

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

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

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

ביצוע קורל של Inside 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

מחיקת המכונות לבדיקה ב-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 לצרכן שאפשרה קישוריות לשירות בארגון.

מה השלב הבא?

כדאי לנסות כמה מ-Codelabs האלה...

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

המשך קריאה סרטונים

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

מסמכי עזר

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