סקירה כללית על מפות של כתובות URL

Google Cloud מאזני עומסים של אפליקציות ו-Cloud Service Mesh משתמשים במשאב הגדרה Google Cloudבשם מפת URL כדי לנתב בקשות HTTP(S) לשירותי קצה עורפי או לקטגוריות קצה עורפי.

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

  • בקשות ל-https://example.com/video מועברות לשירות קצה עורפי אחד.
  • בקשות ל-https://example.com/audio מועברות לשירות קצה עורפי אחר.
  • בקשות ל-https://example.com/images מועברות לקטגוריית קצה עורפי של Cloud Storage.
  • בקשות לכל שילוב אחר של מארח ונתיב מועברות לשירות ברירת מחדל לקצה העורפי.

מפות URL משמשות במוצרים הבאים של Google Cloud :

יש שני סוגים של משאבים למפות URL: גלובליים ואזוריים.

  • urlMaps גלובליים משמשים במאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), במאזני עומסים קלאסיים של אפליקציות (ALB), במאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים וב-Cloud Service Mesh.

  • regionUrlMaps משמשים במאזני עומסים חיצוניים אזוריים של אפליקציות (ALB), במאזני עומסים פנימיים אזוריים של אפליקציות (ALB) וב-Cloud Service Mesh.

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

מוצר סכמת איזון עומסים סוג המשאב של מפת URL יעדים נתמכים
מאזן עומסים גלובלי חיצוני של אפליקציות (ALB) EXTERNAL_MANAGED עולמי שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים קלאסי של אפליקציות (ALB) EXTERNAL עולמי שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים חיצוני אזורי של אפליקציות (ALB) EXTERNAL_MANAGED אזורי שירותים לקצה העורפי, קטגוריות קצה עורפי
מאזן עומסים פנימי של אפליקציות (ALB) באזורים שונים INTERNAL_MANAGED עולמי שירותים לקצה העורפי, קטגוריות לקצה העורפי
מאזן עומסים פנימי אזורי של אפליקציות (ALB) INTERNAL_MANAGED אזורי שירותים לקצה העורפי, קטגוריות קצה עורפי
Cloud Service Mesh INTERNAL_SELF_MANAGED עולמי שירותים לקצה העורפי
Cloud Service Mesh INTERNAL_SELF_MANAGED אזורי שירותים לקצה העורפי

לא כל התכונות של מפת URL זמינות לכל המוצרים. מפות URL שמשמשות עם מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB), מאזני עומסים אזוריים חיצוניים של אפליקציות (ALB), מאזני עומסים פנימיים של אפליקציות (ALB) ו-Cloud Service Mesh תומכות גם בכמה תכונות מתקדמות לניהול תעבורה. למידע נוסף על ההבדלים האלה, קראו את המאמר השוואה בין התכונות של מאזני העומסים: ניתוב וניהול תעבורת נתונים. בנוסף, מפות URL אזוריות יכולות להיות משאב שמיועד כשירות באפליקציות של App Hub.

איך פועל מיפוי כתובות URL

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

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

ב-Cloud Service Mesh, היעדים האפשריים הם:

בנוסף, מאזני עומסים של אפליקציות תומכים באפשרויות הבאות:

לדוגמה, נניח שהגדרתם את ההגדרה הבאה:

  • כתובת IP אחת:
    • כל הבקשות לארגון שלכם מגיעות לאותה כתובת IP ולאותו מאזן עומסים.
    • התעבורה מופנית לשירותי קצה עורפיים שונים על סמך כתובת ה-URL של הבקשה.
  • שני דומיינים:
    • ‫example.net מארח סרטוני הדרכה.
    • example.org מארחת את האתר של הארגון.
  • ארבע קבוצות של שרתים:
    • אחד מהם מארח את האתר של הארגון (שירות קצה עורפי: org-site).
    • אחד מהם מארח את האתר הכללי של סרטוני ההדרכה (שירות קצה עורפי: video-site).
    • אחד מהם מארח סרטוני הדרכה באיכות HD (שירות קצה עורפי: video-hd).
    • אחד מארח סרטוני הדרכה באיכות רגילה (SD) (שירות לקצה העורפי: video-sd).

אתם רוצים שהדברים הבאים יקרו:

  • בקשות אל example.org (או אל כל דומיין אחר מלבד example.net) כדי לעבור אל שירות לקצה העורפי של org-site.
  • בקשות ל-example.net שלא תואמות לנתיבים ספציפיים יותר, יועברו לשירות לקצה העורפי video-site.
  • בקשות אל example.net/video/hd/* עוברות לשירות הקצה העורפי של video-hd.
  • בקשות אל example.net/video/sd/* עוברות אל שירות הקצה העורפי video-sd.

‫--path-rule של /video/* מתאים למזהי URI כמו /video/test1 ו-/video/test2. עם זאת, כלל הנתיב הזה לא תואם לנתיב /video.

אם מאזן העומסים מקבל בקשה עם /../ בכתובת ה-URL, הוא משנה את כתובת ה-URL על ידי הסרת קטע הנתיב שלפני .., ומגיב עם כתובת ה-URL ששונתה. לדוגמה, כשנשלחת בקשה ל-http://example.net/video/../abc, מאזן העומסים מגיב בהפניה אוטומטית (redirect) עם קוד 302 אל http://example.net/abc. רוב הלקוחות מגיבים בשליחת בקשה לכתובת ה-URL שמאזן העומסים החזיר (במקרה הזה, http://example.net/abc). ההפניה האוטומטית מסוג 302 לא מתועדת ב-Cloud Logging.

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

דוגמה להגדרת שירות קצה עורפי.
דוגמה להגדרה של שירות לקצה העורפי (לחצו כדי להגדיל).

מתן שמות למאזני עומסים

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

  • Google Cloud מסוף. אם יוצרים מאזן עומסים של אפליקציות באמצעות מסוףGoogle Cloud , מפת URL מקבלת באופן אוטומטי את אותו שם שהוזן כשם מאזן העומסים.
  • ‫Google Cloud CLI או API. אם יוצרים מאזן עומסים של אפליקציות באמצעות ה-CLI של gcloud או API, צריך להזין שם לבחירה בזמן יצירת מפת URL. השם של מפת URL מופיע במסוףGoogle Cloud כשם של מאזן העומסים.

במאמר סקירה כללית על שירותים לקצה העורפי: מתן שמות למאזני עומסים מוסבר איך לתת שמות למאזני עומסי רשת עם שרת proxy ולמאזני עומסי רשת ב-Passthrough.

רכיבים של מפת URL

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

  • שם מארח הוא החלק של שם הדומיין בכתובת URL. לדוגמה, החלק של שם המארח בכתובת ה-URL‏ http://example.net/video/hd הוא example.net.
  • נתיב הוא החלק מכתובת ה-URL שמופיע אחרי שם המארח ומספר היציאה האופציונלי. לדוגמה, הנתיב בכתובת ה-URL http://example.net/video/hd הוא /video/hd.
הגדרת מאזן עומסים עם מפת URL בסיסית.
הגדרת מאזן עומסים עם מפת URL בסיסית (לחצו כדי להגדיל).

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

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

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

  • כלל מארח (hostRules). כלל מארח מפנה בקשות שנשלחות לשם מארח משויך אחד או יותר אל מאתר נתיבים יחיד (pathMatchers). החלק של שם המארח בכתובת URL תואם בדיוק או תואם באמצעות ביטויים רגולריים לקבוצת שמות המארחים שהוגדרו בכלל המארח. בכלל של מארח ונתיב במפת URL, אם משמיטים את המארח, הכלל תואם לכל מארח מבוקש. כדי להפנות בקשות של http://example.net/video/hd למתאם נתיבים, צריך כלל מארח אחד שכולל לפחות את שם המארח example.net. אותו כלל מארח יכול לטפל גם בבקשות לשמות מארחים אחרים, אבל הוא יפנה אותן לאותו התאמה של נתיב.

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

    אפשר להתאים את כל שמות המארחים על ידי ציון התו הכללי לחיפוש * בכלל המארח. לדוגמה, אם כתובות ה-URL הן http://example.org,‏ http://example.net/video/hd ו-http://example.com/audio, אפשר להתאים את שלושת שמות המארחים example.org,‏ example.net ו-example.com על ידי ציון * בכלל המארח. אפשר גם להתאים שם מארח חלקי באמצעות ציון התו הכללי לחיפוש *. לדוגמה, כלל מארח *.example.net תואם לשמות המארחים news.example.net ו-finance.example.net.

    מספר היציאה. מאזני עומסים קלאסיים של אפליקציות (ALB) מטפלים במספרי יציאות באופן שונה ממאזני עומסים אחרים של אפליקציות. במקרה של מאזן עומסים קלאסי של אפליקציות (ALB), רק שם המארח בכתובת ה-URL נלקח בחשבון כשמבצעים התאמה לכלל מארח. לדוגמה, בקשות של example.net ליציאה 8080 וליציאה 80 תואמות לכלל המארח example.net. בכל שאר מאזני העומסים של אפליקציות, אפשר להשתמש בפרמטר Host rule כדי לציין מספר יציאה. לדוגמה, כדי להפנות בקשות של example.net ליציאה 8080, מגדירים את כלל המארח ל-example.net:8080.

  • התאמת נתיב (pathMatchers). התאמת נתיב היא פרמטר ההגדרה שאליו מתייחס כלל המארח. היא מגדירה את הקשר בין החלק של הנתיב בכתובת ה-URL לבין השירות לקצה העורפי או קטגוריית הקצה העורפי שאמורים לטפל בבקשה. התאמת נתיב מורכבת משני רכיבים:

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

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

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

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

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

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

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

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

הקשר בין שם המארח לכלל המארח

  • שם מארח יכול להפנות רק לכלל מארח אחד.

  • כלל מארח אחד יכול לעבד כמה שמות מארחים.

הקשר בין כלל מארח לבין התאמה לנתיב

  • כמה כללי מארח יכולים להפנות לאותו התאמה לנתיב.

  • כלל מארח יכול להפנות רק למתאם נתיבים אחד.

הקשר בין כתובת ה-URL לבק-אנד

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

  • ‫Google Cloud משתמש בנתח של שם המארח בכתובת URL כדי לבחור כלל מארח יחיד ואת כלי ההשוואה לנתיבים שאליו הוא מפנה.

  • כשמשתמשים בכללי נתיבים במתאם נתיבים, אי אפשר ליצור יותר מכלל נתיב אחד לאותו נתיב. לדוגמה, אי אפשר להפנות בקשות ל-/videos/hd ליותר משירות אחד לקצה העורפי או ליותר מקטגוריית קצה עורפי אחת. לשירותים לקצה העורפי יכולות להיות קבוצות של מכונות לקצה העורפי או קבוצות של נקודות קצה ברשת (NEG) לקצה העורפי באזורים שונים, ואפשר ליצור קטגוריות לקצה העורפי שמשתמשות בסוגי אחסון במספר אזורים.

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

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

מפות URL ופרוטוקולים

אפשר להשתמש באותם מפות URL, כללי מארח וכללי התאמה לנתיב כדי לעבד בקשות HTTP ו-HTTPS שנשלחות על ידי לקוחות, כל עוד גם שרת ה-proxy ל-HTTP וגם שרת ה-proxy ל-HTTPS מפנים למפת ה-URL.

מפת URL פשוטה

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

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

‫ מפת URL ללא כללים, מלבד ברירת המחדל. ‫
מפת URL ללא כללים, מלבד ברירת המחדל (לחצו כדי להגדיל).

סדר הפעולות

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

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

  • אם מפת URL מכילה כלל מארח שכולל את שם המארח של כתובת ה-URL, המערכת בודקת את התאמת הנתיב שאליו מפנה כלל המארח:

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

    • אם למתאם הנתיבים אין כלל נתיב שתואם בדיוק לנתיב של כתובת ה-URL, אבל יש לו כלל נתיב שמסתיים ב-/* והקידומת שלו תואמת לחלק הארוך ביותר של הנתיב של כתובת ה-URL, אז Google Cloudמפנה את הבקשות לשירות לקצה העורפי או לקטגוריית הקצה העורפי של כלל הנתיב הזה. לדוגמה, במפת URL שמכילה שני כללים להתאמת נתיבים, /video/hd/movie1 ו-/video/hd/*, אם כתובת ה-URL מכילה את הנתיב המדויק /video/hd/movie1, היא תותאם לכלל הנתיב הזה.

    • אם אף אחד מהתנאים הקודמים לא מתקיים, Google Cloud הבקשות מופנות לשירות הקצה העורפי של התאמת הנתיבים או לדלי הקצה העורפי, בהתאם למה שהגדרתם.

אילוצים בהגדרת מפת URL

בקטעים הבאים מתוארות מגבלות מסוימות על הגדרת הרכיבים של מפות URL.

התאמות של ביטויים רגולריים בכללי מארח וכללי מסלול

כללי מארח מאפשרים להתאים את החלק של שם המארח בכתובת URL לקבוצת שמות המארחים שהוגדרו בכלל המארח. בשדה hostRules[].hosts[] אפשר להשתמש בשם מארח ספציפי או בתו כללי לחיפוש * כדי להתאים לשם המארח בבקשה הנכנסת.

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

  • ‫pathMatchers[].routeRules[].matchRules[].regexMatch: ביטוי רגולרי שמשמש להתאמת הנתיב של הבקשה הנכנסת.
  • ‫pathMatchers[].routeRules[].matchRules[].headerMatches[].regexMatch: ביטוי רגולרי שמכיל פרדיקט שתואם לכותרת של הבקשה הנכנסת.
  • ‫pathMatchers[].routeRules[].matchRules[].queryParameterMatches[].regexMatch: ביטוי רגולרי שמכיל פרדיקט שתואם לפרמטר של שאילתה בבקשה הנכנסת.

בקשה נחשבת כבקשה שתואמת ל-routeRule אם מתקיים אחד מהתנאים של matchRules. עם זאת, פרדיקטים בתוך matchRule נתון הם בעלי סמנטיקה של AND. כלומר, כל הפרדיקטים ב-matchRule צריכים להתאים כדי שהבקשה תתאים לכלל.

הערות נוספות לגבי השימוש:

  • יש תמיכה בביטויים רגולריים רק במוצרים הבאים:

    • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
    • מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים
    • מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
    • מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)

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

  • כדי ליצור ביטויים רגולריים, צריך להשתמש בתחביר RE2. לרשימה המלאה של המגבלות והאופרטורים שמותרים במפות URL, קראו את מפרט RE2 למפות URL.

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

דוגמה 1: שימוש בביטוי רגולרי כדי להתאים נתיב

הנתיב נחשב לתואם אם הוא תואם לביטוי הרגולרי שצוין על ידי regexMatch אחרי הסרת פרמטרים של שאילתות ועוגנים שסופקו עם כתובת ה-URL המקורית. לדוגמה, במפות ה-URL לדוגמה שבהמשך, הביטוי הרגולרי של כלל המסלול /videos/hd.* יחול על כתובת URL עם הנתיב /videos/hd-abcd?key=245.

defaultService: projects/example-project/global/backendServices/org-site
name: rule-match-url-map
hostRules:
- hosts:
  - '*' # Match any host
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
pathMatchers:
- name: video-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/global/backendServices/video-site
  routeRules:
  - priority: 100000
    matchRules:
    - regexMatch: /videos/hd.*
    routeAction:
      weightedBackendServices:
      - backendService: projects/example-project/global/backendServices/video-hd
        weight: 100

הסבר על כל שדה במפת URL לדוגמה:

  • ‫defaultService: מציין את שירות ה-Backend שמוגדר כברירת מחדל לשימוש אם אף כלל אחר במפת כתובות ה-URL לא תואם לבקשה הנכנסת.
  • ‫name: מקצה את השם rule-match-url-map להגדרת מפת ה-URL הזו.
  • ‫hostRules: הגדרת רשימת כללים להתאמה של כותרת המארח של בקשות נכנסות. הכלל הראשון תואם לכל מארח (*) ומפנה תנועה אל pathMatcher בשם video-matcher. הכלל השני מתאים באופן ספציפי למארח example.net ומפנה את התנועה גם ל-path matcher בשם video-matcher.
  • ‫pathMatchers: מגדיר רשימה של התאמות נתיבים עם שם.
  • ‫name: מגדיר התאמת נתיב בשם video-matcher.
  • ‫defaultService: הגדרת שירות ברירת המחדל למתאם הנתיבים הזה. השירות הזה משמש אם בקשה תואמת לכללי המארח שמפנים אל video-matcher, אבל לא תואמת לאף אחד מכללי ה-routeRules שבתוכו.
  • ‫routeRules: מכיל רשימה של כללים להתאמה לנתיב של כתובת ה-URL.
  • ‫priority: מגדיר את העדיפות של הכלל הזה ל-100000. הכללים נבדקים לפי סדר העדיפות, מהמספר הנמוך ביותר למספר הגבוה ביותר.
  • ‫matchRules: מכיל את התנאים להתאמה של כלל המסלול הזה.
  • regexMatch: התנאי הזה בודק אם נתיב כתובת ה-URL תואם לביטוי הרגולרי /videos/hd.* (לדוגמה, "‎/videos/hd" ו-"‎/videos/hd-caching").
  • ‫routeAction: מציינת את הפעולה שתתבצע אם כל התנאים ב-matchRules יתקיימו.
  • ‫weightedBackendServices: חלוקת התנועה בין רשימה של שירותים לקצה העורפי על סמך משקלים.
  • ‫backendService: מציין את שירות לקצה העורפי שאליו תנותב תעבורת הנתונים.
  • ‫weight: מקצה משקל של 100 לשירות לקצה העורפי הזה. מכיוון שזה השירות היחיד ברשימה, הוא יקבל 100% מהתנועה שתואמת ל-routeRule הזה.

במפת ה-URL הבאה מוצגת דוגמה דומה בלי להשתמש ב-routeAction.

defaultService: projects/example-project/global/backendServices/video-site
name: path-matcher-videos
routeRules:
  matchRules:
  - regexMatch: /videos/hd.*
  priority: 100000
  service: projects/example-project/global/backendServices/video-hd

דוגמה 2: שימוש בביטוי רגולרי להתאמת כותרות

הכותרת נחשבת כתואמת אם הערך של הכותרת תואם לביטוי הרגולרי שצוין על ידי regexMatch. לדוגמה, במיפוי כתובות ה-URL לדוגמה שבהמשך, הביטוי הרגולרי של שם ה-header, ‏ .*Android.*-hd, יחול על בקשה עם ה-header‏ User-Agent:123Androidabc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
name: header-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: header-matcher
pathMatchers:
- name: header-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/default-backend-service
  routeRules:
  - priority: 1
    matchRules:
    - headerMatches:
      - headerName: User-Agent
        regexMatch: .*Android.*-hd
    # This prefix match applies to the path part of the URL
    - prefixMatch: /video/
    # service: can be used instead of routeAction if no other actions are needed
    service: projects/example-project/regions/us-central1/backendServices/video-backend-service
    # Alternatively, use routeAction to specify the service:
    # routeAction:
    #   weightedBackendServices:
    #   - backendService: projects/example-project/regions/us-central1/backendServices/video-backend-service
    #     weight: 100

הסבר על כל שדה במפת URL לדוגמה:

  • ‫defaultService: מציין את שירות ה-Backend שמוגדר כברירת מחדל לשימוש אם אף כלל אחר במפת כתובות ה-URL לא תואם לבקשה הנכנסת.
  • ‫name: מקצה את השם header-match-url-map להגדרת מפת URL זו.
  • ‫hostRules: הגדרת רשימת כללים להתאמה של כותרת המארח של בקשות נכנסות. הכלל תואם לכל מארח ('*') ומפנה את התנועה אל pathMatcher named header-matcher.
  • ‫pathMatchers: מגדיר רשימה של התאמות נתיבים עם שמות.
  • ‫name: מגדיר כלי להתאמת נתיבים בשם header-matcher.
  • ‫defaultService: הגדרת שירות ברירת המחדל להתאמת הנתיב הזו. השירות הזה משמש אם בקשה תואמת לכלל המארח אבל לא תואמת לאף אחד מה-routeRules בתוך התאמת הנתיב הזו.
  • ‫routeRules: מכיל רשימה של כללים להתאמת בקשות נכנסות על סמך כותרות ונתיבים.
  • ‫priority: הגדרת העדיפות של הכלל הזה ל-1. הכללים נבדקים לפי סדר העדיפות, מהמספר הנמוך ביותר למספר הגבוה ביותר.
  • ‫matchRules: מכיל רשימה של תנאים שכולם צריכים להתקיים כדי שהכלל יתאים.
  • ‫headerMatches: הגדרת תנאים על סמך כותרות הבקשה.
  • ‫headerName: חיפוש של הכותרת User-Agent.
  • ‫regexMatch: בודק אם הערך של כותרת סוכן המשתמש תואם לביטוי הרגולרי .*Android.*-hd. התנאי הזה יתאים לסוכני משתמש שמציינים מכשיר Android, עם מחרוזת שמכילה את הערך '-hd'.
  • prefixMatch: כשהתנאי מוגדר לערך /video/, הוא בודק אם נתיב כתובת ה-URL מתחיל ב-"/video/".
  • ‫service: אם כל התנאים של matchRules מתקיימים, תעבורת נתונים מופנית לשירות לקצה העורפי הזה.
  • הקטע routeAction שסומן כהערה מציג דרך חלופית לציין את שירות הקצה העורפי, שנדרשת אם צריך להגדיר פעולות אחרות של מסלולים, כמו שכתוב של כתובות URL, טרנספורמציות של כותרות או שירותי קצה עורפי משוקללים.

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

פרמטר השאילתה נחשב להתאמה אם הערך של הנתיב עם פרמטרים של שאילתה תואם לביטוי הרגולרי שצוין על ידי regexMatch. לדוגמה, במפת כתובות ה-URL הבאה, הביטוי הרגולרי של פרמטר השאילתה, /im.*/.*.html, יחול על כתובת URL עם פרמטרים של שאילתה כמו /images/random_page.html?param1=param_value_123abc-hd.

defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
name: query-match-url-map
hostRules:
- hosts:
  - '*'  # Match any host
  pathMatcher: query-matcher
pathMatchers:
- name: query-matcher
  # Optional: default service for this path matcher if no routeRules match
  defaultService: projects/example-project/regions/us-central1/backendServices/sample-bs
  routeRules:
  - priority: 1
    matchRules:
    - queryParameterMatches:
      - name: param1   #parameter name in query
        regexMatch: param_value_.*-hd
    # This regexMatch applies to the path part of the URL
    - regexMatch: /im.*/.*.html
    # Directs traffic to this service if all conditions in matchRules are met
    service: projects/example-project/regions/us-central1/backendServices/sample-images-bs

הסבר על כל שדה במפת URL לדוגמה:

  • ‫hostRules: מוסיף כלל להתאמה לכל המארחים (*) ומפנה את התנועה אל pathMatcher בשם query-matcher.
  • ‫pathMatchers: מגדיר כלי להתאמת נתיבים בשם query-matcher.
  • ‫routeRules: הצבת הבלוק routeRules שסופק בתוך query-matcher.
  • ‫priority: מגדיר את העדיפות של הכלל הזה ל-1. הערכת הכללים מתבצעת לפי הסדר, ממספר העדיפות הנמוך ביותר למספר העדיפות הגבוה ביותר.
  • ‫matchRules: מכיל את התנאים של routeRules.
  • queryParameterMatches: בודק אם הפרמטר של השאילתה שנקרא "param1" תואם לביטוי הרגולרי param_value_.*-hd.
  • ‫regexMatch: הביטוי הרגולרי /im.*/.*.html חל על הנתיב של כתובת ה-URL (לדוגמה, ‎/images/random_page.html), לפני מחרוזת השאילתה.
  • ‫service: מציין את השירות לקצה העורפי שבו צריך להשתמש אם כל התנאים ב-matchRules מתקיימים.

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

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

אתם מציינים ביטויים רגולריים באמצעות השדות הבאים:

  • ‫pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathPattern: ביטוי רגולרי בתחביר RE2 שמשמש להתאמה וללכידה של חלקים מנתיב הבקשה הנכנסת.
  • ‫pathMatchers[].routeRules[].routeAction.urlRewrite.regexRewrite.pathSubstitution: מחרוזת שמשמשת לשחזור הנתיב לפני שליחת הבקשה לשירות לקצה העורפי. אפשר להפנות לקבוצות שנלכדו מ-pathPattern באמצעות תחביר עם שם \g<name> (לקבוצות עם שם כמו (?<name>re)) או תחביר עם מספר כמו \1 או \2.

איך פועלות קבוצות לחילוץ ב-RE2

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

קבוצות לחילוץ מוגדרות בשדה pathPattern באמצעות הפורמט (?<name>re) או (?P<name>re), כאשר name הוא שם המשתנה שהוקצה לחלק שחולץ מנתיב כתובת ה-URL שיוחלף, ו-re הוא תבנית הביטוי הרגולרי שמשמשת להתאמה לחלק הזה. אחר כך מציינים את קבוצות החילוץ בשדה pathSubstitution כדי להחליף אותן באמצעות הפורמט \g<name>.

לדוגמה:

  • נתיב כתובת ה-URL של בקשת הלקוח הנכנסת: /api/users/21334/profile.json
  • pathPattern: /api/users/(?<id>\d+)/(?<path>[a-z]+\.json)
  • pathSubstitution: /users/\g<id>/\g<path>
  • הנתיב שנשלח לקצה העורפי: /users/21334/profile.json

שימו לב: קבוצות חילוץ שנכתבות בפורמט (?<name>re) מקבלות גם מספר וגם שם. אפשר להתייחס אליהם לפי השם, \g<name>, או לפי המספר, \1.

הערות נוספות לגבי השימוש:

  • אפשר להשתמש בביטויים רגולריים כדי לשכתב כתובות URL רק במוצרים הבאים:

    • מאזני עומסים פנימיים אזוריים של אפליקציות (ALB)
    • מאזני עומסים פנימיים של אפליקציות (ALB) חוצי-אזורים
    • מאזני עומסים חיצוניים אזוריים של אפליקציות (ALB)
    • מאזני עומסים גלובליים חיצוניים של אפליקציות (ALB)

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

  • כדי ליצור ביטויים רגולריים, צריך להשתמש בתחביר RE2. לרשימה המלאה של המגבלות והאופרטורים שמותרים במפות URL, קראו את מפרטי RE2 למפות URL.

  • אפשר לציין רק פעולה אחת של שכתוב כתובת URL לכל כלל ניתוב. אי אפשר להשתמש ב-regexRewrite יחד עם pathPrefixRewrite או pathTemplateRewrite.

  • בשדה pathSubstitution אפשר להגדיר עד שמונה קבוצות לחילוץ, שצריך להגדיר בשדה pathPattern.

  • השדות pathPattern ו-pathSubstitution מוגבלים ל-250 תווים לכל היותר.

דוגמה: כתיבה מחדש של כתובת URL באמצעות קבוצות לחילוץ של ביטויים רגולריים

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

בדוגמה הזו, כתובות URL של בקשות נכנסות כמו /region/us-central1/bucket/my-bucket/stage/dev/object.pdf נכתבות מחדש ל-/us-central1/my-bucket-dev/object.pdf לפני שהן מועברות דרך שרת proxy לשירות לקצה העורפי.

defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
name: regex-rewrite-url-map
pathMatchers:
- name: region-matcher
  defaultService: projects/example-project/regions/us-central1/backendServices/default-bs
  routeRules:
  - matchRules:
    - prefixMatch: /region/
    priority: 1
    service: projects/example-project/regions/us-central1/backendServices/rewrite-bs
    routeAction:
      urlRewrite:
        regexRewrite:
          pathPattern: "/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf"
          pathSubstitution: "/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf"

הסבר על השדות שמופיעים בדוגמה של מפת URL:

  • defaultService: מציין את שירות לקצה העורפי שברירת המחדל היא שהבקשות ינותבו אליו אם אף אחד מהערכים האחרים של routeRules לא תואם לבקשה הנכנסת.
  • ‫name: שם שמוגדר על ידי המשתמש למיפוי כתובות ה-URL הזה.
  • ‫routeRules: רשימה של כללים שמגדירים איך התנועה מותאמת ומנותבת. הערכת הכללים מתבצעת לפי סדר העדיפות שלהם.
  • ‫matchRules: מערך של תנאים שצריכים להתקיים כדי שהכלל הזה יחול.
  • ‫prefixMatch: התאמה לתחילת הנתיב של כתובת ה-URL. בדוגמה המתוקנת, הכלל חל רק על נתיבים שמתחילים ב-/region/.
  • ‫priority: מספר שלם שקובע את הסדר שבו הכללים נבדקים. מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר.
  • ‫service: השירות לקצה העורפי שאליו תועבר התנועה אם מתקיימים התנאים של matchRules בכלל הזה ופעולת הניתוב מבוצעת.
  • ‫routeAction: הפעולה שצריך לבצע כשבקשה תואמת ל-matchRules.
  • ‫urlRewrite: מגדיר איך לשנות את כתובת ה-URL לפני שהיא מועברת דרך שרת proxy לשירות לקצה העורפי.
  • ‫regexRewrite: הגדרה של כתיבה מחדש של כתובות URL באמצעות ביטויים רגולריים.
  • ‫pathPattern: הביטוי הרגולרי (באמצעות תחביר Google RE2) שמשמש להתאמה לנתיב כתובת ה-URL הנכנסת. קבוצות חילוץ עם שם בפורמט (?<name>re) משמשות לחילוץ חלקים מהנתיב. בדוגמה, "/region/(?<reg>[a-z0-9-]+)/bucket/(?<bkt>[a-z0-9-]+)/stage/(?<stg>[a-z0-9-]+)/object\\.pdf" מתעד את האזור (reg), את שם הקטגוריה (bkt) ואת שם השלב (stg).
  • ‫pathSubstitution: המחרוזת שמשמשת לשחזור הנתיב. הוא מפנה לקבוצות החילוץ עם השמות מהתבנית באמצעות התחביר \g<name>. בדוגמה, "/\\g<reg>/\\g<bkt>-\\g<stg>/object.pdf" משתמש בערכים reg,‏ bkt ו-stg שנתפסו כדי לבנות את הנתיב החדש: /us-central1/my-bucket-dev/object.pdf.

תווים כלליים לחיפוש, ביטויים רגולריים וכתובות URL דינמיות בכללי נתיב ובהתאמה לפי קידומת

  • כלל נתיב (pathMatchers[].pathRules[]) יכול לכלול תו כללי לחיפוש (*) רק אחרי לוכסן (/). לדוגמה, /videos/* ו-/videos/hd/* הם כללי נתיב תקינים, אבל /videos* ו-/videos/hd* לא תקינים.

  • כללי נתיב לא משתמשים בביטויים רגולריים או בהתאמה למחרוזת משנה. אפשר להשתמש באופרטורים פשוטים להתאמת נתיבים ב-PathTemplateMatch. לדוגמה, כללי נתיב ל-/videos/hd או ל-/videos/hd/* לא חלים על כתובת URL עם הנתיב /video/hd-abcd. עם זאת, כלל נתיב ל-/video/* חל על הנתיב הזה.

  • בהתאמה לפי קידומת (pathMatchers[].routeRules[].matchRules[].prefixMatch), התו * לא נחשב לתו כללי לחיפוש, אלא לתו מילולי.

  • במגדירי התאמות לנתיבים (ובמפות URL באופן כללי) אין תכונות שפועלות כמו ההוראה <LocationMatch> של Apache. אם יש לכם אפליקציה שיוצרת נתיבי כתובות URL דינמיים עם קידומת משותפת, כמו /videos/hd-abcd ו-/videos/hd-pqrs, ואתם צריכים לשלוח בקשות שמופנות לנתיבים האלה לשירותים שונים בעורף המערכת, יכול להיות שלא תוכלו לעשות זאת באמצעות מיפוי כתובות URL. במקרים שבהם יש רק כמה כתובות URL דינמיות אפשריות, אפשר ליצור התאמה לנתיב עם קבוצה מוגבלת של כללי נתיב. במקרים מורכבים יותר, צריך לבצע התאמה של ביטויים רגולריים מבוססי-נתיב בקצה העורפי.

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

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

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

  • מאזן עומסים גלובלי חיצוני של אפליקציות (ALB)
  • מאזן עומסים חיצוני אזורי של אפליקציות (ALB)
  • מאזן עומסים פנימי אזורי של אפליקציות (ALB)
  • מאזן עומסים פנימי של אפליקציות (ALB) בין אזורים
  • Cloud Service Mesh

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

  pathMatchers:
    - name: cart-matcher
      routeRules:
        - description: CartService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/{username=*}/carts/{cartid=**}'
          service: cart-backend
          priority: 1
          routeAction:
            urlRewrite:
              pathTemplateRewrite: '/{username}-{cartid}/'
    - name: user-matcher
      routeRules:
        - description: UserService
          matchRules:
            - pathTemplateMatch: '/xyzwebservices/v2/xyz/users/*/accountinfo/*'
          service: user-backend
          priority: 1

זה מה שקורה כשלקוח מבקש את /xyzwebservices/v2/xyz/users/abc@xyz.com/carts/FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB, שמכיל גם פרטי משתמש וגם פרטי עגלת קניות:

  1. נתיב הבקשה תואם ל-pathTemplateMatch ב-cart-matcherpathMatcher. המשתנה {username=*} תואם ל-abc@xyz.com והמשתנה {cartid=**} תואם ל-FL0001090004/entries/SJFI38u3401nms.
  2. הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך pathTemplateRewrite והפרמטרים של השאילתה מצורפים לנתיב שנכתב מחדש. אנחנו צריכים להשתמש רק באותם משתנים שבהם השתמשנו כדי להגדיר את pathTemplateMatch ב-pathTemplateRewrite.
  3. הבקשה שנכתבה מחדש נשלחת אל cart-backend עם נתיב כתובת ה-URL שנכתב מחדש: /abc@xyz.com-FL0001090004/entries/SJFI38u3401nms?fields=FULL&client_type=WEB.

אם הלקוח מבקש את /xyzwebservices/v2/xyz/users/abc%40xyz.com/accountinfo/abc-1234, שכולל רק פרטי משתמש וחשבון, קורה הדבר הבא:

  1. נתיב הבקשה תואם ל-pathTemplateMatch ב-user-matcherpathMatcher. המחרוזת הראשונה * תואמת למחרוזת abc%40xyz.com והמחרוזת השנייה * תואמת למחרוזת abc-1234.
  2. הבקשה נשלחת אל user-backend.

בטבלה הבאה מפורט התחביר של תבניות הנתיבים.

אופרטור התאמות
* קטע נתיב יחיד, לא כולל את התווים / שמפרידים בין הנתיבים.
** התאמה לאפס תווים או יותר, כולל כל תו מפריד נתיבים / בין כמה קטעי נתיב. אם כוללים אופרטורים אחרים, האופרטור ** חייב להיות האופרטור האחרון.
{name} או {name=*} משתנה בעל שם שתואם לפלח נתיב אחד. התאמה לקטע נתיב יחיד, לא כולל תווי ההפרדה / של הנתיב שמסביב.
{name=news/*} משתנה עם שם שתואם באופן מפורש לשני פלחים בנתיב: ‫news ופלח עם התו הכללי *.
{name=*/news/*} משתנה בעל שם שתואם לשלושה מקטעי נתיב.
{name=**} משתנה בעל שם שתואם לאפס תווים או יותר. אם הוא מופיע, הוא חייב להיות האופרטור האחרון.

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

  • אפשר לשלב כמה אופרטורים בתבנית אחת.
  • הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך pathTemplateRewrite, והפרמטרים של השאילתה מצורפים לנתיב שנכתב מחדש.
  • הבקשות לא עוברות נורמליזציה של קידוד באחוזים. לדוגמה, כתובת URL עם תו לוכסן בקידוד אחוזים (%2F) לא מפוענחת לצורה הלא מקודדת.
  • כל שם משתנה, כמו {segment} או {region}, יכול להופיע רק פעם אחת באותה תבנית. הגדרה של כמה משתנים עם אותו שם לא תקינה והמערכת תדחה אותה.
  • שמות המשתנים הם תלויי אותיות רישיות (case-sensitive) וחייבים להיות מזהים תקינים. כדי לבדוק אם שם משתנה תקין, מוודאים שהוא תואם לביטוי הרגולרי ^[a-zA-Z][a-zA-Z0-9_]*$.
    • ‫{API}, {api} ו-{api_v1} הם מזהים תקינים. הם מזהים שלושה משתנים נפרדים.
    • המזהים {1}, {_api} ו-{10alpha} לא תקינים.
  • אפשר להוסיף עד חמישה אופרטורים לכל תבנית.

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

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

  • כשמשכתבים כתובת URL, אפשר להשמיט משתנים אם הם לא נדרשים כחלק מכתובת ה-URL המשוכתבת.
  • לפני כל שכתוב, אתם יכולים לזהות את כתובת ה-URL שנשלחה על ידי הלקוח במקור שלכם על ידי בדיקת כותרות התגובה. כתובת ה-URL המקורית של הלקוח מאוכלסת בכותרת x-client-request-url ובכותרת x-envoy-original-path.

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

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

מידע נוסף על יצירה והגדרה של מפות URL עם התאמות נתיבים וכללי מארח זמין במסמכי התיעוד של gcloud compute url-maps create.

  1. יוצרים מיפוי כתובות URL למאזן העומסים ומציינים שירות ברירת מחדל לקצה העורפי. בדוגמה הזו נוצרת מפה של כתובות URL בשם video-org-url-map שמפנה לשירות קיים לקצה העורפי בשם org-site.

    gcloud compute url-maps create video-org-url-map \
    --default-service=org-site

  2. יוצרים התאמה לנתיב בשם video-matcher עם המאפיינים הבאים:

    • שירות ברירת המחדל לקצה העורפי הוא video-site, שירות קיים לקצה העורפי.
    • מוסיפים כללי נתיב שמפנים בקשות לנתיב המדויק של כתובת ה-URL‏ /video/hd או לקידומת של נתיב כתובת ה-URL‏ /video/hd/* לשירות לקצה העורפי קיים בשם video-hd.
    • מוסיפים כללי נתיב שמפנים בקשות לנתיב המדויק של כתובת ה-URL‏ /video/sd או לקידומת של נתיב כתובת ה-URL‏ /video/sd/* לשירות לקצה העורפי קיים בשם video-sd.
    gcloud compute url-maps add-path-matcher video-org-url-map \
    --path-matcher-name=video-matcher \
    --default-service=video-site \
    --path-rules=/video/hd=video-hd,/video/hd/*=video-hd,/video/sd=video-sd,/video/sd/*=video-sd

  3. יוצרים כלל מארח לשם המארח example.net שמפנה למתאם הנתיבים video-matcher.

    gcloud compute url-maps add-host-rule video-org-url-map \
    --hosts=example.net \
    --path-matcher-name=video-matcher

מפת כתובות ה-URL של video-org-url-map צריכה להיראות כך:

gcloud compute url-maps describe video-org-url-map

creationTimestamp: '2021-03-05T13:34:15.833-08:00'
defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/org-site
fingerprint: mfyJIT7Zurs=
hostRules:
- hosts:
  - '*'
  pathMatcher: video-matcher
- hosts:
  - example.net
  pathMatcher: video-matcher
id: '8886405179645041976'
kind: compute#urlMap
name: video-org-url-map
pathMatchers:
- defaultService: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-site
  name: video-matcher
  pathRules:
  - paths:
    - /video/hd
    - /video/hd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-hd
  - paths:
    - /video/sd
    - /video/sd/*
    service: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices/video-sd
selfLink: https://www.googleapis.com/compute/v1/projects/PROJECT_ID/global/urlMaps/video-org-url-map

מפת ה-URL‏ video-org-url-map מפנה כתובות URL שנכללות בבקשות לשרתי קצה עורפיים באופן הבא.

‫ מפת URL עם כלל נתיב, דפוסי נתיב וכלל מארח. ‫
מפת כתובות URL עם כלל נתיב, התאמות נתיבים וכלל מארח (לחצו כדי להגדיל).

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

שם המארח נתיבים של כתובות URL שירות לקצה העורפי שנבחר הסיבה לבחירה
שם המארח:
example.org וכל שמות המארחים האחרים שונה מ
example.net		 כל הנתיבים org-site שם המארח לא נמצא באף כלל מארח של מפת URL, ולכן הבקשה מופנית לשירות לקצה העורפי של מפת URL.
שם מארח:
example.net		 /video
/video/examples		 video-site הבקשה מועברת לשירות ברירת המחדל של הקצה העורפי כי אין כלל נתיב ל-/video/ או ל-/video/*. כלל המארח [example.net] מפנה למתאים נתיבים, אבל למתאים הנתיבים הזה אין כללי נתיבים שיחולו על הנתיבים האלה.
שם המארח:
example.net		 /video/hd
/video/hd/movie1
/video/hd/movies/movie2
כתובות URL אחרות שמתחילות ב-/video/hd/*		 video-hd כלל מארח של example.net מפנה למתאם נתיבים, שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות ה-URL שתואמים בדיוק ל-/video/hd או שמתחילים ב-/video/hd/* לשירות לקצה העורפי video-hd.
שם מארח:
example.net		 /video/sd
/video/sd/show1
/video/sd/shows/show2
כתובות URL אחרות שמתחילות ב-/video/sd/*		 video-sd כלל מארח של example.net מפנה למתאם נתיבים שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות URL שתואמים בדיוק ל-/video/sd או שמתחילים ב-/video/sd/* לשירות לקצה העורפי video-sd.

הפניות לכתובות URL אחרות

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

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

יש כמה דרכים ליצור הפניה אוטומטית לכתובת URL, כפי שמתואר בטבלה הבאה.

‏Method הגדרות אישיות
הפניה אוטומטית לכתובת ה-URL שמוגדרת כברירת מחדל במפת URL defaultUrlRedirect ברמה העליונה
הפניה אוטומטית לכתובת URL שמוגדרת כברירת מחדל של כלי להשוואת נתיבים pathMatchers[].defaultUrlRedirect[]
הפניה לכתובת URL של כלל נתיב של כלי להתאמת נתיבים pathMatchers[].pathRules[].urlRedirect
הפניה אוטומטית של כתובת URL בכלל ניתוב של כלי להשוואת נתיבים pathMatchers[].routeRules[].urlRedirect

בתוך defaultUrlRedirect או urlRedirect, הפונקציה pathRedirect תמיד פועלת באופן הבא:

  • כל נתיב הבקשה מוחלף בנתיב שאתם מציינים.

בתוך defaultUrlRedirect או urlRedirect, אופן הפעולה של prefixRedirect תלוי באופן השימוש בו:

  • אם משתמשים ב-defaultUrlRedirect, prefixRedirect הוא למעשה הוספת קידומת כי הנתיב התואם הוא תמיד /.
  • אם משתמשים ב-urlRedirect בתוך כלל מסלול או כלל נתיב של התאמת נתיב, prefixRedirect הוא החלפה של קידומת על סמך האופן שבו הנתיב המבוקש הותאם כפי שמוגדר בכלל הנתיב או בכלל המסלול.

דוגמאות להפניות אוטומטיות

בטבלה הבאה מופיעות כמה דוגמאות להגדרות של הפניות אוטומטיות. בעמודה השמאלית מוצגת הגדרת ה-API להפניה אוטומטית לכתובת URL שמוגדרת כברירת מחדל.

אתם רוצים ההפניה מתבצעת באמצעות הפניה אוטומטית לכתובת URL שמוגדרת כברירת מחדל
הפניה אוטומטית מ-HTTP ל-HTTPS

הפניה אוטומטית
מ-http://host.name/path
אל
https://host.name/path 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
הפניה אוטומטית מ-HTTP ל-HTTPS + הפניה אוטומטית של מארח

Redirect
http://any-host-name/path
to
https://www.example.com/path 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
‫HTTP ל-HTTPS + הפניה אוטומטית של מארח + הפניה אוטומטית של נתיב מלא

הפניה אוטומטית
http://any-host-name/path
אל
https://www.example.com/newPath 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
‫HTTP ל-HTTPS + הפניה אוטומטית של מארח + הפניה אוטומטית של קידומת

הפניה אוטומטית
מ-http://any-host-name/originalPath
אל
https://www.example.com/newPrefix/originalPath 
            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              prefixRedirect: "/newPrefix"

קטע הקוד החלקי הבא מוסיף הערות לכל משאב API:

defaultUrlRedirect:
   redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
   httpsRedirect: True # True if you want https://, false if you want http://
   hostRedirect: "new-host-name.com" # Omit to keep the requested host
   pathRedirect: "/new-path" # Omit to keep the requested path; mutually exclusive to prefixRedirect
   prefixRedirect: "/newPrefix" # Omit to keep the requested path; mutually exclusive to pathRedirect
   stripQuery: False # True to omit everything in the URL after ?
   ...

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