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

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

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

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

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

מפת כתובות ה-URL האזורית שבה אתם משתמשים תלויה בסכימת איזון העומסים של המוצר.

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

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

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

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

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

יעדים אפשריים למאזני עומסים חיצוניים אזוריים של אפליקציות ולמאזני עומסים פנימיים של אפליקציות:

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

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

מידע על מתן שמות למאזני עומסים מסוג Proxy Network Load Balancer ומאזני עומסים מסוג Passthrough Network Load Balancer זמין במאמר סקירה כללית על שירותי קצה עורפי: מתן שמות למאזני עומסים.

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

  • כלל מארח (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 לבין שירות הקצה העורפי או מאגר הקצה העורפי שאמורים להציג את הבקשה. התאמה לנתיב מורכבת משני רכיבים:

    • Path matcher default backend service או path matcher default backend bucket. לכל התאמה של נתיב, צריך לציין לפחות שירות לקצה העורפי שמוגדר כברירת מחדל או קטגוריית קצה עורפי שמוגדרת כברירת מחדל, אבל לא את שניהם. ערך ברירת המחדל הזה מייצג את שירות הקצה העורפי או את קטגוריית הקצה העורפי שאליהםGoogle Cloud מפנה בקשות לכתובות URL ששמות המארחים שלהן תואמים לכלל מארח שמשויך לכלי להתאמת נתיבים, ושנתיבי כתובות ה-URL שלהן לא תואמים לכלל נתיב בכלי להתאמת נתיבים.

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

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

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

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

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

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

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

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

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

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

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

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

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

הקשר בין כתובת ה-URL לבין הקצה העורפי

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

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

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

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

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

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

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

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

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

הנתיב נחשב לתואם אם הוא תואם לביטוי הרגולרי שצוין על ידי regexMatch אחרי הסרת פרמטרים של שאילתות ועוגנים שסופקו עם כתובת ה-URL המקורית. לדוגמה, במיפוי כתובות ה-URL לדוגמה הבא, כלל הניתוב regular expression, /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: מציין את שירות לקצה העורפי שמוגדר כברירת מחדל לשימוש אם אף כלל אחר במפת 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 לדוגמה הבא, הביטוי הרגולרי של שם הכותרת, .*Android.*-hd, יחול על בקשה עם הכותרת 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: מציין את שירות לקצה העורפי שמוגדר כברירת מחדל לשימוש אם אף כלל אחר במפת 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: בודק אם הערך של כותרת User-Agent תואם לביטוי הרגולרי .*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 לפני שהיא נשלחת אל ה-Backend.

קבוצות לכידה מוגדרות בשדה 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>
  • הנתיב שנשלח אל ה-Backend: /users/21334/profile.json

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

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

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

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

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

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

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

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: מציין את שירות ה-Backend שמוגדר כברירת מחדל שאליו ינותבו הבקשות אם אף אחד משירותי ה-Backend האחרים routeRules לא תואם לבקשה הנכנסת.
  • ‫name: שם שמוגדר על ידי המשתמש למיפוי כתובות ה-URL הזה.
  • ‫routeRules: רשימת כללים שמגדירים איך התנועה מותאמת ומנותבת. הערכת הכללים מתבצעת לפי סדר העדיפות שלהם.
  • ‫matchRules: מערך של תנאים שצריכים להתקיים כדי שהכלל הזה יחול.
  • ‫prefixMatch: תואם לתחילת הנתיב של כתובת ה-URL. בדוגמה המתוקנת, הכלל חל רק על נתיבים שמתחילים ב-/region/.
  • ‫priority: מספר שלם שקובע את סדר הערכת הכללים. מספרים נמוכים יותר מייצגים עדיפות גבוהה יותר.
  • ‫service: שירות הקצה העורפי שאליו התנועה תועבר אם התנאים של matchRules בכלל הזה יתקיימו ופעולת המסלול תבוצע.
  • ‫routeAction: מציין את הפעולה שיש לבצע כשבקשה תואמת ל-matchRules.
  • urlRewrite: מגדיר איך לשנות את כתובת ה-URL לפני שהיא מועברת דרך פרוקסי לשירות לקצה העורפי.
  • ‫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. בעזרת משתנים עם שמות, אפשר לשנות את הסדר של רכיבי כתובת URL ולהסיר אותם לפני שהבקשה נשלחת למקור.

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

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

בדוגמה הבאה מנותב התנועה לאפליקציה למסחר אלקטרוני שיש לה שירותים נפרדים למידע על עגלת הקניות ולמידע על המשתמש. אתם יכולים להגדיר את 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 ופלח עם wildcard ‏*.
{name=*/news/*} משתנה עם שם שתואם לשלושה פלחים של נתיב.
{name=**} משתנה עם שם שתואם לאפס תווים או יותר. אם הוא מופיע, הוא חייב להיות האופרטור האחרון.

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

  • אפשר לשלב כמה אופרטורים בתבנית אחת.
  • הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך pathTemplateRewrite, והפרמטרים של השאילתה מצורפים לנתיב שנכתב מחדש.
  • הבקשות לא עוברות נירמול של קידוד באחוזים. לדוגמה, כתובת URL עם תו קו נטוי (%2F) שמקודד באחוזים לא מפוענחת לפורמט לא מקודד.
  • כל שם של משתנה, כמו {segment} או {region}, יכול להופיע רק פעם אחת באותה תבנית. השימוש בכמה משתנים עם אותו שם לא תקין והם נדחים.
  • שמות המשתנים תלויי אותיות רישיות וחייבים להיות מזהים תקינים. כדי לבדוק אם שם משתנה תקין, מוודאים שהוא תואם לביטוי הרגולרי ^[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 אחרות

הפניה אוטומטית של כתובת 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 + הפניה מ-Host + הפניה מנתיב מלא

Redirect
http://any-host-name/path
to
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 ?
   ...

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

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