הגדרה של מאזן עומסים של אפליקציות (ALB) קלאסי עם Cloud Run,‏ App Engine או פונקציות Cloud Run

בדף הזה מוסבר איך ליצור מאזן עומסים חיצוני של אפליקציות (ALB) כדי לנתב בקשות אל עורפי חזית בלי שרת (serverless). המונח 'בלי שרת' מתייחס כאן למוצרי המחשוב הבאים בלי שרת:

• App Engine
• פונקציות Cloud Run
• Cloud Run

קבוצות של נקודות קצה ברשת (NEGs) בלי שרת (serverless) מאפשרות להשתמש בGoogle Cloud אפליקציות בלי שרת (serverless) עם מאזני עומסים חיצוניים של אפליקציות (ALB). אחרי שמגדירים מאזן עומסים עם קצה עורפי של NEG בלי שרת (serverless), בקשות למאזן העומסים מנותבות לקצה העורפי של האפליקציה בלי שרת (serverless).

מידע נוסף על קבוצות NEGs ללא שרת זמין במאמר סקירה כללית על קבוצות NEGs ללא שרת.

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

1. פריסת פונקציות של App Engine או Cloud Run, או שירות של Cloud Run.
2. אם עדיין לא עשיתם זאת, מתקינים את Google Cloud CLI.
3. הגדרת ההרשאות
4. הוספת משאב של אישור SSL.

פריסת שירות של App Engine, פונקציות Cloud Run או שירות Cloud Run

ההוראות בדף הזה מניחות שכבר יש לכם שירות פעיל של Cloud Run, פונקציות Cloud Run או App Engine.

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

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

Cloud Run

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

אם כבר העליתם קונטיינר לדוגמה ל-Container Registry, תוכלו לעיין במאמר מדריך למתחילים: פריסת קונטיינר לדוגמה שנבנה מראש.

פונקציות Cloud Run

מדריך למתחילים: פונקציות Cloud Run ב-Python

App Engine

כדאי לעיין במדריכים למתחילים הבאים בנושא App Engine ל-Python 3:

• סביבה רגילה
• סביבה גמישה

התקנת Google Cloud CLI

מתקינים את Google Cloud CLI. למידע על הכלי, כולל הסברים והוראות התקנה, אפשר לעיין במאמר סקירה כללית על gcloud.

אם לא הפעלתם את ה-CLI של gcloud בעבר, קודם מריצים את הפקודה gcloud init כדי לאתחל את ספריית gcloud.

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

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

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

אופציונלי: שימוש בכתובות BYOIP

באמצעות העברת כתובות IP משלכם (BYOIP), אתם יכולים לייבא כתובות ציבוריות משלכם אלGoogle Cloud כדי להשתמש בכתובות עם משאבי Google Cloud . לדוגמה, אם מייבאים כתובות IPv4 משלכם, אפשר להקצות אחת מהן לכלל ההעברה כשמגדירים את מאזן העומסים. כשפועלים לפי ההוראות במסמך הזה כדי ליצור את מאזן העומסים, צריך לספק את כתובת ה-IP של BYOIP בתור כתובת ה-IP.

מידע נוסף על השימוש ב-BYOIP זמין במאמר בנושא העברת כתובות IP משלכם.

שמירת כתובת IP חיצונית

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

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

המסוף

1. נכנסים לדף External IP addresses במסוף Google Cloud .

   נכנסים אל External IP addresses

2. לוחצים על שמירת כתובת IP חיצונית סטטית.

3. בשדה Name (שם), מזינים example-ip.

4. בקטע Network service tier, בוחרים באפשרות Premium.

5. בשביל IP version, בוחרים IPv4.

6. בשדה Type (סוג), בוחרים באפשרות Global (גלובלי).

7. לוחצים על Reserve.

gcloud

gcloud compute addresses create EXAMPLE_IP \
    --network-tier=PREMIUM \
    --ip-version=IPV4 \
    --global

שימו לב לכתובת ה-IPv4 שהוקצתה:

gcloud compute addresses describe EXAMPLE_IP \
    --format="get(address)" \
    --global

מחליפים את EXAMPLE_IP בשם של כתובת ה-IP.

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

כדי ליצור את מאזן העומסים, צריך משאב של אישור SSL שאפשר לצרף לפרוקסי היעד. משאב אישור ה-SSL יכול להיות מיפוי אישורים או אישור SSL של Compute Engine (אישור קלאסי).

מפת אישורים

אפשר ליצור מיפוי אישורים כמו שמתואר באחד מהמסמכים הבאים:

• פריסת אישור גלובלי שמנוהל על ידי Google עם הרשאה למאזן עומסים
• פריסת אישור גלובלי שמנוהל על ידי Google באמצעות הרשאת DNS
• פריסת אישור גלובלי שמנוהל על ידי Google באמצעות Certificate Authority Service
• פריסת אישור גלובלי בניהול עצמי

אישור SSL ב-Compute Engine

במאזן עומסים ב-HTTPS, יוצרים משאב אישור SSL ב-Compute Engine, כמו שמתואר באחד מהמסמכים הבאים:

