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

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

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

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

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

  1. אם עדיין לא עשיתם זאת, הורידו והתקינו את Google Cloud CLI.

    הורדת ה-CLI של gcloud

  2. מעדכנים את הרכיבים של ה-CLI של gcloud:

    gcloud components update

  3. פועלים לפי המדריך לתחילת העבודה עם API Gateway כדי לפרוס שירות Cloud Run וליצור שער שמפנה לשירות הזה.

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

  5. הוספת משאב של אישור 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) גלובלי חיצוני של אפליקציות בפרויקט בענן. לשם כך נדרש תפקיד של בעלים או עורך בפרויקט, או תפקידי ה-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)

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

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

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

    כדי ליצור 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

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

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

    קבוצה של נקודות קצה ברשת בלי שרת (serverless) שהוגדרה כבק-אנד לשירות לקצה העורפי

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

    gcloud compute backend-services create BACKEND_SERVICE_NAME --global

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

    לדוגמה:

    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

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

    ניתוב תנועה באמצעות מפת 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 בדוגמה הזו מכוונת רק לשירות קצה עורפי אחד שמייצג שער יחיד, ולכן לא נדרשים כללי מארח או התאמות נתיבים. אם יש לכם יותר משירות קצה עורפי אחד, אתם יכולים להשתמש בכללי מארח כדי להפנות בקשות לשירותים שונים על סמך שם המארח. אפשר להשתמש בבודקי התאמה של נתיבים כדי להפנות בקשות לשירותים שונים על סמך נתיב הבקשה.

    לדוגמה:

    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.

  4. יוצרים אישור SSL לשרת proxy לחלוקת העומס של היעד, כמו שמוצג באיור הבא:

    אישור SSL שמוקצה לשרת ה-proxy של היעד לניתוב מאובטח

    כדי ליצור מאזן עומסים גלובלי חיצוני של אפליקציות, נדרש משאב של אישור 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

  5. יוצרים שרת proxy יעד מסוג HTTP(S) כדי להפנות בקשות למפת כתובות ה-URL, כמו שמוצג באיור הבא:

    שרת proxy לחלוקת העומס שמקבל בקשות ומעביר אותן למפת 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).

  6. יוצרים כלל העברה כדי להפנות בקשות נכנסות לשרת ה-proxy, כמו שמוצג באיור הבא:

    כלל העברה שמנתב תעבורת נתונים נכנסת לשרת 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.

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

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

    gcloud compute forwarding-rules list

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

  3. כדי לוודא שהשער מקבל תנועה, אפשר לבדוק את זה באמצעות curl או על ידי מעבר לכתובת ה-URL בדפדפן. לדוגמה: none 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 GatewayPREVIEW.

הסרת המשאבים

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

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

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

gcloud projects delete PROJECT_ID

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

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

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

    gcloud compute forwarding-rules delete HTTPS_FORWARDING_RULE_NAME --global

  2. מחיקת כתובות IP חיצוניות גלובליות:

    gcloud compute addresses delete IP_ADDRESSES --global

  3. מוחקים את שרת ה-proxy של היעד:

    gcloud compute target-https-proxies delete TARGET_HTTP_PROXY_NAME

  4. מחיקת מפת URL:

    gcloud compute url-maps delete URL_MAP_NAME

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

    gcloud compute backend-services delete BACKEND_SERVICE_NAME --global

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

    gcloud compute ssl-certificates delete SSL_CERTIFICATE_NAME

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

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