‫Google משתמשת בטכנולוגיית AI כדי לתרגם תוכן לשפה המועדפת עליך. בתרגומים כאלו עשויות להיות שגיאות.

עדכון של Apigee Edge 4.17.0x ל-4.18.01

Edge for Private Cloud v4.18.01

אילו גרסאות של Edge אפשר לעדכן לגרסה 4.18.01

אתם יכולים לעדכן את Apigee Edge בגרסה 4.17.0x באמצעות ההליך הזה.

אם יש לכם גרסה של Edge שקודמת לגרסה 4.16.01, אתם צריכים קודם לעבור לגרסה 4.16.01.x ואז לעדכן לגרסה 4.18.01.

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

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

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

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

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

שמירה על תאימות

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

נכס	מיקום	תיאור
`conf_load_balancing_load.balancing. driver.nginx.server.retry`	`router.properties`	צריך להסיר את המאפיין הזה מהקובץ `router.properties`. כדי להגדיר אפשרויות לניסיונות חוזרים בגרסה 4.18.01, משתמשים במאפייני ההגדרות של המארח הווירטואלי.

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

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

חובה להוסיף את פרמטר ההגדרה SMTPMAILFROM

בגרסה 4.17.05 של Edge נוסף פרמטר חובה חדש לקובץ התצורה שמשמש להפעלת שרת SMTP. אם אתם מעדכנים מגרסה 4.17.01, אתם צריכים להגדיר את SMTPMAILFROM בקובץ התצורה כשאתם מפעילים את שרת ה-SMTP.

בגרסה 4.17.09 של API BaaS נוספה גם תמיכה במאפיין SMTPMAILFROM. כשמעדכנים את API BaaS מגרסה 4.17.01 או 4.17.05, צריך להגדיר את SMTPMAILFROM בקובץ התצורה.

הפרמטר הזה הוא בפורמט הבא:

SMTPMAILFROM="My Company <myco@company.com>"

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

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

רוב מערכות הייצור של Edge משתמשות בשני צומתי Postgres שמוגדרים לשכפול מאסטר-גיבוי. במהלך תהליך העדכון, כשצומתי 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.17.0x), ולא לגרסה 4.18.01.

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

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

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

אם הקובץ postgresql.properties לא קיים, יוצרים אותו ומשתמשים ב-chown כדי לתת למשתמש apigee גישה אליו, כמו בדוגמה הבאה:
```
chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
```

מפעילים מחדש את apigee-postgresql ב-Postgres הראשי:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

