הגדרת מוצא

יש הרבה דרכים להגדיר מקורות ל-Media CDN. בדף הזה מוסבר איך להגדיר מקורות.

הגדרת קטגוריה של Cloud Storage כמקור

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

קטגוריות של Cloud Storage מוגדרות באמצעות כתובת ה-URL של הקטגוריה, כמו gs://my-bucket, ככתובת המקור כשיוצרים משאב מקור.

המסוף

  1. נכנסים לדף Media CDN במסוף Google Cloud .

    מעבר אל Media CDN

  2. לוחצים על הכרטיסייה מקורות.

  3. לוחצים על יצירת מקור.

  4. מזינים שם למקור. לדוגמה: cloud-storage-origin.

  5. אופציונלי: מזינים תיאור.

  6. בשדה כתובת המקור, בוחרים באפשרות בחירת קטגוריה של Google Cloud Storage.

  7. מעיינים בקטגוריה של Cloud Storage ובוחרים אותה.

  8. ב-Cloud Storage, משאירים את הגדרות ברירת המחדל של הפרוטוקול והיציאה.

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

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

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

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

  12. בוחרים באפשרות תנאי ניסיון חוזר.

  13. בקטע מספר ניסיונות מקסימלי, בוחרים את מספר הניסיונות המקסימלי למילוי מטמון מהמקור הזה.

  14. אופציונלי: מציינים את ערכי הזמן הקצוב לתפוגה הבאים:

    1. בקטע זמן קצוב לתפוגה של חיבור, בוחרים את משך הזמן המקסימלי להמתנה עד ליצירת חיבור למקור.
    2. בקטע זמן קצוב לתשובה, בוחרים את משך הזמן המקסימלי שיוקצב להשלמת התשובה.
    3. בקטע Read timeout, בוחרים את משך הזמן המקסימלי להמתנה בין קריאות של חיבור HTTP יחיד או של סטרימינג.

  15. אופציונלי: לוחצים על הוספת תווית ומציינים צמד מפתח/ערך אחד או יותר.

  16. לוחצים על יצירת מקור.

gcloud

משתמשים בפקודה gcloud edge-cache origins create:

gcloud edge-cache origins create ORIGIN \
    --origin-address=ADDRESS

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ORIGIN: השם של המקור החדש
  • ‫ADDRESS: שם הקטגוריה, לדוגמה gs://my-bucket

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

כשמגדירים שירות, אפשר להפנות את התוכן של וידאו על פי דרישה (VOD) לדלי אחד ואת התוכן של סטרימינג בשידור חי לדלי שני. האפשרות הזו שימושית אם יש לכם צוותים שונים שמנהלים כל תהליך עבודה. כדי לצמצם את זמן האחזור של מילוי המטמון, אפשר להפנות את אזור eu-media.example.com באופן דומה לקטגוריה של Cloud Storage במספר אזורים שנמצאת באיחוד האירופי, ואת אזור us-media.example.com (או להתאים לפי נתיב, כותרת או פרמטר של שאילתה) לקטגוריה של אחסון בארה"ב.

קטגוריות Media CDN.
קטגוריות של Media CDN (לחצו כדי להגדיל).

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

אימות בקשות

כדי לוודא שהבקשה מגיעה מ-Media CDN, אפשר להשתמש באחת מהגישות הנתמכות הבאות:

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

הגדרת פרוטוקול מקור

אם המקור תומך ב-HTTP/2, לא צריך להגדיר את הפרוטוקול באופן מפורש. למקורות שתומכים רק ב-HTTPS ‏ (HTTP/1.1 over TLS) או ב-HTTP/1.1 (ללא TLS), צריך להגדיר את השדה protocol באופן מפורש. לשם כך:

המסוף

  1. נכנסים לדף Media CDN במסוף Google Cloud .

    מעבר אל Media CDN

  2. לוחצים על הכרטיסייה מקורות.

  3. בוחרים את המקור ולוחצים על עריכה.

  4. בפרוטוקול, בוחרים באפשרות HTTPS או HTTP. במקרה של HTTP, צריך גם לציין את היציאה כ-80.

  5. לוחצים על עדכון המקור.

gcloud

משתמשים בפקודה gcloud edge-cache origins update:

gcloud edge-cache origins update LEGACY_ORIGIN \
    --protocol=HTTPS

מחליפים את LEGACY_ORIGIN בשם של נקודת המוצא.

הגדרת קטגוריות פרטיות ב-Cloud Storage