• שימוש באישורי SSL בניהול עצמי
• שימוש באישור SSL שמנוהל על ידי Google

מומלץ להשתמש באישור שמנוהל על ידי Google.

אזהרה: אל תשתמשו באישור בחתימה עצמית למטרות ייצור.

יצירת מאזן העומסים

בתרשים הבא, מאזן העומסים משתמש בקצה עורפי מסוג NEG ללא שרת כדי להפנות בקשות לשירות Cloud Run ללא שרת. בדוגמה הזו, השתמשנו בהפעלה מהירה של Python ב-Cloud Run כדי לפרוס שירות Cloud Run.

‫

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

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

המסוף

בחירת סוג מאזן העומסים

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף Load balancing

2. לוחצים על Create load balancer (יצירת מאזן עומסים).
3. בקטע Type of load balancer, בוחרים באפשרות Application Load Balancer (HTTP/HTTPS) ולוחצים על Next.
4. בקטע Public facing or internal (פנימי או גלוי לכולם), בוחרים באפשרות Public facing (external) (גלוי לכולם – חיצוני) ולוחצים על Next (הבא).
5. אם רוצים פריסה גלובלית או פריסה באזור יחיד, בוחרים באפשרות הכי מתאים לעומסי עבודה גלובליים ולוחצים על הבא.
6. בקטע Load balancer generation (דור מאזן העומסים), בוחרים באפשרות Classic Application Load Balancer (מאזן עומסים קלאסי לאפליקציות) ולוחצים על Next (הבא).
7. לוחצים על Configure (הגדרה).

הגדרה בסיסית

1. בשדה של שם מאזן העומסים, מזינים serverless-lb.
2. כדי להמשיך, צריך להשאיר את החלון פתוח.

הגדרות הקצה הקדמי

1. לוחצים על Frontend configuration.
2. בשדה Name (שם), מזינים שם.
3. כדי ליצור מאזן עומסים ב-HTTPS, צריך שיהיה לכם אישור SSL (gcloud compute ssl-certificates list).

   מומלץ להשתמש באישור ש-Google מנהלת, כמו שמתואר למעלה.

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

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

מאפיין (property)	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTPS
Network Service Tier	‫Premium
גרסת ה-IP	IPv4
כתובת IP	example-ip
יציאה	443
אישור	בקטע בחירת מאגר אישורים, בוחרים באפשרות שימוש במיפוי אישורים או שימוש באישורים קלאסיים. בהתאם לבחירה שלכם, בוחרים מפת אישורים או אישור קלאסי.
אופציונלי: הפעלת הפניה אוטומטית מ-HTTP ל-HTTPS	משתמשים בתיבת הסימון הזו כדי להפעיל הפניות אוטומטיות מ-HTTP ל-HTTPS. אם מסמנים את תיבת הסימון הזו, נוצר מאזן עומסים חלקי נוסף של HTTP שמשתמש באותה כתובת IP כמו מאזן העומסים של HTTPS, ומפנה בקשות HTTP לחלק הקדמי של מאזן העומסים של HTTPS. אפשר לסמן את התיבה הזו רק אם בוחרים בפרוטוקול HTTPS ומשתמשים בכתובת IP שמורה.

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

כדי ליצור מאזן עומסים ב-HTTP, מוודאים שהאפשרויות הבאות מוגדרות עם הערכים האלה:

מאפיין (property)	ערך (מקלידים ערך או בוחרים אפשרות כמפורט)
פרוטוקול	HTTP
Network Service Tier	פרימיום
גרסת ה-IP	IPv4
כתובת IP	example-ip
יציאה	80

4. לוחצים על סיום.

הגדרת הקצה העורפי

1. לוחצים על Backend configuration.
2. ברשימה Backend services & backend buckets לוחצים על Create a backend service.
3. בשדה Name (שם), מזינים שם.
4. בקטע Backend type (סוג קצה עורפי), בוחרים באפשרות Serverless network endpoint group (קבוצה של נקודות קצה ברשת ללא שרת).
5. משאירים את Protocol ללא שינוי. המערכת מתעלמת מהפרמטר הזה.
6. בקטע Backends, באפשרות New backend, בוחרים באפשרות Create Serverless network endpoint group.
7. בשדה Name (שם), מזינים שם.
8. בקטע Region, בוחרים באפשרות us-central1 ואז באפשרות Cloud Run.
9. לוחצים על בחירת שם שירות.
10. ברשימה Service, בוחרים את שירות Cloud Run שרוצים ליצור עבורו מאזן עומסים.
11. לוחצים על יצירה.
12. בקטע New backend (שרת קצה עורפי חדש), לוחצים על Done (סיום).
13. לוחצים על יצירה.

כללי ניתוב

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

1. לוחצים על Host and path rules (כללים לגבי מארח ונתיב).

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

בדיקת ההגדרות

1. לוחצים על Review and finalize.
2. בודקים את כל ההגדרות.
3. אופציונלי: לוחצים על Equivalent Code (קוד מקביל) כדי לראות את בקשת ה-API בארכיטקטורת REST שתשמש ליצירת מאזן העומסים.
4. לוחצים על יצירה.
5. מחכים שמאזן העומסים ייווצר.
6. לוחצים על השם של מאזן העומסים (serverless-lb).
7. שימו לב לכתובת ה-IP של מאזן העומסים לקראת המשימה הבאה. היא נקראת IP_ADDRESS.

כשמשתמשים במסוף Google Cloud כדי ליצור מאזן עומסים מסוג HTTP(S) עם קצה עורפי של NEG בלי שרת (serverless), הרישום ביומן מופעל כברירת מחדל. אפשר להשתמש בפקודה gcloud compute backend-services update כדי להשבית את הרישום ביומן, אם צריך.

gcloud

1. יוצרים NEG ללא שרת בשביל האפליקציה ללא שרת.

   כדי ליצור NEG ללא שרת עם שירות Cloud Run:

      gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME \
          --region=us-central1 \
          --network-endpoint-type=serverless  \
          --cloud-run-service=CLOUD_RUN_SERVICE_NAME
      

   אפשרויות נוספות זמינות במדריך העזר של gcloud בנושא gcloud compute network-endpoint-groups create.
2. יוצרים שירות לקצה העורפי.

      gcloud compute backend-services create BACKEND_SERVICE_NAME \
          --load-balancing-scheme=EXTERNAL \
          --global
      

3. מוסיפים את ה-NEG בלי שרת (serverless) כקצה עורפי לשירות לקצה העורפי:

      gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
          --global \
          --network-endpoint-group=SERVERLESS_NEG_NAME \
          --network-endpoint-group-region=us-central1
      

4. יוצרים מפת URL כדי לנתב בקשות נכנסות לשירות הקצה העורפי:

      gcloud compute url-maps create URL_MAP_NAME \
          --default-service BACKEND_SERVICE_NAME
      

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

5. מבצעים את השלב הזה רק אם רוצים ליצור מאזן עומסים ב-HTTPS. הדרישה הזו לא חלה על מאזני עומסים מסוג HTTP.
   כדי ליצור מאזן עומסים ב-HTTPS, צריך משאב של אישור SSL לשימוש בשרת ה-proxy של יעד HTTPS. אפשר ליצור משאב של אישור SSL באמצעות אישור SSL בניהול Google או אישור SSL בניהול עצמי. מומלץ להשתמש באישורים שמנוהלים על ידי Google כי Google Cloud היא משיגה, מנהלת ומחדשת את האישורים האלה באופן אוטומטי.
   
   כדי ליצור אישור שמנוהל על ידי 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
      

6. יוצרים שרת proxy של HTTP(S) ליעד כדי להפנות בקשות למפת URL.

   כדי ליצור מאזן עומסים מסוג HTTP, יוצרים proxy ליעד HTTP:

      gcloud compute target-http-proxies create TARGET_HTTP_PROXY_NAME \
          --url-map=URL_MAP_NAME
      

   למאזן עומסים מסוג HTTPS, יוצרים שרת proxy ליעד מסוג HTTPS. הפרוקסי הוא החלק במאזן העומסים שמכיל את אישור ה-SSL לאיזון עומסים של HTTPS, ולכן בשלב הזה טוענים גם את האישור.

      gcloud compute target-https-proxies create TARGET_HTTPS_PROXY_NAME \
         --ssl-certificates=SSL_CERTIFICATE_NAME \
         --url-map=URL_MAP_NAME
      

7. יוצרים כלל העברה כדי להפנות בקשות נכנסות לשרת ה-proxy.
   
   

   עבור מאזן עומסים מסוג HTTP:

      gcloud compute forwarding-rules create HTTP_FORWARDING_RULE_NAME \
          --load-balancing-scheme=EXTERNAL \
          --network-tier=PREMIUM \
          --address=EXAMPLE_IP \
          --target-http-proxy=TARGET_HTTP_PROXY_NAME \
          --global \
          --ports=80
      

   במאזן עומסים מסוג HTTPS:

      gcloud compute forwarding-rules create HTTPS_FORWARDING_RULE_NAME \
          --load-balancing-scheme=EXTERNAL \
          --network-tier=PREMIUM \
          --address=EXAMPLE_IP \
          --target-https-proxy=TARGET_HTTPS_PROXY_NAME \
          --global \
          --ports=443
      

חיבור הדומיין למאזן העומסים

אחרי שיוצרים את מאזן העומסים, רושמים את כתובת ה-IP שמשויכת למאזן העומסים – לדוגמה, 30.90.80.100. כדי להפנות את הדומיין למאזן העומסים, צריך ליצור רשומת A באמצעות שירות הרישום של הדומיין. אם הוספתם מספר דומיינים לאישור ה-SSL, צריך להוסיף רשומת A לכל אחד מהם, כשכולם מפנים לכתובת ה-IP של מאזן העומסים. לדוגמה, כדי ליצור רשומות A בשביל www.example.com ובשביל example.com, משתמשים בפקודה הבאה:

NAME                  TYPE     DATA
www                   A        30.90.80.100
@                     A        30.90.80.100

