כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של
Apigee X. מידע
ב-Apigee Edge יש מגוון סוגים של משאבים, ולכל אחד מהם יש מטרה אחרת. יש משאבים מסוימים שאפשר להגדיר (כלומר ליצור, לעדכן ו/או למחוק) רק דרך ממשק המשתמש של Edge, ממשקי ה-API לניהול או הכלים שמשתמשים בממשקי API לניהול, ומשתמשים עם ההרשאות והתפקידים הנדרשים. לדוגמה, רק מנהלי חשבון ארגוני ששייכים לארגון ספציפי יכולים להגדיר את המשאבים האלה. המשמעות היא שמשתמשי הקצה לא יכולים להגדיר את המשאבים האלה באמצעות פורטלים למפתחים, וגם לא בכל דרך אחרת. מקורות המידע האלה כוללים:
- ממשקי proxy ל-API
- תהליכי עבודה משותפים
- מוצרי API
- קובצי מטמון
- מכונות KVM
- מאגרי מפתחות ו-Truststores
- מארחים וירטואליים
- שרתי היעד
- קובצי משאבים
הגישה למשאבים האלה מוגבלת, אבל אם עורכים בהם שינויים גם על ידי המשתמשים המורשים, הנתונים ההיסטוריים מוחלפים בנתונים החדשים. הסיבה לכך היא שהמשאבים האלה מאוחסנים ב-Apigee Edge רק בהתאם למצבם הנוכחי. החריגים העיקריים לכלל הזה הם שרתי proxy של API ותהליכי עבודה משותפים.
שרתי proxy של API ותהליכי עבודה משותפים בבקרת גרסאות
שרתי proxy של API ותהליכי עבודה משותפים מנוהלים – במילים אחרות, נוצרים, מעודכנים ופרוסים – באמצעות גרסאות קודמות. הגרסאות ממוספרות ברצף, כך שאפשר להוסיף שינויים חדשים ולשמור אותם כגרסה חדשה או לבטל שינוי באמצעות פריסת גרסה קודמת של תהליך העבודה המשותף/שרת ה-proxy של ה-API. בכל שלב יכול להיות רק גרסה אחת של שרת proxy או זרימה משותפת של API שנפרסים בסביבה, אלא אם לגרסאות קודמות יש נתיב בסיס שונה.
על אף ששרתי ה-proxy והזרימות המשותפים של ה-API מנוהלים באמצעות תיקונים, אם מתבצעים שינויים בגרסה קודמת, לא ניתן לחזור למצב הקודם כי השינויים הישנים פשוט מחליפים.
ביקורות והיסטוריה
ב-Apigee Edge אפשר למצוא את התכונות לביקורות ולהיסטוריית ה-API, המוצר והארגון שיכולות לעזור בפתרון בעיות. התכונות האלה מאפשרות להציג מידע כמו מי שביצע פעולות ספציפיות (יצירה, קריאה, עדכון, מחיקה, פריסה וביטול פריסה) ומתי הפעולות בוצעו במשאבים של Edge. עם זאת, אם מתבצעות פעולות עדכון או מחיקה באחד ממשאבי Edge, הביקורות לא יכולות לספק את הנתונים הישנים.
דוגמת עיצוב
ניהול המשאבים של Edge (שמפורטים למעלה) ישירות דרך ממשק המשתמש של Edge או ממשקי API לניהול בלי שימוש במערכת בקרת מקורות
קיימת תפיסה שגויה ש-Apigee Edge יוכל לשחזר משאבים למצב הקודם שלהם לאחר שינויים או מחיקה. עם זאת, אי אפשר לשחזר משאבים למצב הקודם ב-Edge Cloud. לכן, המשתמשים אחראים לוודא שכל הנתונים שקשורים למשאבי Edge מנוהלים דרך ניהול בקרת מקורות, כדי שניתן יהיה לשחזר נתונים ישנים במהירות במקרה של מחיקה מקרית או מצבים שבהם יש צורך לבטל שינויים כלשהם. הדבר חשוב במיוחד לסביבות ייצור שבהן הנתונים האלה נדרשים לצורך תעבורת נתונים בזמן ריצה.
נסביר זאת בעזרת כמה דוגמאות ואיזו השפעה עלולה להיגרם אם הנתונים אינם מנוהלים באמצעות מערכת לבקרת מקורות ומשנים/מוחקים אותם ביודעין או שלא בידיעה:
דוגמה 1: מחיקה או שינוי של שרת proxy ל-API
אחרי שמוחקים שרת proxy של API, או כשמתבצעת פריסה של שינוי בגרסה קיימת, אי אפשר לשחזר את הקוד הקודם. אם שרת ה-API של שרת ה-API מכיל קוד Java, JavaScript, Node.js או Python שאינו מנוהל במערכת לניהול בקרות מקור (SCM) מחוץ ל-Apigee, עלול להיעלם מאמצי פיתוח רבים.
דוגמה 2: קביעת שרתי proxy של API באמצעות מארחים וירטואליים ספציפיים
תוקף האישור במארח וירטואלי עומד לפוג וצריך לעדכן את המארח הווירטואלי. אם יש הרבה שרתי proxy של API, יכול להיות שתתקשו לזהות באילו שרתי proxy של API משתמשים במארח הווירטואלי למטרות בדיקה. אם שרתי ה-proxy של ה-API מנוהלים במערכת SCM מחוץ ל-Apigee, אפשר לחפש בקלות במאגר.
דוגמה 3: מחיקה של keystore/truststore
אם יימחקו מאגר מפתחות או Truststore שמשמש מארח וירטואלי או הגדרה של שרת יעד, לא תהיה אפשרות לשחזר אותם, אלא אם פרטי התצורה של ה-Keystore/truststore, כולל אישורים ו/או מפתחות פרטיים, מאוחסנים בבקרת המקור.
השפעה
- אם משאבים כלשהם של Edge יימחקו, לא ניתן יהיה לשחזר את המשאב ואת התוכן שלו מ-Apigee Edge.
- בקשות API עלולות להיכשל עם שגיאות לא צפויות שמובילות להפסקה זמנית בשירות, עד שהמשאב ישוחזר למצבו הקודם.
- קשה לחפש יחסי תלות בין שרתי proxy של API ומשאבים אחרים ב-Apigee Edge.
שיטה מומלצת
- כדי לנהל שרתי proxy של API ותהליכי עבודה משותפים, אפשר להשתמש בכל SCM סטנדרטי בשילוב עם צינור עיבוד נתונים של אינטגרציה רציפה ופריסה רציפה (CICD).
- משתמשים בכל SCM סטנדרטי לניהול משאבי Edge האחרים, כולל מוצרי API, מטמון, KVMs, שרתי יעד, מארחים וירטואליים ומאגרי מפתחות.
- אם יש משאבי Edge קיימים, תוכלו להשתמש בממשקי API לניהול כדי לקבל את פרטי התצורה שלהם כמטען ייעודי (payload) של JSON/XML, ולאחסן אותם בניהול בקרת המקור.
- אפשר לנהל עדכונים חדשים למשאבים האלה בניהול של בקרת המקור.
- אם צריך ליצור משאבים חדשים של Edge או לעדכן משאבים קיימים של Edge, צריך להשתמש במטען הייעודי (payload) המתאים של JSON/XML שמאוחסן בניהול בקרת המקור, ולעדכן את ההגדרה ב-Edge באמצעות ממשקי API לניהול.
* לא ניתן לייצא מכונות KVM מוצפנים בטקסט פשוט מה-API. המשתמש אחראי לשמור תיעוד של הערכים שמוזנים במכונות KVM מוצפנות.