מוודאים שצומת ההמתנה החדש נוסף על ידי הצגת הקובץ /opt/apigee/apigee-postgresql/conf/pg_hba.conf במאסטר. השורות הבאות אמורות להופיע בקובץ:
```
host replication apigee existing_slave_ip/32 trust
host replication apigee new_slave_ip/32 trust
```
מתקינים את שרת הגיבוי החדש של 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 כמו שמתואר במאמר התקנת כלי השירות apigee-setup של Edge.
3. מורידים את הקובץ Edge bootstrap_4.17.0x.sh (כאשר 4.17.0x הוא 4.17.01,‏ 4.17.05 או 4.17.09) אל /tmp/bootstrap_4.17.0x.sh :
```
curl https://software.apigee.com/bootstrap_4.17.0x.sh -o /tmp/bootstrap_4.17.0x.sh
```
4. מתקינים את הכלי apigee-service של Edge ואת יחסי התלות:
```
sudo bash /tmp/bootstrap_4.17.0x.sh apigeeuser=uName
  apigeepassword=pWord
```
5. משתמשים ב-apigee-service כדי להתקין את הכלי apigee-setup:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
6. מתקינים את Postgres:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
7. בשרת הגיבוי החדש, מריצים את הפקודה הבאה:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```
  מוודאים שמופיע הכיתוב "standby" (המתנה).

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

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

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

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

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

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

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

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

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

> /opt/apigee/apigee-service/bin/apigee-all status

מה עושים אם העדכון נכשל

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

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

רישום פרטי העדכון

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

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

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

אם למשתמש אין גישה אל ‎/tmp, הכלי update.sh נכשל.

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

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

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

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

מעדכנים את המכונות בסדר הנכון להתקנה, כמו שמתואר בהמשך בקטע "סדר עדכון המכונות".
כשיגיע הזמן לעדכן את הנתבים, בוחרים נתב אחד ומשנים את הסטטוס שלו ל"לא נגיש", כמו שמתואר במאמר הפעלה או השבתה של הנגישות לשרת (מעבד בקשות או נתב).
מעדכנים את הנתב שנבחר ואת כל רכיבי Edge האחרים באותו מחשב כמו הנתב. בכל ההגדרות של Edge מוצגים נתב ומעבד בקשות באותו צומת.
צריך לוודא שהנתב זמין שוב.
חוזרים על שלבים 2 עד 4 בשאר הנתבים.
ממשיכים לעדכן את שאר המחשבים בהתקנה.

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

בצומת משולב של נתב ומעבד בקשות:
- לפני העדכון – מבצעים את הפעולות הבאות:
  1. הופכים את הנתב ללא נגיש.
  2. הופכים את מעבד הבקשות ללא נגיש.
- אחרי העדכון – מבצעים את הפעולות הבאות:
  1. מוודאים שמעבד הבקשות נגיש.
  2. מוודאים שהנתב נגיש.
בצומת Router יחיד:
- לפני העדכון, צריך להגדיר את הנתב כלא נגיש.
- אחרי העדכון, צריך לוודא שהנתב נגיש.
בצומת יחיד של מעבד בקשות:
- לפני העדכון, צריך להגדיר שאי אפשר יהיה להגיע למעבד הבקשות.
- אחרי העדכון, צריך לוודא שאפשר להגיע למעבד הבקשות.

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

צריך להעביר קובץ תצורה שקט לפקודת העדכון. קובץ התצורה השקט צריך להיות זהה לזה שבו השתמשתם כדי להתקין את Edge 4.17.0x.

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

כדי לעדכן את רכיבי Edge בצומת:

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

אם משתמשים באחסון ברשת, לא צריך להתקין את הצומת החדש. במקום זאת, צריך ליצור תמונת מצב של הרשת של מאגר הנתונים שמשמש את Postgres. למידע נוסף, ראו שדרוג נדרש ל-Postgres 9.6.
אם יש משימות CRON שמוגדרות לבצע פעולת תיקון ב-Cassandra, צריך להשבית אותן עד לסיום העדכון.
כדי להתקין את חבילות ה-RPM של Edge, מתחברים לצומת כמשתמש root.
הערה: כדי להתקין את RPM נדרשת גישת root, אבל אפשר להגדיר את Edge בלי גישת root.
מתקינים את yum-utils ואת yum-plugin-priorities:
‎> sudo yum install yum-utils
‎> sudo yum install yum-plugin-priorities
משביתים את SELinux כמו שמתואר במאמר Install the Edge apigee-setup utility.
אם מתקינים ב-Oracle 7.x, מריצים את הפקודה הבאה:
> sudo yum-config-manager --enable ol7_optional_latest
אם אתם מתקינים ב-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
מורידים את הקובץ bootstrap_4.18.01.sh של Edge 4.18.01 אל /tmp/bootstrap_4.18.01.sh:
> curl https://software.apigee.com/bootstrap_4.18.01.sh -o /tmp/bootstrap_4.18.01.sh
מתקינים את כלי השירות apigee-service של Edge 4.18.01 ואת יחסי התלות:
> sudo bash /tmp/bootstrap_4.18.01.sh apigeeuser=uName apigeepassword=pWord

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

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

I = התקנת OpenJDK 1.8 (ברירת מחדל)
C = המשך בלי להתקין את Java
Q = יציאה. כדי להשתמש באפשרות הזו, צריך להתקין את Java בעצמכם.
השתמשו ב-apigee-service כדי לעדכן את כלי השירות apigee-setup:
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
מעדכנים את כלי השירות apigee-validate בשרת הניהול:
> /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
עדכון כלי השירות apigee-provision:
> /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
מריצים את כלי העדכון בצמתים לפי הסדר שמתואר בקטע "סדר עדכון המכונות" בהמשך:
> ‎/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

הדרישה היחידה לגבי קובץ התצורה היא שהוא יהיה נגיש או קריא למשתמש apigee.

משתמשים באפשרות "‎-c" כדי לציין את הרכיב שרוצים לעדכן. רשימת הרכיבים האפשריים כוללת:
ldap = OpenLDAP
cs = Cassandra
zk = Zookeeper
qpid = qpidd
ps = postgresql
edge =כל רכיבי Edge, חוץ מ-Edge UI: Management Server, ‏ Message Processor, ‏ Router, ‏ QPID Server, ‏ Postgres Server
ui = Edge UI
all = עדכון כל הרכיבים במכונה (משתמשים רק בפרופיל התקנה של Edge aio או בפרופיל התקנה של API BaaS asa)
e = ElasticSearch
b = API BaaS Stack
p = API BaaS Portal
ebp = ElasticSearch, ‏ API BaaS Stack ו-API BaaS Portal באותו צומת
כדי לבדוק את העדכון, מריצים את הכלי apigee-validate בשרת הניהול, כמו שמתואר בקטע בדיקת ההתקנה.
אם התקנתם צומת המתנה חדש של Postgres, הוציאו אותו משימוש כמו שמתואר למעלה בקטע הוצאה משימוש של צומת Postgres.

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

כדי לחזור לגרסה הקודמת, צריך לפעול לפי ההוראות שמפורטות בקטע 4.18.01 Rollback Process.

תהליך העדכון לגרסה 4.18.01 ממאגר מקומי

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

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

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

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

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

אם משתמשים באחסון ברשת, לא צריך להתקין את הצומת החדש. במקום זאת, צריך ליצור תמונת מצב של הרשת של מאגר הנתונים שמשמש את Postgres. למידע נוסף, ראו שדרוג נדרש ל-Postgres 9.6.
יוצרים מאגר מקומי בגרסה 4.18.01, כמו שמתואר בקטע "יצירת מאגר Apigee מקומי" במאמר התקנת כלי השירות apigee-setup של Edge.
הערה: אם כבר יש לכם מאגר 4.17.0x, אתם יכולים להוסיף לו את המאגר 4.18.01, כמו שמתואר בקטע "עדכון מאגר Apigee מקומי" במאמר התקנת כלי השירות apigee-setup של Edge.
כדי להתקין את apigee-service מקובץ ‎ .tar:
1. בצומת עם המאגר המקומי, משתמשים בפקודה הבאה כדי לארוז את המאגר המקומי לקובץ ‎ .tar יחיד בשם /opt/apigee/data/apigee-mirror/apigee-4.18.01.tar.gz:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
2. מעתיקים את קובץ ה-‎ .tar לצומת שבו רוצים לעדכן את Edge. לדוגמה, מעתיקים אותו לספרייה ‎/tmp בצומת החדש.
3. בצומת החדש, מחלצים את הקובץ לספרייה ‎ /tmp:
  > tar -xzf apigee-4.18.01.tar.gz
  
  הפקודה הזו יוצרת ספרייה חדשה בשם repos בספרייה שמכילה את קובץ ה-‎ .tar. לדוגמה, ‎ /tmp/repos.
4. מתקינים את כלי השירות apigee-service של Edge ואת יחסי התלות מ-‎ /tmp/repos:
  > sudo bash /tmp/repos/bootstrap_4.18.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
  
  שימו לב שאתם כוללים את הנתיב לספריית המאגרים בפקודה הזו.
כדי להתקין את apigee-service באמצעות שרת האינטרנט Nginx:
1. מגדירים את שרת האינטרנט Nginx כמו שמתואר בקטע "התקנה מהמאגר באמצעות שרת האינטרנט Nginx" במאמר התקנת כלי השירות apigee-setup של Edge.
2. בצומת המרוחק, מורידים את הקובץ bootstrap_4.18.01.sh של Edge אל /tmp/bootstrap_4.18.01.sh:
  > /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.18.01.sh -o /tmp/bootstrap_4.18.01.sh
  
  כאשר uName:pWord הם שם המשתמש והסיסמה שהגדרתם למעלה למאגר, ו-remoteRepo הוא כתובת ה-IP או שם ה-DNS של צומת המאגר.
3. בצומת המרוחק, מתקינים את כלי השירות apigee-service של Edge ואת יחסי התלות:
  > sudo bash /tmp/bootstrap_4.18.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
  
  כאשר uName:pWord הם שם המשתמש והסיסמה של המאגר.
השתמשו ב-apigee-service כדי לעדכן את כלי השירות apigee-setup:
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
מעדכנים את כלי השירות apigee-validate בשרת הניהול.
> /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
עדכון כלי השירות apigee-provision:
> /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
מריצים את כלי העדכון בצמתים לפי הסדר שמתואר בקטע "סדר עדכון המכונות" בהמשך:
> ‎/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

הדרישה היחידה לגבי קובץ התצורה היא שהוא יהיה נגיש או קריא למשתמש apigee.

משתמשים באפשרות "‎-c" כדי לציין את הרכיב שרוצים לעדכן. רשימת הרכיבים האפשריים כוללת:
ldap = OpenLDAP
cs = Cassandra
zk = Zookeeper
qpid = qpidd
ps = postgresql
edge =כל רכיבי Edge, חוץ מ-Edge UI: Management Server, ‏ Message Processor, ‏ Router, ‏ QPID Server, ‏ Postgres Server
ui = Edge UI
all = עדכון כל הרכיבים במכונה (משתמשים רק בפרופיל התקנה של Edge aio או בפרופיל התקנה של API BaaS asa)
e = ElasticSearch
b = API BaaS Stack
p = API BaaS Portal
ebp = ElasticSearch, ‏ API BaaS Stack ו-API BaaS Portal באותו צומת
בודקים את העדכון על ידי הפעלת הכלי apigee-validate בשרת הניהול, כפי שמתואר בקטע בדיקת ההתקנה.
אם התקנתם צומת המתנה חדש של Postgres, צריך להוציא אותו משימוש כמו שמתואר למעלה בקטע הוצאה משימוש של צומת Postgres.

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

כדי לחזור לגרסה הקודמת, צריך לפעול לפי ההוראות שמפורטות בקטע 4.18.01 Rollback Process.

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

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

צריך לעדכן את כל הצמתים של Cassandra ו-ZooKeeper לפני שמעדכנים צמתים אחרים.
בכל מכונה עם כמה רכיבי Edge (שרת ניהול, מעבד בקשות, נתב, שרת QPID אבל לא שרת Postgres), צריך להשתמש באפשרות "‎-c edge" כדי לעדכן את כולם בו-זמנית.
אם בשלב מסוים מצוין שצריך לבצע אותו בכמה מכונות, בצעו אותו לפי סדר המכונות שצוין.
אין שלב נפרד לעדכון המונטיזציה. הוא מתעדכן כשמציינים את האפשרות "‎-c edge".