אם אתם משתמשים ב-Cloud DNS כספק ה-DNS, תוכלו לעיין במאמר בנושא הוספה, שינוי ומחיקה של רשומות.

בדיקת מאזן העומסים

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

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף Load balancing

2. לוחצים על מאזן העומסים שיצרתם.

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

4. במקרה של מאזן עומסים מסוג HTTP, אפשר לבדוק את מאזן העומסים באמצעות דפדפן אינטרנט. לשם כך, עוברים אל http://IP_ADDRESS. מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים. המערכת אמורה להפנות אתכם לדף הבית של שירות helloworld.
   

5. במקרה של מאזן עומסים ב-HTTPS, אפשר לבדוק את מאזן העומסים באמצעות דפדפן אינטרנט על ידי מעבר אל https://IP_ADDRESS. מחליפים את IP_ADDRESS בכתובת ה-IP של מאזן העומסים. המערכת אמורה להפנות אתכם לדף הבית של שירות helloworld.
   אם זה לא עובד ואתם משתמשים באישור שמנוהל על ידי Google, צריך לוודא שהסטטוס של משאב האישור הוא ACTIVE. מידע נוסף זמין במאמר סטטוס של משאב אישור SSL בניהול Google.
   אם השתמשתם באישור בחתימה עצמית לבדיקה, תוצג בדפדפן אזהרה. צריך להנחות את הדפדפן באופן מפורש לקבל אישור בחתימה עצמית. לוחצים על האזהרה כדי לראות את הדף בפועל.

הגבלת תעבורה נכנסת בנקודת קצה (endpoint) שמוגדרת כברירת מחדל

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

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

• הגדרת תעבורת כניסה לרשת כ'איזון עומסים פנימי ו-Cloud Load Balancing' ב-App Engine
• הגדרת גישה לרשת לערך 'פנימית ו-Cloud Load Balancing' עבור פונקציות Cloud Run
• הגדרת תעבורת כניסה לרשת לערך 'פנימית ו-Cloud Load Balancing' ב-Cloud Run

בנוסף, אפשר להשבית את כתובת ה-URL שמוגדרת כברירת מחדל ב-Cloud Run.

אפשרויות הגדרה נוספות

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

הגדרת איזון עומסים במספר אזורים

הערה: עבור NEGs בלי שרת (serverless), איזון עומסים במספר אזורים נתמך רק אם ה-NEG בלי שרת (serverless) מצביע על שירות Cloud Run או על פונקציות Cloud Run. אי אפשר להשתמש ב-App Engine לאיזון עומסים במספר אזורים עם זיהוי חריגים, כי אי אפשר לפרוס את App Engine של פרויקט במספר אזורים.

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

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

כדי להגדיר שרתים בכמה אזורים, צריך להשתמש ברמת הפרימיום של הרשת כדי לוודא שכל הפריסות האזוריות של Cloud Run תואמות ומוכנות להעברת תנועה מכל אזור.

כדי להגדיר מאזן עומסים במספר אזורים:

1. מגדירים שני שירותי Cloud Run באזורים שונים. נניח שפרסתם שני שירותים של Cloud Run: אחד באזור בארה"ב ואחד באזור באירופה.
2. יוצרים מאזן עומסים חיצוני של אפליקציות (ALB) עם ההגדרה הבאה:
   1. מגדירים שירות עורפי גלובלי עם שני NEGs ללא שרת:
      1. יוצרים את ה-NEG הראשון באותו אזור שבו פועל שירות Cloud Run שנפרס בארה"ב.
      2. יוצרים את ה-NEG השני באותו אזור שבו פועל שירות Cloud Run שנפרס באירופה.
   2. מגדירים את ההגדרות של הקצה הקדמי עם מסלול שירות הרשת Premium.

ההגדרה שמתקבלת מוצגת בתרשים הבא.

ניתוב לאפליקציות ללא שרתים במספר אזורים

הקטע הזה מבוסס על הגדרת איזון העומסים שמתוארת בהמשך הדף, שבה יצרתם NEG בלי שרת (serverless) באזור us-central1 שמפנה לשירות Cloud Run באותו אזור. בנוסף, מניחים שאתם יוצרים שירות Cloud Run שני באזור europe-west1. ה-NEG השני ללא שרת שתיצרו יצביע על שירות Cloud Run הזה באזור europe-west1.

בדוגמה הזו, תבצעו את השלבים הבאים:

1. יוצרים NEG שני ללא שרת באזור europe-west1.
2. מצרפים את ה-NEG השני בלי שרת (serverless) לשירות לקצה העורפי.

כדי להוסיף NEG שני ללא שרת לשירות קיים של קצה עורפי, פועלים לפי השלבים הבאים.

המסוף

1. נכנסים לדף Load balancing במסוף Google Cloud .

   כניסה לדף Load balancing

2. לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות לקצה העורפי שלו.

3. בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה).

4. בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.

5. בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.

6. בקטע Backends (שרתי קצה עורפי), לוחצים על Add a backend (הוספת שרת קצה עורפי).

