Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. מבוא

הערה: ‏ Looker תומך ב-Southbound Producers בכל אזור. כדי לקבל גישה באמצעות Looker Northbound, נקודת הקצה או ה-backend של הלקוח צריכים להיות באותו אזור כמו מכונת Looker PSC.

בשיעור Codelab הזה תבצעו חיבור HTTPS דרומה לסביבת GitLab בניהול עצמי באמצעות מאזן עומסים פנימי בשרתי TCP Proxy וקבוצת נקודות קצה ברשת האינטרנט (NEG) שהופעלו מ-Looker PSC כצרכן שירות.

‫Private Service Connect הוא יכולת של רשת Google Cloud שמאפשרת לצרכנים לגשת לשירותים מנוהלים באופן פרטי מתוך רשת ה-VPC שלהם. באופן דומה, הוא מאפשר ליצרני שירותים מנוהלים לארח את השירותים האלה ברשתות VPC נפרדות משלהם ולהציע חיבור פרטי לצרכנים שלהם. לדוגמה, כשמשתמשים ב-Private Service Connect כדי לגשת ל-Looker, המשתמש הוא צרכן השירות ו-Google היא בעלת השירות המנוהל, כפי שמודגש באיור 1.

Figure 1.

גישה מדרום לצפון, שנקראת גם PSC הפוך, מאפשרת לצרכן ליצור שירות שפורסם בתור יצרן כדי לאפשר ל-Looker גישה לנקודות קצה (endpoints) מקומיות, ב-VPC, לשירותים מנוהלים ולאינטרנט. אפשר לפרוס חיבורים מדרום לצפון בכל אזור, בלי קשר למיקום הפריסה של Looker PSC, כפי שמודגש באיור 2.

איור 2.

מה תלמדו

• דרישות רשת
• יצירת שירות מנוהל של Private Service Connect
• יצירת נקודת קצה של Private Service Connect ב-Looker
• יצירת קישוריות למכונה ב-GitLab Self-Managed

מה תצטרכו

• פרויקט ב-Google Cloud עם הרשאות בעלים
• חשבון ומאגר ב-GitLab
• מופע קיים של Looker PSC

2. מה תפַתחו

תגדירו רשת של יצרן, looker-psc-demo, כדי לפרוס מאזן עומסים של שרת proxy פנימי של TCP ו-NEG באינטרנט שפורסם כשירות באמצעות Private Service Connect ‏ (PSC). אחרי הפרסום, תבצעו את הפעולות הבאות כדי לאמת את הגישה לשירות Producer:

• יצירת נקודת קצה של PSC ב-Looker שמשויכת לקובץ המצורף של שירות ההפקה
• משתמשים ב-Looker Console כדי ליצור פרויקט חדש ולבדוק את קישוריות ה-HTTPS לסביבת GitLab Self-Managed.

הערה: במדריך לא מוסבר איך לבצע בדיקות כדי לפרוס מופע של Gitlab Self-Managed

3. דרישות רשת

למטה מפורטות דרישות הרשת עבור רשת היצרן. הצרכן בשיעור Codelab הזה הוא מופע Looker PSC.

רכיבים	תיאור
VPC (looker-psc-demo)	מצב מותאם אישית של VPC
רשת משנה של NAT ב-PSC	מנות מרשת ה-VPC של הצרכן מתורגמות באמצעות NAT של המקור (SNAT), כך שכתובות ה-IP המקוריות של המקור מומרות לכתובות IP של המקור מרשת המשנה של ה-NAT ברשת ה-VPC של היצרן.
תת-רשת של כלל העברה של PSC	משמש להקצאת כתובת IP למאזן עומסים אזורי פנימי מסוג TCP Proxy
תת-רשת של PSC NEG	משמש להקצאת כתובת IP לקבוצת נקודות קצה ברשת
Proxy Only Subnet	לכל אחד מהפרוקסי של מאזן העומסים מוקצית כתובת IP פנימית. למנות שנשלחות מ-proxy למכונה וירטואלית או לנקודת קצה בקצה העורפי יש כתובת IP של מקור מרשת המשנה של ה-proxy בלבד.
NEG באינטרנט	משאב שמשמש להגדרת בק-אנד חיצוני למאזן העומסים, שמוגדר כ-FQDN שמציין את ה-FQDN של Gitlab Self-Managed on-premesis. ה-FQDN של האינטרנט מבצע חיפוש DNS בתוך ה-VPC לצורך רזולוציה.
שירות לקצה העורפי	שירות לקצה העורפי משמש כגשר בין מאזן העומסים לבין משאבי הקצה העורפי. במדריך, שירות הקצה העורפי משויך ל-Internet NEG.

