הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
ארגון הוא מאגר ברמה העליונה ב-Apigee. הארגון ב-Apigee מכיל את כל פרוקסי ה-API והמשאבים שקשורים אליהם. בהמשך המאמר הזה נסביר יותר לעומק על ארגונים, אבל בינתיים נציין כמה נקודות חשובות:
- ארגון Apigee הוא נפרד מארגון Google Cloud ומשני לו. כשיוצרים ארגון ב-Apigee X או ב-Apigee Hybrid, הוא ממופה לפרויקט אחד בלבד ב-Google Cloud project, והשם של הארגון ב-Apigee זהה לשם של הפרויקט ב-Google Cloud. לא לכל הפרויקטים ב-Google Cloud יש ארגון Apigee משויך.
- במקומות שבהם נעשה שימוש במונח 'ארגון' במסמכי Apigee, הכוונה היא לארגון Apigee. במסמכי Apigee נעשה שימוש במונח 'ארגון Google Cloud' כדי להתייחס לאפשרות החלופית.
- אחרי שיוצרים ארגון ב-Apigee, אי אפשר לשנות את השם שלו.
- שם הארגון שלכם ב-Apigee מוצג כשם הפרויקט בכתובת ה-URL של הקטע Apigee ב-the Google Cloud console.
לדוגמה:
https://console.cloud.google.com/apigee/overview?project=ORG_ID
- כשמפעילים קריאות REST ל-Apigee API, מזהה הארגון הוא חלק נדרש מהנתיב. לדוגמה, הבקשה הבאה
curlמחזירה רשימה של כל ה-API proxy בארגון באמצעות organizations API:curl https://apigee.googleapis.com/v1/organizations/ORG_ID/apis
- יכול להיות שיצרתם רק ארגון אחד, אבל יש לכם הרשאה בארגונים אחרים בתור משתמש או אדמין עם הרשאות ספציפיות. במסוף הענן, אתם יכולים לעבור לארגון אחר כמו שמתואר במאמר מעבר בין הארגונים שלכם.
סרטון: בסרטון הקצר הזה מוסבר איך ארגונים תומכים בארכיטקטורה של ריבוי דיירים לניהול API.
סוגי ארגונים
יש שני סוגים של ארגונים:
בתשלום: ארגון קבוע עם יכולת הרחבה מלאה. נקרא גם ארגון הפקה. ארגונים בתשלום כוללים ארגונים שנוצרו כחלק ממינוי או ממודל התמחור של Apigee בתשלום לפי שימוש.
הערכה: ארגון זמני בשירות עצמי לבדיקת Apigee. ארגונים כאלה נקראים לפעמים ארגוני הערכה. הם מוגבלים בזמן ואין להם את יכולת ההתאמה והגמישות של ארגוני ייצור.
אפשר לעיין גם במאמר השוואה בין ארגונים בתקופת ניסיון לבין ארגונים שמשלמים על המינוי.
משך החיים של ארגון לצורך הערכה
לארגוני הערכה יש משך חיים מוגבל:
- יום 0: יצירת ארגון לצורך הערכה.
- יום 30: Google שולחת לכם התרעה באימייל על תפוגה קרובה.
- יום 60: Google מוחקת את הארגון לצורך הערכה.
ארגונים ב-Apigee בהיררכיה של Google Cloud
בתרשים הבא מוצג הקשר בין ארגונים וסביבות ב-Apigee לבין פרויקטים ותיקיות ב-Google Cloud.

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

