מידע על סביבות וקבוצות של סביבות

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

בקטע הזה מתוארות סביבות וקבוצות של סביבות.

סקירה כללית

סביבה ב-Apigee היא סביבת תוכנה בתוך ארגון, שמשמשת ליצירה ופריסה של שרתי proxy ל-API. כדי שניתן יהיה לגשת ל-proxy ל-API, צריך לפרוס אותו בסביבה. אפשר לפרוס שרת proxy של API לסביבה אחת או לכמה סביבות.

כל סביבה כפופה למגבלות על מספר שרתי ה-proxy ל-API, הרכיבים המשותפים ומשאבים אחרים שאפשר לפרוס בה. המגבלות האלה משתנות בהתאם לסוג הארגון ב-Apigee (מינוי, תשלום לפי שימוש או היברידי) שמשתמש בסביבה. מידע מפורט יותר זמין במאמר בנושא מגבלות.

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

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

הקיבוץ הלוגי של סביבות לפי קבוצת סביבות מספק את היתרונות הבאים:

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

סוגי פריסה נתמכים

‫Apigee תומך בסוגי הפריסה הבאים בסביבה:

סוג תיאור
בשם אחרים מפתחים ובודקים את שרתי ה-proxy של ה-API בסביבות הפיתוח של Apigee, ואז פורסים אותם בסביבות הבדיקה והייצור של Apigee. מידע נוסף זמין במאמר בנושא פריסת proxy ל-API.
העברה לארכיון פיתוח ובדיקה של שרתי proxy ל-API שניתנים לתכנות באמצעות Apigee ב-VS Code

סיכום של פעולות שנמנעו עם פריסה של ארכיון

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

  • בממשק המשתמש של Apigee אי אפשר להציג את סטטוס הפריסה, לאשר את הפריסות של הארכיון או לנהל אותן, כמו שמתואר במאמר פריסת proxy ל-API, וגם אי אפשר להשתמש בממשק המשתמש של Debug כמו שמתואר במאמר שימוש ב-Debug. כפתרון עקיף, אפשר להשתמש ב-gcloud או ב-API כדי לרשום את כל הפריסות בארכיון בסביבה ולהשתמש ב-Debug API.
  • אי אפשר ליצור, לעדכן או למחוק קובצי משאבים או שרתי יעד באמצעות ממשק המשתמש של Apigee,‏ Apigee API או gcloud.
  • בשלב הזה, אין תמיכה באימות של Google באמצעות חשבונות שירות.

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

FAILED_PRECONDITION

יחידות פריסה של שרת proxy

יחידות פריסת שרת proxy סופרות שרתי proxy וזרימות משותפות שנפרסו בסביבות לפי אזור.

אלה סוגי יחידות הפריסה:

  • ‫Standard proxy deployment units (יחידות פריסת proxy רגילות) – מספר שרתי ה-proxy שפרוסים כרגע ועומדים בדרישות של Standard proxies (שרתי proxy רגילים).
  • יחידות פריסה של שרתי proxy עם יכולת הרחבה – מספר שרתי ה-proxy שנפרסו כרגע ועומדים בדרישות של שרתי proxy עם יכולת הרחבה.
  • יחידות פריסה של תהליכי עבודה משותפים: מספר תהליכי העבודה המשותפים שנפרסו.

יכול להיות שהשימוש שלכם כפוף למכסת פריסות, שהיא מגבלה על מספר יחידות הפריסה שבהן אתם יכולים להשתמש בכל פעם. פרטים נוספים מופיעים בזכויות שלכם (Pay-as-you-go או מינוי 2024). מידע על מגבלות המערכת זמין במאמר בנושא יחידות פריסת proxy מקסימליות לכל מופע.

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

סוגי סביבות

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

בתוכניות מינוי, סוג הסביבה הוא תמיד Comprehensive (מקיף) ולא צריך לדעת על סוגי סביבות.

העברה דרך שרת proxy

