איך הבקשות מנותבות

מזהה אזור

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, REGION_ID.r נכלל בכתובות URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

מידע נוסף על מזהי אזורים

בדף הזה מוסבר איך בקשות HTTP ממשתמשים מגיעות לגרסה המתאימה של שירות. אפשר לנתב בקשות בדרכים הבאות:

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

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

ניתוב באמצעות כתובות URL

אחרי שהאפליקציה פועלת ב-App Engine, אפשר להשתמש בכתובת ה-URL הבאה כדי לשלוח בקשות HTTP לאפליקציה:

https://PROJECT_ID.REGION_ID.r.appspot.com

כאשר PROJECT_ID הוא המזהה של Google Cloud הפרויקט שמכיל את האפליקציה.

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

כתובות URL של שירותים וגרסאות

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

כתובות ה-URL של שירותים וגרסאות ספציפיים הן בפורמט הבא:

VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com

אפשר להשמיט את VERSION-dot- אם לא צריך לטרגט גרסה ספציפית.

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

המסוף

במסוף Google Cloud אפשר לראות את הדפים המתאימים: Instances,‏ Services ו-Versions.

gcloud

מריצים את הפקודה gcloud app instances list כדי להציג את מזהי המשאבים בפרויקט מסוים Google Cloud .

API

כדי לאחזר מזהי משאבים באופן פרוגרמטי, אפשר לעיין בשיטות list ב-Admin API.

כתובות URL לדוגמה

הנה כמה דוגמאות לכתובות URL של App Engine, שבהן מוצג גם הדומיין appspot.com ש-App Engine מקצה לאפליקציה וגם דומיין מותאם אישית שאפשר להגדיר לאפליקציה.

  • הבקשה נשלחת למופע זמין של שירות default:
    
https://PROJECT_ID.REGION_ID.r.appspot.com
https://CUSTOM_DOMAIN

    הבקשות מתקבלות בכל גרסה שמוגדרת לתנועה בשירות default.

  • שליחת בקשה למופע זמין של שירות ספציפי:
    
https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://SERVICE_ID.CUSTOM_DOMAIN

    בקשות מתקבלות בכל גרסה שמוגדרת לתנועה בשירות המטרה. אם השירות שאליו מכוונים לא קיים, הבקשה עוברת ניתוב רך.

  • שליחת בקשה למופע זמין של גרסה ספציפית ב-
    שירות default:
    
https://VERSION_ID-dot-default-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.CUSTOM_DOMAIN

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

ניתוב רך

אם בקשה תואמת לחלק PROJECT_ID.REGION_ID.r.appspot.com של שם המארח, אבל כוללת שם של שירות, גרסה או מופע שלא קיימים, הבקשה מנותבת לשירות default. ניתוב רך לא חל על דומיינים מותאמים אישית. בקשות לדומיינים כאלה יחזירו קוד סטטוס HTTP 404 אם שם המארח לא תקין.

ניתוב מטורגט

דפוסי כתובות ה-URL הבאים מגיעים ליעד שלהם, אם הם קיימים. בקשות שלא עוברות דרך Cloud Load Balancing אף פעם לא נחסמות ולא מנותבות מחדש על ידי התבניות שהגדרתם בקובץ dispatch:

  • שליחת הבקשה למופע זמין של שירות ספציפי וגרסה ספציפית: 

    
https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://VERSION_ID.SERVICE_ID.PROJECT_ID.CUSTOM_DOMAIN

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

    שליחת בקשה לשירות ולגרסה ספציפיים בתוך מופע ספציפי: 

    https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
https://INSTANCE_ID.VERSION_ID.SERVICE_ID.CUSTOM_DOMAIN

ניתוב באמצעות קובץ dispatch

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

יצירת קובץ dispatch

