הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.
לעיון במסמכי התיעוד של
Apigee Edge
ארגון הוא מאגר ברמה העליונה ב-Apigee. הארגון ב-Apigee כולל את כל ה-API proxy והמשאבים שקשורים אליו. בהמשך הנושא הזה נסביר יותר לעומק על ארגונים, אבל הנה כמה נקודות פרקטיות:
- ארגון 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 בארגון באמצעות 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, אבל הוא נועד להראות לכם שהארגון הוא הבסיס ל-Deployment (פריסה).
בטבלה הבאה מפורטים הרכיבים של המודל הארגוני:
| רכיב | תיאור |
|---|---|
| ארגון |
כל ארגון Apigee שייך לפרויקט אחד בלבד ב-Google Cloud, ופרויקט יכול להכיל ארגון אחד לכל היותר. ארגון מכיל סביבות, שרתי proxy ל-API, מוצרי API, חבילות API, אפליקציות ומשתמשים. בעלי החשבונות לא מוגבלים לארגון יחיד. יכול להיות שבעלי חשבונות מסוימים יגדירו כמה ארגונים או יהיו חברים בכמה ארגונים שתומכים בקהילות שונות של מפתחי אפליקציות. |
| סביבות וקבוצות סביבות | סביבה היא סביבת תוכנה מבודדת בתוך ארגון, שבה פורסים שרתי proxy ל-API. אפשר ליצור כמה סביבות בארגון. קבוצת סביבות היא קבוצה של סביבות עם שם מארח אחד או יותר. שם המארח הוא חלק מכתובת ה-URL שמשמשת להפעלת שרתי proxy של API שנפרסו בכל סביבה בקבוצת הסביבות. |
|
API מסוג proxy |
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 עם כל בקשה ל-API. אם המפתח הזה תקין, 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 ומוצרי ה-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 סופרת כל proxy ל-API שאתם פורסים. ההרשאה הכוללת לפריסת שרת proxy היא סכום ההרשאה שסופקה ברמת המינוי שלכם בתוספת הרשאה נוספת שהתקבלה דרך חבילות לפריסת שרת proxy. במסגרת תוכנית מינוי, 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 מחייבת אתכם על מספר ה-API proxies שנפרסו בסביבות Apigee שלכם. |
פרטים נוספים זמינים במאמר בנושא זכויות שימוש בתשלום לפי שימוש.