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

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

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

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

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

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

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

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

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

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

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

ב-Application Load Balancers, השם של מאזן העומסים תמיד זהה לשם של מפת URL. ההתנהגות של כל Cloud de Confiance ממשק היא כדלקמן:

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

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

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

מפת URL היא קבוצה של Cloud de Confiance משאבי הגדרה שמפנים בקשות לכתובות 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, צריך לציין שירות קצה עורפי שמוגדר כברירת מחדל או קטגוריית קצה עורפי שמוגדרת כברירת מחדל, אבל לא את שניהם. ברירת המחדל הזו מייצגת את שירות הקצה העורפי או את קטגוריית הקצה העורפי שאליהם Cloud de Confiance מפנה בקשות לכתובות 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) מטפלים במספרי יציאות באופן שונה ממאזני עומסים אחרים של אפליקציות. במקרה של מאזן עומסים קלאסי של אפליקציות, רק שם המארח בכתובת ה-URL נלקח בחשבון כשמתאימים כלל מארח. לדוגמה, בקשות example.net ליציאה 8080 וליציאה 80 תואמות לכלל המארח example.net. בכל מאזני העומסים האחרים של האפליקציות, אפשר להשתמש בפרמטר Host rule כדי לציין מספר יציאה. לדוגמה, כדי להפנות בקשות example.net ליציאה 8080, מגדירים את כלל המארח ל-example.net:8080.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Cloud de Confiance משתמש בחלק של שם המארח בכתובת 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 המבוקשות מטופלות על ידי שירות הקצה העורפי שמוגדר כברירת מחדל או על ידי קטגוריית הקצה העורפי שמוגדרת כברירת מחדל (בהתאם למה שהגדרתם).

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

סדר הפעולות

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

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

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

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

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

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

אילוצים בהגדרת מפת 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 לדוגמה הבא, כלל הניתוב 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: מגדיר את העדיפות של הכלל הזה ל-100,000. הכללים מוערכים לפי סדר העדיפות, מהנמוך לגבוה.
• ‫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 דינמיות בכללי נתיב והתאמה של קידומת

• כלל נתיב (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)

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

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

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

• אפשר לשלב כמה אופרטורים בתבנית אחת.
• הפרמטרים של השאילתה מופרדים מהנתיב, הנתיב נכתב מחדש על סמך 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, כמו שמתואר בטבלה הבאה.

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

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

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

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

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

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

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
           

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
          

            kind: compute#urlMap
            name: web-map-http
            defaultUrlRedirect:
              httpsRedirect: True
              hostRedirect: "www.example.com"
              pathRedirect: "/newPath"
           

            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.