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

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

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

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

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

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

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

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

    • 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) לא תומכים בביטויים רגולריים.

  • כדי ליצור ביטויים רגולריים, צריך להשתמש בתחביר של 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: מציין את שירות לקצה העורפי שמוגדר כברירת מחדל לשימוש אם אף כלל אחר במפת 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: מציין את שירות ה-Backend שאליו התנועה מנותבת.
  • ‫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 דינמיות בכללי נתיב והתאמה לפי קידומת

  • כלל נתיב (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 ב-pathMatcher user-matcher. המחרוזת הראשונה * תואמת ל-abc%40xyz.com והמחרוזת השנייה * תואמת ל-abc-1234.
  2. הבקשה נשלחת אל user-backend.

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

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

מידע נוסף על יצירה והגדרה של מיפוי כתובות 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 מפנה ל-path matcher שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות 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 מפנה ל-path matcher שכללי הנתיב שלו מפנים בקשות לנתיבי כתובות URL שתואמים בדיוק ל-/video/sd או שמתחילים ב-/video/sd/* לשירות הקצה העורפי video-sd.

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

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-to-HTTPS + Host redirect + Full path redirect

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 ?
   ...

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