יצירה מחדש של מכונת Apigee ללא השבתה

הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.

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

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

מבוא

למופעי Apigee שנוצרו לפני 25 בינואר 2022 אין מספיק מרחב של כתובות פרוטוקול אינטרנט (IP) כדי לאפשר את הרחבת נפח העבודה של Apigee כדי לטפל בתנועת API גדלה, או כדי לאפשר לכם להוסיף יותר מ-10 סביבות למופע.

ב-24 בינואר 2022, Apigee הציגה שיפור כדי לפתור את הבעיה הזו. השיפור הזה מקטין את טווח כתובות ה-IP שנדרש כדי לקשר את רשת ה-VPC עם Apigee, ומשתמש בכתובות IP ציבוריות בשימוש פרטי (PUPI) כדי לאפשר לעומסי עבודה להתרחב למגבלות גבוהות יותר.

מה צריך לעשות?

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

איך קובעים את תאריך היצירה של מופע

כדי לקבוע את תאריך היצירה של מופע Apigee:

  1. פירוט של כל המקרים של Apigee בארגון: 
    AUTH="Authorization: Bearer $(gcloud auth print-access-token)"

curl -i -X GET -H "$AUTH" \
"https://apigee.googleapis.com/v1/organizations/PROJECT_ID/instances"

    כאשר:

    • ‫AUTH היא כותרת האימות עם טוקן bearer. חשוב לוודא שפרויקט ברירת המחדל של gcloud מוגדר כ-PROJECT_ID.
    • ‫PROJECT_ID הוא מזהה הפרויקט ב-Cloud שיצרתם כשביצעתם הקצאת משאבים ל-Apigee.

    פלט לדוגמה: 

    {
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.117.200.2",
      "port": "443",
      "createdAt": "1642698826000",
      "lastModifiedAt": "1655745226000",
      "diskEncryptionKeyName": "projects/myproject/locations/us-west1/keyRings/my-key-ring/cryptoKeys/my-key",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-8-0-apigee-33",
      "ipRange": "10.117.200.0/22,10.81.174.192/28",
      "consumerAcceptList": [
        "myproject"
      ],
      "serviceAttachment": "projects/z11f28c6f3104980e-tp/regions/us-west1/serviceAttachments/apigee-us-west1-lbko"
    }
  ]
}
  2. לכל מופע, בודקים את הערך של השדה createdAt על ידי פענוח חותמת הזמן של מערכת Unix כדי לקבל את התאריך.
    • אם מופע נוצר ב-25 בינואר 2022 או אחריו, לא צריך לבצע פעולות נוספות לגבי המופע הזה.
    • אם מופע נוצר לפני 25 בינואר 2022, מומלץ להחליף את המופע, כמו שמוסבר במסמך הזה.

מידע על תהליך השחזור

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

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

דרישות מוקדמות

לפני שמתחילים בשלבים ליצירה מחדש של המכונה:

  • צריך להכיר את התהליך שבו נוצר מופע Apigee. השלבים ליצירה מחדש של המופע תלויים בפרטים על אופן ההגדרה של המופע המקורי.
  • צריכה להיות לכם הרשאה להקצאת Apigee לפחות בשני אזורים. אם אתם לא בטוחים שיש לכם זכאות מספקת, אתם יכולים ליצור מכונה וירטואלית באזור חדש. אם אין לכם את ההרשאה המתאימה, הניסיון ייכשל ותוצג שגיאת הגבלה. במקרה כזה, צריך לפנות לתמיכת Apigee כדי לקבל חריגה זמנית להגדלת המגבלה האזורית. אם כבר יש לכם הרשאה להשתמש בשירות בשני אזורים או יותר, מומלץ לפנות אלינו כדי לקבל חריגה זמנית, וכך להימנע מהפעלת עומס העבודה של הייצור עם מופע מופחת במהלך תהליך היצירה מחדש.
  • כדי ליצור את המופע החדש, צריך שיהיה מקום בפרויקט לטווחים נוספים של כתובות IP של בלוקים ‎/22 ו-‎/28. אפשר לעיין גם במאמר התאמת גודל הרשת. אפשר לשחרר את טווחי הכתובות האלה כשמוחקים את האזור הנוסף אחרי ששחזור המופע מסתיים. שימו לב שאפשר להגדיר את הבלוק ‎/22. אתם יכולים לבחור באיזה בלוק /28‏ Apigee ישתמש, או שאם לא תבחרו, המערכת תקצה בלוק זמין באופן אוטומטי.

יצירה מחדש של המכונה

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

  1. חשוב לוודא שאתם עומדים בדרישות המוקדמות.
  2. מורידים את הסקריפטים מ-GitHub.
  3. פועלים לפי השלבים בקובץ README במאגר Git כדי ליצור את המופע החדש.
  4. מגדירים מחדש את החיבורים צפונה ודרומה כך שיצביעו על מופע Apigee החדש. מידע נוסף על שינויים בנתונים שיוצאו ומידע נוסף על שינויים בנתונים שיועלו

מידע על שינויים בנתונים שמועברים מהמכשיר לשרת

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

הסקריפטים שסופקו מגדירים מחדש את הקצה העורפי של מאזן העומסים. אם ניתוב הרשת של המופע הוגדר באמצעות קבוצת מופעי מכונה מנוהלים (MIG), סקריפט שסופק יוצר מחדש את ה-MIG שמעביר את התנועה לנקודת הקצה של Apigee, ומצרף את ה-MIG כקצה עורפי לשירות הקיים של הקצה העורפי. אם הניתוב הוגדר באמצעות Private Service Connect, סקריפט יוצר מחדש את קבוצת נקודות הקצה ברשת (NEG) לקובץ המצורף של נקודת הקצה של שירות Apigee, ומצרף את ה-NEG החדש כקצה עורפי לשירות הקיים של הקצה העורפי.

שימו לב: לא תצטרכו לשנות את רשומות שם המארח בקבוצות סביבות שמשויכות למופע הישן.

שינויים בכיוון דרום

תעבורת נתונים דרומה מתייחסת לתעבורת נתונים של API מ-Apigee לשירותי היעד של ה-proxy ל-API.

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