‫Apigee תומך בהעברת תנועה לכתובת URI ספציפית. התכונה הזו חלה ברמת הסביבה, ואפשר להשתמש בה כדי להפנות תנועה לאינטרנט אחרי עיבוד ראשוני בשרת proxy.

בקשות נכנסות לשרתי proxy בסביבה המוגדרת עוברות עיבוד לכל המדיניות הכלולה (ראו תמיכה בתכונת העברת בקשות דרך שרת proxy) ואז מועברות באמצעות HTTP ל-URI החדש.

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

הוראות להגדרת שרת proxy קדמי זמינות במאמר הגדרת שרת proxy קדמי בסביבה.

תמיכה בתכונה של שרתי proxy להעברה

לא כל התכונות של ה-Proxy שזמינות בדרך כלל, זמינות או רלוונטיות ל-Proxy קדימה.

נכון לעכשיו, Apigee לא תומך באימות בסיסי עם העברת בקשות דרך שרת proxy, למעט ב-Apigee Hybrid.

בטבלה הזו מפורטת תמיכה בפונקציונליות נוספת:

תכונה או מדיניות האם יש תמיכה בשרת proxy קדימה או שהאפשרות רלוונטית לשרת proxy קדימה?
נקודות קצה של היעד כן
בדיקת תקינות של HTTP כן
יתרונות מרכזיים של שירותים כן
קריאות HTTP באמצעות JavaScript כן
יעדי שילוב כן
שרשור של שרתי Proxy דרך לולאות חוזרות מקומיות לא
פרסום הודעות לא
רישום ביומן Cloud לא
תקשורת עם הכלי לסנכרון לא
רישום הודעות ביומן באמצעות Syslog לא

מגבלות של שרתי proxy להעברה

בשלב הזה אין תמיכה ב-GoogleToken דרך קהל חיצוני עם העברת בקשות דרך שרת proxy.

נקודות עיקריות

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

רכיב כללים
ארגונים
  • יכול להכיל כמה קבוצות סביבות
  • צריך להזין לפחות קבוצת סביבות אחת
סביבות
  • צריך להיות לפחות בקבוצת סביבות אחת
  • יכול להיות ביותר מקבוצה אחת
  • שיתוף שמות מארחים עם כל הסביבות האחרות באותה קבוצה
  • אפשר להשתמש בה כדי להעביר תנועה ל-URI שצוין
סוגי סביבות
  • קביעת הפונקציונליות שזמינה בסביבה הזו
  • קובעים את התמחור של הסביבה

(סוגי סביבות)
קבוצות סביבה
  • יכולים להיות כמה שמות מארחים
  • מכילים סביבה אחת או יותר
  • שמות המארחים שמוקצים לקבוצה חייבים להיות ייחודיים לקבוצה הזו (אי אפשר להשתמש בהם בקבוצות אחרות)

דוגמאות

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

קבוצת סביבות אחת וסביבה אחת

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

כמה סביבות בקבוצת סביבות אחת

קבוצת סביבות יכולה להכיל כמה סביבות. לדוגמה, קבוצת סביבות אחת, prod-group, יכולה להכיל שלוש סביבות: cart-prod,‏ catalog-prod ו-payment-prod.

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

במאמר עבודה עם קבוצות סביבות מוסבר איך ליצור את קבוצת הסביבות הזו.

הגבלת הניתוב לסביבה אחת

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

לדוגמה, שם המארח catalog.example.com של קבוצת הסביבות catalog-prod-group יכול להפנות בקשות רק לשרתי proxy בסביבה catalog-prod.

 

מוכנים ליצור קבוצה?

פתיחת המסוף

 

 

מידע נוסף על סביבות

להמשיך לקרוא

 

 

מידע נוסף על קבוצות סביבות

להמשיך לקרוא

 

ניתוב ונתיבי בסיס

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

https://www.example.com/shopping/cart/addItem
        |_____________| |___________| |_____|
               |             |           |
            hostname      basepath     resource

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

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

שמות מארחים

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

שם קבוצת הסביבה
(סביבות)		 prod-group

(catalog-prod
cart-prod
pymnt-prod)		 dev-group