הערה: בהגדרה שלנו, NEG לאינטרנט שהוגדר עם FQDN נפרס ב-VPC של הלקוח כדי לפתור את כתובת ה-IP של מופע GitLab Self-Managed שנמצא בפריסה מקומית. כברירת מחדל, ה-NEG של האינטרנט יבצע חיפוש DNS ל-FQDN שסופק. לכן, אם אפשר לפתור את ה-FQDN של מופע GitLab Self-Managed ממופע GCE, לא צריך לבצע פעולה נוספת. אם אי אפשר לפתור את ה-FQDN, תצטרכו לפרוס אזור פרטי של Cloud DNS יחד עם רשומת A של כתובת ה-IP של שרת Gitlab Self-Managed. במדריך הזה נגדיר אזור DNS פרטי עבור gitlabonprem.com ורשומת A שמטרגטת את השרת של Gitlab Self-Managed.

4. טופולוגיית Codelab

5. הגדרה ודרישות

הגדרת סביבה בקצב אישי

1. נכנסים ל-מסוף Google Cloud ויוצרים פרויקט חדש או משתמשים בפרויקט קיים. אם עדיין אין לכם חשבון Gmail או Google Workspace, אתם צריכים ליצור חשבון.

• שם הפרויקט הוא השם המוצג למשתתפים בפרויקט. זו מחרוזת תווים שלא נמצאת בשימוש ב-Google APIs. תמיד אפשר לעדכן את המיקום.
• מזהה הפרויקט הוא ייחודי לכל הפרויקטים ב-Google Cloud ואי אפשר לשנות אותו אחרי שהוא מוגדר. מסוף Cloud יוצר באופן אוטומטי מחרוזת ייחודית, ובדרך כלל לא צריך לדעת מה היא. ברוב ה-Codelabs, תצטרכו להפנות למזהה הפרויקט (בדרך כלל מסומן כ-PROJECT_ID). אם אתם לא אוהבים את המזהה שנוצר, אתם יכולים ליצור מזהה אקראי אחר. אפשר גם לנסות שם משתמש משלכם ולבדוק אם הוא זמין. אי אפשר לשנות את ההגדרה הזו אחרי השלב הזה, והיא נשארת לאורך הפרויקט.
• לידיעתכם, יש ערך שלישי, מספר פרויקט, שחלק מממשקי ה-API משתמשים בו. מידע נוסף על שלושת הערכים האלה מופיע במאמרי העזרה.

שימו לב: מזהה הפרויקט הוא ייחודי גלובלית, ואחרי שתבחרו אותו אף אחד אחר לא יוכל להשתמש בו. אתם המשתמשים היחידים במזהה הזה. גם אם פרויקט נמחק, אי אפשר להשתמש שוב במזהה שלו.

הערה: אם אתם משתמשים בחשבון Gmail, אתם יכולים להשאיר את המיקום שמוגדר כברירת מחדל לללא ארגון. אם אתם משתמשים בחשבון Google Workspace, אתם צריכים לבחור מיקום שמתאים לארגון שלכם.

2. בשלב הבא, תצטרכו להפעיל את החיוב במסוף Cloud כדי להשתמש במשאבי Cloud או בממשקי API של Cloud. השלמת ה-codelab הזה לא תעלה לכם הרבה, אם בכלל. כדי להשבית את המשאבים ולמנוע חיובים נוספים אחרי שתסיימו את המדריך הזה, תוכלו למחוק את המשאבים שיצרתם או למחוק את הפרויקט. משתמשים חדשים ב-Google Cloud זכאים לתוכנית תקופת ניסיון בחינם בשווי 300$.

מפעילים את Cloud Shell

אפשר להפעיל את Google Cloud מרחוק מהמחשב הנייד, אבל ב-Codelab הזה נשתמש ב-Google Cloud Shell, סביבת שורת פקודה שפועלת בענן.

ב-מסוף Google Cloud, לוחצים על סמל Cloud Shell בסרגל הכלים שבפינה הימנית העליונה:

הקצאת המשאבים והחיבור לסביבה יימשכו רק כמה רגעים. בסיום התהליך, אמור להופיע משהו כזה:

המכונה הווירטואלית הזו כוללת את כל הכלים שדרושים למפתחים. יש בה ספריית בית בנפח מתמיד של 5GB והיא פועלת ב-Google Cloud, מה שמשפר מאוד את הביצועים והאימות ברשת. אפשר לבצע את כל העבודה ב-codelab הזה בדפדפן. לא צריך להתקין שום דבר.

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

הפעלת ממשקי ה-API

ב-Cloud Shell, מוודאים שמזהה הפרויקט מוגדר:

gcloud config list project
gcloud config set project [YOUR-PROJECT-ID]
project=[YOUR-PROJECT-ID]
region=[YOUR-REGION]
echo $project
echo $region

מפעילים את כל השירותים הנדרשים:

gcloud services enable compute.googleapis.com

7. יצירת רשת VPC של ספק

רשת VPC

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

gcloud compute networks create looker-psc-demo --subnet-mode custom

יצירת תת-רשתות

רשת המשנה של PSC תשויך לקובץ המצורף של שירות PSC לצורך תרגום כתובות רשת (NAT).

ב-Cloud Shell, יוצרים את תת-הרשת של PSC NAT:

gcloud compute networks subnets create producer-psc-nat-subnet --network looker-psc-demo --range 172.16.10.0/28 --region $region --purpose=PRIVATE_SERVICE_CONNECT

ב-Cloud Shell, יוצרים את תת-הרשת של כלל העברת התנועה של היצרן:

gcloud compute networks subnets create producer-psc-fr-subnet --network looker-psc-demo --range 172.16.20.0/28 --region $region --enable-private-ip-google-access

ב-Cloud Shell, יוצרים את תת-הרשת של ה-proxy האזורי של היצרן בלבד:

gcloud compute networks subnets create $region-proxy-only-subnet \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=$region \
  --network=looker-psc-demo \
  --range=10.10.10.0/24

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

ב-Cloud Shell, שומרים כתובת IP פנימית למאזן העומסים:

gcloud compute addresses create internet-neg-lb-ip \
  --region=$region \
  --subnet=producer-psc-fr-subnet

ב-Cloud Shell, מציגים את כתובת ה-IP השמורה.

gcloud compute addresses describe internet-neg-lb-ip \
  --region=$region | grep -i address:

פלט לדוגמה:

user@cloudshell$ gcloud compute addresses describe internet-neg-lb-ip   --region=$region | grep -i address:
address: 172.16.20.2

הגדרת NEG באינטרנט

יוצרים קבוצת נקודות קצה ברשת האינטרנט ומגדירים את ‎–network-endpoint-type ל-internet-fqdn-port (שם המארח והיציאה שדרכם אפשר להגיע לבק-אנד החיצוני).

ב-Cloud Shell, יוצרים NEG לאינטרנט שמשמש לגישה למופע של Gitlab Self-Managed, ‏ gitlabonprem.com.

gcloud compute network-endpoint-groups create gitlab-self-managed-internet-neg \
    --network-endpoint-type=INTERNET_FQDN_PORT \
    --network=looker-psc-demo \
    --region=$region

הערה: כדי לתמוך ב-HTTPS, צריך לאמת את האישור באמצעות fqdn=gitlabonprem,port=443

ב-Cloud Shell, מעדכנים את ה-NEG של האינטרנט gitlab-self-managed-internet-neg עם ה-FQDN‏ gitlabonprem.com והיציאה 443.

gcloud compute network-endpoint-groups update gitlab-self-managed-internet-neg \
    --add-endpoint="fqdn=gitlabonprem.com,port=443" \
    --region=$region

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

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

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

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

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

8. יצירת שירות של ספק

יצירת רכיבים של מאזן עומסים

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

gcloud compute backend-services create producer-backend-svc  --protocol=tcp --region=$region --load-balancing-scheme=INTERNAL_MANAGED

gcloud compute backend-services add-backend producer-backend-svc --network-endpoint-group=gitlab-self-managed-internet-neg --network-endpoint-group-region=$region --region=$region

ב-Cloud Shell, יוצרים שרת proxy של TCP ליעד כדי לנתב בקשות לשירות הקצה העורפי:

gcloud compute target-tcp-proxies create producer-lb-tcp-proxy \
      --backend-service=producer-backend-svc  \
      --region=$region

בתחביר הבא, יוצרים כלל העברה (מאזן עומסים פנימי מסוג TCP Proxy).

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

gcloud compute forwarding-rules create producer-gitlab-self-managed-fr\
     --load-balancing-scheme=INTERNAL_MANAGED \
     --network-tier=PREMIUM \
     --network=looker-psc-demo \
     --subnet=producer-psc-fr-subnet \
     --address=internet-neg-lb-ip \
     --target-tcp-proxy=producer-lb-tcp-proxy \
     --target-tcp-proxy-region=$region \
     --region=$region \
     --ports=443

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

ב-Cloud Shell, יוצרים את קובץ Service Attachment‏, gitlab-self-managed-svc-attachment-https, עם אישור אוטומטי שמאפשר קישוריות של Looker Core לקובץ Service Attachment. אם רוצים לשלוט בגישה ל-service attachment, אפשר להשתמש באפשרות אישורים מפורשים.

gcloud compute service-attachments create gitlab-self-managed-svc-attachment-https --region=$region --producer-forwarding-rule=producer-gitlab-self-managed-fr --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=producer-psc-nat-subnet

לאחר מכן, צריך להשיג את Service Attachment שמופיע ב-URI של selfLink שמתחיל ב-projects ולרשום אותו כדי להגדיר את נקודת הקצה של PSC ב-Looker.

selfLink: projects/<your-project-id>/regions/<your-region>/serviceAttachments/gitlab-self-managed-svc-attachment-https

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

gcloud compute service-attachments describe gitlab-self-managed-svc-attachment-https --region=$region

דוגמה:

connectionPreference: ACCEPT_AUTOMATIC
creationTimestamp: '2025-03-04T18:55:42.254-08:00'
description: ''
enableProxyProtocol: false
fingerprint: MlY9GLLGsgE=
id: '9103522880241140673'
kind: compute#serviceAttachment
name: gitlab-self-managed-svc-attachment-https
natSubnets:
- https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/subnetworks/producer-psc-nat-subnet
pscServiceAttachmentId:
  high: '115404658846991336'
  low: '9103522880241140673'
reconcileConnections: false
region: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1
selfLink: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/serviceAttachments/gitlab-self-managed-svc-attachment-https
targetService: https://www.googleapis.com/compute/v1/projects/$projectid/regions/us-central1/forwardingRules/producer-gitlab-self-managed-fr

ב-Cloud Console, עוברים אל:

שירותי רשת ← Private Service Connect ← שירותים שפורסמו

9. יצירת חיבור לנקודת קצה של PSC ב-Looker

בקטע הבא, תשייכו את קובץ ה-Service Attachment של שירות הבעלים ל-PSC של Looker Core באמצעות השימוש בדגלים ‎–psc-service-attachment ב-Cloud Shell עבור דומיין יחיד.

הערה: בכל פעם שמריצים פקודת עדכון עם דגלים של ‎–psc-service-attachment, צריך לכלול את כל החיבורים שרוצים להפעיל, כולל חיבורים שכבר הופעלו בעבר. דוגמה זמינה במסמכי Looker PSC.

הערה: נדרש הדגל domain=gitlabonprem.com כדי ליצור חיבור HTTPS אל gitlabonprem.com

הערה: צריך להפעיל את Looker PSC Instance לפני שממשיכים.

ב-Cloud Shell, יוצרים את השיוך של ה-PSC על ידי עדכון הפרמטרים הבאים בהתאם לסביבה שלכם:

• INSTANCE_NAME: השם של המכונה של Looker (Google Cloud Core)‎.
• DOMAIN_1: gitlabonprem.com
• ‫SERVICE_ATTACHMENT_1: ‏ URI שצולם כשמתארים את קובץ השירות המצורף, gitlab-self-managed-svc-attachment-https.
• אזור: האזור שבו מתארח מופע Looker (Google Cloud Core).

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

gcloud looker instances update INSTANCE_NAME \
--psc-service-attachment  domain=DOMAIN_1,attachment=SERVICE_ATTACHMENT_URI_1 \
--region=REGION

דוגמה:

gcloud looker instances update looker-psc-instance \
--psc-service-attachment  domain=gitlabonprem.com,attachment=projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https \
--region=$region

ב-Cloud Shell, מוודאים ש-connectionStatus של serviceAttachments הוא ACCEPTED, ומעדכנים את INSTANCE_NAME של Looker PSC

gcloud looker instances describe [INSTANCE_NAME] --region=$region --format=json

דוגמה:

gcloud looker instances describe looker-psc-instance --region=$region --format=json

דוגמה:

{
  "adminSettings": {},
  "createTime": "2024-08-23T00:00:45.339063195Z",
  "customDomain": {
    "domain": "cosmopup.looker.com",
    "state": "AVAILABLE"
  },
  "encryptionConfig": {},
  "lookerVersion": "24.12.28",
  "name": "projects/$project/locations/$region/instances/looker-psc-instance",
  "platformEdition": "LOOKER_CORE_ENTERPRISE_ANNUAL",
  "pscConfig": {
    "allowedVpcs": [

    "projects/$project/global/networks/looker-psc-demo"
    ],
    "lookerServiceAttachmentUri": "projects/t7ec792caf2a609d1-tp/regions/$region/serviceAttachments/looker-psc-f51982e2-ac0d-48b1-91bb-88656971c183",
    "serviceAttachments": [
      {
        "connectionStatus": "ACCEPTED",
        "localFqdn": "gitlabonprem.com",
        "targetServiceAttachmentUri": "projects/$project/regions/$region/serviceAttachments/gitlab-self-managed-svc-attachment-https"
      }
    ]
  },
  "pscEnabled": true,
  "state": "ACTIVE",
  "updateTime": "2024-08-30T17:47:33.440271635Z"
}

אימות של נקודת הקצה של PSC ב-Cloud Console

אפשר לאמת את חיבור ה-PSC במסוף Cloud

ב-Cloud Console, עוברים אל:

‫Looker → מכונת Looker → פרטים

10. רזולוציית DNS

בקטע הבא, יוצרים מופע GCE ומאמתים את פתרון ה-DNS למופע Gitlab Self-Managed,‏ gitlabonprem.com, באמצעות ביצוע PING. כצפוי, הרזולוציה תיכשל ותדרוש אזור DNS פרטי עבור gitlabonprem.com.

11. יצירת מכונה ב-GCE

ב-Cloud Shell, יוצרים את מופע GCE שמשמש לאימות של פתרון ה-DNS.

gcloud compute instances create gce-dns-lookup \
    --project=$projectid \
    --machine-type=e2-micro \
    --image-family debian-11 \
    --no-address \
    --image-project debian-cloud \
    --zone us-central1-a \
    --subnet=producer-psc-fr-subnet

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

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

ממערכת ההפעלה, מבצעים PING אל gitlabonprem.com. הכשל צפוי.

ping gitlabonprem.com

דוגמה:

user@gce-dns-lookup:~$ ping gitlabonprem.com
ping: gitlabonprem.com: Name or service not known

יוצאים ממערכת ההפעלה וחוזרים לטרמינל של Cloud Shell.

exit

12. יצירת שרת DNS פרטי

ב-Cloud Shell, יוצרים את האזור הפרטי של Cloud DNS.

gcloud dns --project=$projectid managed-zones create gitlab-self-managed --description="" --dns-name="gitlabonprem.com." --visibility="private" --networks="https://compute.googleapis.com/compute/v1/projects/$projectid/global/networks/looker-psc-demo"

ב-Cloud Shell, יוצרים רשומת A שכוללת את כתובת ה-IP של מופע Gitlab Self-Managed, ‏ 192.168.10.4.

gcloud dns --project=$projectid record-sets create gitlabonprem.com. --zone="gitlab-self-managed" --type="A" --ttl="300" --rrdatas="192.168.10.4"

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