כדי ליצור קובץ dispatch:

  1. יוצרים קובץ בשם dispatch.yaml בשורש של ספריית הפרויקט או בשורש של ספריית השירות default.

  2. מגדירים את כללי הניתוב בקובץ כמו שמתואר במאמר בנושא dispatch.yaml.

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

  • אפשר להגדיר עד 20 כללי ניתוב. כל כלל חייב להכיל את הרכיבים url ו-service.
  • הכללים צריכים להשתמש בתבניות של כתובות URL מסוג HTTP שכוללות את הסימון . להפרדה בין תתי-דומיינים. אין תמיכה בכתובות URL שמוגדרות עם הסימון HTTPS ‏ "-dot-".
  • הכללים חלים גם על כתובות ה-URL שמוגדרות בקובץ cron.yaml.

לדוגמה, אפשר ליצור קובץ dispatch כדי להפנות בקשות לנייד כמו https://simple-sample.uc.r.appspot.com/mobile/ לקצה קדמי לנייד, ולהפנות בקשות של עובדים כמו https://simple-sample.uc.r.appspot.com/work/ לבק-אנד סטטי:

dispatch:
  # Send all mobile traffic to the mobile frontend.
  - url: "*/mobile/*"
    service: mobile-frontend

  # Send all work to the one static backend.
  - url: "*/work/*"
    service: static-backend

פריסת קובץ ה-dispatch

כדי לפרוס את קובץ dispatch באמצעות gcloud, מריצים את הפקודה הבאה:

gcloud app deploy dispatch.yaml

ניתוב באמצעות Cloud Load Balancing

‫Cloud Load Balancing הוא מוצר נפרד שמאפשר הגדרות מתקדמות של רשת לכל האפליקציות שפועלות ב- Google Cloud.

כשאיזון עומסים ב-HTTP(S) מופעל באפליקציות בלי שרת (serverless), אפשר:

  • מגדירים את האפליקציה ללא שרת כך שתפעל מכתובת IP ייעודית מסוג IPv4 או IPv6 שלא משותפת עם שירותים אחרים.

  • אפשר לעשות שימוש חוזר באישורי ה-SSL ובמפתחות הפרטיים שבהם אתם משתמשים ב-Compute Engine, ב-Google Kubernetes Engine וב-Cloud Storage. כך לא צריך לנהל אישורים נפרדים לאפליקציות בלי שרת (serverless).

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

שימו לב לנקודות הבאות:

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

הסבר על מזהה האזור בכתובות URL

‫REGION_ID הוא קוד מקוצר ש-Google מקצה על סמך האזור שבוחרים כשיוצרים את האפליקציה. הקוד לא תואם למדינה או למחוז, למרות שחלק ממזהי האזורים עשויים להיראות דומים לקודים נפוצים של מדינות ומחוזות. באפליקציות שנוצרו אחרי פברואר 2020, REGION_ID.r נכלל בכתובות URL של App Engine. באפליקציות קיימות שנוצרו לפני התאריך הזה, מזהה האזור הוא אופציונלי בכתובת ה-URL.

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

המסוף

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

כל כתובות ה-URL האלה כוללות את מזהה האזור.

gcloud

כשפורסים אפליקציה או שירות, הפקודה gcloud app deploy מציגה את כתובת ה-URL אחרי שהפריסה מסתיימת בהצלחה. כתובת ה-URL הזו כוללת את מזהה האזור.

כדי לראות את כתובת ה-URL של שירות שכבר נפרס:

  1. מזינים את הפקודה gcloud app versions list כדי להציג את הגרסאות של שירות ספציפי. לדוגמה, כדי להציג את הגרסאות של שירות ברירת המחדל, מזינים gcloud app versions list --service=default.

  2. מזינים את הפקודה gcloud app versions describe. הפלט של הפקודה הזו כולל את כתובת ה-URL של הגרסה עם מזהה האזור של האפליקציה. לדוגמה, כדי לתאר את גרסה 20191023t101741 של שירות ברירת המחדל, מזינים את הערך gcloud app versions describe 20191023t101741 --service=default

שם הדומיין כלול בנתוני הבקשה

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