אנטי-תבנית: ניהול משאבים בלי להשתמש בניהול בקרת מקור

הדף הזה רלוונטי ל-Apigee ול-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

‫Apigee מספק הרבה סוגים שונים של משאבים, ולכל אחד מהם יש מטרה שונה. יש משאבים מסוימים שאפשר להגדיר (כלומר, ליצור, לעדכן או למחוק) רק דרך ממשק המשתמש של Apigee, ממשקי ה-API של Apigee או כלים שמשתמשים בממשקי API, ורק על ידי משתמשים עם התפקידים וההרשאות הנדרשים. לדוגמה, רק אדמינים בארגון ששייכים לארגון ספציפי יכולים להגדיר את המשאבים האלה. כלומר, משתמשי קצה לא יכולים להגדיר את המשאבים האלה דרך פורטלים למפתחים או בכל דרך אחרת. מקורות המידע האלה כוללים:

  • ממשקי proxy ל-API
  • תהליכי עבודה משותפים
  • מוצרי API
  • קובצי מטמון
  • KVMs
  • מאגרי מפתחות ומאגרי אישורים מהימנים
  • מארחים וירטואליים
  • שרתי היעד
  • קובצי משאבים

למשאבים האלה יש גישה מוגבלת, אבל אם מתבצעים בהם שינויים, גם על ידי משתמשים מורשים, הנתונים ההיסטוריים פשוט נמחקים ומוחלפים בנתונים החדשים. הסיבה לכך היא שהמשאבים האלה מאוחסנים ב-Apigee רק בהתאם למצב הנוכחי שלהם. החריגים העיקריים לכלל הזה הם שרתי proxy של API ורכיבי Shared Flow.

גרסאות של proxy ל-API ותהליכי עבודה משותפים

פרוקסי של API ותהליכי עבודה משותפים מנוהלים – כלומר, נוצרים, מתעדכנים ונפרסים – באמצעות גרסאות. הגרסאות ממוספרות ברצף, כך שאפשר להוסיף שינויים חדשים ולשמור אותם כגרסה חדשה, או לבטל שינוי על ידי פריסת גרסה קודמת של ה-API proxy או של הרכיב Shared Flow. בכל נקודת זמן, יכולה להיות רק גרסה אחת של proxy ל-API או של תהליך עבודה משותף שמוצבת בסביבה, אלא אם לגרסאות יש נתיב בסיס שונה.

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

ביקורות והיסטוריה

‫Apigee מספקת את התכונה Audits (ביקורות), שיכולה לעזור בתרחישי פתרון בעיות. התכונות האלה מאפשרות לכם לראות מידע כמו מי ביצע פעולות ספציפיות (יצירה, קריאה, עדכון, מחיקה, פריסה וביטול פריסה) ומתי הפעולות בוצעו במשאבי Apigee. עם זאת, אם מתבצעים עדכונים או פעולות מחיקה במשאבי Apigee, הביקורות לא יכולות לספק לכם את הנתונים הישנים.

תבנית אנטי

ניהול משאבי Apigee (שמפורטים למעלה) ישירות דרך ממשקי המשתמש או ממשקי ה-API של Apigee בלי להשתמש במערכת בקרת מקורות

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

כדי להסביר את זה, נשתמש בכמה דוגמאות ונסביר מה יכול לקרות אם הנתונים לא מנוהלים באמצעות מערכת בקרת מקורות, ועוברים שינוי או נמחקים ביודעין או שלא ביודעין:

דוגמה 1: מחיקה או שינוי של proxy ל-API

כשמוחקים proxy ל-API או כשפורסים שינוי בגרסה קיימת, אי אפשר לשחזר את הקוד הקודם. אם שרת ה-proxy של ה-API מכיל קוד Java,‏ JavaScript או Python שלא מנוהל במערכת לניהול בקרת מקור (SCM) מחוץ ל-Apigee, יכול להיות שתאבדו הרבה עבודת פיתוח ומאמץ.

דוגמה 2: קביעת שרתי proxy ל-API באמצעות מארחים וירטואליים ספציפיים

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

דוגמה 3: מחיקה של מאגר מפתחות או מאגר אישורים

אם מוחקים מאגר מפתחות או מאגר אישורים שמשמשים להגדרת מארח וירטואלי או שרת יעד, לא ניתן יהיה לשחזר אותם אלא אם פרטי ההגדרה של מאגר המפתחות או מאגר האישורים, כולל אישורים או מפתחות פרטיים, מאוחסנים בבקרת מקור.

השפעה

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

שיטה מומלצת

  • משתמשים בכל מערכת SCM רגילה בשילוב עם צינור עיבוד נתונים של אינטגרציה רציפה ופריסה רציפה (CICD) לניהול של שרתי proxy של API ושל רכיבי Shared Flow.
  • אפשר להשתמש בכל מערכת SCM רגילה לניהול שאר המשאבים של Apigee, כולל מוצרי API, מטמונים, KVM, שרתי יעד, מארחים וירטואליים ומאגרי מפתחות.
    • אם יש משאבי Apigee קיימים, צריך להשתמש בממשקי Apigee API כדי לקבל את פרטי ההגדרה שלהם כמטען ייעודי (payload) בפורמט JSON או XML, ולאחסן אותם במערכת לניהול בקרת מקור.
    • לנהל את העדכונים החדשים במשאבים האלה באמצעות מערכת לניהול בקרת מקורות.
    • אם יש צורך ליצור משאבים חדשים ב-Apigee או לעדכן משאבים קיימים, צריך להשתמש במטען הייעודי (payload) המתאים בפורמט JSON או XML שמאוחסן במערכת לניהול בקרת מקורות, ולעדכן את ההגדרות ב-Apigee באמצעות ממשקי API.

* אי אפשר לייצא מכונות KVM מוצפנות כטקסט פשוט מה-API. המשתמש אחראי לשמור תיעוד של הערכים שמוזנים למכונות KVM מוצפנות.

קריאה נוספת