7. ברשימה Serverless network endpoint groups (קבוצות של נקודות קצה ברשת ללא שרתים), בוחרים באפשרות Create Serverless network endpoint group (יצירת קבוצה של נקודות קצה ברשת ללא שרתים).

8. מזינים שם ל-NEG ללא שרת.

9. בשדה אזור, בוחרים באפשרות europe-west1.

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

    1. בוחרים באפשרות בחירת שירות.
    2. ברשימה Service, בוחרים את שירות Cloud Run שרוצים ליצור עבורו מאזן עומסים.

11. לוחצים על יצירה.

12. בדף New backend (מערכת עורפית חדשה), לוחצים על Done (סיום).

13. לוחצים על Save.

14. כדי לעדכן את שירות לקצה העורפי, לוחצים על עדכון.

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

gcloud

1. יוצרים עוד NEG ללא שרת באותו אזור שבו נפרס שירות Cloud Run.

   gcloud compute network-endpoint-groups create SERVERLESS_NEG_NAME_2 \
     --region=europe-west1 \
     --network-endpoint-type=SERVERLESS \
     --cloud-run-service=CLOUD_RUN_SERVICE_2
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת
   • ‫CLOUD_RUN_SERVICE_2: השם של שירות Cloud Run

2. מוסיפים את ה-NEG השני בלי שרת (serverless) כקצה עורפי לשירות לקצה העורפי.

   gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
     --global \
     --network-endpoint-group=SERVERLESS_NEG_NAME_2 \
     --network-endpoint-group-region=europe-west1
   

   מחליפים את מה שכתוב בשדות הבאים:

   • ‫BACKEND_SERVICE_NAME: השם של שירות ה-Backend
   • ‫SERVERLESS_NEG_NAME_2: השם של ה-NEG השני ללא שרת

שימוש במינוי דחיפה מאומת ל-Pub/Sub עם פריסה של Cloud Run במספר אזורים

בבקשות push מאומתות, Cloud Run מצפה לשדה קהל ספציפי לאזור כברירת מחדל. במקרה של פריסת Cloud Run מרובת אזורים, אם בקשת ה-push מנותבת לשירות Cloud Run באזור אחר, האימות של אסימון ה-JWT נכשל בגלל חוסר התאמה של קהל היעד.

כדי לעקוף את ההגבלה הספציפית לאזור הזה:

1. הגדרת קהל בהתאמה אישית שזהה לפריסות של שירותים באזורים שונים.
2. מגדירים את הודעות ה-push ב-Pub/Sub כך שישתמשו בקהל בהתאמה אישית כקהל באסימון JWT.

הגדרת ניתוב אזורי

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

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

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

כדי להגדיר מאזן עומסים עם ניתוב אזורי:

1. מגדירים שני שירותי Cloud Run באזורים שונים. נניח שפרסתם שני שירותי Cloud Run: ‏hello-world-eu באזור באירופה ו-hello-world-us באזור בארה"ב.
2. יוצרים מאזן עומסים חיצוני של אפליקציות (ALB) עם ההגדרה הבאה:
   1. הגדרת שירות backend עם NEG ללא שרת באירופה. צריך ליצור את ה-NEG בלי שרת (serverless) באותו אזור שבו נפרס שירות Cloud Run באירופה.
   2. מגדירים שירות קצה עורפי שני עם NEG אחר בלי שרת (serverless) בארה"ב. צריך ליצור את ה-NEG בלי שרת באותו אזור שבו נפרס שירות Cloud Run בארה"ב.
   3. מגדירים את מפת ה-URL עם כללי המארח והנתיב המתאימים, כך שקבוצה אחת של כתובות URL תנותב לשירות לקצה העורפי באירופה, וכל הבקשות ינותבו לשירות לקצה העורפי בארה"ב.
   4. מגדירים את הקצה הקדמי עם מסלול שירות הרשת Premium.

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

ניתוב אזורי לאפליקציות בלי שרת (serverless) ללא יתירות כשל

שימוש במסכת כתובת URL

כשיוצרים NEG בלי שרת (serverless), במקום לבחור שירות ספציפי של Cloud Run, אפשר להשתמש במסכת כתובות URL כדי להפנות לכמה שירותים שפועלים באותו דומיין. מסכת כתובת URL היא תבנית של סכמת כתובת ה-URL. ה-NEG בלי שרת (serverless) ישתמש בתבנית הזו כדי לחלץ את שם השירות מכתובת ה-URL של הבקשה הנכנסת ולמפות את הבקשה לשירות המתאים.

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

אם עדיין לא עשיתם את זה, מומלץ לקרוא את המאמר סקירה כללית על קבוצות של נקודות קצה ללא שרתים: מסיכות של כתובות URL.

יצירת מסכת כתובת URL

כדי ליצור מסכת כתובת URL למאזן העומסים, מתחילים עם כתובת ה-URL של השירות. בדוגמה הזו נשתמש באפליקציה לדוגמה ללא שרת שפועלת בכתובת https://example.com/login. זו כתובת ה-URL שבה loginהשירות של האפליקציה יוצג.

