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

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

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

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

סקירה כללית

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

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

קבוצת סביבות (לפעמים נקראת 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‏ (PDU) מודדות את צריכת הקיבולת של Apigee על סמך הפריסה של שרתי proxy ל-API ושל רכיבי Shared Flow בתשתית.

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

חישוב של יחידות PDU

כדי לחשב את סך יחידות ה-PDU, מסכמים את יחידות הפריסה בכל הסביבות בארגון. בכל סביבה, התרומה של יחידת ה-PDU היא מספר הגרסאות הפרוסות כפול מספר המופעים (האזורים) שהסביבה מצורפת אליהם.

הנוסחה הכללית לחישוב סך יחידות ה-PDU היא:

Total PDUs = Σ (Deployed Revisions in Envn × Instances for Envn)

הסכום הוא של כל הסביבות (Envn) שבהן מתבצע פריסה של ה-proxy או של התהליך המשותף.

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

PDUs = (Deployed Revisions) × (Environments) × (Instances)

דוגמאות

בטבלה הבאה מוצגות דוגמאות לאופן החישוב של יחידות PDU בתרחישים שונים של תשתית:

תרחיש קובצי Proxy סביבות מכונות (אזורים) סך כל יחידות ה-PDU
אזור יחיד
פריסה בקנה מידה קטן		 1 1 1 1
זמינות גבוהה בכמה אזורים
אותו שרת proxy בשני אזורים		 1 ‫1 (מצורף ל-2 מקרים) 2 2
סביבות מרובות
אותו שרת proxy בסביבות הפיתוח והבדיקה		 1 ‫2 (פיתוח, בדיקה) 1 2
Enterprise Scale
Global deployment across multiple envs
(Assumes both Prod and Staging environments are attached to all 3 instances)		 5 ‫2 (Prod, Staging) ‫3 (ארה"ב, האיחוד האירופי, אסיה) 30

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

יחידות פריסת ה-Proxy סופרות את ה-Proxies ואת הרכיבים המשותפים שנפרסו בסביבות לפי אזור.

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

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

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

סוגי סביבות

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

בתוכניות מינוי ל-Apigee, סוג הסביבה הוא תמיד Apigee Comprehensive, ולא צריך לדעת מהם סוגי סביבות.

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

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

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

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

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

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

לא כל התכונות של שרת proxy שזמינות לכולם זמינות או רלוונטיות לשרת proxy קדימה.

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

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

תכונה או מדיניות האם יש תמיכה בשרת proxy קדימה או שהיא רלוונטית לו?
נקודות קצה של היעד כן
בדיקת תקינות של HTTP כן
יתרונות מרכזיים של שירותים כן
קריאות HTTP באמצעות JavaScript כן
יעדי שילוב כן
שרשור שרתי Proxy דרך לולאות מקומיות לא
פרסום הודעות לא
Cloud Logging לא
תקשורת עם הכלי לסנכרון לא
רישום הודעות ביומן באמצעות 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 זמין במאמר הסבר על נתיבים. בנוסף, כדאי לעיין בהפניה להגדרת זרימות ובהפניה למשתני זרימות כדי להבין טוב יותר איך כל החלקים האלה משתלבים זה בזה.

שמות מארחים

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

שם קבוצת הסביבה
(Environments)		 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.

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

בקשות ל-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 באותה סביבה, או שאם כמה סביבות חולקות קבוצת סביבות אחת, יכול להיות שהיא תופנה לשרת proxy בסביבה אחרת.

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

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

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