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

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

לצפייה במאמרי העזרה של Apigee Edge.

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

סקירה כללית

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

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

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

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

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

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

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

ב-Apigee יש תמיכה בסוגי הפריסה הבאים בסביבה:

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

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

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

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

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

FAILED_PRECONDITION

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

יחידות פריסה של שרתי proxy‏ (PDU) מודדות את צריכת הקיבולת של Apigee על סמך הפריסה של שרתי proxy ל-API ותהליכים משותפים בתשתית שלכם.

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

חישוב יחידות ה-PDU

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

ב-Apigee Hybrid, כל אשכול Kubernetes שבו מגדירים סביבה נחשב כמכונה (אזור) בחישוב ה-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 (ייצור, Staging) ‫3 (ארה"ב, האיחוד האירופי, אסיה) 30

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

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

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

  • יחידות פריסה של שרתי proxy רגילים סופרות את מספר שרתי ה-proxy שנפרסו כרגע ומוגדרים כשרתי proxy רגילים.
  • יחידות פריסה של שרתי proxy ניתנים להרחבה סופרות את מספר שרתי ה-proxy שנפרסו כרגע ועומדים בדרישות של שרתי proxy ניתנים להרחבה.
  • יחידות פריסה של תהליכים משותפים סופרות את מספר התהליכים המשותפים שנפרסו.

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

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

סוגי סביבות

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

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

שרת proxy להעברה

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

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

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

להוראות להגדרת שרת proxy להעברה, ראו הגדרת שרת proxy להעברה בסביבה.

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

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

בשלב הזה, Apigee לא תומכת באימות בסיסי עם שרת proxy להעברה, חוץ מאשר ב-Apigee Hybrid.

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

תכונה או מדיניות האם יש תמיכה בשרת proxy להעברה או שהאפשרות רלוונטית?
נקודות קצה (endpoint) של היעד כן
בדיקת תקינות של HTTP כן
יתרונות מרכזיים של השירות כן
קריאות HTTP באמצעות JavaScript כן
יעדי שילוב כן
שרשור שרתי proxy, באמצעות לולאות חזרה מקומיות לא
פרסום הודעות לא
Cloud Logging לא
תקשורת עם Synchronizer לא
רישום הודעות ביומן באמצעות Syslog לא

מגבלות על שרתי פרוקסי להעברה

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

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

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

רכיב כללים
ארגונים
  • יכול להכיל כמה קבוצות של סביבות
  • חייבת להיות לפחות קבוצת סביבות אחת
סביבות
  • חייב להיות לפחות בקבוצת סביבות אחת
  • יכולות להיכלל ביותר מקבוצה אחת
  • שיתוף שמות מארחים עם כל הסביבות האחרות באותה קבוצה
  • אפשר להשתמש בו כדי להעביר תנועה ל-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 הבאים נפרסים בסביבות האלה:

    • שרת ה-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 יהיו כמה כתובות, אחת לכל קבוצת סביבות שאליה הסביבה שייכת. האפשרות הזו שימושית אם ללקוח יש תעודות wildcard (כמו ‎*.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) יהיו זמינים ברמת הארגון, כך שכל שרתי ה-proxy ל-API שנפרסו בכל סביבה בארגון יוכלו לגשת לאותם נתוני KVM.

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

לתשומת ליבכם

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

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

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

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

בקטעים הבאים מוסבר איך לנהל את הסביבות ואת קבוצות הסביבות: