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

מזהה אזור

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

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

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

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

ניתוב באמצעות כתובות 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

כדי לאחזר מזהי משאבים באופן פרוגרמטי, אפשר לעיין ב-methods של 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

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

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

יצירת קובץ שיגור

כדי ליצור קובץ שיגור:

  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/ לקצה קדמי לנייד, ולנתב בקשות worker כמו 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. כך לא תצטרכו לנהל אישורים נפרדים לאפליקציות ללא שרת.

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

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

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

מדדים לא עקביים כשמשתמשים ב-Cloud Load Balancing בסביבה גמישה של App Engine

במרכז הבקרה של הסביבה הגמישה של App Engine מוצגים כל המדדים רק לבקשות שמופנות דרך קצה עורפי מנוהל של סביבה גמישה. אם אתם משתמשים בסביבה הגמישה של App Engine עם Cloud Load Balancing, מדדים מסוימים בטבלת המדדים של App Engine מדווחים כמדדים מהטבלה loadbalancing. למידע נוסף, אפשר לעיין במאמר בנושא רישום ביומן ומעקב אחרי איזון עומסים מסוג HTTP(S).

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