המודל הזה לא מציג את כל התכונות של Apigee, אבל הוא נועד להראות שהארגון הוא הבסיס לפריסה.
בטבלה הבאה מפורטים הרכיבים של המודל הארגוני:
| רכיב | תיאור |
|---|---|
| ארגון |
כל ארגון ב-Apigee שייך לפרויקט אחד בלבד ב-Google Cloud, ופרויקט יכול להכיל ארגון אחד לכל היותר. ארגון מכיל סביבות, שרתי proxy ל-API, מוצרי API, חבילות API, אפליקציות ומשתמשים. בעלי חשבונות לא מוגבלים לארגון אחד. חלק מבעלי החשבונות עשויים להגדיר או להיות חברים בכמה ארגונים שתומכים בקהילות שונות של מפתחי אפליקציות. |
| סביבות וקבוצות סביבות | סביבה היא סביבת תוכנה מבודדת בתוך ארגון, שבה פורסים שרתי proxy ל-API. אפשר ליצור כמה סביבות בארגון. קבוצת סביבות היא קבוצה של סביבות עם שם מארח אחד או יותר. שם המארח הוא חלק מכתובת ה-URL שמשמשת להפעלת שרתי proxy של API שנפרסו בכל סביבה בקבוצת הסביבות. |
|
proxy ל-API |
proxy ל-API הוא ממשק בין בקשות נכנסות לבין שירותים לקצה העורפי. ישות ה-proxy מכילה את ההוראות והמדיניות ש-Apigee מבצעת בזמן שהיא מעבדת בקשות מלקוחות ותשובות מהקצה העורפי. |
|
מוצר API |
ישות לפרסום ממשקי API. מוצרי API מתפרסמים בפורטל המפתחים כדי שמפתחים חיצוניים יוכלו להשתמש בהם. מוצר API הוא ממשק לגישה לממשק API אחד או יותר שפורסמו. הממשק (שאפשר לתאר באמצעות מפרט OpenAPI) עשוי לכלול שילוב של בקשות API אחת או יותר שמטופלות על ידי פרוקסי API אחד או יותר. המשתמשים בארגון יוצרים מוצרי API. במקרה כזה, הם יכולים לצרף מטא-נתונים שרירותיים לכל מוצר API. סוג נפוץ של מטא-נתונים יכול להגדיר תוכנית שירות, שבה אפשר לציין מגבלות גישה לקריאות ל-API, לקבוע דרישות אבטחה, לאפשר מעקב וניתוח נתונים ולספק תכונות נוספות. Apigee אוסף נתונים לצורך ניתוח של מוצרי API. |
|
ספק API |
האדם או הישות שיוצרים ומנהלים שרתי proxy ל-API ומוצרי API. מפתחים של אפליקציות לקוח ניגשים לממשקי ה-API שפורסמו. |
|
מפתח אפליקציות |
ארגון מכיל מפתח אחד או יותר שיוצרים את האפליקציות שצורכות את ממשקי ה-API (שמתפרסמים כמוצרי API) שהוגדרו על ידי הארגון. מפתחים משתמשים בממשקי API, אבל לא יכולים ליצור ממשקי API או לבצע פעולות אחרות בארגון. מפתחים יכולים להיות עובדים בחברה שלכם, שותפים או מפתחים חיצוניים שעשויים לשלם על גישה לממשקי ה-API שלכם. אפשר לחשוב על מפתחים כלקוחות שמשתמשים בממשקי ה-API שלכם. מפתחים צריכים להיות רשומים בארגון שלכם כדי שיוכלו לרשום אפליקציה ולקבל מפתח API או פרטי כניסה אחרים של לקוח שמאפשרים גישה לממשקי ה-API שלכם. בתור ספקי API, אתם קובעים איך להוסיף, לעדכן או להסיר מפתחים בארגון שלכם. אפשר להוסיף אותם באופן ידני דרך ממשק המשתמש, ליצור פורטל מפתחים כדי לרשום אותם דרך אתר, או להגדיר וליישם מנגנון רישום משלכם באמצעות Apigee API. |
|
אפליקציית Apigee (או אפליקציה) |
מפתחי Apigee יוצרים אפליקציות לקוח אחת או יותר שצורכות את ממשקי ה-API שלכם. מפתחים שיוצרים אפליקציות לקוח שקוראות לממשקי API שדורשים בדיקות של פרטי כניסה (כמו מפתחות API או טוקנים של OAuth) צריכים קודם ליצור רישום אפליקציה בארגון שלכם. רישום אפליקציה מספק למפתח את מפתח ה-API, זוג מפתח/סוד או פרטי כניסה אחרים שצריך להשתמש בהם כשאפליקציית הלקוח קוראת לממשקי ה-API שלכם. מכיוון שכל האפליקציות רשומות בארגון, אתם יכולים להשתמש ב-Apigee כדי לעקוב אחרי האפליקציה ולאסוף מידע ניתוחי עליה ועל השימוש שלה בממשקי ה-API שלכם. |
רכיבים נוספים של Apigee שלא מוצגים הם מפתחות API וטוקנים של OAuth.
Apigee תומך בסוגים שונים של אימות, כמו מפתח API פשוט, OAuth דו-שלבי, OAuth תלת-שלבי ועוד.
אם ספק ה-API מציין אימות של מפתח API כמנגנון ההרשאה, אפליקציית הלקוח חייבת להעביר מפתח API עם כל בקשה ל-APIs שלכם. אם המפתח הזה תקין, Apigee מאשר את הבקשה. לחלופין, אם ספק ה-API מציין אימות של טוקן OAuth כמנגנון ההרשאה, אפליקציית הלקוח צריכה קודם לקבל טוקן OAuth, ואז להעביר את הטוקן הזה עם כל בקשה ל-APIs. אם האסימון תקף, Apigee מאשר את הבקשה. אפשר להשתמש בסכימות הרשאה מותאמות אישית אחרות.
כספקי API, אתם צריכים להגדיר דרך שבה מפתחים יכולים לרשום את האפליקציות שלהם. לכל רישום של אפליקציה יש מפתח אחד או יותר או פרטי כניסה שמשויכים אליו. אם אתם מאפשרים למפתחים לרשום את האפליקציות שלהם דרך פורטל למפתחים, המפתחים יכולים לאחזר את המפתח או את פרטי הכניסה שנדרשים כדי לגשת לממשקי ה-API שלכם, באמצעות חוויית שירות עצמי נוחה.
בזמן רישום האפליקציה, מפתחים יכולים לבחור לגשת למוצר API יחיד או לכמה מוצרי API. אפליקציה של מפתח משתמשת באותו מפתח או באותם פרטי כניסה כדי לגשת לכל מוצרי ה-API שמשויכים לאפליקציה.
בכל שלב אפשר לבטל את המפתח, כך שלאפליקציה של המפתח לא תהיה יותר גישה לממשקי ה-API שלכם (גם אם הייצוג הרשום של האפליקציה של המפתח עדיין קיים בארגון שלכם). לחלופין, אפשר לבטל את הגישה של מפתח. במקרה כזה, כל פרטי הכניסה של כל האפליקציות שרשומות על שם המפתח הזה לא יפעלו. אפשר לבטל את השלילה. כש-Apigee יוצר את פרטי הכניסה של האפליקציה, אפשר לציין מועד תפוגה כדי שהמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו אחרי פרק זמן מסוים, והמפתח או פרטי הכניסה יפוגו
משתמשי Apigee
משתמשי Apigee הם חלק מצוות ה-API של הארגון, ויכולים לכלול אנשים כמו אדמינים, יוצרי proxy ל-API ומוצרי API, או משתמשים שעוקבים אחרי ניתוח נתונים וסטטיסטיקות אחרות. משתמשי קצה הם אנשים שמשתמשים באפליקציות שמפתחי Apigee יוצרים. ברוב המקרים, המונח 'משתמש' במסמכי התיעוד האלה מתייחס למשתמש Apigee.
אדמינים יכולים להוסיף משתמשים לארגון.
למשתמשים שונים יכולים להיות תפקידים שונים והרשאות גישה שונות. לדוגמה, אפשר להגדיר חלק מהמשתמשים כאדמינים של הארגון וכאדמינים של פעולות עם הרשאות לשנות את הארגון ואת הרכיבים שלו, ולהגדיר משתמשים אחרים עם הרשאות ליצור פרוקסי של API ומוצרי API, אבל בלי הרשאות לשנות משתמשים אחרים.
משתמשים יכולים להיות חברים בכמה ארגונים. לדוגמה, יכול להיות שהחברה שלכם תגדיר כמה ארגונים ב-Apigee כדי לתמוך בקהילות שונות של מפתחים, למרות שבפועל אותם אנשים יוצרים את כל ה-API proxies ואת מוצרי ה-API, ולכן הם חברים בכל הארגונים שלכם.
לא צריך ליצור ארגון Apigee כדי להיות משתמש. אדמין יכול להוסיף אתכם לארגון קיים.
נכנסים לדף Apigee במסוף Google Cloud .
זכויות גישה וחיוב
לא משנה אם הארגון בתשלום משתמש במודל תמחור של מינוי או של תשלום לפי שימוש, הפריטים שמחושבים לחיוב הם: סביבות, קריאות ל-API ופריסות של שרת proxy.
תוכניות מינוי מאפשרות לשלם מראש על זכויות שימוש, ולקבל בתמורה הנחות משמעותיות. תוכניות מינוי מתאימות לנפחי צריכה גבוהים יותר – כשמדובר במספר גדול יותר של סביבות, בנפח גבוה של קריאות ל-API או במספר גדול של שרתי proxy ל-API שמנוהלים על ידי Apigee. במסגרת המודל של תשלום לפי שימוש, אתם משלמים רק על המשאבים שבהם אתם משתמשים, אבל לא נהנים מהנחות על נפח שימוש.
זכויות גישה למינוי
| ארגונים |
אפשר להפעיל את Apigee בכל פרויקט ב-Google Cloud. פעולה כזו יוצרת ארגון Apigee עבור הפרויקט הזה. אפשר ליצור כמה ארגונים שרוצים. כמו שאין צורך בזכאות או בתשלום כדי ליצור פרויקט בענן ב-Google Cloud, אין צורך בזכאות כדי ליצור ארגון Apigee. |
|---|---|
| סביבות |
הזכאות לשימוש בסביבות מבוטאת ביחידות. יש תהליך של שני שלבים לשימוש בזכאות ליחידות של סביבות: קודם יוצרים סביבה ואז מצרפים את הסביבה לארגון. סביבה נספרת במסגרת הזכאות ליחידות של סביבות אחרי שהיא מצורפת לארגון. במאמר מגבלות מפורט המספר המקסימלי של סביבות בארגון יחיד. אתם יכולים ליצור סביבת Apigee באחד או יותר מהאזורים הזמינים ב-Google Cloud. כל אזור שממופה לסביבה צורך יחידת סביבה אחת מהזכאות שלכם. סביבה שמוקצית באזור יחיד צורכת יחידת סביבה אחת מההרשאה שלכם. סביבה שמוקצה בשני אזורים צורכת שתי יחידות סביבה מההרשאה שלכם. השימוש הכולל ביחידות סביבה הוא סכום מספר יחידות הסביבה שנעשה בהן שימוש בכל הארגונים. ההרשאה הכוללת ליחידות סביבה היא סכום ההרשאה שסופקה ברמת המינוי, בתוספת ההרשאה הנוספת שהתקבלה באמצעות חבילות סביבה. Google אוכפת את ההרשאה לסביבות, ואי אפשר לחרוג ממגבלת ההרשאה. אם תנסו ליצור סביבה שתחרוג ממגבלת ההרשאות שלכם, תקבלו שגיאה. אפשר להרחיב את הזכאות על ידי רכישה של חבילות סביבות נוספות. |
| קריאות ל-API |
Google סופרת כל קריאה ל-API שעוברת עיבוד על ידי Apigee. ההרשאה הכוללת שלכם לקריאות ל-API היא סכום ההרשאה שסופקה ברמת המינוי שלכם בתוספת הרשאה נוספת שקיבלתם באמצעות חבילות של קריאות ל-API. בתוכנית מינוי, Google לא אוכפת את מגבלת ההרשאות לקריאות ל-API. אם חרגתם ממגבלת ההרשאות לקריאות ל-API, Apigee ימשיך לטפל בקריאות ל-API. Google תחייב אתכם על השימוש מעבר למגבלת ההרשאות הקיימת. אתם יכולים להרחיב את מגבלת ההרשאות לקריאות ל-API בכל שלב על ידי רכישת חבילות נוספות של קריאות. |
| פריסות של שרת proxy |
Google סופרת כל פרוקסי API שאתם פורסים. המכסה הכוללת של פריסת פרוקסי היא סכום המכסה שמופיעה ברמת המינוי שלכם בתוספת מכסה נוספת שקיבלתם דרך חבילות פריסת פרוקסי. בתוכנית מינוי, Google לא מגבילה את פריסות ה-proxy בהתאם לזכאות שלכם. אם תפרסו יותר שרתי proxy ממה שאתם זכאים לו, כלומר תחרגו מהזכאות שלכם לפריסת שרתי proxy, מערכת Apigee תמשיך לאפשר לכם לפרוס שרתי proxy חדשים, ותמשיך לטפל בקריאות ל-API. Google תחייב אתכם על השימוש מעבר לזכאות הקיימת. אתם יכולים להרחיב את הזכאות שלכם לפריסת שרתי proxy על ידי רכישת חבילות נוספות של קריאות. |
פרטים נוספים זמינים במאמר בנושא זכויות שימוש במינוי.
הרשאות של תשלום לפי שימוש
| ארגונים |
אפשר להפעיל את Apigee בכל פרויקט ב-Google Cloud. פעולה כזו יוצרת ארגון Apigee עבור הפרויקט הזה. אפשר ליצור כמה ארגונים שרוצים. בדיוק כמו שאין חיוב על יצירת פרויקט ב-Google Cloud, אין חיוב על יצירת ארגון Apigee במסגרת מודל התמחור 'תשלום לפי שימוש'. |
|---|---|
| סביבות |
אפשר לצרף כמה סביבות לארגון Apigee. תהליך השימוש בסביבה כולל שני שלבים: קודם יוצרים את הסביבה ואז מצרפים אותה לארגון. Google מחייבת אתכם על סביבות שמקושרות לארגון. אפשר ליצור עד 85 סביבות בארגון אחד. בסביבות מרובות אזורים, Google מחייבת אתכם על כל אזור שבו הסביבה זמינה. אתם יכולים לבחור כל אחד מהאזורים הזמינים ב-Google Cloud. |
| קריאות ל-API |
Google סופרת כל קריאה ל-API שעוברת עיבוד על ידי Apigee. Google מחייבת אתכם על מספר הקריאות ל-API שהסביבות של Apigee מעבדות. אין הגבלה. Apigee מבצע שינוי גודל אוטומטי וממשיך לטפל בקריאות ל-API, גם כשהעומס גדל. |
| פריסות של שרת proxy |
Google סופרת כל proxy ל-API שאתם פורסים. Google מחייבת אתכם על מספר שרתי ה-proxy של ה-API שפרסתם בסביבות Apigee. |
פרטים נוספים זמינים במאמר בנושא זכויות שימוש בתשלום לפי שימוש.