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

מוצג המסמך של Apigee Edge.
עוברים אל מסמכי תיעוד של Apigee X. מידע

ב-Apigee Edge, נתב מטפל בכל תעבורת הנתונים הנכנסת מ-API. כלומר כל הפרוטוקולים HTTP ו-HTTPS בקשות לשרת proxy של Edge API מטופלות תחילה על ידי נתב Edge. לכן, בקשה של שרת proxy ל-API חייבות להיות מכוונות לכתובת ה-IP וליציאה הפתוחה בנתב.

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

מארח וירטואלי ב-Edge מגדיר פרוטוקול (HTTP או HTTPS), יחד עם יציאת נתב ומארח חלופי. הכינוי של המארח הוא בדרך כלל שם דומיין DNS שממפה אל כתובת ה-IP של הנתב.

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

בדוגמה הזו, יש שתי הגדרות של מארח וירטואלי. אחד מטפל בבקשות HTTPS הדומיין domainName1, השני מטפל בבקשות HTTP ב-domainName2.

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

תצורה לדוגמה של מארחים וירטואליים:

דוגמה להגדרת vhost

נגד דוגמת עיצוב

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

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

חשוב לזכור שיש שני מארחים וירטואליים sandbox and secure מוגדרים עם אותו כינוי מארח, כלומר, api.company.abc.com בסביבה:

מארחים עם אותה כתובת אימייל

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

תרחיש 1 : שרת proxy ל-API מוגדר לקבל בקשות רק לאחד ארגז חול למארחים 

<ProxyEndpoint name="default">
  ...
  <HTTPProxyConnection>
    <BasePath>/demo</BasePath>
    <VirtualHost>sandbox</VirtualHost>
  </HTTPProxyConnection>
  ...
</ProxyEndpoint>

בתרחיש הזה, כאשר אפליקציות הלקוח מבצעות את הקריאות לשרת Proxy מסוים ל-API באמצעות בכינוי api.company.abc.com, לסירוגין הם יקבלו לסירוגין שגיאות 404 עם ההודעה:

Unable to identify proxy for host: secure

הסיבה לכך היא שהנתב שולח את הבקשות גם ל-sandbox וגם ל-secure מארחים וירטואליים. כשהבקשות מנותבות למארח וירטואלי של sandbox, אפליקציות הלקוח תקבלו תשובה מוצלחת. עם זאת, כשהבקשות ינותבו למארח וירטואלי של secure, אפליקציות הלקוח יקבלו שגיאה 404 כי ה-API Proxy לא מוגדר לקבל בקשות מארח וירטואלי של secure.

תרחיש 2 : שרת proxy ל-API מוגדר לקבל בקשות גם לארגז החול של המארח הווירטואלי וגם ל-Secure

<ProxyEndpoint name="default">
  ...
  <HTTPProxyConnection>
    <BasePath>/demo</BasePath>
    <VirtualHost>sandbox</VirtualHost>
    <VirtualHost>secure</VirtualHost>
  </HTTPProxyConnection>
  ...
</ProxyEndpoint>

בתרחיש הזה, כאשר אפליקציות הלקוח מבצעות את הקריאות לשרת Proxy מסוים ל-API באמצעות מארח חלופי api.company.abc.com, יקבל תשובה תקינה בהתאם ללוגיקה של שרת ה-proxy.

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

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

השפעה

  1. שגיאות 404 מאחר שבקשות ה-API עשויות לנתב למארח וירטואלי שאליו ייתכן ששרת ה-proxy של ה-API לא יהיה זמין מוגדר לקבל את הבקשות.
  2. נתוני Analytics שגויים, מפני שבקשות ה-API ינותבו לכל המארחים הווירטואליים עם אותו כינוי מארח בזמן שהבקשות נשלחו רק עבור מארח וירטואלי ספציפי.

שיטה מומלצת

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

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

    שתי רוחות

קריאה נוספת