אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info
ב-Apigee Edge יש סוגים רבים של משאבים, וכל אחד מהם משמש למטרה שונה. יש משאבים מסוימים שאפשר להגדיר (כלומר ליצור, לעדכן ו/או למחוק) רק דרך ממשק המשתמש של Edge, ממשקי API לניהול או כלים שמשתמשים בממשקי API לניהול, ורק משתמשים עם התפקידים וההרשאות הנדרשים יכולים לעשות זאת. לדוגמה, רק אדמינים ארגוניים ששייכים לארגון ספציפי יכולים להגדיר את המשאבים האלה. המשמעות היא שמשתמשי הקצה לא יכולים להגדיר את המשאבים האלה דרך פורטלים למפתחים או בכל דרך אחרת. המקורות האלה כוללים:
- ממשקי proxy ל-API
- תהליכי עבודה משותפים
- מוצרי API
- קובצי מטמון
- מכונות KVM
- מאגרי מפתחות ומאגרי אמון
- מארחים וירטואליים
- שרתי היעד
- קובצי משאבים
למשאבים האלה יש גישה מוגבלת, אבל אם יבוצעו בהם שינויים, גם על ידי המשתמשים המורשים, הנתונים ההיסטוריים פשוט יכוסו על ידי הנתונים החדשים. הסיבה לכך היא שהמשאבים האלה נשמרים ב-Apigee Edge רק לפי המצב הנוכחי שלהם. החריגים העיקריים לכלל הזה הם שרתים proxy של API ותהליכים משותפים.
שרתים proxy ל-API ותהליכים משותפים במסגרת בקרת גרסאות
שרתים proxy של API ותהליכי עבודה משותפים מנוהלים – כלומר נוצרים, מתעדכנים ופורסים – באמצעות גרסאות. הגרסאות ממוספרות בסדר עוקב, כך שאפשר להוסיף שינויים חדשים ולשמור אותם כגרסה חדשה, או לחזור לשינוי קודם על ידי פריסה של גרסה קודמת של שרת ה-proxy או התהליך המשותף של ה-API. בכל זמן נתון, יכולה להיות רק גרסה אחת של שרת proxy ל-API או של תהליך עבודה משותף שנפרס בסביבה, אלא אם לגרסאות יש נתיב בסיס שונה.
אמנם שרת ה-API העקיף והתהליכים המשותפים מנוהלים באמצעות גרסאות מתוקנות, אבל אם מבצעים שינויים בגרסה קיימת, אי אפשר לבצע חזרה לגרסה הקודמת כי השינויים הישנים פשוט נמחקים.
ביקורות והיסטוריה
ב-Apigee Edge יש את התכונות ביקורות והיסטוריה של API, מוצרים וארגונים, שיכולות לעזור בתרחישים של פתרון בעיות. התכונות האלה מאפשרות לכם לראות מידע כמו מי ביצע פעולות ספציפיות (יצירה, קריאה, עדכון, מחיקה, פריסה וביטול פריסה) ומתי בוצעו הפעולות האלה במשאבי Edge. עם זאת, אם מתבצעות פעולות עדכון או מחיקה של משאבי Edge, הביקורות לא יכולות לספק את הנתונים הישנים יותר.
דפוס שלילי
ניהול המשאבים של Edge (המפורטים למעלה) ישירות דרך ממשק המשתמש של Edge או ממשקי API לניהול, בלי להשתמש במערכת לבקרת מקורות
יש טעות נפוצה לגבי Apigee Edge, לפיה אפשר לשחזר משאבים למצב הקודם שלהם אחרי שינויים או מחיקה. עם זאת, ב-Edge Cloud אי אפשר לשחזר משאבים למצב הקודם. לכן, באחריות המשתמש לוודא שכל הנתונים שקשורים למשאבי Edge מנוהלים באמצעות ניהול בקרת מקורות, כדי שניתן יהיה לשחזר נתונים ישנים במהירות במקרה של מחיקה בטעות או במצבים שבהם צריך לבטל שינוי. הדבר חשוב במיוחד בסביבות ייצור שבהן הנתונים האלה נדרשים לתנועה בסביבת זמן הריצה.
נציג כמה דוגמאות ונראה איזה נזק יכול להיגרם אם הנתונים לא מנוהלים באמצעות מערכת לבקרת גרסאות, ומשנים או מוחקים אותם ביודעין או שלא ביודעין:
דוגמה 1: מחיקה או שינוי של שרת proxy ל-API
כששומרים עותק proxy של API או פורסים שינוי בגרסה קיימת, אי אפשר לשחזר את הקוד הקודם. אם שרת ה-API proxy מכיל קוד 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.
שיטה מומלצת
- אפשר להשתמש בכל מערכת ניהול גרסאות רגילה בשילוב עם צינור עיבוד נתונים לאינטגרציה רציפה ולפריסה רציפה (CICD) כדי לנהל שרתים proxy של API ותהליכים משותפים.
- אפשר להשתמש בכל מערכת ניהול גרסאות רגילה לניהול המשאבים האחרים של Edge, כולל מוצרי API, מטמון, מכונות KVM, שרתי יעד, מארחים וירטואליים ומאגרי מפתחות.
- אם יש משאבי Edge קיימים, משתמשים בממשקי API לניהול כדי לקבל את פרטי ההגדרה שלהם כמטען שימושי בפורמט JSON/XML, ולאחר מכן שומרים אותם בניהול בקרת הגרסאות.
- ניהול עדכונים חדשים למשאבים האלה באמצעות ניהול בקרת הגרסאות.
- אם צריך ליצור משאבים חדשים ב-Edge או לעדכן משאבים קיימים ב-Edge, צריך להשתמש ב-payload המתאים של JSON/XML שנשמר בניהול בקרת הגרסאות ולעדכן את ההגדרה ב-Edge באמצעות ממשקי API לניהול.
* אי אפשר לייצא מכונות KVM מוצפנות כטקסט ללא הצפנה מה-API. המשתמשים אחראים על תיעוד הערכים שמוזנים למכונות KVM מוצפנות.