1. מבוא
Private Service Connect עם הגדרת DNS אוטומטי משתמש ב-Service Directory וב-Cloud DNS כדי ליצור באופן אוטומטי רשומות DNS שמתוכנתות עם כתובות ה-IP של נקודת הקצה של Private Service Connect לצרכנים.
מה תפַתחו
ב-Codelab הזה, אתם עומדים לפתח ארכיטקטורה מקיפה של Private Service Connect שממחישה את השימוש ב-DNS אוטומטי, כפי שמתואר באיור 1.
כדי לאפשר DNS אוטומטי:
- המקור של הקובץ המצורף לשירות של היצרן הוא DNS אוטומטי על ידי אספקת נחלת הכלל בבעלות עם '– שמות דומיינים' בזמן יצירת הקובץ המצורף לשירות Private Service Connect.
- הצרכן מגדיר שם של נקודת קצה.
- DNS אוטומטי יוצר גם DNS Zone - goog-psc-default-us-central1 וגם שם DNS cosmopup.net, בנוסף לרשומה של Service Directory שמכילה את השם של נקודת הקצה לצרכן.
היתרון של DNS אוטומטי מודגם בסעיף (4) שבו משתמש קצה יכול לתקשר עם נקודת הקצה לצרכן באמצעות DNS, FQDN stargazer.cosmopup.net.
איור 1
מה תלמדו
- איך יוצרים מאזן עומסים פנימי מסוג 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
הצגת כתובת ה-IP שהוקצתה
משתמשים בפקודה לתיאור כתובות המחשוב כדי להציג את כתובת ה-IP שהוקצתה
gcloud compute addresses describe lb-ip --region=us-central1 | grep address:
יצירת רשתות המשנה של שרת proxy אזורי
הקצאת שרת ה-proxy היא ברמת רשת ה-VPC, ולא ברמת מאזן העומסים. צריך ליצור רשת משנה אחת לשרת proxy בלבד בכל אזור של רשת וירטואלית (VPC) שבה משתמשים במאזני עומסים מבוססי Envoy. אם פורסים כמה מאזני עומסים באותו אזור ובאותה רשת VPC, הם חולקים את אותה רשת משנה של שרת proxy בלבד לאיזון עומסים.
- לקוח יוצר חיבור לכתובת ה-IP וליציאה של כלל ההעברה של מאזן העומסים.
- כל שרת proxy מאזין לכתובת ה-IP וליציאה שצוינו בכלל ההעברה של מאזן העומסים המתאים. אחד משרתי ה-proxy מקבל ומסיים את החיבור לרשת של הלקוח.
- שרת ה-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
יוצרים את הקובץ המצורף לשירות
יוצרים את הקובץ המצורף של השירות בתוך 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