‫Media CDN יכול למשוך תוכן מכל נקודת קצה של HTTP או HTTPS שאפשר להגיע אליה באינטרנט. במקרים מסוימים, יכול להיות שתרצו לדרוש אימות כדי לאפשר ל-Media CDN לשלוף תוכן בלבד ולמנוע גישה לא מורשית. ‫Cloud Storage תומך בזה באמצעות הרשאות IAM.

למקורות Cloud Storage, מבצעים את הפעולות הבאות:

  • נותנים לחשבון השירות של Media CDN את הרשאת ה-IAM‏ objectViewer בקטגוריות של Cloud Storage שבהן אתם משתמשים כמקורות.
  • מסירים את ההרשאה allUsers.
  • אופציונלי: מסירים את ההרשאה allAuthenticatedUsers.

כדי לשנות את ההרשאות של קטגוריה של Cloud Storage, צריך את התפקיד אדמין לניהול אחסון (roles/storage.admin).

חשבון השירות של Media CDN נמצא בבעלות הפרויקט Media CDN, והוא לא יופיע ברשימת חשבונות השירות של הפרויקט שלכם. חשבון השירות מעניק גישה רק למשאבי Media CDN בפרויקטים שאתם מאשרים במפורש.

כדי להפעיל את יצירת חשבון השירות, צריך ליצור לפחות משאב אחד של Media CDN. ברוב המקרים, זהו משאב EdgeCacheOrigin שמקושר לקטגוריה של Cloud Storage.

כדי לתת ל-Media CDN גישה לקטגוריה, מקצים לחשבון השירות את התפקיד objectViewer:

gcloud storage buckets add-iam-policy-binding gs://BUCKET \
    --member=serviceAccount:service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com \
    --role=roles/storage.objectViewer

מחליפים את PROJECT_NUMBER במספר הפרויקט.

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

כדי להסיר הרשאות שניתנו לתפקיד allUsers בקטגוריה מסוימת, משתמשים בפקודה gcloud storage buckets remove-iam-policy-binding. לדוגמה, אם לקטגוריה מוקצה התפקיד objectViewer של allUsers, מסירים את ההרשאה באמצעות הפקודה הבאה:

gcloud storage buckets remove-iam-policy-binding gs://BUCKET \
    --member=allUsers --role=roles/storage.objectViewer

כדי לוודא שהגישה הציבורית הוסרה, פותחים חלון אנונימי בדפדפן ומנסים לגשת לאובייקט בקטגוריה באמצעות https://storage.googleapis.com/BUCKET/object.ext.

כדי לאפשר למשאבי EdgeCacheService בפרויקט אחד גישה לקטגוריה של Cloud Storage בפרויקט אחר, אפשר לתת לחשבון השירות של Media CDN בפרויקט הזה גישה לקטגוריית האחסון.

כדי לעשות זאת, מוודאים ש-PROJECT_NUMBER ב-service-PROJECT_NUMBER@gcp-sa-mediaedgefill.iam.gserviceaccount.com הוא מספר הפרויקט של הפרויקט עם משאבי EdgeCacheService שזקוקים לגישה. אפשר לחזור על התהליך הזה לכמה פרויקטים, במיוחד אם חלק מהם מארחים סביבות שונות של Media CDN (כמו פיתוח, Staging או ייצור), ובפרויקט נפרד נמצאים נכסי הווידאו או המדיה שלכם.

אתם יכולים להגן על הגישה למקור שלכם ב-Cloud Storage בלי להפעיל בקשות חתומות עבור המסלול הזה.

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

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

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

כך תוכלו להגדיר (לדוגמה) את כלי האריזה של השידור החי מאחורי Media CDN או קבוצה של פרוקסי Envoy שמנוהלים על ידי Cloud Service Mesh כדי להתחבר חזרה לתשתית המקומית.

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

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

פריסת מטמון קצה.
פריסת מטמון קצה (לחצו כדי להגדיל).

כדי להגדיר מאזן עומסים של אפליקציות (ALB) חיצוני כמקור, צריך ליצור משאב מקור עם כתובת ה-IP או שם המארח הציבורי שמפנים אל כללי ההעברה של מאזן העומסים. עדיף להשתמש בשם מארח ציבורי (שם דומיין) כי הוא נדרש לאישור SSL‏ (TLS) ולגרסאות HTTP מודרניות (HTTP/2 ו-HTTP/3).

בנוסף, צריך לאשר את הפרטים הבאים:

  • למאזן העומסים יש מסלול שתואם לשם המארח שמשמש למשאב EdgeCacheService, או שהגדרתם urlRewrite.hostRewrite למסלולים שבהם מאזן העומסים מוגדר כמקור.
  • במאזן העומסים מוגדר אישור SSL ‏ (TLS) ממקור מהימן לשימוש ציבורי עבור שמות המארחים האלה.

לדוגמה, אם שם הדומיין הציבורי שמצביע על כלל ההעברה של מאזן העומסים הוא origin-packager.example.com, צריך ליצור מקור עם originAddress שמוגדר לשם הזה.

המסוף

  1. נכנסים לדף Media CDN במסוף Google Cloud .

    מעבר אל Media CDN

  2. לוחצים על הכרטיסייה מקורות.

  3. לוחצים על יצירת מקור.

  4. מזינים שם למקור. לדוגמה: load-balancer-origin.

  5. אופציונלי: מזינים תיאור.

  6. בקטע כתובת המקור, בוחרים באפשרות ציון שם דומיין מלא (FQDN) או כתובת IP.

  7. מזינים את ה-FQDN או את כתובת ה-IP של מאזן העומסים Google Cloud .

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

  9. בוחרים באפשרות תנאי ניסיון חוזר.

  10. בקטע מספר ניסיונות מקסימלי, בוחרים את מספר הניסיונות המקסימלי למילוי מטמון מהמקור הזה.

  11. אופציונלי: מציינים את ערכי הזמן הקצוב לתפוגה הבאים:

    1. בקטע זמן קצוב לתפוגה של חיבור, בוחרים את משך הזמן המקסימלי להמתנה עד ליצירת חיבור למקור.
    2. בקטע זמן קצוב לתשובה, בוחרים את משך הזמן המקסימלי שיוקצב להשלמת התשובה.
    3. בקטע Read timeout, בוחרים את משך הזמן המקסימלי להמתנה בין קריאות של חיבור HTTP יחיד או של סטרימינג.

  12. אופציונלי: לוחצים על הוספת תווית ומציינים צמד מפתח/ערך אחד או יותר.

  13. לוחצים על יצירת מקור.

gcloud

משתמשים בפקודה gcloud edge-cache origins create:

gcloud edge-cache origins create LB_ORIGIN \
    --origin-address=LB_ADDRESS

מחליפים את מה שכתוב בשדות הבאים:

  • ‫LB_ORIGIN: השם של נקודת המוצא
  • ‫LB_ADDRESS: שם הדומיין המוגדר במלואו (FQDN) או כתובת ה-IP. לדוגמה, origin-packager.example.com

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

הגדרת אזור להגנה גמישה

אתם יכולים להגדיר אזור להגנה גמישה כשאתם יוצרים או מעדכנים מקור.

המסוף

  1. נכנסים לדף Media CDN במסוף Google Cloud .

    מעבר אל Media CDN

  2. לוחצים על הכרטיסייה מקורות.

  3. לוחצים על שם המקור שרוצים לעדכן.

  4. כדי לעבור למצב עריכה, לוחצים על הלחצן עריכה.

  5. בקטע Origin controls (אמצעי בקרה על מקור), בוחרים באפשרות Flexible shielding (custom) (הגנה גמישה (מותאמת אישית)) בשדה Origin shielding (הגנה על מקור). האזור הקרוב ביותר נבחר באופן אוטומטי. אם האזור הכי קרוב לא מופיע ברשימה, צריך לבחור ערך באופן ידני מתוך רשימת האזורים הזמינים. הערכים התקינים הם africa_south1 ו-me_central1.

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

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

gcloud

כדי להגדיר הגנה גמישה לאזור במקור קיים, משתמשים בפקודה gcloud edge-cache origins update:

gcloud edge-cache origins update ORIGIN \
    --origin-address=ADDRESS \
    --flex-shielding=REGION

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ORIGIN: השם של נקודת המוצא
  • ‫ADDRESS: הכתובת של המקור
  • ‫REGION: האזור של ההגנה על מקור התוכן. הערכים התקינים הם africa_south1 ו-me_central1.

כדי להגדיר את ההגנה בחזרה להגנה המקורית שמוגדרת כברירת מחדל, מריצים את אותה פקודה אחרי שמגדירים את האפשרות flex-shielding כריקה.

yaml

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

name: ORIGIN
originAddress: ADDRESS
# ... Other fields
flexShielding:
  flexShieldingRegions:
    - REGION
# ... Other fields

מחליפים את מה שכתוב בשדות הבאים:

  • ‫ORIGIN: השם של נקודת המוצא
  • ‫ADDRESS: הכתובת של המקור
  • ‫REGION: האזור של ההגנה על מקור התוכן. הערכים התקינים הם africa_south1 ו-me_central1.

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

הגדרת מעבר אוטומטי למקור אחר

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

מעבר לגיבוי בעקבות כשל בשרת המקור ללא מעקב אחר הפניה אוטומטית

ההגדרה הבסיסית של מעבר אוטומטי לגיבוי EdgeCacheOrigin היא:

name: FAILOVER_ORIGIN
originAddress: FAILOVER_DOMAIN_NAME

‫Media CDN ינסה שוב להתחבר למקור הראשי של המסלול עד שלוש פעמים לפני שינסה לעבור למקור ליתירות כשל. בהגדרה הזו, אחרי שלושה ניסיונות להתחבר למקור הראשי, Media CDN מנסה לשלוח בקשה אחת אל FAILOVER_ORIGIN. אם גם המקור ליתירות כשל לא מצליח להגיב בהצלחה, Media CDN מחזיר את התגובה המלאה של המקור או, אם לא מתקבל קוד סטטוס, תגובת HTTP 502 Bad Gateway.

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

בדוגמה הבאה מוצגת הגדרה ששולחת בקשות למילוי אל MY_ORIGIN. ההגדרה גורמת ל-Media CDN לנסות שוב במקרה של שגיאות בחיבור (כמו שגיאות DNS,‏ TCP או TLS), תגובות HTTP 5xx מהמקור או HTTP 404 Not Found. אחרי שני ניסיונות, המערכת עוברת ל-FAILOVER_ORIGIN.

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

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2 # the number of attempts to make before trying the failoverOrigin
failoverOrigin: FAILOVER_ORIGIN
# what conditions trigger a retry or failover
retryConditions:
- CONNECT_FAILURE
- HTTP_5xx # any HTTP 5xx response
- NOT_FOUND # retry on a HTTP 404
timeout:
  maxAttemptsTimeout: 10s # set a deadline for all retries and failover

מעבר לגיבוי (failover) של המקור עם מעקב אחר הפניה אוטומטית

לדוגמה, נניח שהגדרתם את המשאבים EdgeCacheOrigin הבאים, והמסלולים של המשאב EdgeCacheService מוגדרים לשימוש ב-PrimaryOrigin למילוי מטמון:

name: PrimaryOrigin
originAddress: "primary.example.com"
maxAttempts: 2
failoverOrigin: "SecondaryOrigin"
retryConditions: [CONNECT_FAILURE]
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

name: SecondaryOrigin
originAddress: "secondary.example.com"
maxAttempts: 3
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

בדוגמה הזו, כש-Media CDN מבצע מילוי של המטמון, הוא קורא את ההגדרה של PrimaryOrigin ומגיב בהתאם.

נניח ש-Media CDN מתחבר אל primary.example.com כניסיון מספר 1 ליצור קשר עם השרת המקורי. אם primary.example.com מחזיר תגובה מוצלחת, Media CDN משתמש בתגובה הזו כדי למלא את המטמון.

נניח עכשיו ש-primary.example.com מחזירה HTTP 302 Found Redirect אל Location: b.example.com. לאחר מכן, בניסיון השני ליצור קשר עם המקור, Media CDN עוקב אחרי ההפניה האוטומטית אל b.example.com. במקרה כזה, Media CDN מבצע את הפעולות הבאות:

  • אם b.example.com מחזיר תגובה מוצלחת, Media CDN משתמש בתגובה הזו כדי למלא את המטמון.
  • אם הפונקציה b.example.com מחזירה הפניה או תגובה של כשל, Media CDN עובר ל-SecondaryOrigin שהוגדר. הסיבה לכך היא שבדוגמה הזו, PrimaryOrigin מוגדר לשני maxAttempts.

אם Media CDN עובר לגיבוי ל-SecondaryOrigin, הוא משתמש בהגדרות של SecondaryOrigin ומנסה להתחבר ל-secondary.example.com. זהו הניסיון הראשון ליצור קשר עם המקור, והניסיון השלישי בסך הכול.

במקרה כזה, Media CDN מבצע את הפעולות הבאות:

  • אם secondary.example.com מחזירה תגובה מוצלחת, Media CDN משתמשת בתגובה הזו כדי למלא את המטמון.
  • אם secondary.example.com מחזיר HTTP 302 Found Redirect ל-Location: c.example.com, ‏ Media CDN מנסה ליצור קשר עם c.example.com. בדוגמה הזו, זה הניסיון השני של SecondaryOrigin והניסיון הרביעי בסך הכול.

אם הניסיון ליצור קשר עם c.example.com מחזיר תגובה מוצלחת, Media CDN משתמש בתגובה הזו כדי למלא את המטמון. אם הניסיון מחזיר הפניה אוטומטית ש-Media CDN מוגדר לעקוב אחריה,‏ Media CDN מחזיר קוד סטטוס 502 Bad Gateway של HTTP כי הוא מיצה את מספר הניסיונות המקסימלי ליצירת קשר עם מקור. ‫Media CDN מבצע לכל היותר ארבעה ניסיונות בכל המקורות, בלי קשר להגדרות של EdgeCacheOrigin. לבסוף, אם Media CDN לא מצליח ליצור קשר עם c.example.com, הוא מחזיר תשובה מסוג 504 Gateway Timeout או 502 Bad Gateway.

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

הגדרת הפניות אוטומטיות מהמקור

‫Media CDN תומך בהפניות שמוחזרות על ידי השרת המקורי באופן פנימי במהלך מילוי המטמון, במקום להחזיר תגובות הפניה ישירות ללקוח. כשמגדירים את Media CDN כך שיפעל לפי הפניות אוטומטיות של מקורות, הוא מאחזר תוכן ממיקום ההפניה האוטומטית לפני שהוא שומר אותו במטמון ומחזיר את התגובה שהופנתה ללקוח. ‫Media CDN עוקב אחרי הפניות אוטומטיות בין דומיינים.

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

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

name: MY_ORIGIN
originAddress: DOMAIN_NAME
maxAttempts: 2
originRedirect:
  redirectConditions: [FOUND, TEMPORARY_REDIRECT]

‫Media CDN משתמש בפרוטוקול שצוין בהפניות האוטומטיות כדי להגיע לכל השרתים. מוודאים שכל השרתים שאליהם Media CDN עשוי להפנות תומכים בפרוטוקולים הנדרשים. באופן ספציפי, אם הפרוטוקול מוגדר ל-HTTPS,‏ HTTP/2 או HTTP/3,‏ Media CDN לא חוזר לחיבורי HTTP/1.1 כדי לעקוב אחרי הפניות לא מאובטחות. כותרת המארח שנשלחה למקור שהופנה אליו תואמת לכתובת ה-URL שהופנתה אליה. ‫Media CDN עוקב אחרי הפניה אוטומטית אחת לכל ניסיון EdgeCacheOrigin לפני שהוא מחזיר את התשובה הסופית או מעריך תנאים של ניסיון חוזר או מעבר לגיבוי.

ההגדרה redirectConditions מציינת אילו קודי תגובת HTTP גורמים ל-Media CDN לבצע הפניה אוטומטית לכל מקור.

תנאי תיאור
MOVED_PERMANENTLY הפניה אוטומטית לקוד התגובה HTTP 301
FOUND הפניה אוטומטית לקוד התגובה HTTP 302
SEE_OTHER הפניה אוטומטית לקוד התגובה HTTP 303
TEMPORARY_REDIRECT הפניה אוטומטית לקוד התגובה HTTP 307
PERMANENT_REDIRECT הפניה אוטומטית לקוד התגובה HTTP 308

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

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

name: FAILOVER_ORIGIN
originAddress: FAILOVER_ORIGIN_HOST"
originOverrideAction:
  urlRewrite:
    hostRewrite: FAILOVER_ORIGIN_HOST"
  headerAction:
    requestHeadersToAdd:
    - headerName: "Authorization"
      headerValue: "AUTH-KEY"
      replace: true

ההגדרה originOverrideAction.hostRewrite מקבלת עדיפות על פני שינויים בכותרות שקיימים במסלולים שמפנים למקור הזה.

אפשר להשתמש ב-requestHeadersToAdd בכותרות ייחודיות לכל מקור, שנדרשות על ידי המקור הספציפי הזה. תרחיש נפוץ לדוגמה הוא הוספה של כותרות סטטיות Authorization. השינויים האלה בכותרות מתבצעים במהלך בקשת המקור, ולכן כותרות שנוספות לכל מקור מחליפות כותרות קיימות עם אותו שם שדה או מצורפות אליהן. כברירת מחדל, Media CDN מוסיף לערכים קיימים בכותרות. כדי להחליף כותרות קיימות, מגדירים את headerAction.replace ל-true.

שינויים בכותרות שספציפיים למקור משתמשים רק בערכים סטטיים של כותרות. אין תמיכה במשתני כותרת דינמיים כמו {client_region}.

במאמר הגדרת כותרות מותאמות אישית מוסבר איך מגדירים כותרות של בקשות לכל מסלול.

פתרון בעיות שקשורות למקורות

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

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