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