(dev-env)		 ‫test-group

(test-env)
שמות מארחים catalog.example.com
payment.example.com		 dev.example.com test.example.com

את נתיבי הבסיס מגדירים בשרת ה-proxy כשיוצרים אותו.

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

אפשר להגדיר יותר משם מארח אחד בקבוצת סביבות. אפשר להשתמש בכל אחד מהם כדי להתקשר לכל שרת proxy שנפרס בכל סביבה בקבוצה. לדוגמה, גם catalog.example.com/proxy1 וגם payment.example.com/proxy1 יפעילו את המשאב proxy1 אם שמות המארחים catalog.example.com ו-payment.example.com מוגדרים באותה קבוצת סביבות.

דוגמה לניתוב

לדוגמה:

  • קבוצת הסביבות prod-group מכילה את הסביבות הבאות:

    • catalog-prod
    • cart-prod
    • pymnt-prod

  • ב-prod-group מוגדרים שמות המארחים הבאים:

    • catalog.example.com
    • payment.example.com

  • הפרוקסי הבאים נפרסים בסביבות האלה:

    • ה-proxy‏ catalog ב-catalog-prod עם נתיב בסיס של /catalog
    • ה-proxy‏ cart ב-cart-prod עם נתיב בסיס של /catalog/cart
    • ה-proxy‏ payment ב-pymnt-prod עם נתיב בסיס של /payment

נוצרות נקודות הקצה הבאות:

  • catalog.example.com/catalog מסלולים לשרת ה-proxy‏ catalog בסביבת catalog-prod.
  • catalog.example.com/catalog/cart מסלולים לשרת ה-proxy‏ cart בסביבת cart-prod.
  • payment.example.com/payment מסלולים לשרת ה-proxy‏ payment בסביבת pymnt-prod.

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

בקשות ל-API מנותבות לסביבות שונות בתוך הקבוצה על סמך שם המארח ונתיב הבסיס

סביבות משותפות וניתוב

סביבה יכולה להשתייך לכמה קבוצות סביבות. אם פורסים שרת proxy בסביבה כזו, לשרת ה-proxy יהיו כמה כתובות, אחת לכל קבוצת סביבות שהסביבה שייכת לה. האפשרות הזו שימושית אם ללקוח יש אישורים כלליים (כמו *.example.com) לכמה שותפים.

לדוגמה:

  • ‫shared-env שייך לשתי קבוצות סביבות:
    • ‫partner-1 עם כתובת אימייל חלופית למארח api.partner-1.com
    • ‫partner-2 עם כתובת אימייל חלופית למארח api.partner-2.com
  • שרת ה-Proxy‏ foo נפרס ב-shared-env עם נתיב בסיס /foo. מכיוון ש-shared-env משותף לשתי קבוצות הסביבות, ל-foo יש שתי כתובות:
    • api.partner-1.com/foo
    • api.partner-2.com/foo

שימו לב ששני שמות המארחים מנותבים לאותה סביבה. כך לכל קבוצת סביבות יש שם דומיין ייחודי. ב-Apigee hybrid, בתרחיש הזה אפשר להשתמש ב-mTLS עם אישור שונה לכל שותף.

הסבר על היקף הסביבה

הארגון מספק היקף לכמה יכולות של Apigee. לדוגמה, אפשר להפוך נתונים של מיפוי מפתח/ערך (KVM) לזמינים ברמת הארגון, כלומר פרוקסי של API שנפרס בכל סביבה בארגון יכול לגשת לאותם נתונים של KVM.

באופן דומה, אפשר להגדיר את ההיקף של חלק מהיכולות לסביבות או לקבוצות סביבות בתוך הארגון. לדוגמה, נתוני הניתוח של Apigee מחולקים למחיצות לפי שילוב של ארגון, סביבה ו (בסופו של דבר) קבוצת סביבות.

לתשומת ליבכם

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

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

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

מקורות מידע נוספים

בהמשך מוסבר איך לנהל את הסביבות ואת קבוצות הסביבות: