Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

מידע על Codelab זה

41 דקות

העדכון האחרון: 2 באפריל 2025

נכתב על ידי Deepak Michael

1. מבוא

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

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

איור 1.

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

איור 2.

מה תלמדו

דרישות הרשת
יצירת שירות הפקה ב-Private Service Connect
יצירת נקודת קצה של Private Service Connect ב-Looker
חיבור למכונה של GitLab בניהול עצמי

מה צריך להכין

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

2. מה תפַתחו

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

יצירת נקודת קצה מסוג PSC ב-Looker שמשויכת לקובץ המצורף של שירות ההפקה
שימוש במסוף Looker כדי ליצור פרויקט חדש ולבדוק את קישוריות ה-HTTPS לסביבה של GitLab בניהול עצמי.

3. דרישות הרשת

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

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

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

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

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

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

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

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

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

הפעלת Cloud Shell

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

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

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

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

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 את תת-הרשת של NAT ב-PSC:

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 באינטרנט

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

ב-Cloud Shell, יוצרים NEG לאינטרנט שמשמש לגישה למכונה של Gitlab בניהול עצמי, 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

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

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

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, יוצרים את הצירוף לשירות, gitlab-self-managed-svc-attachment-https, עם אישור אוטומטי שמאפשר ל-Looker Core להתחבר לצירוף לשירות. אם רוצים לשלוט בגישה לקובץ המצורף לשירות, אפשר להשתמש באפשרות אישורים מפורשים.

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, עוברים אל:

Network Services‏ → Private Service Connect‏ → Published Services

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

בקטע הבא נסביר איך לשייך את הצירוף של שירותי הבעלים ל-PSC של Looker Core באמצעות הדגלים ‎-psc-service-attachment ב-Cloud Shell לדומיין יחיד.

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

INSTANCE_NAME: השם של המכונה של Looker (Google Cloud core).
DOMAIN_1: gitlabonprem.com
SERVICE_ATTACHMENT_1: מזהה URI שסומן בתיאור של Service Attachment, ‏ gitlab-self-managed-svc-attachment-https.
REGION: האזור שבו מתארחת המכונה של 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 של PSC ב-Looker.

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

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

במסוף Cloud, עוברים אל:

Looker → מכונה של Looker → פרטים

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

בקטע הבא תיצורו מכונה של GCE ותבצעו בדיקת PING כדי לאמת את פתרון ה-DNS למכונה של Gitlab בניהול עצמי, gitlabonprem.com. כצפוי, הרזולוציה תיכשל ותידרש תחום 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 DNS Private Zone ב-Cloud Shell.

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, 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, שמתקבלת אליו כתובת ה-IP 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 שכנות, ה-NEG המעורב פורס באותו VPC שבו נמצא Cloud Router (רכז)
מוודאים שחומות האש המקומיות מעודכנות כך שיתאימו לטווח של תת-הרשת של שרת ה-proxy בלבד, כי תת-הרשת הזו משמשת ככתובת ה-IP של המקור לתקשורת עם עומסי העבודה המקומיים.
פרסום תת-הרשת לשרתי proxy בלבד מ-Cloud Router כמודעת מסלול בהתאמה אישית

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

בשלבים הבאים נעזרים ב-Looker Console כדי ליצור פרויקט לאימות קישוריות HTTPS אל gitlabonprem.com, לפי התהליך שמתואר במאמר הגדרה ובדיקה של חיבור 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 באמצעות Looker Console שמופעל על ידי Private Service Connect.

יצרתם את התשתית של הבעלים של השירות, למדתם איך ליצור NEG באינטרנט, שירות של בעלים של שירות ונקודת קצה מסוג PSC של Looker שמאפשרות קישוריות לשירות של בעלים של שירות.

Looker PSC Southbound HTTPS Internet NEG Gitlab Self-Managed

1. מבוא

מה תלמדו

מה צריך להכין

2. מה תפַתחו

3. דרישות הרשת

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

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

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

הפעלת Cloud Shell

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

הפעלת ממשקי API

7. יצירת רשת VPC של יוצר

רשת VPC

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

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

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

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

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

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

יצירת צירוף לשירות

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

אימות נקודת הקצה של PSC במסוף Cloud

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

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

12. יצירת תחום DNS פרטי

13. Hybrid Connectivity

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

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

16. מזל טוב

מה השלב הבא?

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

מסמכי עזר