אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע
ב-Apigee Edge יש הרבה סוגים שונים של משאבים, ולכל אחד מהם יש מטרה שונה. יש משאבים מסוימים שאפשר להגדיר (כלומר, ליצור, לעדכן או למחוק) רק באמצעות ממשק המשתמש של Edge, ממשקי ניהול של API או כלים שמשתמשים בממשקי ניהול של API, ורק על ידי משתמשים עם התפקידים וההרשאות הנדרשים. לדוגמה, רק אדמינים בארגון ששייכים לארגון ספציפי יכולים להגדיר את המשאבים האלה. המשמעות היא שמשתמשי קצה לא יכולים להגדיר את המשאבים האלה דרך פורטלים למפתחים, וגם לא בכל דרך אחרת. מקורות המידע האלה כוללים:
- ממשקי proxy ל-API
- תהליכי עבודה משותפים
- מוצרי API
- קובצי מטמון
- KVMs
- מאגרי מפתחות ומאגרי אישורים
- מארחים וירטואליים
- שרתי היעד
- קובצי משאבים
למשאבים האלה יש גישה מוגבלת, אבל אם מתבצעים בהם שינויים, גם על ידי משתמשים מורשים, הנתונים ההיסטוריים פשוט נמחקים ומוחלפים בנתונים החדשים. הסיבה לכך היא שהמשאבים האלה מאוחסנים ב-Apigee Edge רק בהתאם למצב הנוכחי שלהם. החריגים העיקריים לכלל הזה הם שרתי proxy של API ורכיבי Shared Flow.
גרסאות של proxy ל-API ותהליכים משותפים
פרוקסי של API ותהליכי עבודה משותפים מנוהלים – כלומר, נוצרים, מתעדכנים ונפרסים – באמצעות גרסאות. הגרסאות ממוספרות ברצף, כך שאפשר להוסיף שינויים חדשים ולשמור אותם כגרסה חדשה, או לבטל שינוי על ידי פריסת גרסה קודמת של ה-API proxy או של הרכיב Shared Flow. בכל נקודת זמן, יכולה להיות רק גרסה אחת של proxy ל-API או של תהליך משותף שמוצבת בסביבה, אלא אם לגרסאות יש נתיב בסיס שונה.
למרות שניהול ה-API proxies וה-shared flows מתבצע באמצעות גרסאות, אם מבצעים שינויים בגרסה קיימת, אין אפשרות לבטל את השינויים כי הם פשוט מחליפים את השינויים הקודמים.
ביקורות והיסטוריה
Apigee Edge מספק את התכונות Audits ו-API, Product, and organization history שיכולות לעזור בתרחישי פתרון בעיות. התכונות האלה מאפשרות לכם לראות מידע כמו מי ביצע פעולות ספציפיות (יצירה, קריאה, עדכון, מחיקה, פריסה וביטול פריסה) ומתי הפעולות בוצעו במשאבי Edge. עם זאת, אם מתבצעים עדכון או מחיקה של משאבים כלשהם ב-Edge, לא תוכלו לקבל מהביקורות את הנתונים הישנים.
תבנית אנטי
ניהול משאבי Edge (שמפורטים למעלה) ישירות דרך ממשק המשתמש של Edge או ממשקי ניהול של Edge, בלי להשתמש במערכת לניהול קוד מקור
יש תפיסה מוטעית שלפיה Apigee Edge יוכל לשחזר משאבים למצב הקודם שלהם אחרי שינויים או מחיקות. עם זאת, Edge Cloud לא מספק שחזור של משאבים למצב הקודם שלהם. לכן, באחריות המשתמש לוודא שכל הנתונים שקשורים למשאבי Edge מנוהלים באמצעות מערכת לניהול בקרת מקורות, כדי שיהיה אפשר לשחזר במהירות נתונים ישנים במקרה של מחיקה בשוגג או במצבים שבהם צריך לבטל שינוי כלשהו. זה חשוב במיוחד בסביבות ייצור שבהן הנתונים האלה נדרשים לתנועה בזמן ריצה.
כדי להסביר את זה, נשתמש בכמה דוגמאות ונסביר מה יכול לקרות אם הנתונים לא מנוהלים באמצעות מערכת בקרת מקורות, ועוברים שינוי או נמחקים ביודעין או שלא ביודעין:
דוגמה 1: מחיקה או שינוי של proxy ל-API
כשמוחקים proxy ל-API או כשפורסים שינוי בגרסה קיימת, אי אפשר לשחזר את הקוד הקודם. אם proxy ל-API מכיל קוד Java, JavaScript, Node.js או Python שלא מנוהל במערכת לניהול בקרת מקור (SCM) מחוץ ל-Apigee, יכול להיות שתאבדו הרבה עבודת פיתוח ומאמץ.
דוגמה 2: קביעת שרתי proxy ל-API באמצעות מארחים וירטואליים ספציפיים
התוקף של אישור במארח וירטואלי עומד לפוג, וצריך לעדכן את המארח הווירטואלי. אם יש הרבה שרתי proxy ל-API, יכול להיות שיהיה קשה לזהות אילו שרתי proxy ל-API משתמשים במארח הווירטואלי הזה למטרות בדיקה. אם שרתי ה-proxy של ה-API מנוהלים במערכת SCM מחוץ ל-Apigee, יהיה קל לחפש במאגר.
דוגמה 3: מחיקה של מאגר מפתחות או מאגר אישורים
אם מוחקים מאגר מפתחות או מאגר אישורים שמשמשים להגדרת מארח וירטואלי או שרת יעד, לא ניתן יהיה לשחזר אותם אלא אם פרטי ההגדרה של מאגר המפתחות או מאגר האישורים, כולל אישורים או מפתחות פרטיים, מאוחסנים בבקרת מקור.
השפעה
- אם מוחקים משאבים של Edge, אי אפשר לשחזר את המשאב ואת התוכן שלו מ-Apigee Edge.
- יכול להיות שבקשות ל-API ייכשלו בגלל שגיאות לא צפויות, מה שיוביל להשבתה עד לשחזור המשאב למצבו הקודם.
- קשה לחפש תלות הדדית בין שרתי proxy של API לבין משאבים אחרים ב-Apigee Edge.
שיטה מומלצת
- משתמשים בכל מערכת SCM רגילה בשילוב עם צינור עיבוד נתונים של אינטגרציה רציפה ופריסה רציפה (CICD) לניהול של שרתי proxy של API ושל רכיבי Shared Flow.
- אפשר להשתמש בכל מערכת SCM רגילה לניהול שאר המשאבים של Edge, כולל מוצרי API, מטמונים, KVM, שרתי יעד, מארחים וירטואליים ומאגרי מפתחות.
- אם יש משאבי Edge קיימים, צריך להשתמש בממשקי ניהול API כדי לקבל את פרטי ההגדרה שלהם כמטען ייעודי (payload) בפורמט JSON או XML, ולאחסן אותם בניהול בקרת מקור.
- לנהל את העדכונים החדשים במשאבים האלה באמצעות מערכת לניהול בקרת מקור.
- אם יש צורך ליצור משאבי Edge חדשים או לעדכן משאבי Edge קיימים, אז משתמשים במטען הייעודי (payload) המתאים של JSON/XML שמאוחסן בניהול בקרת המקורות ומעדכנים את ההגדרה ב-Edge באמצעות ממשקי ניהול API.
* אי אפשר לייצא מכונות KVM מוצפנות כטקסט פשוט מה-API. המשתמש אחראי לשמור תיעוד של הערכים שמוזנים למכונות KVM מוצפנות.