אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
ב-Apigee Edge, נתב מטפל בכל תעבורת הנתונים הנכנסת של API. כלומר, כל הבקשות מסוג HTTP ו-HTTPS ל-proxy ל-API של Edge מטופלות קודם על ידי Edge Router. לכן, בקשות ל-proxy ל-API צריכות להיות מופנות לכתובת ה-IP ולפורט הפתוח בנתב.
מארח וירטואלי מאפשר לכם לארח כמה שמות דומיין בשרת יחיד או בקבוצת שרתים. ב-Edge, השרתים תואמים לנתבי Edge. אם מגדירים מארחים וירטואליים בנתב, אפשר לטפל בבקשות לכמה דומיינים.
מארח וירטואלי ב-Edge מגדיר פרוטוקול (HTTP או HTTPS), יחד עם יציאת נתב וכינוי מארח. כינוי המארח הוא בדרך כלל שם דומיין של DNS שממופה לכתובת ה-IP של הנתב.
לדוגמה, בתמונה הבאה מוצג נתב עם שתי הגדרות של מארח וירטואלי:
בדוגמה הזו יש שתי הגדרות של מארחים וירטואליים. אחד מטפל בבקשות HTTPS בדומיין domainName1, והשני מטפל בבקשות HTTP בדומיין domainName2.
כשמתקבלת בקשה ל-proxy ל-API, הנתב משווה בין כותרת המארח ומספר היציאה של הבקשה הנכנסת לבין רשימת כינויי המארחים שמוגדרים בכל המארחים הווירטואליים, כדי לקבוע איזה מארח וירטואלי יטפל בבקשה.
דוגמאות להגדרות של מארחים וירטואליים:
תבנית אנטי
הגדרה של כמה מארחים וירטואליים עם אותו כינוי מארח ומספר יציאה באותן סביבות או בסביבות שונות של ארגון, או בארגונים שונים, תוביל לבלבול בזמן ניתוב בקשות API, ועלולה לגרום לשגיאות או להתנהגות לא צפויות.
נשתמש בדוגמה כדי להסביר את ההשלכות של שימוש בכמה מארחים וירטואליים עם אותו כינוי מארח.
נניח שיש שני מארחים וירטואליים sandbox and secure מוגדרים
עם אותו כינוי מארח, כלומר, api.company.abc.com בסביבה:
בהגדרה שלמעלה, יכולים להיות שני תרחישים כמו שמתואר בקטעים הבאים.
תרחיש 1 : שרת proxy של API מוגדר לקבל בקשות רק לאחד מארגזי החול של המארחים הווירטואליים
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>בתרחיש הזה, כשאפליקציות הלקוח מבצעות קריאות ל-API Proxy ספציפי באמצעות כינוי המארח api.company.abc.com, הן יקבלו לסירוגין שגיאות 404 עם ההודעה:
Unable to identify proxy for host: secure
הסיבה לכך היא שהנתב שולח את הבקשות למארחים הווירטואליים sandbox ו-secure. כשהבקשות מנותבות למארח הווירטואלי sandbox, אפליקציות הלקוח מקבלות תגובה שהפעולה בוצעה בהצלחה. עם זאת, כשבקשות מנותבות אל secure מארח וירטואלי, אפליקציות הלקוח מקבלות שגיאה 404 כי פרוקסי ה-API לא מוגדר לקבל בקשות במארח הווירטואלי secure.
תרחיש 2 : שרת proxy של API מוגדר לקבל בקשות גם לארגז החול וגם למארחים הווירטואליים המאובטחים
<ProxyEndpoint name="default">
...
<HTTPProxyConnection>
<BasePath>/demo</BasePath>
<VirtualHost>sandbox</VirtualHost>
<VirtualHost>secure</VirtualHost>
</HTTPProxyConnection>
...
</ProxyEndpoint>בתרחיש הזה, כשאפליקציות הלקוח מבצעות קריאות ל-API Proxy ספציפי באמצעות כינוי המארח api.company.abc.com, הן מקבלות תגובה תקינה על סמך הלוגיקה של ה-proxy.
עם זאת, הפעולה הזו גורמת לאחסון נתונים שגויים ב-Analytics, כי בקשות ה-API מנותבות לשני המארחים הווירטואליים, בזמן שהבקשות בפועל נועדו להישלח רק למארח וירטואלי אחד.
זה יכול להשפיע גם על פרטי הרישום ביומן ועל כל נתון אחר שמבוסס על המארחים הווירטואליים.
השפעה
- שגיאות 404 כי יכול להיות שבקשות ה-API מנותבות למארח וירטואלי שפרוקסי ה-API לא מוגדר לקבל את הבקשות ממנו.
- נתוני Analytics לא מדויקים כי בקשות ה-API מנותבות לכל המארחים הווירטואליים עם אותו כינוי מארח, למרות שהבקשות נוצרו רק עבור מארח וירטואלי ספציפי.
שיטה מומלצת
- אל תגדירו כמה מארחים וירטואליים עם אותו שם מארח וירטואלי ומספר יציאה באותה סביבה, או בסביבות שונות של ארגון.
אם יש צורך להגדיר כמה מארחים וירטואליים, צריך להשתמש בשמות מארחים וירטואליים שונים בכל אחד מהמארחים הווירטואליים, כמו בדוגמה הבאה:
