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

יצירה מחדש של המופע

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

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

מידע על שינויים בכיוון צפון

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

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

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

שינויים בנסיעה דרומה

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

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