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

1. מבוא

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

מה תפַתחו

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

האפשרות 'DNS אוטומטי' מתאפשרת בזכות:

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

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

איור 1

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

מה תלמדו

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

מה תצטרכו

• פרויקט ב-Google Cloud
• דומיין ציבורי שבבעלותכם

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

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

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

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

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

3. הגדרת Producer

יצירת ה-VPC של היצרן

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

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

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

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

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

ב-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 למאזן עומסים פנימי

ב-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 שהוקצתה

משתמשים בפקודה compute addresses describe כדי לראות את כתובת ה-IP שהוקצתה.

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

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

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

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

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

ב-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 \
    --project $projectname \
    --network producer-vpc \
    --region us-central1 \
    --range 100.100.10.0/24 \
    --purpose PRIVATE_SERVICE_CONNECT

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

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

ב-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 בלבד, כדי לאפשר למאזן העומסים לתקשר עם שרתים עורפיים (backend instance) ביציאה 80 ב-TCP.

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

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

ב-Cloud Shell, יוצרים את Cloud Router.

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

ב-Cloud Shell, יוצרים את שער ה-NAT.

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

ב-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"

ב-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, שיפורסם כצירוף שירות בשלב מאוחר יותר.

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

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

ב-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

ב-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

ב-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 → Load Balancers. הערה לגבי בדיקת תקינות מוצלחת לשירות לקצה העורפי

בחירה באפשרות 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 של קובץ השירות המצורף שמשמש את הצרכן ליצירת חיבור Private Service Connection ושם הדומיין.

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

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 של צרכן

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

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

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

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

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

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

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

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

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

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

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

ב-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 של הצרכן, עוברים אל Network Services → Private Service Connect→ Connected Endpoints כדי לוודא שנוצר חיבור Private Service Connect. שימו לב לחיבור stargazer שנוצר ולכתובת ה-IP התואמת שיצרנו קודם.

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

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

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

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

בואו נבדוק את הגדרות ה-DNS ואת הגדרות ספריית השירותים.

הגדרת Cloud DNS

עוברים אל Network Services → Cloud DNS → Zones (שירותי רשת → Cloud DNS → אזורים). האזור goog-psc-default-us-central & ושם ה-DNS cosmopup.net. נוצרים באופן אוטומטי.

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

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

הגדרת Service Directory

עוברים אל Network Services → Service Directory (שירותי רשת → ספריית שירותים).

זוכרים את שם נקודת הקצה של הצרכן, stargazer? היא מתוכנתת אוטומטית בספריית השירותים, ומאפשרת לנו להגיע לנקודת הקצה של הצרכן באמצעות FQDN‏ stargazer.goog-psc-default–us-central1

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

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

ב-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 להתחבר למכונות הווירטואליות, צריך ליצור כלל חומת אש ש:

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

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

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

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

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

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

ב-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. הסרת המשאבים

מ-Cloud Shell, מוחקים את רכיבי ה-codelab.

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. מזל טוב

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

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

‫Cosmopup חושב ש-codelabs הם מדהימים!!

מה השלב הבא?

כדאי לעיין ב-Codelabs הבאים…

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

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

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

מסמכי עזר

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