עדכון של Apigee Edge 4.52.02 או 4.53.00 לגרסה 4.53.01

‫Apigee תומך בשדרוג של Edge for Private Cloud ישירות מגרסה 4.52.02 או 4.53.00 לגרסה 4.53.01. בדף הזה מוסבר איך לבצע שדרוגים כאלה.

סקירה כללית של נתיבי שדרוג תואמים זמינה בטבלת התאימות לשדרוג של מהדורות Edge for Private Cloud.

מי יכול לבצע את העדכון

האדם שמבצע את העדכון צריך להיות אותו אדם שהתקין את Edge במקור, או אדם שמריץ את העדכון כמשתמש root.

אחרי שמתקינים את חבילות ה-RPM של Edge, כל אחד יכול להגדיר אותן.

אילו רכיבים צריך לעדכן

צריך לעדכן את כל רכיבי Edge. דפדפן Edge לא תומך בהגדרה שמכילה רכיבים מכמה גרסאות.

עדכון הדרישות המוקדמות

סקירת השינויים ב-Edge לענן פרטי 4.53.01

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

לפני שמשדרגים את Apigee Edge, חשוב לוודא שמתקיימות הדרישות המוקדמות הבאות:

  • גיבוי של כל הצמתים
    לפני שמבצעים עדכון, מומלץ לבצע גיבוי מלא של כל הצמתים מטעמי בטיחות. כדי לבצע את הגיבוי, צריך לפעול לפי ההליך שמתאים לגרסה הנוכחית של Edge.

    כך תוכלו להכין תוכנית גיבוי למקרה שהעדכון לגרסה חדשה לא יפעל כמו שצריך. מידע נוסף על גיבוי זמין במאמר גיבוי ושחזור.

  • מוודאים ש-Edge פועל
    כדי לוודא ש-Edge פועל במהלך תהליך העדכון, משתמשים בפקודה: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • אימות הדרישות המוקדמות של Cassandra

    אם שדרגתם בעבר מגרסה ישנה יותר של Edge for Private Cloud לגרסה 4.52.02, ועכשיו אתם מתכננים לשדרג לגרסה 4.53.01, הקפידו להשלים את השלבים הנדרשים אחרי השדרוג של Cassandra. השלבים האלה מפורטים במסמכי השדרוג של גרסה 4.52.02, ומוזכרים גם בקטע תנאים מוקדמים לשדרוג Cassandra. אם אתם לא בטוחים שהשלבים האלה בוצעו במהלך השדרוג הקודם, עליכם לבצע אותם שוב לפני שתמשיכו בשדרוג לגרסה 4.53.01.

  • הגדרת מפתחות ואישורים של ספק זהויות ב-Edge לענן פרטי 4.53.01

    ב-Edge for Private Cloud 4.53.01, מפתחות ואישורים של ספק זהויות (IdP) שמשמשים ברכיב apigee-sso מוגדרים עכשיו דרך מאגר מפתחות. תצטרכו לייצא את המפתח והאישור שבהם השתמשתם קודם ל-keystore. לפני שמעדכנים את רכיב ה-SSO, צריך לפעול לפי השלבים המפורטים בקטע הוראות לעדכון Apigee SSO מגרסאות ישנות יותר.

  • דרישות Python
    לפני שמנסים לבצע את השדרוג, צריך לוודא שבכל הצמתים, כולל צמתי Cassandra, מותקנת גרסה Python 3.

אילו שלבים מיוחדים צריך לבצע כדי לשדרג

כדי לשדרג ל-Edge for Private Cloud 4.53.01, כדאי להפעיל שלבים ספציפיים לשדרוג תוכנה מסוימת. השלבים הנדרשים משתנים בהתאם לגרסה הנוכחית. בטבלה שלמטה מפורטות תוכנות שדורשות שלבים נוספים, ומופיעות הוראות מפורטות לכל אחת מהן. אחרי שמשלימים את המשימות הנדרשות, חוזרים לתהליך השדרוג הראשי כדי להמשיך בתהליך השדרוג.

גרסה נוכחית תוכנה שנדרשים שלבים מיוחדים כדי לשדרג אותה לגרסה 4.53.01
4.52.02 ‫LDAP, ‏ Cassandra, ‏ Zookeeper, ‏ Postgres
4.53.00 ‫LDAP, ‏ Zookeeper, ‏ Postgres

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

הפצה אוטומטית של הגדרות הנכס

אם הגדרתם מאפיינים כלשהם על ידי עריכת קובצי .properties ב-/opt/apigee/customer/application, הערכים האלה יישמרו אחרי העדכון.

נדרש שדרוג ל-OpenLDAP 2.6

בהמשך מפורט תהליך השדרוג של שירות ה-LDAP הבסיסי של Apigee Edge לענן פרטי מ-OpenLDAP 2.4 מדור קודם ל-OpenLDAP 2.6. השדרוג הזה הוא דרישה מחייבת לעדכון לגרסה 4.53.01 ומעלה של Apigee Edge for Private Cloud. השדרוג הזה רלוונטי לכל טופולוגיות הפריסה של Apigee LDAP: שרת יחיד, פעיל-סביל ופעיל-פעיל (multi-master).

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

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

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

הכנה והתקנה (כל שרתי ה-LDAP)

השלבים בקטע הזה (שלב 2 עד שלב 5) זהים לכל טופולוגיות הפריסה של LDAP. צריך לבצע את הפעולות האלה בכל שרת שבו מותקן הרכיב apigee-openldap, בלי קשר לתפקיד שלו.

  1. לפני שממשיכים בשדרוג LDAP, חשוב להקפיד לכבות את כל edge-management-server ואת edge-ui. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop

  2. גיבוי נתוני LDAP קיימים

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

    • מריצים את פקודת הגיבוי. הפעולה הזו יוצרת ארכיון גיבוי עם חותמת זמן בספרייה /opt/apigee/backup/openldap. 
      apigee-service apigee-openldap backup
    • קבלת המספר הכולל של הרשומות: צריך לתעד את מספר הרשומות בספרייה לצורך אימות אחרי השדרוג (מספר הרשומות צריך להיות זהה בכל שרתי ה-LDAP). זוהי בדיקה ראשונית. 
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

  3. הפסקת LDAP וניקוי ספריות נתונים

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

    • מפסיקים את שירות ה-LDAP. 
      apigee-service apigee-openldap stop
    • מסירים לצמיתות את נתוני ה-LDAP הישנים ואת ספריות ההגדרות. 
      rm -rf /opt/apigee/data/apigee-openldap/*

  4. התקנה והגדרה של גרסת ה-LDAP החדשה

    בכל שרתי ה-LDAP, משתמשים בסקריפטים הרגילים של Apigee כדי להוריד ולהתקין את הגרסה החדשה של הרכיב.

    • מתקינים את רכיב ה-LDAP החדש: סקריפט העדכון קורא את קובץ ההגדרות ומתקין את חבילת apigee-openldap החדשה. 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf
    • מאמתים את גרסת ה-LDAP החדשה: אחרי שההתקנה מסתיימת, טוענים מחדש את הפרופיל ומוודאים שגרסת ה-LDAP החדשה הותקנה בצורה תקינה. 
      source ~/.bash_profile
ldapsearch -VV
Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

  5. הפסקת LDAP בכל השרתים לפני שחזור הנתונים

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

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*

  6. שחזור נתוני LDAP

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

    1. זיהוי השרת הפעיל הראשון לשחזור

      • להגדרה של שרת יחיד: זהו שרת ה-LDAP היחיד שלכם. אפשר להמשיך ישירות לשלב הבא.
      • בהגדרות active-passive ו-active-active: מריצים את פקודת האבחון הבאה בכל שרת LDAP: 
        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
Note:
-If this command returns output, the server is a passive server.
-If it returns no output, the server is the active server.

    2. שחזור נתוני הגיבוי

      לפני שממשיכים, בודקים שוב ששלב 5 הושלם בהצלחה בכל שרתי ה-LDAP.

      • בשרת הפעיל הראשון שזיהיתם למעלה, עוברים לספריית הגיבוי. 
        cd /opt/apigee/backup/openldap
      • מריצים את הפקודה restore. מומלץ מאוד לציין את חותמת הזמן המדויקת של הגיבוי משלב 2 כדי למנוע שחזור של גרסה לא רצויה או ישנה יותר. 
        # To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
      • אחרי שתהליך השחזור יסתיים בהצלחה, מפעילים את שירות LDAP בשרת הפעיל הראשון. 
        apigee-service apigee-openldap start

  7. הפעלת שרתי LDAP שנותרו

    אם יש לכם הגדרה של כמה שרתים, בכל אחד משרתי ה-LDAP, מפעילים את השירות: 

    apigee-service apigee-openldap start

  8. אימות סופי

    השלב האחרון הוא לוודא שהשדרוג בוצע בהצלחה ושהנתונים עקביים בכל אשכול ה-LDAP.

    • מריצים את פקודת האימות בכל שרתי ה-LDAP. מספר הרשומות צריך להיות זהה בכל השרתים, וצריך להיות זהה למספר שרשמתם בשלב 2.
      • # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • אחרי שמוודאים שהנתונים נכונים ועקביים, השדרוג של LDAP הושלם. עכשיו אפשר להמשיך ולהפעיל את edge-management-server, את edge-ui ואת כל הרכיבים התלויים האחרים, בהתאם לנוהל השדרוג הרגיל של הארגון.

נדרש שדרוג ל-Cassandra 4.0.18

‫Apigee Edge for Private Cloud 4.53.01 כולל שדרוג של Cassandra לגרסה 4.0.18.

שדרוגים וביטול שינויים

  • השדרוג מ-Cassandra 3.11.X ל-Cassandra 4.0.X הוא תהליך פשוט. ‫Cassandra 4.0.X, שפורסמה עם Edge for Private Cloud 4.53.00, תואמת לרכיבי זמן הריצה והניהול של Private Cloud 4.52.02.
  • אי אפשר לבצע ישירות שחזור במקום מ-Cassandra 4.0.X ל-3.11.X. ביצוע Rollback באמצעות רפליקות או גיבויים הוא הליך מורכב, ועשוי לכלול השבתה או אובדן נתונים. עדיף לפתור בעיות ולשדרג ל-Cassandra 4.0.X מאשר לבטל את השדרוג.
  • חשוב להכיר את הנהלים לביטול השינויים לפני שמנסים לבצע את השדרוג. חשוב להבין את הניואנסים של החזרה לגרסה קודמת במהלך השדרוג כדי לוודא שנתיבי החזרה לגרסה קודמת מתאימים זמינים.

מרכז נתונים יחיד

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

אם אי אפשר להוסיף מרכז נתונים חדש אבל עדיין רוצים את האפשרות לבטל את השדרוג, יהיה צורך בגיבויים כדי לשחזר את Cassandra 3.11.X. עם זאת, סביר להניח שהשיטה הזו תגרום להשבתה ולאובדן נתונים.

כמה מרכזי נתונים

הפעלת מספר מרכזי נתונים עם Edge for Private Cloud 4.52.02 מאפשרת גמישות רבה יותר בהחזרה לגרסה קודמת במהלך השדרוג ל-Edge for Private Cloud 4.53.00.

  • החזרה לגרסה קודמת תלויה בכך שלפחות מרכז נתונים אחד מריץ את הגרסה הישנה יותר של Cassandra‏ (3.11.X).
  • אם כל אשכול Cassandra שודרג לגרסה 4.0.X, אסור לחזור לגרסה 3.11.X של Cassandra. צריך להמשיך להשתמש בגרסת Cassandra החדשה עם הרכיבים האחרים של Private Cloud 4.53.00 או 4.52.02.
  1. משדרגים מרכז נתונים אחד של Cassandra בכל פעם: מתחילים בשדרוג של צמתי Cassandra בנפרד בתוך מרכז נתונים יחיד. משלימים את השדרוגים של כל צמתי Cassandra במרכז נתונים אחד לפני שעוברים למרכז הבא.
  2. השהיה ואימות: אחרי השדרוג של מרכז נתונים אחד, משהים את הפעולה כדי לוודא שקלאסטר הענן הפרטי, ובמיוחד מרכז הנתונים ששודרג, פועל בצורה תקינה.
  3. חשוב לזכור: אפשר לחזור לגרסה הקודמת של Cassandra רק אם יש לכם לפחות מרכז נתונים אחד שעדיין פועלת בו הגרסה הישנה.
  4. רגיש לזמן: אפשר להשהות את המעבר לפרק זמן קצר (מומלץ לכמה שעות) כדי לאמת את הפונקציונליות, אבל אי אפשר להישאר במצב של גרסה מעורבת לזמן בלתי מוגבל. הסיבה לכך היא שלקלאסטר Cassandra לא אחיד (עם צמתים בגרסאות שונות) יש מגבלות תפעוליות.
  5. בדיקה יסודית: מומלץ מאוד לבצע בדיקה מקיפה של הביצועים והפונקציונליות לפני שמשדרגים את מרכז הנתונים הבא. אחרי שכל מרכזי הנתונים ישודרגו, לא תהיה אפשרות לחזור לגרסה הקודמת.
חזרה לגרסה קודמת כתהליך עם שתי נקודות ביקורת
  1. נקודת ביקורת 1: המצב ההתחלתי, שבו כל הרכיבים הם בגרסה 4.52.02. אפשר לבצע חזרה מלאה לגרסה הקודמת כל עוד לפחות מרכז נתונים אחד של Cassandra נשאר בגרסה הקודמת.
  2. נקודת ביקורת 2: אחרי שכל צמתי Cassandra בכל מרכזי הנתונים מתעדכנים. אפשר לחזור למצב הזה, אבל אי אפשר לחזור לנקודת הבדיקה 1.
דוגמה

נניח שיש לכם קלאסטר עם שני מרכזי נתונים (DC):

  1. מצב התחלתי: צמתי Cassandra בשני מרכזי הנתונים הם בגרסה 3.11.X. כל שאר הצמתים נמצאים ב-Edge for Private Cloud בגרסה 4.52.02. נניח שיש שלושה צמתי Cassandra בכל מרכז נתונים.
  2. שדרוג DC-1: משדרגים את שלושת צמתי Cassandra ב-DC-1 אחד אחרי השני.
  3. השהיה ואימות: מבצעים השהיה כדי לוודא שהאשכול, ובמיוחד DC-1, פועל בצורה תקינה (בודקים את הביצועים והפונקציונליות). אפשר לחזור למצב ההתחלתי באמצעות צמתי Cassandra ב-DC-2. חשוב לזכור שההשהיה הזו חייבת להיות זמנית בגלל המגבלות של אשכול Cassandra עם גרסאות מעורבות.
  4. שדרוג DC-2: משדרגים את שלושת צמתי Cassandra שנותרו ב-DC-2. הנקודה הזו הופכת לנקודת הבדיקה החדשה של החזרה לגרסה קודמת.
  5. שדרוג רכיבים אחרים: משדרגים את ניהול הנתונים, את זמן הריצה ואת צמתי הניתוח כרגיל בכל מרכזי הנתונים, צומת אחד ומרכז נתונים אחד בכל פעם. אם מתעוררות בעיות, אפשר לחזור למצב של שלב 4.

דרישות מוקדמות לשדרוג Cassandra

צריך להפעיל את Cassandra 3.11.16 עם Edge for Private Cloud 4.52.02 ולוודא את הדברים הבאים:
  1. האשכול כולו פועל וכל הפונקציות שלו זמינות עם Cassandra 3.11.16.
  2. אסטרטגיית הדחיסה מוגדרת ל-LeveledCompactionStrategy (דרישה מוקדמת לשדרוג לגרסה 4.52.02).

  3. מוודאים שכל אחד מהשלבים הבאים הושלם כחלק מהשדרוג הראשוני של Cassandra 3.11 ב-Edge for Private Cloud מגרסה 4.52.02.

    • הפקודה post_upgrade הופעלה בכל צומת של Cassandra במהלך השדרוג הקודם
    • הפקודה drop_old_tables הופעלה על כל אשכול Cassandra במהלך השדרוג הקודם.

אם אתם לא בטוחים שהפקודות post_upgrade ו-drop_old_tables הופעלו ב-Cassandra 3.11 בזמן השימוש ב-Edge for Private Cloud 4.52.02, תוכלו להפעיל אותן מחדש בבטחה לפני שתנסו לשדרג לגרסה 4.53.01.

שלב 1: הכנה לשדרוג

השלבים הבאים הם בנוסף לקבצים רגילים שאתם בדרך כלל יוצרים, כמו קובץ התצורה הרגיל של Apigee להפעלת שדרוגים של רכיבים.

  1. גיבוי של Cassandra באמצעות Apigee.
  2. יוצרים תמונות מצב של מכונות וירטואליות של צמתי Cassandra (אם אפשר).
  3. אם עדיין לא הגדרתם את יציאה 9042, ודאו שהיא נגישה מכל הרכיבים של Edge for Private Cloud, כולל שרת הניהול, מעבד ההודעות, הנתב, Qpid ו-Postgres, לצמתים של Cassandra. מידע נוסף מופיע במאמר בנושא דרישות לגבי יציאות.

שלב 2: משדרגים את כל צמתי Cassandra

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

אחרי שמשדרגים את כל צמתי Cassandra במרכז נתונים, צריך להמתין זמן מה (בין 30 דקות לכמה שעות) לפני שממשיכים עם הצמתים במרכז הנתונים הבא. במהלך הזמן הזה, חשוב לבדוק היטב את מרכז הנתונים שעודכן ולוודא שמדדי הביצועים והתפקוד של אשכול Apigee שלכם תקינים. השלב הזה חשוב מאוד כדי להבטיח את היציבות של מרכז הנתונים שבו שודרגה Cassandra לגרסה 4.0.X, בזמן ששאר רכיבי Apigee נשארים בגרסה 4.52.02.

  1. כדי לשדרג צומת Cassandra, מריצים את הפקודה הבאה: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. אחרי שמעדכנים צומת, מריצים את הפקודה הבאה בצומת כדי להריץ כמה אימותים לפני שממשיכים: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
  3. הפלט של הפקודה שלמעלה ייראה בערך כך: 
    Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
Metadata is verified
  4. מריצים את הפקודה post_upgrade הבאה בצומת Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. מריצים את הפקודות הבאות של nodetool כדי לבנות מחדש את האינדקסים בצומת Cassandra: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
     אם אתם משתמשים במונטיזציה, מריצים גם את הפקודות הבאות של בנייה מחדש של אינדקסים שקשורות למרחבי מפתחות של מונטיזציה: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

שלב 3: שדרוג כל צמתי הניהול

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

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

שלב 4: שדרוג כל צמתי זמן הריצה

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

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

שלב 5: משדרגים את כל הרכיבים הנותרים של Edge for Private Cloud 4.53.01

משדרגים את כל הצמתים שנותרו מסוג edge-qpid-server ו-edge-postgres-server בכל האזורים, אחד אחרי השני.

נדרש שדרוג ל-Zookeeper 3.8.4

הגרסה הזו של Edge for Private Cloud כוללת שדרוג ל-Zookeeper 3.8.4. כחלק מהשדרוג הזה, כל הנתונים של Zookeeper יועברו ל-Zookeeper 3.8.4.

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

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

באופן כללי, תהליך השדרוג כולל גיבוי של כל צומת. לאחר מכן, כל הצופים והעוקבים משודרגים, ולבסוף משודרג צומת המוביל.

יצירת גיבוי

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

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

אם אתם משתמשים במכונות וירטואליות ויש לכם את היכולת, אתם יכולים גם ליצור גיבויים או תמונות מצב של מכונות וירטואליות לצורך שחזור או חזרה למצב קודם (אם צריך).

זיהוי מנהיג, חסידים וצופים

הערה: בדוגמאות של הפקודות שבהמשך נעשה שימוש בכלי nc כדי לשלוח נתונים ל-Zookeeper. אפשר גם להשתמש בכלי עזר חלופיים כדי לשלוח נתונים ל-Zookeeper.

  1. אם הוא לא מותקן בצומת ZooKeeper, מתקינים את nc: 
      sudo yum install nc
  2. מריצים את פקודת ה-nc הבאה בצומת, כאשר 2181 הוא יציאת ZooKeeper: 
      echo stat | nc localhost 2181

    הפלט אמור להיראות כך:

      Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
  Clients:
   /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
  
  Latency min/avg/max: 0/0.2518/41
  Received: 647228
  Sent: 647339
  Connections: 4
  Outstanding: 0
  Zxid: 0x400018b15
  Mode: follower
  Node count: 100597

    בשורה Mode של הפלט עבור הצמתים, אמור להופיע observer,‏ leader או follower (כלומר, מצביע שלא נבחר להיות המוביל), בהתאם להגדרת הצומת. הערה: בהתקנה עצמאית של Edge עם צומת ZooKeeper יחיד, הערך של Mode מוגדר כ-standalone.

  3. חוזרים על שלבים 1 ו-2 בכל צומת של ZooKeeper.

שדרוג Zookeeper בצמתי הצופה והעוקב

משדרגים את Zookeeper בכל אחד מהצמתים של observer ו-follower באופן הבא:

  1. מורידים ומריצים את bootstrap של Edge for Private Cloud 4.53.01, כמו שמתואר במאמר עדכון לגרסה 4.53.01 בצומת עם חיבור אינטרנט חיצוני. התהליך משתנה בהתאם לשאלה אם לצומת יש חיבור חיצוני לאינטרנט או אם מבצעים התקנה אופליין.
  2. משדרגים את הרכיב Zookeeper: 
      /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
     הערה: אם בצמתים האלה מותקנים רכיבים אחרים (כמו Cassandra), אפשר לשדרג אותם עכשיו (כמו בפרופיל cs,zk) או לשדרג את הרכיבים האחרים מאוחר יותר. ‫Apigee ממליצה לשדרג קודם רק את Zookeeper ולוודא שהאשכול פועל בצורה תקינה לפני שמשדרגים רכיבים אחרים.
  3. חוזרים על השלבים שלמעלה בכל אחד מהצמתים של Zookeeper observer ו-follower.

השבתה של השרת הראשי

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

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

שימו לב: במהלך האירוע הזה, לפני שבוחרים מנהיג חדש, יכול להיות שיהיו עיכובים רגעיים או שפעולות כתיבה ב-Zookeeper ייכשלו. הדבר עלול להשפיע על פעולות שכותבות ל-Zookeeper, כמו פעולות פריסה של שרתי proxy או שינויים בתשתית של Apigee, כמו הוספה או הסרה של מעבדי הודעות וכו'.

מוודאים שהמנהיג החדש נבחר

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

הבכיר בארגון שמשדרג

פועלים לפי אותם השלבים שמפורטים בקטע שדרוג Zookeeper בצמתי הצופה והעוקב למעלה.

אחרי שגם צומת ה-leader הישן ישודרג, צריך לוודא שהאשכול תקין ושיש צומת leader.

שדרוג Nginx 1.26 ב-Edge-Router

אם משדרגים ל-Edge for Private Cloud 4.53.01 מגרסאות קודמות, תוכנת Nginx לא משודרגת אוטומטית לגרסה האחרונה (1.26.x). השינוי הזה נועד למנוע תופעות לוואי לא מכוונות בזמן הריצה כתוצאה מהשינויים שמפורטים במאמר Nginx 1.26 changes in Apigee Edge 4.53.01. אחרי האימות בסביבות נמוכות יותר, אפשר לשדרג את Nginx מגרסה 1.20.x לגרסה 1.26.x באופן ידני. כדי לשדרג באופן ידני:

  1. מוודאים שבצומת של נתב הקצה מותקנת התוכנה העדכנית ביותר, גרסה 4.53.01

    /opt/apigee/apigee-service/bin/apigee-service edge-router version

  2. בדיקה ואימות של גרסת Nginx שפועלת כרגע

    /opt/nginx/sbin/nginx -V

    אם אתם משתמשים בגרסה ישנה יותר של Nginx, אתם יכולים לפעול לפי השלבים הבאים כדי לשדרג את Nginx לגרסה 1.26.X בצומת הנתב.

  3. הפסקת התהליך של נתב קצה בצומת הנתב

    /opt/apigee/apigee-service/bin/apigee-service edge-router stop

  4. שדרוג תוכנת nginx בצומת הנתב

    dnf update apigee-nginx

  5. מוודאים שגרסת Nginx עודכנה

    /opt/nginx/sbin/nginx -V

  6. הפעלת תהליך הנתב בצומת

    /opt/apigee/apigee-service/bin/apigee-service edge-router start

  7. חוזרים על התהליך בכל צומת של הנתב, אחד בכל פעם

נדרש שדרוג ל-Postgres 17

הגרסה הזו של Edge כוללת שדרוג ל-Postgres 17. כחלק מהשדרוג הזה, כל נתוני Postgres מועברים ל-Postgres 17.

רוב מערכות הייצור של Edge משתמשות בשני צמתי Postgres שהוגדרו לשכפול master-standby. במהלך תהליך העדכון, בזמן שצמתי Postgres מושבתים לצורך העדכון, נתוני הניתוח עדיין נכתבים לצמתי Qpid. אחרי שהצמתים של Postgres מתעדכנים וחוזרים למצב אונליין, נתוני הניתוח נדחפים לצמתים של Postgres.

הדרך שבה מבצעים את העדכון של Postgres תלויה באופן שבו הגדרתם את אחסון הנתונים בצמתי Postgres:

  • אם אתם משתמשים באחסון נתונים מקומי לצמתי Postgres, אתם צריכים להתקין צומת חדש של Postgres במצב המתנה למשך השדרוג. אחרי שהשדרוג יסתיים, תוכלו להוציא משימוש את צומת הגיבוי החדש של Postgres.

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

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

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

    לפני שמתחילים בתהליך העדכון, צריך ליצור תמונת מצב של הרשת של מאגר הנתונים שמשמש את Postgres. אם מתרחשות שגיאות במהלך העדכון ואתם נאלצים לבצע החזרה לאחור, תוכלו לשחזר את צומת Postgres מאותו snapshot.

התקנת צומת חדש במצב המתנה של Postgres

התהליך הזה יוצר שרת Postgres במצב המתנה בצומת חדש. חשוב לוודא שמתקינים שרת המתנה חדש של Postgres לגרסה הקיימת של Edge (4.52.02 או 4.53.00), ולא לגרסה 4.53.01.

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

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

  1. בשרת ה-Postgres הראשי הנוכחי, עורכים את הקובץ /opt/apigee/customer/application/postgresql.properties כדי להגדיר את האסימון הבא. אם הקובץ לא קיים, יוצרים אותו: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

    כאשר existing_standby_ip היא כתובת ה-IP של שרת ה-Postgres הנוכחי במצב המתנה ו-new_standby_ip היא כתובת ה-IP של צומת ההמתנה החדש.

  2. מפעילים מחדש את apigee-postgresql ב-Postgres master: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  3. בודקים שהצומת החדש במצב המתנה נוסף על ידי צפייה בקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf בשרת הראשי. אתם אמורים לראות את השורות הבאות בקובץ: 
    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
  4. מתקינים את שרת ההמתנה החדש של Postgres:
    1. עורכים את קובץ ההגדרות שבו השתמשתם כדי להתקין את הגרסה הנוכחית של Edge, ומציינים את הפרטים הבאים: 
      # IP address of the current master:
PG_MASTER=192.168.56.103
# IP address of the new standby node
PG_STANDBY=192.168.56.102
    2. משביתים את SELinux כמו שמתואר במאמר Install the Edge apigee-setup utility.

    3. אם אתם משתמשים כרגע ב-Edge 4.52.02:

      1. מורידים את הקובץ Edge bootstrap_4.52.02.sh אל /tmp/bootstrap_4.52.02.sh : 
        curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh
      2. מתקינים את כלי השירות Edge apigee-service ואת יחסי התלות שלו: 
        sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      אם אתם משתמשים כרגע ב-Edge 4.53.00:

      1. מורידים את קובץ האתחול bootstrap_4.53.00.sh של Edge אל /tmp/bootstrap_4.53.00.sh : 
        curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
      2. מתקינים את כלי השירות Edge apigee-service ואת יחסי התלות שלו: 
        sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    4. משתמשים ב-apigee-service כדי להתקין את כלי השירות apigee-setup: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. מתקינים את Postgres: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. בצומת ההמתנה החדש, מריצים את הפקודה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      מוודאים שהוא במצב המתנה.

ביצוע שדרוג במקום של Postgres

הערה: לפני שמבצעים שדרוג במקום של Postgres, צריך לבצע את השלב המקדים הבא.

שלב מקדים

לפני שמבצעים שדרוג במקום ל-Postgres, מבצעים את השלבים הבאים גם במארח הראשי וגם במארח ההמתנה, כדי לעדכן את המאפיין max_locks_per_transaction ב-apigee-postgresql:

  1. אם הקובץ לא קיים, יוצרים את הקובץ /opt/apigee/customer/application/postgresql.properties.
  2. שינוי הבעלות על הקובץ הזה לapigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. מוסיפים את הנכס הבא לקובץ: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. הגדרה של apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. הפעלה מחדש של apigee-postgresql: 
    apigee-service apigee-postgresql restart

ביצוע שדרוג במקום

כדי לבצע שדרוג במקום ל-Postgres 17, פועלים לפי השלבים הבאים:

  1. שדרוג postgres במארח הראשי 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. מריצים את פקודת ההגדרה במחשב המארח הראשי: 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. מריצים את פקודת ההגדרה במארח הראשי: 
    apigee-service apigee-postgresql configure
  4. מפעילים מחדש את המארח הראשי: 
    apigee-service apigee-postgresql restart
  5. מגדירים אותו כראשי: 
    apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
  6. מוודאים שהמארח הראשי התחיל את הפגישה: 
    apigee-service apigee-postgresql wait_for_ready
  7. מפסיקים את מצב ההמתנה: 
    apigee-service apigee-postgresql stop
  8. משדרגים את מצב ההמתנה.

    הערה: אם השלב הזה נכשל או מציג שגיאה, אפשר להתעלם ממנו. ‫update.sh ינסה להפעיל את השרת במצב המתנה עם הגדרה שגויה. אם התקנת Postgres משודרגת לגרסה 17, אפשר להתעלם מהשגיאה.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  9. מוודאים שהמצב של הגיבוי הוא 'הופסק': 
    apigee-service apigee-postgresql stop
  10. מסירים את הגדרת הגיבוי הישנה: 
    rm -rf /opt/apigee/data/apigee-postgresql/
  11. מגדירים שכפול בשרת ההמתנה: 
    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
  12. מסירים את השורה conf/postgresql.conf+max_locks_per_transaction=30000 מהקובץ /opt/apigee/customer/application/postgresql.properties במארח הראשי ובמארח ההמתנה. השורה הזו נוספה בשלב המקדים.

אחרי שמבצעים את התהליך הזה, מצב ההמתנה מתחיל בהצלחה.

הוצאה משימוש של צומת Postgres

אחרי שהעדכון מסתיים, מוציאים משימוש את צומת ההמתנה החדש:

  1. מוודאים ש-Postgres פועל: 
    /opt/apigee/apigee-service/bin/apigee-all status

    אם Postgres לא פועל, מפעילים אותו: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. מריצים את הפקודה curl הבאה בצומת ההמתנה החדש כדי לקבל את ה-UUID שלו: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    בסוף הפלט אמור להופיע ה-UUID של הצומת, בפורמט הבא: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. מפסיקים את צומת ההמתנה החדש על ידי הפעלת הפקודה הבאה בצומת ההמתנה החדש: 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. בצומת הראשי של Postgres, עורכים את /opt/apigee/customer/application/postgresql.properties כדי להסיר את צומת ההמתנה החדש מ-conf_pg_hba_replication.connection: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. מפעילים מחדש את apigee-postgresql ב-Postgres master: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. כדי לוודא שהוסר צומת חדש במצב המתנה, צופים בקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf בשרת הראשי. בקובץ הזה אמורה להופיע רק השורה הבאה: 
    host replication apigee existing_standby_ip/32 trust
  7. כדי למחוק את ה-UUID של צומת ההמתנה מ-ZooKeeper, מבצעים את קריאת Edge Management API הבאה בצומת של שרת הניהול: 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

השלבים שלאחר השדרוג ל-Postgres

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

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

כדי לפתור את הבעיה הזו, מריצים את הפקודה ANALYZE בכל הטבלאות במסד הנתונים בצומת ה-Postgres הראשי. אפשר גם להריץ את הפקודה ANALYZE לכמה טבלאות בכל פעם.

שלבים לעדכון Apigee SSO מגרסאות ישנות יותר

ב-Edge for Private Cloud 4.53.01, המפתחות והאישורים של ספק הזהויות שמשמשים ברכיב apigee-sso מוגדרים עכשיו דרך מאגר מפתחות. תצטרכו לייצא את המפתח והאישור שבהם השתמשתם קודם למאגר מפתחות, להגדיר אותו ואז להמשיך בעדכון ה-SSO כרגיל.

  1. מזהים את המפתח והאישור הקיימים שמשמשים להגדרת ספק הזהויות:

    1. מאחזרים את האישור על ידי חיפוש הערך של SSO_SAML_SERVICE_PROVIDER_CERTIFICATE בקובץ התצורה של התקנת ה-SSO או על ידי שליחת שאילתה לרכיב apigee-sso לגבי conf_login_service_provider_certificate.

      מריצים את הפקודה הבאה בצומת ה-SSO כדי לשלוח שאילתה אל apigee-sso לגבי הנתיב של אישור ה-IdP. בפלט, מחפשים את הערך בשורה האחרונה. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. מאחזרים את המפתח על ידי חיפוש הערך של SSO_SAML_SERVICE_PROVIDER_KEY בקובץ ההגדרות של התקנת ה-SSO או על ידי שליחת שאילתה לרכיב apigee-sso לגבי conf_login_service_provider_key.

      מריצים את הפקודה הבאה בצומת ה-SSO כדי לשלוח שאילתה ל-apigee-sso לגבי נתיב המפתח של ספק ה-IdP. בפלט, מחפשים את הערך בשורה האחרונה.

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. מייצאים את המפתח והאישור למאגר מפתחות:
    1. מייצאים את המפתח והאישור אל מאגר מפתחות PKCS12: 
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      פרמטרים:

      • ‫certificate_path: הנתיב לקובץ האישור שאוחזר בשלב 1.א.
      • ‫key_path: הנתיב לקובץ המפתח הפרטי שאוחזר בשלב 1.ב.
      • ‫keystore_path: הנתיב למאגר המפתחות שנוצר לאחרונה ומכיל את האישור ואת המפתח הפרטי.
      • ‫alias: הכינוי שמשמש לזוג המפתחות והאישורים במאגר המפתחות.

      פרטים נוספים זמינים בתיעוד של OpenSSL.

    2. (אופציונלי) מייצאים את המפתח והאישור מ-PKCS12 למאגר מפתחות JKS: 
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      פרמטרים:

      • ‫PKCS12_keystore_path: הנתיב למאגר המפתחות PKCS12 שנוצר בשלב 2א, שמכיל את האישור והמפתח.
      • ‫destination_keystore_path: הנתיב למאגר המפתחות החדש בפורמט JKS שאליו ייוצאו האישור והמפתח.
      • ‫alias: שם הכינוי שמשמש לזוג המפתחות והאישורים במאגר המפתחות JKS.

      3. פרטים נוספים זמינים בתיעוד של keytool.

  3. משנים את הבעלים של קובץ מאגר המפתחות של הפלט למשתמש apigee: 
    sudo chown apigee:apigee <keystore_file>
  4. מוסיפים את המאפיינים הבאים ב קובץ התצורה של Apigee SSO ומעדכנים אותם עם הנתיב לקובץ של מאגר המפתחות, הסיסמה, סוג מאגר המפתחות והכינוי: 
    # Path to the keystore file
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks

# Keystore password
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore

# Keystore type
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12

# Alias within keystore that stores the key and certificate
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert
  5. מעדכנים את תוכנת Apigee SSO בצומת ה-SSO כרגיל באמצעות הפקודה הבאה: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

ממשק משתמש חדש של Edge

בקטע הזה מפורטים שיקולים לגבי ממשק המשתמש של Edge. מידע נוסף זמין במאמר ממשק המשתמש החדש של Edge ל-Private Cloud.

התקנת ממשק המשתמש של Edge

אחרי שמסיימים את ההתקנה הראשונית, מומלץ להתקין את ממשק המשתמש של Edge, שהוא ממשק משתמש משופר למפתחים ולמנהלים של Apigee Edge לענן פרטי.

שימו לב: בממשק המשתמש של Edge צריך להשבית את האימות הבסיסי ולהשתמש בIDP כמו SAML או LDAP.

מידע נוסף זמין במאמר התקנת ממשק המשתמש החדש של Edge.

עדכון באמצעות Apigee mTLS

כדי לעדכן את Apigee mTLS , פועלים לפי השלבים הבאים:

חזרה לגרסה קודמת של עדכון

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

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

רישום מידע על עדכונים

כברירת מחדל, כלי השירות update.sh כותב את פרטי היומן אל:

/opt/apigee/var/log/apigee-setup/update.log

אם לאדם שמריץ את כלי השירות update.sh אין גישה לספרייה הזו, היומן נכתב לספרייה /tmp כקובץ בשם update_username.log.

אם לאדם אין גישה ל-/tmp, כלי השירות update.sh ייכשל.

עדכון ללא השבתה

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

אפשר לבצע עדכון ללא השבתה רק בהגדרה של 5 צמתים ומעלה.

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

  1. מעדכנים את המכונות בסדר הנכון להתקנה, כמו שמתואר בסדר העדכון של המכונות.
  2. כשמגיע הזמן לעדכן את הנתבים, בוחרים נתב כלשהו וגורמים לכך שלא תהיה אליו גישה, כמו שמתואר במאמר הפעלה או השבתה של הגישה לשרת (מעבד הודעות או נתב).
  3. מעדכנים את הנתב שנבחר ואת כל רכיבי Edge האחרים באותו מחשב שבו מותקן הנתב. בכל ההגדרות של Edge מוצגים Router ו-Message Processor באותו הצומת.
  4. מוודאים שאפשר להגיע לנתב.
  5. חוזרים על שלבים 2 עד 4 בשביל שאר הנתבים.
  6. ממשיכים את העדכון בכל המחשבים שנותרו בהתקנה.

לפני ואחרי העדכון, חשוב לבצע את הפעולות הבאות:

שימוש בקובץ תצורה שקט

צריך להעביר קובץ תצורה שקט לפקודת העדכון. קובץ התצורה השקט צריך להיות אותו קובץ שבו השתמשתם כדי להתקין את Edge for Private Cloud 4.52.02 או 4.53.00.

עדכון לגרסה 4.53.01 בצומת עם חיבור אינטרנט חיצוני

כדי לעדכן את רכיבי Edge בצומת, מבצעים את הפעולות הבאות:

  1. אם יש משימות cron שמוגדרות לבצע פעולת תיקון ב-Cassandra, צריך להשבית אותן עד לסיום העדכון.
  2. מתחברים לצומת כמשתמש root כדי להתקין את חבילות ה-RPM של Edge.
  3. משביתים את SELinux כמו שמתואר במאמר התקנה של כלי השירות apigee-setup של Edge.
  4. אם אתם מתקינים ב-AWS, מריצים את הפקודות הבאות של yum-configure-manager: 
    yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

  5. אם אתם משתמשים כרגע בגרסה Edge 4.52.02 או 4.53.00:

    1. מורידים את קובץ Edge bootstrap_4.53.01.sh אל /tmp/bootstrap_4.53.01.sh: 
      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
    2. מריצים את הפקודה הבאה כדי להתקין את כלי השירות Edge 4.53.01 apigee-service ואת יחסי התלות: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      כאשר uName:pWord הם שם המשתמש והסיסמה שקיבלתם מ-Apigee. אם לא תזינו את pWord, תתבקשו להזין אותו.

      כברירת מחדל, תוכנת ההתקנה בודקת אם Java 1.8 מותקנת. אם לא, תוכנת ההתקנה תתקין אותו בשבילכם.

      משתמשים באפשרות JAVA_FIX כדי לציין איך לטפל בהתקנה של Java. המאפיין JAVA_FIX יכול לקבל את הערכים הבאים:

      • ‫I: התקנה של OpenJDK 1.8 (ברירת מחדל).
      • ‫C: המשך ללא התקנת Java.
      • ‫Q: יציאה. כדי להשתמש באפשרות הזו, צריך להתקין את Java באופן עצמאי.
    3. משתמשים בפקודה apigee-service כדי לעדכן את כלי השירות apigee-setup, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. מעדכנים את כלי השירות apigee-validate בשרת הניהול, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. מעדכנים את כלי השירות apigee-provision בשרת הניהול, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. מריצים את כלי השירות update בצמתים באמצעות הפקודה הבאה: 
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      צריך לבצע את הפעולות בסדר שמתואר במאמר סדר העדכון של המכונה.

      כאשר:

      • ‫component הוא רכיב Edge שרוצים לעדכן. הערכים האפשריים כוללים:
        • ‫cs: Cassandra
        • ‫edge: כל רכיבי Edge מלבד ממשק המשתמש של Edge: שרת הניהול, מעבד ההודעות, הנתב, שרת QPID, שרת Postgres
        • ‫ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • ‫sso: Apigee SSO (אם התקנתם SSO)
        • ‫ue: ממשק משתמש חדש של Edge
        • ‫ui: ממשק המשתמש של הגרסה הקלאסית של Edge
        • zk: Zookeeper
      • ‫configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסה 4.52.02 או 4.53.00.

      אפשר להריץ את update.sh על כל הרכיבים על ידי הגדרת component ל-all, אבל רק אם יש לכם פרופיל התקנה של Edge all-in-one (AIO). לדוגמה:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. אם עדיין לא עשיתם את זה, מפעילים מחדש את רכיבי Edge UI בכל הצמתים שבהם הם פועלים: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. כדי לבדוק את העדכון, מריצים את כלי השירות apigee-validate בשרת הניהול, כמו שמתואר במאמר בדיקת ההתקנה.

אם מחליטים מאוחר יותר לבטל את העדכון, צריך לפעול לפי ההליך שמתואר במאמר ביטול העדכון לגרסה 4.53.01.

עדכון לגרסה 4.53.01 ממאגר מקומי

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

אחרי שיוצרים מאגר מקומי של Edge, יש שתי אפשרויות לעדכן את Edge מהמאגר המקומי:

  • יוצרים קובץ ‎ .tar של המאגר, מעתיקים את קובץ ה-‎ .tar לצומת ומעדכנים את Edge מקובץ ה-‎.tar.
  • מתקינים שרת אינטרנט בצומת עם המאגר המקומי כדי שצמתים אחרים יוכלו לגשת אליו. ‫Apigee מספקת לכם את שרת האינטרנט Nginx, או שאתם יכולים להשתמש בשרת אינטרנט משלכם.

כדי לעדכן ממאגר מקומי בגרסה 4.53.01:

  1. יוצרים מאגר מקומי בגרסה 4.53.01 כמו שמתואר במאמר בנושא התקנת כלי השירות apigee-setup של Edge.
  2. כדי להתקין את apigee-service מקובץ ‎ .tar:
    1. בצומת עם המאגר המקומי, משתמשים בפקודה הבאה כדי לארוז את המאגר המקומי לקובץ ‎ .tar יחיד בשם /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. מעתיקים את קובץ ה-‎ .tar לצומת שבו רוצים לעדכן את Edge. לדוגמה, מעתיקים אותו לספרייה /tmp בצומת החדש.
    3. בצומת החדש, מבטלים את הדחיסה של הקובץ בספרייה /tmp: 
      tar -xzf apigee-4.53.01.tar.gz

      הפקודה הזו יוצרת ספרייה חדשה בשם repos בספרייה שמכילה את קובץ ה-‎ .tar. לדוגמה /tmp/repos.

    4. מתקינים את כלי השירות Edge apigee-service ואת יחסי התלות מ-/tmp/repos: 
      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

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

  3. כדי להתקין את apigee-service באמצעות שרת האינטרנט Nginx:
    1. מגדירים את שרת האינטרנט Nginx כמו שמתואר במאמר בנושא התקנה של כלי השירות apigee-setup של Edge בקטע 'התקנה ממאגר באמצעות שרת האינטרנט Nginx'.
    2. בצומת המרוחק, מורידים את קובץ Edge bootstrap_4.53.01.sh אל /tmp/bootstrap_4.53.01.sh: 
      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

      כאשר uName:pWord הם שם המשתמש והסיסמה שהגדרתם קודם למאגר, ו-remoteRepo היא כתובת ה-IP או שם ה-DNS של צומת המאגר.

    3. בצומת המרוחק, מתקינים את כלי השירות Edge apigee-setup ואת יחסי התלות: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      כאשר uName:pWord הם שם המשתמש והסיסמה של המאגר.

  4. משתמשים בפקודה apigee-service כדי לעדכן את כלי השירות apigee-setup, כמו בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. מעדכנים את כלי השירות apigee-validate בשרת הניהול, כמו בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. מעדכנים את כלי השירות apigee-provision בשרת הניהול, כמו בדוגמה הבאה: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. מריצים את כלי השירות update בצמתים לפי הסדר שמתואר במאמר סדר העדכון של המכונות: 
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    כאשר:

    • ‫component הוא רכיב Edge שרוצים לעדכן. בדרך כלל מעדכנים את הרכיבים הבאים:
      • ‫cs: Cassandra
      • ‫edge: כל רכיבי Edge חוץ מממשק המשתמש של Edge: שרת הניהול, מעבד ההודעות, הנתב, שרת QPID, שרת Postgres
      • ‫ldap: OpenLDAP
      • ps: postgresql
      • qpid: qpidd
      • ‫sso: Apigee SSO (אם התקנתם SSO)
      • ue ממשק משתמש חדש של Edge
      • ‫ui: ממשק המשתמש של הגרסה הקלאסית של Edge
      • zk: Zookeeper
    • ‫configFile הוא אותו קובץ תצורה שבו השתמשתם כדי להגדיר את רכיבי Edge במהלך ההתקנה של גרסה 4.52.02 או 4.53.00.

    אפשר להריץ את update.sh על כל הרכיבים על ידי הגדרת component ל-all, אבל רק אם יש לכם פרופיל התקנה של Edge all-in-one (AIO). לדוגמה:

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. אם עדיין לא עשיתם את זה, מפעילים מחדש את רכיבי ממשק המשתמש בכל הצמתים שבהם הוא פועל: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. כדי לבדוק את העדכון, מריצים את כלי השירות apigee-validate בשרת הניהול, כמו שמתואר במאמר בדיקת ההתקנה.

אם מחליטים מאוחר יותר לבטל את העדכון, צריך לפעול לפי ההליך שמתואר במאמר ביטול העדכון לגרסה 4.53.01.

סדר העדכון של המכונה

הסדר שבו מעדכנים את המכונות בהתקנת Edge הוא חשוב:

  • חובה לעדכן את כל צמתי ה-LDAP לפני עדכון של רכיבים אחרים. כדי לשדרג את LDAP, צריך לפעול לפי שלבים מיוחדים.
  • צריך לעדכן את כל הצמתים של Cassandra ו-ZooKeeper. אם אתם משדרגים מגרסה 4.52.02, עליכם לפעול לפי השלבים המיוחדים לשדרוג Cassandra. כדי לשדרג את Zookeeper לגרסה 4.52.02 או 4.53.00, צריך לבצע את השלבים המיוחדים.
  • כדי לעדכן את כל שרתי הניהול ואת מעבדי הנתבים וההודעות, צריך לשדרג אותם באמצעות האפשרות ‎-c edge.
  • צריך לשדרג את כל צמתי Postgres לפי השלבים המיוחדים לשדרוג Postgres.
  • צריך לעדכן את הרכיבים edge-qpid-server ו-edge-postgres-server בכל מרכזי הנתונים.
  • חובה לשדרג את כל צמתי Qpid.
  • צריך לשדרג את הצמתים של ממשק המשתמש של Edge, וגם לשדרג את הצמתים של ממשק המשתמש החדש של Edge ושל הכניסה היחידה(אם רלוונטי).
  • אין שלב נפרד לעדכון המונטיזציה. הוא מתעדכן כשמציינים את האפשרות -c edge.

שדרוג עצמאי עם צומת אחד

כדי לשדרג הגדרה עצמאית עם צומת אחד לגרסה 4.53.01:

  1. עדכון כל הרכיבים: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

שדרוג עצמאי של 2 צמתים

מעדכנים את הרכיבים הבאים בהתקנה עצמאית של 2 צמתים:

רשימה של טופולוגיות Edge ומספרי צמתים מופיעה במאמר טופולוגיות התקנה.

  1. מעדכנים את LDAP במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. מעדכנים את רכיבי Edge במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres במחשב 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. מעדכנים את רכיבי Edge במכונה 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. מעדכנים את Qpid במחשב 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. מעדכנים את ממשק המשתמש במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (אם התקנתם את apigee-adminapi) עדכנתם את כלי השירות apigee-adminapi במחשב 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  10. מפעילים מחדש את רכיב Edge UI במכונה 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

שדרוג של 5 צמתים

כדי לעדכן את הרכיבים הבאים בהתקנה של 5 צמתים:

רשימת הטופולוגיות של Edge ומספרי הצמתים מופיעה במאמר טופולוגיות של התקנות.

  1. מעדכנים את LDAP במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. מעדכנים את רכיבי Edge במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres במחשב 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. מעדכנים את Postgres במכונה 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. מעדכנים את רכיבי Edge במכונות 4 ו-5: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את Qpid במחשב 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את Qpid במחשב 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. עדכון ממשק המשתמש של Edge:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, אתם צריכים לעדכן את הרכיב ui במכונה 1, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • ממשק משתמש חדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך לעדכן את הרכיב ue במכונה המתאימה (יכול להיות שלא מדובר במכונה 1): 
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  10. (אם התקנתם את apigee-adminapi) עדכנתם את כלי השירות apigee-adminapi במחשב 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  12. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, עליכם להפעיל מחדש את הרכיב edge-ui במכונה 1, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק משתמש חדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את רכיב edge-management-ui במחשב המתאים (יכול להיות שלא מדובר במחשב 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 9 צמתים

צריך לעדכן את הרכיבים הבאים בהתקנה של אשכול עם 9 צמתים:

רשימת הטופולוגיות של Edge ומספרי הצמתים מופיעה במאמר טופולוגיות של התקנות.

  1. מעדכנים את LDAP במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. מעדכנים את רכיבי Edge במכונות 1, 4 ו-5 (שרת ניהול, מעבד הודעות, נתב) בסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres במחשב 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. מעדכנים את Postgres במחשב 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. מעדכנים את רכיבי Edge במכונות 6, 7, 8 ו-9 בסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. מעדכנים את Qpid במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את ממשק המשתמש החדש (ue) או את ממשק המשתמש הקלאסי (ui) במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (אם התקנתם את apigee-adminapi) מעדכנים את כלי השירות apigee-adminapi במחשב 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במחשב 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  11. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, עליכם להפעיל מחדש את הרכיב edge-ui במכונה 1, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק משתמש חדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את רכיב edge-management-ui במחשב המתאים (יכול להיות שלא מדובר במחשב 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 13 צמתים

צריך לעדכן את הרכיבים הבאים בהתקנה של אשכול עם 13 צמתים:

רשימה של טופולוגיות Edge ומספרי צמתים מופיעה במאמר טופולוגיות התקנה.

  1. מעדכנים את LDAP במכונות 4 ו-5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper במכונות 1, 2 ו-3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. מעדכנים את רכיבי Edge במכונות 6, 7, 10 ו-11 בסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres במחשב 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. מעדכנים את Postgres במחשב 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. מעדכנים את רכיבי Edge במכונות 12, 13, 8 ו-9 בסדר הזה: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. עדכון Qpid במכונות 12 ו-13: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. מעדכנים את ממשק המשתמש החדש (ue) או את ממשק המשתמש הקלאסי (ui) במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (אם התקנתם את apigee-adminapi) בוצע עדכון של כלי השירות apigee-adminapi במכונות 6 ו-7: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO במכונות 6 ו-7: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  11. מפעילים מחדש את רכיב ממשק המשתמש:
    • ממשק משתמש קלאסי: אם אתם משתמשים בממשק המשתמש הקלאסי, תצטרכו להפעיל מחדש את הרכיב edge-ui במכונות 6 ו-7, כמו בדוגמה הבאה: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • ממשק משתמש חדש של Edge: אם התקנתם את ממשק המשתמש החדש של Edge, צריך להפעיל מחדש את רכיב edge-management-ui במחשבים 6 ו-7: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

שדרוג של אשכול עם 12 צמתים

צריך לעדכן את הרכיבים הבאים בהתקנה של אשכול עם 12 צמתים:

רשימה של טופולוגיות Edge ומספרי צמתים מופיעה במאמר טופולוגיות התקנה.

  1. עדכון LDAP:
    1. מכונה 1 במרכז נתונים 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. מכונה 7 במרכז נתונים 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. מעדכנים את Cassandra ואת ZooKeeper:
    1. מכונות 1, 2 ו-3 במרכז הנתונים 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. במכונות 7, 8 ו-9 במרכז הנתונים 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. עדכון רכיבי Edge:
    1. במכונות 1, 2 ו-3 במרכז הנתונים 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. במכונות 7, 8 ו-9 במרכז הנתונים 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. מעדכנים את Postgres:
    1. מכונה 6 במרכז הנתונים 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. מכונה 12 במרכז נתונים 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. עדכון רכיבי Edge:
    1. מכונות 4, 5, 6 במרכז הנתונים 1 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. מכונות 10, 11, 12 במרכז הנתונים 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. ‫Update qpidd:
    1. מכונות 4 ו-5 במרכז הנתונים 1
      1. מעדכנים את qpidd במחשב 4: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. מעדכנים את qpidd במחשב 5: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. מכונות 10 ו-11 במרכז הנתונים 2
      1. עדכון qpidd במחשב 10: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. עדכון qpidd במחשב 11: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. מעדכנים את הממשק החדש (ue) או את הממשק הקלאסי (ui):
    1. מכונה 1 במרכז נתונים 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. מכונה 7 במרכז הנתונים 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. (אם התקנתם את apigee-adminapi) עודכן כלי השירות apigee-adminapi:
    1. מכונה 1 במרכז נתונים 1: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. מכונה 7 במרכז הנתונים 2: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (אם התקנתם את Apigee SSO) מעדכנים את Apigee SSO:
    1. מכונה 1 במרכז נתונים 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. מכונה 7 במרכז הנתונים 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. ‫sso_config_file הוא קובץ ההגדרות שיצרתם כשהתקנתם את ה-SSO.

  10. מפעילים מחדש את הרכיב של ממשק המשתמש החדש של Edge‏ (edge-management-ui) או של ממשק המשתמש הקלאסי של Edge‏ (edge-ui) במחשבים 1 ו-7: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

להגדרה לא רגילה

אם יש לכם הגדרה לא סטנדרטית, צריך לעדכן את רכיבי Edge בסדר הבא:

  1. LDAP
  2. Cassandra
  3. מטפל בבעלי חיים
  4. שרת ניהול
  5. מעבד בקשות
  6. נתב
  7. Postgres
  8. ‫Edge, כלומר פרופיל ‎-c edge בכל הצמתים בסדר הבא: צמתים עם שרת Qpid,‏ שרת Edge Postgres.
  9. qpidd
  10. ממשק המשתמש של Edge (קלאסי או חדש)
  11. apigee-adminapi
  12. Apigee SSO

אחרי שמסיימים את העדכון, חשוב להפעיל מחדש את רכיב Edge UI בכל המכונות שבהן הוא פועל.