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

מזהה אזור

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

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

אישור

Go Java Node.js PHP Python Ruby .NET Custom

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

• ניתוב באמצעות כתובות URL
• ניתוב באמצעות קובץ dispatch
• ניתוב באמצעות Cloud Load Balancing

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

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

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

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

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

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

הערה: מומלץ להשתמש בפרוטוקול HTTPS כדי לשלוח בקשות לאפליקציה. בקשות HTTPS שנשלחות אל REGION_ID.r.appspot.com צריכות להשתמש במחרוזת -dot- כדי להפריד בין תת-דומיינים במקום .. אפשר להשתמש בסימון הפשוט של כתובת ה-URL . עם דומיינים מותאמים אישית משלכם ועם בקשות HTTP.

כתובות 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

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

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