gcloud compute ssh gce-dns-lookup --project=$projectid --zone=us-central1-a --tunnel-through-iap

ממערכת ההפעלה, מבצעים PING ל-gitlabonprem.com, שמוביל ל-192.168.10.4.

ping gitlabonprem.com

דוגמה:

user@gce-dns-lookup:~$ ping gitlabonprem.com
PING gitlabonprem.com (192.168.10.4) 56(84) bytes of data

יוצאים ממערכת ההפעלה וחוזרים לטרמינל של Cloud Shell.

exit

13. Hybrid Connectivity

עכשיו אפשר לפתור את ה-FQDN gitlabonprem.com באמצעות כתובת ה-IP הפרטית שמתארחת בפריסה מקומית. לאחר מכן, צריך להגדיר רשת היברידית (למשל Interconnect, ‏ HA-VPN) בין ה-VPC של looker-psc-demo לבין הרשת המקומית כדי לאפשר קישוריות.

כדי ליצור קישוריות היברידית של NEG לשרת מקומי, צריך לבצע את השלבים הבאים:

• בחירת מוצרים של Network Connectivity | Google Cloud
• בארכיטקטורת רכזת וחישורים עם קישור בין רשתות VPC שכנות (peering), ה-NEG ההיברידי פרוס באותו VPC כמו Cloud Router (הרכזת).
• חשוב לוודא שחומות האש המקומיות מעודכנות כך שיכללו את טווח תת-הרשת של שרת ה-proxy בלבד, כי תת-הרשת הזו משמשת ככתובת ה-IP של המקור לתקשורת עם עומסי עבודה מקומיים.
• פרסום ניתוב של רשת המשנה של ה-proxy בלבד מ-Cloud Router כפרסום ניתוב בהתאמה אישית

14. בדיקת הקישוריות

בשלבים הבאים, תשתמשו ב-Looker Console כדי ליצור פרויקט לאימות קישוריות HTTPS אל gitlabonprem.com באמצעות התהליך שמפורט במאמר הגדרה ובדיקה של חיבור Git.

הערה: חשוב להגדיר את חיבור Git עם ה-FQDN המקומי שהוגדר כשמחילים את Service Attachment על Looker Core. אם לא משתמשים באותו FQDN מקומי בשלב של הגדרת git, תהיה שגיאה בחיבור.

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

מחיקת רכיבי מעבדה ממסוף Cloud Shell יחיד

gcloud compute service-attachments delete gitlab-self-managed-svc-attachment-https --region=$region -q

gcloud compute forwarding-rules delete producer-gitlab-self-managed-fr --region=$region -q

gcloud compute target-tcp-proxies delete producer-lb-tcp-proxy --region=$region -q

gcloud compute backend-services delete producer-backend-svc --region=$region -q

gcloud compute network-endpoint-groups delete gitlab-self-managed-internet-neg --region=$region -q

gcloud compute instances delete gce-dns-lookup --zone=us-central1-a -q

gcloud compute networks subnets delete producer-psc-fr-subnet producer-psc-nat-subnet $region-proxy-only-subnet --region=$region -q

gcloud dns --project=$projectid record-sets delete gitlabonprem.com. --zone="gitlab-sel
f-managed" --type="A"

gcloud dns --project=$projectid managed-zones delete gitlab-self-managed 

gcloud compute networks delete looker-psc-demo -q

16. מזל טוב

הגדרתם ואימתתם בהצלחה את הקישוריות למופע GitLab Self-Managed באמצעות Looker Console שמבוסס על Private Service Connect.

יצרתם את התשתית של בעל השירות, ולמדתם איך ליצור Internet NEG, שירות של בעל השירות ונקודת קצה (endpoint) של Looker PSC שמאפשרים קישוריות לשירות של בעל השירות.

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

מה השלב הבא?

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

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

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

• הגדרה ובדיקה של חיבור Git | ‏ Looker | ‏ Google Cloud
• סקירה כללית על Private Service Connect

מסמכי עזר

• הגדרת מאזן עומסי רשת פנימי אזורי לשרת proxy עם קצה עורפי חיצוני
• יצירת מופע של Private Service Connect ב-Looker (Google Cloud core)
• איך מפרסמים שירות באמצעות Private Service Connect