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

הדף הזה רלוונטי ל-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 כולל את התכונה 'ביקורות' שיכולה לעזור בתרחישים של פתרון בעיות. התכונות האלה מאפשרות לכם לראות מידע כמו מי ביצע פעולות ספציפיות (יצירה, קריאה, עדכון, מחיקה, פריסה וביטול פריסה) ומתי הפעולות בוצעו במשאבי Apigee. עם זאת, אם מתבצעים עדכון או מחיקה של אחד מהמשאבים של Apigee, לא תוכלו לקבל מהביקורות את הנתונים הישנים.

תבנית אנטי

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

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

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

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

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

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

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

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

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

השפעה

  • אם מוחקים משאבים של Apigee, אי אפשר לשחזר את המשאב ואת התוכן שלו מ-Apigee.
  • יכול להיות שבקשות ל-API ייכשלו בגלל שגיאות לא צפויות, מה שיוביל להשבתה עד לשחזור המשאב למצבו הקודם.
  • קשה לחפש תלות הדדית בין פרוקסי של 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 מוצפנות.

קריאה נוספת