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

הדף הזה רלוונטי ל-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
פריסה בקנה מידה ארגוני
פריסה גלובלית במספר סביבות
(בהנחה שסביבות הייצור וההכנה לפרסום מחוברות לכל 3 המקרים)		 5 ‫2 (Prod, Staging) ‫3 (ארה"ב, האיחוד האירופי, אסיה) 30

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

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

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

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

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

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

סוגי סביבות

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

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

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

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

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

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

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

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

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

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

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

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

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

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