1. מסירים את http או https מכתובת ה-URL. נותרו לך example.com/login.
2. מחליפים את שם השירות בפלייסלודר של מסכת כתובת ה-URL.
   1. ‫Cloud Run: מחליפים את שם השירות של Cloud Run במחזיק המקום <service>. אם שירות Cloud Run משויך לתג, מחליפים את שם התג במחזיק המקום <tag>. בדוגמה הזו, מסכת כתובת ה-URL שנשארת היא example.com/<service>.
   2. פונקציות Cloud Run: מחליפים את שם הפונקציה במחזיק המקום <function>. בדוגמה הזו, מסכת כתובת ה-URL שנשארת היא example.com/<function>.
   3. ‫App Engine: מחליפים את שם השירות ב-placeholder‏ <service>. אם לשירות יש גרסה שמשויכת אליו, מחליפים את הגרסה ב-placeholder <version>. בדוגמה הזו, מסכת כתובת ה-URL שנשארת היא example.com/<service>.
   4. ‫API Gateway: מחליפים את שם השער ב-placeholder‏ <gateway>. בדוגמה הזו, מסכת כתובת ה-URL שנשארת היא example.com/<gateway>.

3. (Optional) אם אפשר לחלץ את שם השירות (או הפונקציה, הגרסה או התג) מחלק הנתיב של כתובת ה-URL, אפשר להשמיט את הדומיין. החלק של הנתיב במסכת כתובת ה-URL מובחן על ידי התו הראשון /. אם התו / לא מופיע במסכת כתובת ה-URL, המסכה מייצגת רק את המארח. לכן, בדוגמה הזו, אפשר לצמצם את מסכת כתובת ה-URL ל-/<service>,‏ /<gateway> או /<function>.

   באופן דומה, אם אפשר לחלץ את שם השירות מחלק המארח של כתובת ה-URL, אפשר להשמיט את הנתיב לחלוטין ממסכת כתובת ה-URL.

   אפשר גם להשמיט רכיבים של מארח או של תת-דומיין שמגיעים לפני ה-placeholder הראשון, וגם רכיבים של נתיב שמגיעים אחרי ה-placeholder האחרון. במקרים כאלה, הפלייסהולדר [מציין המיקום] מתעד את המידע הנדרש לגבי הרכיב.

הנה עוד כמה דוגמאות שממחישות את הכללים האלה:

Cloud Run

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי Cloud Run ממופים לדומיין הזה באמצעות מאזן עומסים של אפליקציות (ALB) חיצוני.

שירות, שם התג	כתובת ה-URL של הדומיין המותאם אישית	אנונימיזציה של כתובת URL
service: login	https://login-home.example.com/web	<service>-home.example.com
service: login	https://example.com/login/web	example.com/<service> או /<service>
service: login, tag: test	https://test.login.example.com/web	<tag>.<service>.example.com
service: login, tag: test	https://example.com/home/login/test	example.com/home/<service>/<tag> or /home/<service>/<tag>
service: login, tag: test	https://test.example.com/home/login/web	‪<tag>.example.com/home/<service>

פונקציות Cloud Run

בטבלה הזו מניחים שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי הפונקציות של Cloud Run ממופים לדומיין הזה.

שם הפונקציה	כתובת ה-URL של הדומיין המותאם אישית	אנונימיזציה של כתובת URL
login	https://example.com/login	/<function>
login	https://example.com/home/login	‎/home/<function>‎
login	https://login.example.com	<function>.example.com
login	https://login.home.example.com	<function>.home.example.com

App Engine

הטבלה הזו מניחה שיש לכם דומיין מותאם אישית בשם example.com וכל שירותי App Engine ממופים לדומיין הזה.

שם השירות, הגרסה	כתובת ה-URL של הדומיין המותאם אישית	אנונימיזציה של כתובת URL
service: login	https://login.example.com/web	<service>.example.com
service: login	https://example.com/home/login/web	example.com/home/<service>, or /home/<service>
service: login, version: test	https://test.example.com/login/web	<version>.example.com/<service>
service: login, version: test	https://example.com/login/test	example.com/<service>/<version>

API Gateway

בטבלה הזו מניחים שיש לכם דומיין בהתאמה אישית בשם example.com וכל השירותים של API Gateway ממופים לדומיין הזה.

שם השער	כתובת URL של דומיין מותאם אישית ב-API Gateway(גרסת Preview)	אנונימיזציה של כתובת URL
login	https://example.com/login	/<gateway>
login	https://example.com/home/login	‎/home/<gateway>‎
login	https://login.example.com	<gateway>.example.com
login	https://login.home.example.com	<gateway>.home.example.com

יצירת NEG ללא שרת עם מסכת כתובת URL

המסוף

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

אם יש לכם מאזן עומסים קיים, אתם יכולים לערוך את הגדרות ה-backend ולהגדיר את ה-NEG בלי שרת כך שיפנה למסכת כתובות URL במקום לשירות ספציפי.

כדי להוסיף NEG ללא שרתים שמבוסס על מסיכת כתובת URL לשירות קיים של קצה עורפי:

1. נכנסים לדף Load balancing במסוף Google Cloud .
   כניסה לדף Load balancing
2. לוחצים על השם של מאזן העומסים שרוצים לערוך את שירות לקצה העורפי שלו.
3. בדף Load balancer details (פרטי איזון העומסים), לוחצים על Edit (עריכה) .
4. בדף Edit global external Application Load Balancer, לוחצים על Backend configuration.
5. בדף Backend configuration (הגדרות ה-Backend), לוחצים על Edit (עריכה) בשירות לקצה העורפי שרוצים לשנות.
6. לוחצים על הוספת קצה עורפי.
7. בוחרים באפשרות יצירת קבוצה של נקודות קצה ברשת ללא שרת.
   1. בשדה Name (שם), מזינים helloworld-serverless-neg.
   2. בקטע Region, בוחרים באפשרות us-central1.
   3. בקטע סוג קבוצת נקודות קצה ברשת ללא שרת, בוחרים את הפלטפורמה שבה נוצרו האפליקציות (או השירותים או הפונקציות) ללא שרת.
      1. בוחרים באפשרות שימוש במסכת כתובת URL.
      2. מזינים מסכת כתובות URL. הוראות ליצירת מסכת כתובת URL מופיעות במאמר יצירת מסכת כתובת URL.
      3. לוחצים על יצירה.
8. בקטע New backend (שרת קצה עורפי חדש), לוחצים על Done (סיום).
9. לוחצים על עדכון.

‫gcloud: Cloud Run

כדי ליצור NEG בלי שרת (serverless) עם מסכת כתובות URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-url-mask="example.com/<service>"

‫gcloud: פונקציות Cloud Run

כדי ליצור NEG בלי שרת (serverless) עם מסכת כתובות URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
 --region=us-central1 \
 --network-endpoint-type=serverless \
 --cloud-function-url-mask="example.com/<service>"

‫gcloud: App Engine

כדי ליצור Serverless NEG עם מסכת כתובת URL לדוגמה של example.com/<service>:

gcloud compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --app-engine-url-mask="example.com/<service>"

‫gcloud: API Gateway

כדי ליצור Serverless NEG עם מסכת כתובת URL לדוגמה של example.com/<gateway>:

gcloud beta compute network-endpoint-groups create helloworld-neg-mask \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --serverless-deployment-platform=apigateway.googleapis.com \
  --serverless-deployment-resource=my-gateway \
  --serverless-deployment-url-mask="example.com/<gateway>"

כדי להבין איך מאזן העומסים מטפל בבעיות שקשורות לחוסר התאמה של מסכות כתובות URL, אפשר לעיין במאמר פתרון בעיות שקשורות ל-NEGs ללא שרתים.

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

אם אפליקציות ה-Serverless שלכם ממופות לדומיינים מותאמים אישית, יכול להיות שתרצו לעדכן את רשומות ה-DNS כך שהתנועה שנשלחת לכתובות ה-URL הקיימות של Cloud Run, פונקציות Cloud Run,‏ API Gateway או דומיין מותאם אישית של App Engine תנותב דרך מאזן העומסים.

לדוגמה, אם יש לכם דומיין מותאם אישית בשם example.com וכל השירותים של Cloud Run ממופים לדומיין הזה, צריך לעדכן את רשומת ה-DNS של example.com כך שתפנה לכתובת ה-IP של מאזן העומסים.

לפני שמעדכנים את רשומות ה-DNS, אפשר לבדוק את ההגדרה באופן מקומי על ידי אילוץ פענוח DNS מקומי של הדומיין המותאם אישית לכתובת ה-IP של מאזן העומסים. כדי לבצע בדיקה מקומית, אפשר לשנות את הקובץ /etc/hosts/ במחשב המקומי כך שיפנה example.com לכתובת ה-IP של איזון העומסים, או להשתמש בדגל curl --resolve כדי לאלץ את curl להשתמש בכתובת ה-IP של איזון העומסים עבור הבקשה.

כשרשומת ה-DNS של example.com מפוענחת לכתובת ה-IP של מאזן העומסים HTTP(S), הבקשות שנשלחות אל example.com מתחילות להיות מנותבות דרך מאזן העומסים. מאזן העומסים מעביר אותן לשירות הרלוונטי לקצה העורפי בהתאם למפת ה-URL שלו. בנוסף, אם שירות לקצה העורפי מוגדר עם מסכת כתובת URL, ה-NEG בלי שרת (serverless) משתמש במסכה כדי לנתב את הבקשה לשירות המתאים ב-Cloud Run, בפונקציות Cloud Run, ב-API Gateway או ב-App Engine.

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

הפעלת Cloud CDN

הפעלת Cloud CDN בשירות Cloud Run מאפשרת לכם לבצע אופטימיזציה של העברת התוכן על ידי שמירת התוכן במטמון קרוב למשתמשים.

אפשר להפעיל את Cloud CDN בשירותי קצה עורפי שמשמשים מאזני עומסים גלובליים חיצוניים של אפליקציות באמצעות הפקודה gcloud compute backend-services update.

gcloud compute backend-services update helloworld-backend-service 

    --enable-cdn 

    --global

‫Cloud CDN נתמך בשירותי קצה עורפיים עם Cloud Run, פונקציות Cloud Run,‏ API Gateway וקצה עורפי של App Engine.

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

הערה: אי אפשר להשתמש ב-IAP עם Cloud CDN.

אפשר להגדיר את IAP כך שיהיה מופעל או מושבת (ברירת מחדל). אם האפשרות הזו מופעלת, צריך לספק ערכים למאפיינים oauth2-client-id ו-oauth2-client-secret.

כדי להפעיל את IAP, מעדכנים את שירות לקצה העורפי כך שיכלול את הדגל --iap=enabled עם הערכים oauth2-client-id ו-oauth2-client-secret.

gcloud compute backend-services update BACKEND_SERVICE_NAME \
    --iap=enabled,oauth2-client-id=ID,oauth2-client-secret=SECRET \
    --global

אפשר גם להפעיל את IAP למשאב Compute Engine באמצעות מסוף Google Cloud ,‏ ה-CLI של gcloud או API.

הפעלת Google Cloud Armor

‫Cloud Armor הוא מוצר אבטחה שמספק הגנה מפני התקפות מניעת שירות מבוזרות (DDoS) לכל מאזני העומסים של פרוקסי GCLB. בנוסף, Cloud Armor מספק מדיניות אבטחה שניתנת להגדרה לשירותים שאליהם ניגשים דרך מאזן עומסים חיצוני של אפליקציות (ALB). מידע על כללי מדיניות האבטחה של Cloud Armor למאזני עומסים חיצוניים באפליקציות זמין במאמר סקירה כללית על כללי מדיניות האבטחה של Cloud Armor.

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

1. כדי לבטל את ההצטרפות למדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות None ברשימה Cloud Armor backend security policy (מדיניות אבטחה של Cloud Armor לשרת עורפי).
2. כדי להגדיר את מדיניות האבטחה שמוגדרת כברירת מחדל ב-Cloud Armor, בוחרים באפשרות Default security policy (מדיניות האבטחה שמוגדרת כברירת מחדל) ברשימה Cloud Armor backend security policy (מדיניות האבטחה של העורף ב-Cloud Armor).
3. בשדה Policy name, מאשרים את השם שנוצר באופן אוטומטי או מזינים שם למדיניות האבטחה.
4. בשדה Request count (מספר הבקשות), מאשרים את מספר הבקשות שמוגדר כברירת מחדל או מזינים מספר שלם בין 1 ל-10,000.
5. בשדה Interval, בוחרים מרווח זמן.
6. בשדה Enforce on key (החלת האכיפה על מפתח), בוחרים באחד מהערכים הבאים: All (הכול), IP address (כתובת IP) או X-Forwarded-For IP address (כתובת IP של X-Forwarded-For). מידע נוסף על האפשרויות האלה זמין במאמר בנושא זיהוי לקוחות להגבלת קצב.

הפעלת רישום ביומן ומעקב

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

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

מחיקה של NEG ללא שרת

אי אפשר למחוק קבוצת נקודות קצה ברשת אם היא מצורפת לשירות קצה עורפי. לפני שמוחקים NEG, מוודאים שהוא מנותק משירות לקצה העורפי.

המסוף

1. כדי לוודא שקבוצת ה-NEG בלי שרת (serverless) שרוצים למחוק לא נמצאת כרגע בשימוש על ידי אף שירות לקצה העורפי, עוברים לכרטיסייה Backend services בתפריט Load balancing advanced menu.
   עוברים לכרטיסייה Backend services
2. אם ה-NEG ללא שרת נמצא כרגע בשימוש:
   1. לוחצים על השם של שירות הקצה העורפי באמצעות ה-NEG ללא שרת.
   2. לוחצים על Edit ‏.
   3. ברשימה Backends (עורפי קצה), לוחצים על כדי להסיר את עורף הקצה של ה-NEG ללא שרת משירות עורף הקצה.
   4. לוחצים על Save.
3. נכנסים לדף Network endpoint group במסוף Google Cloud .
   לדף Network Endpoint Group
4. מסמנים את התיבה שלצד ה-NEG ללא שרת שרוצים למחוק.
5. לוחצים על Delete.
6. כדי לאשר, לוחצים שוב על מחיקה.

gcloud

כדי להסיר NEG בלי שרת (serverless) משירות לקצה העורפי, צריך לציין את האזור שבו נוצר ה-NEG. צריך לציין גם את האפשרות --global flag כי helloworld-backend-service הוא משאב גלובלי.

gcloud compute backend-services remove-backend helloworld-backend-service \
    --network-endpoint-group=helloworld-serverless-neg \
    --network-endpoint-group-region=us-central1 \
    --global

כדי למחוק את ה-NEG בלי שרת (serverless):

gcloud compute network-endpoint-groups delete helloworld-serverless-neg \
    --region=us-central1

המאמרים הבאים

• שימוש ברישום ביומן ובמעקב
• פתרון בעיות ב-NEGs ללא שרת
• ניקוי ההגדרות של מאזן העומסים
• שימוש במודול Terraform למאזן עומסים חיצוני מסוג HTTPS עם קצה עורפי של Cloud Run