Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

תחילת העבודה עם איזון עומסים ב-API Gateway

במדריך הזה נסביר איך ליצור מאזן עומסים גלובלי-חיצוני של אפליקציות כדי לנתב בקשות ל-API Gateway. תהליך ההגדרה זהה לשלבי ההגדרה של שילוב מאזן עומסים של אפליקציות (ALB) גלובלי חיצוני עם מוצרים אחרים בלי שרת (serverless), כמו Cloud Run, ‏ Cloud Run Functions ו-App Engine.

מאזן עומסים לא נדרש כדי ש-API Gateway יפעל, אבל הוא מאפשר לשער ליהנות מהיתרונות של מאזן עומסים. לדוגמה, שימוש במאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עם API Gateway מאפשר לכם:

שימוש בדומיינים מותאמים אישית.
שימוש ב-Google Cloud Armor כשירות אבטחת רשת.
ניהול יעיל של איזון עומסים בין שערים בכמה מיקומים.
הטמעה של ניהול מתקדם של תעבורת נתונים.

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

אם עדיין לא עשיתם זאת, הורידו והתקינו את Google Cloud CLI.
הורדת ה-CLI של gcloud
עדכון רכיבים של gcloud:
```
gcloud components update
```
כדי לפרוס שירות Cloud Run וליצור שער שמפנה לשירות הזה, פועלים לפי השלבים במדריך API Gateway Quickstart.
הגדרת ההרשאות
הוספת משאב של אישור SSL.

פריסת שירות Cloud Run ומופע API Gateway

במדריך הזה תפרסו שירות hello-world ב-Cloud Run, תיצרו שער שמנתב לשירות Cloud Run ותגדירו מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) כדי לנתב בקשות לדומיין מותאם אישית.

במדריך הזה נעשה שימוש ב-Cloud Run כשירות העורפי של API Gateway, אבל השלבים האלה רלוונטיים גם לכל שירות לקצה העורפי אחר ש-API Gateway תומך בו.

אחרי שתשלימו בהצלחה את ההפעלה המהירה של API Gateway, תהיה לכם כתובת URL של שער פרוס שמפנה לשירות Cloud Run.

הגדרת ההרשאות

במדריך הזה תיצרו קבוצה של נקודות קצה (endpoint) ברשת, ללא שרת (NEG) ותיצרו מאזן עומסים (LB) גלובלי חיצוני של אפליקציות בפרויקט Cloud. לשם כך נדרש תפקיד בעלים או עורך בפרויקט, או תפקידי ה-IAM הבאים ב-Compute Engine:

משימה	התפקיד הנדרש
יצירת מאזן עומסים ורכיבי רשת	אדמין רשתות
יצירה ושינוי של קבוצות NEG	Compute Instance Admin
יצירה ושינוי של אישורי SSL	Security Admin

יצירת משאב של אישור SSL

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

אישורים שמנוהלים על ידי Google. מומלץ להשתמש באישורים בניהול Google כי Google Cloud מקבלים, מנהלים ומחדשים את האישורים האלה באופן אוטומטי. כדי ליצור אישור שמנוהל על ידי Google, צריך דומיין ורשומות DNS של הדומיין הזה כדי שהאישור יוקצה. אם עדיין אין לכם דומיין, אתם יכולים לקבל אותו מ-Google Domains. בנוסף, תצטרכו לעדכן את רשומת ה-A ב-DNS של הדומיין כך שתפנה לכתובת ה-IP של מאזן העומסים שתיצור בשלב מאוחר יותר. הוראות מפורטות זמינות במאמר בנושא שימוש באישורים שמנוהלים על ידי Google.
אישורים בחתימה עצמית. אם אתם לא רוצים להגדיר דומיין בשלב הזה, אתם יכולים להשתמש באישור SSL בחתימה עצמית לצורך בדיקה.

המדריך הזה מניח שכבר יצרתם משאב של אישור SSL.

אם אתם רוצים לבדוק את התהליך הזה בלי ליצור משאב של אישור SSL (או דומיין, כפי שנדרש באישורים בניהול Google), אתם עדיין יכולים להשתמש בהוראות שבדף הזה כדי להגדיר איזון עומסים של HTTP.

יצירת מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)

יוצרים NEG ללא שרת עבור API Gateway.

קבוצה של נקודות קצה ברשת (NEG) מציינת קבוצה של נקודות קצה של בק-אנד למאזן עומסים. בלי שרת (serverless) הוא בק-אנד שמפנה לשירות כמו API Gateway, כפי שמוצג באיור הבא:

כדי ליצור NEG בלי שרת (serverless) עבור השער, מריצים את הפקודה הבאה, שבה:
- ‫SERVERLESS_NEG_NAME הוא השם של קבוצת ה-NEG ללא שרת שרוצים ליצור.
- ‫GATEWAY_ID מציין את שם השער.
- ‫REGION_ID הוא אזור הפריסה של ה-NEG ללא שרת (צריך להיות זהה לאזור השער).
```
gcloud beta compute network-endpoint-groups create SERVERLESS_NEG_NAME \
  --region=REGION_ID \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=GATEWAY_ID
```
לדוגמה:
```
gcloud beta compute network-endpoint-groups create api-gateway-serverless-neg \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway
```
יוצרים שירות קצה עורפי כדי להגדיר איך מאזן העומסים הגלובלי החיצוני של האפליקציות מבזר את תעבורת הנתונים.

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

כדי ליצור שירות לקצה העורפי, מריצים את הפקודה הבאה:
```
gcloud compute backend-services create BACKEND_SERVICE_NAME --global
```
כאשר BACKEND_SERVICE_NAME הוא השם של שירות ה-Backend החדש.

לדוגמה:
```
gcloud compute backend-services create api-gateway-backend-service --global
```
כדי להוסיף את ה-NEG בלי שרת (serverless) כקצה עורפי לשירות לקצה העורפי, מריצים את הפקודה הבאה, כאשר:
- ‫BACKEND_SERVICE_NAME הוא השם של שירות הקצה העורפי.
- ‫SERVERLESS_NEG_NAME הוא השם של קבוצת ה-NEG ללא שרתים שנוצרה בשלב הקודם.
- ‫REGION_ID הוא אזור הפריסה של ה-NEG ללא שרת (צריך להיות זהה לאזור השער).
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --global \
  --network-endpoint-group=SERVERLESS_NEG_NAME \
  --network-endpoint-group-region=REGION_ID
```
לדוגמה:
```
gcloud compute backend-services add-backend api-gateway-backend-service \
  --global \
  --network-endpoint-group=api-gateway-serverless-neg \
  --network-endpoint-group-region=us-central1
```
יוצרים מפת URL כדי לנתב בקשות נכנסות לשירות הקצה העורפי, כמו שמוצג באיור שלמטה:

כדי ליצור את מפת URL, מריצים את הפקודה הבאה, כאשר:
- ‫URL_MAP_NAME הוא השם של מפת URL שרוצים ליצור.
- ‫BACKEND_SERVICE_NAME הוא השם של שירות הקצה העורפי.
```
gcloud compute url-maps create URL_MAP_NAME \
  --default-service BACKEND_SERVICE_NAME
```
לדוגמה:
```
gcloud compute url-maps create api-gateway-url-map \
  --default-service api-gateway-backend-service
```
מפת ה-URL בדוגמה הזו מכוונת רק לשירות לקצה העורפי אחד שמייצג שער יחיד, ולכן לא נדרשים כללי מארח או התאמות נתיב. אם יש לכם יותר משירות קצה עורפי אחד, אתם יכולים להשתמש בכללי מארח כדי להפנות בקשות לשירותים שונים על סמך שם המארח. אפשר להשתמש ב-path matchers כדי להפנות בקשות לשירותים שונים על סמך נתיב הבקשה.

לדוגמה:
```
gcloud compute url-maps add-path-matcher api-gateway-url-map \
  --path-matcher-name=my-pm2  \
  --default-service=my-host-default-backend \
  --path-rules="/video=video-service,/video/*=video-service" \
  --new-hosts my-hosts.com
```
```
gcloud compute url-maps add-host-rule api-gateway-url-map \
  --hosts=my-app-domain \
  --path-matcher-name=my-app-path-matcher
```
מידע נוסף על כללי מארח ועל התאמה של נתיבים זמין במסמכי התיעוד בנושא מיפוי כתובות URL.
יוצרים אישור SSL לשרת ה-proxy של היעד, כמו שמוצג באיור הבא:

כדי ליצור מאזן עומסים גלובלי חיצוני של אפליקציות (ALB), נדרש משאב של אישור SSL לשרת ה-proxy של יעד HTTP(S). אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google. אם אתם בודקים את התהליך הזה בלי משאב של אישור SSL ורוצים להגדיר איזון עומסים של HTTP, אתם יכולים לדלג על השלב הזה.

כדי ליצור אישור שמנוהל על ידי Google, צריך שיהיה לכם דומיין. אם אין לכם דומיין, אתם יכולים להשתמש באישור SSL בחתימה עצמית לצורך בדיקה.

כדי ליצור משאב של אישור SSL בניהול Google:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --domains DOMAIN
```
כדי ליצור משאב של אישור SSL בניהול עצמי:
```
gcloud compute ssl-certificates create SSL_CERTIFICATE_NAME \
  --certificate CRT_FILE_PATH \
  --private-key KEY_FILE_PATH
```
יוצרים שרת proxy של HTTP(S) ליעד כדי לנתב בקשות למפת URL, כמו שמוצג באיור שלמטה:

כדי ליצור את שרת ה-proxy של היעד, משתמשים בפקודה הבאה, כאשר:
- ‫TARGET_HTTPS_PROXY_NAME הוא השם של שרת ה-proxy של HTTP(S) ביעד שרוצים ליצור.
- ‫URL_MAP_NAME הוא השם של מפת URL שנוצר בשלב הקודם.
- אופציונלי: ‫SSL_CERT_NAME הוא השם של אישור ה-SSL שנוצר.
```
gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
  --ssl-certificates=SSL_CERT_NAME \
  --url-map=URL_MAP_NAME
```
לדוגמה:
```
gcloud compute target-https-proxies create api-gateway-https-proxy \
  --ssl-certificates=hello-cert \
  --url-map=api-gateway-url-map
```
כמו שצוין קודם, אפשר ליצור מאזן עומסים ב-HTTP בלי ליצור משאב של אישור SSL. כדי לעשות זאת, משתמשים בפקודה הבאה:
```
gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
      --url-map=URL_MAP_NAME
```
לדוגמה:
```
gcloud compute target-http-proxies create api-gateway-http-proxy \
  --url-map=api-gateway-url-map
```
צריך לשנות את הפקודות הבאות לשרתי proxy של HTTP כדי להתאים אותן לדגל --target-http-proxy ול-TARGET_HTTP_PROXY_NAME עבור המקבילות שלהן ב-HTTP(S).
יוצרים כלל העברה כדי להפנות בקשות נכנסות לשרת ה-proxy, כמו שמוצג באיור הבא:

כדי ליצור את כלל ההעברה, משתמשים בפקודה הבאה, כאשר:
- ‫HTTPS_FORWARDING_RULE_NAME הוא שם הכלל שרוצים ליצור.
- ‫TARGET_HTTPS_PROXY_NAME הוא השם של שרת ה-proxy של יעד HTTP(S).
```
gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
  --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
  --global \
  --ports=443
```
לדוגמה:
```
gcloud compute forwarding-rules create my-fw \
  --target-https-proxy=api-gateway-https-proxy \
  --global \
  --ports=443
```

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

אם יש לכם דומיין בהתאמה אישית, אתם צריכים לבצע את השלב הזה כדי להגדיר את הגדרות ה-DNS של הדומיין כך שיפנו לכתובת ה-IP החדשה של השירות. המאפיין הזה נדרש גם אם יצרתם מאזן עומסים חיצוני גלובלי של אפליקציות (ALB) עם אישור בניהול Google (שדורש דומיין). מומלץ להקצות ולהשתמש בכתובת IP סטטית כשמשתמשים ב-DNS. ההוראות הספציפיות לשלב הזה תלויות בספק ה-DNS.

כדי לשלוח תעבורה למאזן העומסים, רשומת ה-DNS של הדומיין (במדריך הזה, my-app-domain) צריכה להפנות לכתובות ה-IP של מאזן העומסים.

כדי למצוא את כתובת ה-IP של כלל ההעברה הגלובלי, משתמשים בפקודה הבאה:
```
gcloud compute forwarding-rules list
```
מעדכנים את רשומת ה-DNS A או רשומת AAAA של הדומיין כך שתפנה לכתובת ה-IP של מאזן העומסים, כדי שתעבורת הנתונים שנשלחת לכתובת ה-URL הקיימת של הדומיין המותאם אישית תנותב דרך מאזן העומסים. יכול להיות שיחלפו כמה שניות או כמה שעות עד שהשינוי הזה יתעדכן בשרת ה-DNS.
כדי לוודא שהשער מקבל תנועה, אפשר להשתמש ב-curl או להיכנס לכתובת ה-URL בדפדפן. לדוגמה: https://my-app-domain

אחרי הבדיקה, אמורה להופיע התגובה שנוצרה על ידי שירות Cloud Run. לדוגמה, זה יכול להיות דף HTML עם הכיתוב Hello World או תגובה צפויה אחרת שנוצרה ישירות על ידי שירות לקצה העורפי. כלומר, הבקשה עוברת דרך מאזן העומסים, והשירות לקצה העורפי מורה למאזן העומסים לשלוח אותה לשער.

בדיקת ההגדרה של מאזן העומסים

אחרי שמגדירים את מאזן העומסים, אפשר להתחיל לשלוח תנועה לכתובת ה-IP של כלל ההעברה.

כדי למצוא את כתובת ה-IP של כלל ההעברה הגלובלי, משתמשים בפקודה הבאה:

gcloud compute forwarding-rules list

משתמשים בפקודה curl כדי לבדוק את התגובה לכתובות URL שונות של השירותים. לדוגמה:

curl https://HOST_URL/hello/

curl https://HOST_URL

אתם יכולים להשתמש במסוף Cloud של API Gateway כדי לוודא שהבקשות מגיעות לשירותים הנכונים.

כל הכבוד! הגדרתם בהצלחה מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) עבור API Gateway^PREVIEW.

הסרת המשאבים

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

מחיקת הפרויקט

מריצים את הפקודה הבאה ומחליפים את PROJECT_ID במזהה הפרויקט:

gcloud projects delete PROJECT_ID

מחיקת משאבים בודדים

מוחקים כל רכיב במאזן העומסים:

מחיקת כללי ההעברה:

gcloud compute forwarding-rules delete HTTPS_FORWARDING_RULE_NAME --global

מחיקת כתובות IP חיצוניות גלובליות:
```
gcloud compute addresses delete IP_ADDRESSES --global
```

מחיקת שרת proxy ליעד:

gcloud compute target-https-proxies delete TARGET_HTTP_PROXY_NAME

מחיקת מפת URL:

gcloud compute url-maps delete URL_MAP_NAME

מוחקים את שירותי ה-Backend:

gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

(אופציונלי) מוחקים את אישור ה-SSL:

gcloud compute ssl-certificates delete SSL_CERTIFICATE_NAME

מוחקים את ה-NEG ללא שרת:

gcloud compute network-endpoint-groups delete SERVERLESS_NEG_NAME --region=REGION