התחברות לשירות פרטי עם הגדרת DNS אוטומטית

1. מבוא

Private Service Connect עם הגדרת DNS אוטומטי משתמש ב-Service Directory וב-Cloud DNS כדי ליצור באופן אוטומטי רשומות DNS שמתוכנתות עם כתובות ה-IP של נקודת הקצה של Private Service Connect לצרכנים.

מה תפַתחו

ב-Codelab הזה, אתם עומדים לפתח ארכיטקטורה מקיפה של Private Service Connect שממחישה את השימוש ב-DNS אוטומטי, כפי שמתואר באיור 1.

כדי לאפשר DNS אוטומטי:

1. המקור של הקובץ המצורף לשירות של היצרן הוא DNS אוטומטי על ידי אספקת נחלת הכלל בבעלות עם '– שמות דומיינים' בזמן יצירת הקובץ המצורף לשירות Private Service Connect.
2. הצרכן מגדיר שם של נקודת קצה.
3. DNS אוטומטי יוצר גם DNS Zone - goog-psc-default-us-central1 וגם שם DNS cosmopup.net, בנוסף לרשומה של Service Directory שמכילה את השם של נקודת הקצה לצרכן.

היתרון של DNS אוטומטי מודגם במשפט (4) שבו משתמש קצה יכול לתקשר עם נקודת הקצה לצרכן באמצעות DNS, FQDN stargazer.cosmopup.net.

איור 1

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

מה תלמדו

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

מה צריך להכין

• פרויקט ב-Google Cloud
• נחלת הכלל שבבעלותך

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

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

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

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

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

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

יצירת ה-VPC המקורי

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

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

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

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

gcloud compute networks subnets create gce-subnet --project=$projectname --range=172.16.20.0/28 --network=producer-vpc --region=us-central1

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

gcloud compute networks subnets create load-balancer-subnet --project=$projectname --range=172.16.10.0/28 --network=producer-vpc --region=us-central1

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

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

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

הערה: השימוש ב-SHARED_VIP לא נתמך ב-Private Service Connect. צריך להשתמש ב-GCE_ENDPOINT במקום זאת

הצגת כתובת ה-IP שהוקצתה

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

צריך ליצור תת-רשתות לשרת proxy בלבד, גם אם רשת ה-VPC היא במצב אוטומטי וגם אם היא במצב מותאם אישית. תת-רשת של שרת proxy בלבד חייבת לספק 64 כתובות IP או יותר. הערך הזה תואם לאורך קידומת של /26 או פחות. הגודל המומלץ של רשת המשנה הוא /23 (512 כתובות לשרת 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 \
    --project $projectname \
    --network producer-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

יצירת כללי חומת האש של היצרן

מגדירים כללי חומת אש כדי לאפשר תעבורת נתונים בין רשת המשנה של Private Service Connect NAT לבין רשת המשנה של שרת proxy של ILB בלבד.

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

gcloud compute --project=$projectname 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

הגדרת Cloud Router ו-NAT

Cloud NAT משמש ב-Codelab להתקנת חבילות תוכנה כי למכונה הווירטואלית אין כתובת IP חיצונית.

יוצרים את הנתב Cloud Shell בתוך Cloud Shell.

gcloud compute routers create cloud-router-for-nat --network producer-vpc --region us-central1

יוצרים את שער NAT בתוך Cloud Shell.

gcloud compute routers nats create cloud-nat-us-central1 --router=cloud-router-for-nat --auto-allocate-nat-external-ips --nat-all-subnet-ip-ranges --region us-central1

הגדרה של קבוצת מכונות

בקטע הבא יוצרים את המכונה של Compute Engine & קבוצת מכונות לא מנוהלת. בשלבים הבאים קבוצת המכונות תשמש כשירות לקצה העורפי של מאזן העומסים.

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

gcloud compute instances create app-server-1 \
    --project=$projectname \
    --machine-type=e2-micro \
    --image-family debian-10 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=gce-subnet \
    --metadata startup-script="#! /bin/bash
      sudo apt-get update
      sudo apt-get install apache2 -y
      sudo service apache2 restart
      echo 'Welcome to App-Server-1 !!' | tee /var/www/html/index.html
      EOF"

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

gcloud compute instance-groups unmanaged create psc-instance-group --zone=us-central1-a

gcloud compute instance-groups unmanaged set-named-ports psc-instance-group --project=$projectname --zone=us-central1-a --named-ports=http:80

gcloud compute instance-groups unmanaged add-instances psc-instance-group --zone=us-central1-a --instances=app-server-1

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

בשלבים הבאים צריך להגדיר את מאזן העומסים הפנימי של HTTP שיפורסם כקובץ מצורף לשירות בשלב מאוחר יותר.

יוצרים את בדיקת התקינות האזורית ב-Inside Cloud Shell.

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

Inside Cloud Shell, יוצרים את השירות לקצה העורפי.

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

Inside Cloud Shell מוסיפים קצוות עורפיים לשירות לקצה העורפי.

gcloud compute backend-services add-backend l7-ilb-backend-service \
  --balancing-mode=UTILIZATION \
  --instance-group=psc-instance-group \
  --instance-group-zone=us-central1-a \
  --region=us-central1

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

gcloud compute url-maps create l7-ilb-map \
    --default-service l7-ilb-backend-service \
    --region=us-central1

יוצרים את שרת ה-Proxy של יעד ה-HTTP.

gcloud compute target-http-proxies create l7-ilb-proxy\
    --url-map=l7-ilb-map \
    --url-map-region=us-central1 \
    --region=us-central1

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

 gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
      --load-balancing-scheme=INTERNAL_MANAGED \
      --network=producer-vpc \
      --subnet=load-balancer-subnet \
      --address=lb-ip \
      --ports=80 \
      --region=us-central1 \
      --target-http-proxy=l7-ilb-proxy \
      --target-http-proxy-region=us-central1

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

ממסוף Cloud, עוברים אל Network Services ← Load Balancing ← מאזני עומסים. חשוב לשים לב שבדיקת התקינות בוצעה בהצלחה לשירות לקצה העורפי

אם בוחרים באפשרות 'l7-ilb-map', המערכת מפיקה את כתובת ה-IP של הקצה העורפי, שאמורה להיות זהה לכתובת ה-IP שצירפתם בשלב הקודם ומזהה את השירות לקצה העורפי.

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

הערה: אם מציינים שם דומיין, השם משמש להגדרה אוטומטית של רשומות DNS פרטיות לשירותים שלכם ברשת ה-VPC של צרכן השירות. עליכם להיות הבעלים המאומתים של שם הדומיין שציינתם. פרסום השירות ייכשל אם אתם לא הבעלים של הדומיין. אפשר ללחוץ על 'אימות הדומיין' כדי להציג ולהגדיר את הבעלות על הדומיין. בתחביר שלמטה, cosmopup.net. משמש בתור שם הדומיין. מעדכנים את ההגדרה עם דומיין ציבורי מורשה שנמצא בבעלותכם.

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

יוצרים את הקובץ המצורף של השירות בתוך Cloud Shell. חשוב להוסיף את '.' בסוף שם הדומיין.

gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet --domain-names=cosmopup.net.

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

gcloud compute service-attachments create published-service --region=us-central1 --producer-forwarding-rule=l7-ilb-forwarding-rule --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/us-central1/subnetworks/psc-nat-subnet --domain-names=cosmopup.net.

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

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

פרטים על הקובץ המצורף לשירות:

projects/<project name>/regions/us-central1/serviceAttachments/published-service

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

הפעלת ממשקי API לצרכנים

בתוך Cloud, Shell מבצעת את הפעולות הבאות:

gcloud services enable dns.googleapis.com
gcloud services enable servicedirectory.googleapis.com

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

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

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

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

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

gcloud compute networks subnets create db1-subnet --project=$projectname --range=10.20.0.0/28 --network=consumer-vpc --region=us-central1

Inside Cloud Shell יוצרים רשת משנה עבור נקודת הקצה לצרכנים.

gcloud compute networks subnets create consumer-ep-subnet --project=$projectname --range=10.10.0.0/28 --network=consumer-vpc --region=us-central1

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

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

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=consumer-ep-subnet --addresses 10.10.0.10

כדי ליצור את נקודת הקצה לצרכנים, אנחנו משתמשים ב-URI לצירוף שירות שנוצר בעבר.

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

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

7. אימות החיבור ברשת ה-VPC של הצרכן

ברשת ה-VPC לצרכנים, מוודאים שהחיבור לשירות Private Service Connect מוצלח: עוברים אל Network Services ← Private Service Connect ← Connected Endpoints. שים לב לחיבור Stargazer שנוצר ולכתובת ה-IP התואמת שיצרנו בעבר.

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

8. אימות החיבור ברשת ה-VPC של היצרן

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

9. אימות של הגדרת ה-DNS האוטומטי

נבדוק את ההגדרות של DNS ו-Service Directory

הגדרות אישיות של Cloud DNS

עוברים אל שירותי רשת ← Cloud DNS ← Zones. שם התחום goog-psc-default-us-central &, cosmopup.net. נוצר באופן אוטומטי.

הצגת ההגדרות של DNS ו-Service Directory

בחירת שם התחום תאפשר לנו לראות איך Service Directory משתלבת עם Cloud DNS.

הגדרה של ספריית השירות

עוברים אל שירותי רשת ← Service Directory.

להיזכר בשם נקודת הקצה לצרכנים? stargazer? היא מתוכנתת באופן אוטומטי ב-Service Directory, וכך אנחנו יכולים להגיע לנקודת הקצה (endpoint) של הצרכן באמצעות FQDN stargazer.goog-psc-default–us-central1

10. לאמת את גישת הצרכן לשירות של היצרן

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

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

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

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

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

בתוך Cloud Shell, יוצרים את כלל חומת האש IAP.

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

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

gcloud compute ssh db1 --project=$projectname --zone=us-central1-a --tunnel-through-iap

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

Inside Cloud Shell מבצעים curl על הדומיין המותאם אישית שלכם, לדוגמה stargazer.[custom-domain.com]. בפלט שבהמשך, מבוצע curl על stargazer.cosmopup.net

user@db1:~$ curl -v stargazer.cosmopup.net
*   Trying 10.10.0.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55d3aa8190f0)
* Connected to stargazer.cosmopup.net (10.10.0.10) port 80 (#0)
> GET / HTTP/1.1
> Host: stargazer.cosmopup.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< date: Thu, 22 Dec 2022 00:16:25 GMT
< server: Apache/2.4.38 (Debian)
< last-modified: Wed, 21 Dec 2022 20:26:32 GMT
< etag: "1b-5f05c5e43a083"
< accept-ranges: bytes
< content-length: 27
< content-type: text/html
< via: 1.1 google
< 
Welcome to App-Server-1 !!

יוצאים מה-VM שחוזרת אל Cloud Shell כדי להתחיל את משימות הניקוי

11. הסרת המשאבים

מוחקים את רכיבי Codelab מ-Cloud Shell.

gcloud compute forwarding-rules delete stargazer --region=us-central1 --quiet

gcloud compute instances delete db1 --zone=us-central1-a --quiet 

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

gcloud compute networks subnets delete consumer-ep-subnet db1-subnet --region=us-central1 --quiet 

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

gcloud compute networks delete consumer-vpc --quiet 

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

gcloud compute forwarding-rules delete l7-ilb-forwarding-rule --region=us-central1 --quiet 

gcloud compute target-http-proxies delete l7-ilb-proxy --region=us-central1 --quiet 
 
gcloud compute url-maps delete l7-ilb-map --region=us-central1 --quiet 
 
gcloud compute backend-services delete l7-ilb-backend-service --region=us-central1 --quiet
 
gcloud compute instance-groups unmanaged delete psc-instance-group --zone=us-central1-a --quiet
 
gcloud compute instances delete app-server-1 --zone=us-central1-a --quiet 
 
gcloud compute firewall-rules delete allow-to-ingress-nat-subnet fw-allow-health-check fw-allow-proxy-only-subnet --quiet 
 
gcloud compute addresses delete lb-ip --region=us-central1 --quiet 
 
gcloud compute networks subnets delete gce-subnet load-balancer-subnet psc-nat-subnet proxy-subnet-us-central --region=us-central1 --quiet 
 
gcloud compute routers delete cloud-router-for-nat --region=us-central1 --quiet 
 
gcloud compute networks delete producer-vpc --quiet 

12. מזל טוב

מזל טוב, הגדרת בהצלחה ואימתת נקודת קצה של Private Service Connect עם הגדרת DNS אוטומטית.

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

Cosmopup אומר ש-Codelabs מדהימים!

מה השלב הבא?

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

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

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

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

מסמכי עזר

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