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

שדרוג Apigee Hybrid לגרסה 1.12

ההליך הזה מתייחס לשדרוג מגרסה Apigee hybrid 1.11.x לגרסה Apigee hybrid 1.12.4, ומגרסאות קודמות של hybrid 1.12.x לגרסה 1.12.4.

אפשר להשתמש באותן פעולות לשדרוג גרסה משנית (לדוגמה, מגרסה 1.11 לגרסה 1.12) ולשדרוג גרסת תיקון (לדוגמה, מגרסה 1.12.0 לגרסה 1.12.4).

אם אתם משדרגים מ-Apigee Hybrid בגרסה 1.10 או בגרסה ישנה יותר, אתם צריכים לשדרג קודם לגרסה 1.11 לפני שתשדרגו לגרסה 1.12.4. אפשר לעיין בהוראות בנושא שדרוג Apigee Hybrid לגרסה 1.11.

שינויים מגרסה Apigee Hybrid v1.11

בגרסה 1.12 של Apigee Hybrid בוצעו השינויים הבאים שמשפיעים על תהליך השדרוג. רשימה מלאה של התכונות בגרסה 1.12 זמינה בהערות על הגרסה ההיברידית 1.12.0.

‫Cassandra 4.x: החל מגרסה 1.12, ‏ Apigee Hybrid משתמש ב-Cassandra מגרסה 4 ואילך.
חשוב: בגלל השינוי במסד הנתונים, אי אפשר לחזור אחורה לרכיב apigee-datastore המשודרג. לכן, חשוב מאוד לגבות את מסד הנתונים של Cassandra ואת ההתקנה ההיברידית לפני השדרוג. אם אתם צריכים לבטל את השדרוג, כדאי להביא בחשבון את התרחישים הבאים:
- Cassandra עדיין לא שודרג: אפשר לבטל את כל השינויים.
- Cassandra שודרג וכל ה-pods של Cassandra תקינים: אפשר לבטל את השינויים בכל הרכיבים חוץ מ-apigee-datastore. ההתקנה של גרסה 1.11.x תמשיך לפעול עם מופע של גרסה 1.12 של apigee-datastore שפועל עם Cassandra גרסה 4.
- השדרוג של Cassandra בוצע וה-pods של Cassandra במצב לא תקין: צריך להסיר את hybrid v1.12 ולשחזר את ההתקנה של v.11 מגיבוי.
הוצאה משימוש של apigeectl: החל מגרסה 1.12, Apigee hybrid תומך רק ב-Helm להתקנה ולניהול של התקנת hybrid.
שימו לב: apigeectl יצא משימוש החל מ-17 באפריל 2024. הכלי apigeectl לא נתמך ב-Apigee hybrid v1.12. התמיכה ב-apigeectl ב-Apigee hybrid בגרסאות 1.10 ו-1.11 תסתיים ב-17 באפריל 2025. מידע נוסף זמין במאמר בנושא הוצאה משימוש של apigeectl.

חשוב: אם אתם מנהלים את גרסה 1.11 באמצעות apigeectl, אתם צריכים קודם להעביר את ההתקנה של גרסה 1.11 לשימוש ב-Helm לפני שתשדרגו לגרסה 1.12. פועלים לפי ההוראות במאמר העברת Apigee Hybrid לתרשימי Helm מ-apigeectl.
הוספנו חבילה חדשה של מדדים למעקב אחרי שרתי proxy של Apigee ונקודות קצה של יעדים. ב-hybrid v1.12, המשאבים שבמעקב ProxyV2 ו-TargetV2 לא ישמשו יותר כברירת מחדל. כל מדדי ה-proxy והיעד יפורסמו במשאבים שבמעקב Proxy ו-Target.

כדי להמשיך לשלוח מדדים אל ProxyV2 וTargetV2 משאבים שבמעקב, צריך להגדיר את metrics.disablePrometheusPipeline לערך true ב-overrides.yaml.
אם הגדרתם התראות שמבוססות על מדדים, ודאו שאתם משתמשים במדדים הנכונים להתקנה ההיברידית. מידע נוסף זמין במאמר בנושא התראות שמבוססות על מדדים.
בדיקות מחמירות יותר של יצירת מופע של מחלקה: החל מגרסה 1.12.4 של Apigee hybrid, ‏ JavaCallout policy כולל עכשיו אבטחה נוספת במהלך יצירת מופע של מחלקת Java. אמצעי האבטחה המשופר מונע פריסה של מדיניות שמנסה לבצע פעולות שדורשות הרשאות שלא מותרות, באופן ישיר או עקיף.
ברוב המקרים, כללי מדיניות קיימים ימשיכו לפעול כצפוי ללא בעיות. עם זאת, יכול להיות שתהיה השפעה על כללי מדיניות שמסתמכים על ספריות של צד שלישי, או על כללי מדיניות עם קוד מותאם אישית שמפעיל באופן עקיף פעולות שדורשות הרשאות גבוהות יותר.

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

נקודות שכדאי לשים לב אליהן לפני שמתחילים שדרוג לגרסה 1.12

שיקולים לגבי Cassandra

שדרוג מגרסה 1.11 של Apigee Hybrid לגרסה 1.12 כולל שדרוג של מסד הנתונים של Cassandra מגרסה 3.11.x לגרסה 4.x. השדרוג של Cassandra מתבצע כחלק מתהליך השדרוג של Apigee Hybrid, אבל חשוב לתכנן את הפעולות הבאות:

שדרוג הגרסה של Cassandra יתבצע ברקע, על פוד אחד (או על צומת Cassandra) בכל פעם, לכן כדאי לתכנן קיבולת מסד נתונים מופחתת במהלך השדרוג.
לפני שמתחילים בשדרוג, צריך להגדיל את הקיבולת של Cassandra ולוודא ששימוש הדיסק קרוב ל-50% או פחות.
מומלץ לבדוק את הגיבוי של Cassandra ואת תהליכי השחזור.
לפני שמתחילים לשדרג את ההתקנה של Cassandra בגרסה היברידית 1.11, צריך לגבות את הנתונים של Cassandra ולאמת את הגיבויים.
שדרוג של apigee-datastore יגרום לעלייה זמנית בצריכת המעבד בגלל משימות שמתבצעות על ידי Cassandra אחרי השדרוג
אחרי שמשדרגים את רכיב apigee-datastore (Cassandra), אי אפשר לחזור לגרסה הקודמת של הרכיב הזה. יש שני תרחישים לחזרה משדרוג ל-hybrid v1.12 אחרי שמשדרגים את רכיב apigee-datastore:
- אם הרכיב apigee-datastore במצב טוב אבל רכיבים אחרים צריכים לחזור לגרסה קודמת, אפשר להחזיר כל אחד מהרכיבים האחרים לגרסה קודמת בנפרד.
  הערה: לא תוכלו להוסיף אזורים או לשנות את גודל הצמתים של Cassandra בזמן שרכיבים של גרסאות היברידיות שונות פועלים.
- אם רכיב apigee-datastore נמצא במצב לא תקין, צריך לשחזר מגיבוי v1.11 להתקנה v1.11.
  הערה: אי אפשר לשלב בין גרסאות כשמשחזרים. חובה לשחזר גיבוי שנוצר בהתקנה של גרסה 1.11 לתוך התקנה של גרסה 1.11.

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

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

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

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

‫Apigee ממליץ על הרצף הבא לשדרוג התקנה במספר אזורים:

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

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

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

התקנה של Apigee Hybrid גרסה 1.11 שמנוהלת באמצעות Helm.
- אם אתם מנהלים את ההתקנה ההיברידית באמצעות apigeectl, אתם צריכים קודם להעביר את האשכולות לניהול באמצעות Helm. מידע נוסף זמין במאמר העברת Apigee Hybrid ל-Helm מגרסה apigeectl בתיעוד של Hybrid v1.11.
- אם ההתקנה ההיברידית שלכם מריצה גרסה ישנה יותר מגרסה 1.11, אתם צריכים לשדרג לגרסה 1.11 לפני שמשדרגים לגרסה 1.12. מידע נוסף על שדרוג Apigee Hybrid לגרסה 1.11
‫Helm גרסה v3.14.2 ומעלה.
גרסה 1.27,‏ 1.28 או 1.29 (מומלץ).kubectl
גרסה v1.13.0 של cert-manager. במקרה הצורך, תוכלו לשדרג את cert-manager בקטע הכנה לשדרוג לגרסה שבהמשך.

מגבלות

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

אי אפשר לשחזר גיבויים מ-Hybrid 1.12 ב-Hybrid 1.11, ולהפך, בגלל חוסר תאימות בין שתי הגרסאות.
אי אפשר לשנות את גודל ה-pods של מאגר הנתונים במהלך השדרוג לגרסה 1.12. לפני שמתחילים לשדרג את ההתקנה ההיברידית, צריך לטפל בצרכים שלכם בנוגע להרחבת הפריסה בכל האזורים.
בהתקנה היברידית באזור יחיד, אי אפשר לבטל את השדרוג של רכיב מאגר הנתונים אחרי שתהליך השדרוג של מאגר הנתונים מסתיים. אי אפשר להחזיר מאגר נתונים של Cassandra 4.x למאגר נתונים של Cassandra 3.x. כדי לעשות את זה, תצטרכו לשחזר את הגיבוי האחרון של נתוני Cassandra 3.x (מההתקנה של הגרסה ההיברידית 1.11).
אי אפשר למחוק או להוסיף אזור במהלך השדרוג. בשדרוג של מספר אזורים, צריך להשלים את השדרוג של כל האזורים לפני שמוסיפים או מוחקים אזורים.

סקירה כללית של שדרוג לגרסה 1.12.4

יכול להיות ששדרוג לגרסה 1.12 של Apigee Hybrid ידרוש השבתה.

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

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

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

ההליכים לשדרוג Apigee hybrid מאורגנים בקטעים הבאים:

הכנות לשדרוג
- גיבוי של Cassandra.
- מגבים את ספריות ההתקנה ההיברידית.
איך מתקינים את גרסת זמן הריצה ההיברידית 1.12.4

הכנה לשדרוג לגרסה 1.12

גיבוי של Cassandra

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

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

כדי להפעיל מחדש את ה-pods של Cassandra ולבדוק אותם, מוחקים כל pod בנפרד, אחד בכל פעם, ואז מוודאים שהוא חוזר למצב פעיל ושהבדיקה של מוכנות עוברת:

מציגים את רשימת ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

לדוגמה:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

מחיקת פוד:

kubectl delete pod -n APIGEE_NAMESPACE CASSANDRA_POD_NAME

לדוגמה:

kubectl delete pod -n apigee apigee-cassandra-default-0

כדי לבדוק את הסטטוס, מריצים שוב את הפקודה לרשימת ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

לדוגמה:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          16s
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

. . .

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

מוודאים שכל צמתי Cassandra בכל האזורים נמצאים במצב UN (Up / Normal). אם צומת Cassandra כלשהו נמצא במצב שונה, צריך לטפל בבעיה הזו לפני שמתחילים בשדרוג.

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

מציגים את רשימת ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

לדוגמה:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

בודקים את מצב הצמתים של כל פוד של Cassandra באמצעות הפקודה kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool status

לדוגמה:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.16.2.6    690.17 KiB  256          48.8%             b02089d1-0521-42e1-bbed-900656a58b68  ra-1
UN  10.16.4.6    705.55 KiB  256          51.6%             dc6b7faf-6866-4044-9ac9-1269ebd85dab  ra-1
UN  10.16.11.11  674.36 KiB  256          48.3%             c7906366-6c98-4ff6-a4fd-17c596c33cf7  ra-1
UN  10.16.1.11   697.03 KiB  256          49.8%             ddf221aa-80aa-497d-b73f-67e576ff1a23  ra-1
UN  10.16.5.13   703.64 KiB  256          50.9%             2f01ac42-4b6a-4f9e-a4eb-4734c24def95  ra-1
UN  10.16.8.15   700.42 KiB  256          50.6%             a27f93af-f8a0-4c88-839f-2d653596efc2  ra-1
UN  10.16.11.3   697.03 KiB  256          49.8%             dad221ff-dad1-de33-2cd3-f1.672367e6f  ra-1
UN  10.16.14.16  704.04 KiB  256          50.9%             1feed042-a4b6-24ab-49a1-24d4cef95473  ra-1
UN  10.16.16.1   699.82 KiB  256          50.6%             beef93af-fee0-8e9d-8bbf-efc22d653596  ra-1

גיבוי של ספריות ההתקנה ההיברידית

בהוראות האלה נעשה שימוש במשתנה הסביבה APIGEE_HELM_CHARTS_HOME עבור הספרייה במערכת הקבצים שבה התקנתם את תרשימי Helm. אם צריך, משנים את הספרייה לספרייה הזו ומגדירים את המשתנה באמצעות הפקודה הבאה:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Mac OS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
יוצרים עותק גיבוי של ספריית $APIGEE_HELM_CHARTS_HOME/ בגרסה 1.11. אפשר להשתמש בכל תהליך גיבוי. לדוגמה, אפשר ליצור קובץ tar של כל הספרייה באמצעות הפקודה:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.11-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
מגבים את מסד הנתונים של Cassandra לפי ההוראות במאמר בנושא גיבוי ושחזור של Cassandra.

אם אתם משתמשים בקובצי אישורים של שירות (.json) בשינויים שלכם כדי לאמת חשבונות שירות, ודאו שקובצי האישורים של חשבונות השירות נמצאים בספריית תרשימי ה-Helm הנכונה. תרשימי Helm לא יכולים לקרוא קבצים מחוץ לספרייה של כל תרשים.

לא צריך לבצע את השלב הזה אם משתמשים בסודות של Kubernetes או ב-Workload Identity כדי לאמת חשבונות שירות.

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

Prod

חשבון שירות	שם קובץ ברירת מחדל	ספריית תרשימי Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

Non-prod

יוצרים עותק של קובץ חשבון השירות apigee-non-prod בכל אחת מהספריות הבאות:

חשבון שירות	שם קובץ ברירת מחדל	ספריות של תרשימי Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

מוודאים שקובצי המפתח ואישור ה-TLS (.crt,‏ .key ו/או .pem) נמצאים בספרייה $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

שדרוג גרסת Kubernetes

בודקים את גרסת פלטפורמת Kubernetes, ואם צריך, משדרגים את פלטפורמת Kubernetes לגרסה שנתמכת על ידי hybrid 1.11 ו-hybrid 1.12. אם אתם צריכים עזרה, תוכלו לעיין במסמכי התיעוד של הפלטפורמה.

כאן אפשר ללחוץ כדי להרחיב את רשימת הפלטפורמות הנתמכות

	‫1.10 ⁽³⁾	‫1.11	‫1.12
‫GKE ב- Google Cloud	‫1.24.x ‫1.25.x ‫1.26.x ‫1.27.x^{(≥ 1.10.5)} ‫1.28.x^{(≥ 1.10.5)}	‫1.25.x ‫1.26.x ‫1.27.x ‫1.28.x^{(≥ 1.11.2)} ‫1.29.x^{(≥ 1.11.2)}	‫1.26.x ‫1.27.x ‫1.28.x ‫1.29.x^{(≥ 1.12.1)}
‫GKE ב-AWS	‫1.13.x (K8s v1.24.x) ‫1.14.x (K8s v1.25.x) ‫1.26.x⁽¹²⁾ ‫1.27.x^{(≥ 1.10.5)} ‫1.28.x^{(≥ 1.10.5)}	‫1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	‪1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
‫GKE ב-Azure	‫1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	‫1.14.x 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	‫1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(‎≥ 1.12.1)}
‫Google Distributed Cloud (תוכנה בלבד) ב-VMware ⁽¹⁾ ⁽¹³⁾	‫1.13.x ‫1.14.x ‫1.15.x‏ (K8s v1.26.x) ‫1.16.x‏ (K8s v1.27.x) ‫1.27.x^{(≥ 1.10.5)} ‫1.28.x^{(≥ 1.10.5)}	‫1.14.x ‫1.15.x‏ (K8s v1.26.x) ‫1.16.x‏ (K8s v1.27.x) ‫1.28.x^{(≥ 1.11.2)} ‫1.29.x^{(≥ 1.11.2)}	‫1.15.x‏ (K8s v1.26.x) ‫1.16.x‏ (K8s v1.27.x) ‫1.28.x⁽¹²⁾ ‫1.29.x^{(‎≥ 1.12.1)}
‫Google Distributed Cloud (תוכנה בלבד) בשרת פיזי ⁽¹⁾	‫1.13.x ‫1.14.x‏ (K8s v1.25.x) ‫1.15.x‏ (K8s v1.26.x) ‫1.16.x‏ (K8s v1.27.x) ‫1.27.x⁽¹²⁾^{(≥ 1.10.5)} ‫1.28.x^{(≥ 1.10.5)}	‫1.14.x ‫1.15.x (K8s v1.26.x) ‫1.16.x (K8s v1.27.x) ‫1.28.x⁽¹²⁾^{(≥ 1.11.2)} ‫1.29.x^{(≥ 1.11.2)}	‫1.15.x‏ (K8s v1.26.x) ‫1.16.x‏ (K8s v1.27.x) ‫1.28.x⁽¹²⁾ ‫1.29.x^{(‎≥ 1.12.1)}
EKS⁽⁷⁾	‪1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	‫1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	‫1.26.x ‫1.27.x ‫1.28.x ‫1.29.x^{(≥ 1.12.1)}
AKS⁽⁷⁾	‪1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	‫1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	‫1.26.x ‫1.27.x ‫1.28.x ‫1.29.x^{(≥ 1.12.1)}
OpenShift⁽⁷⁾	‫4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	‫4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	‫4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	‫v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	‫v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(‎≥ 1.12.1)}
VMware Tanzu	לא רלוונטי	לא רלוונטי	v1.26.x
רכיבים	‫1.10	‫1.11	‫1.12
Cloud Service Mesh	‫1.17.x⁽¹⁰⁾	‫1.18.x⁽¹⁰⁾	‫1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	‫1.10.x 1.11.x 1.12.x	‫1.11.x 1.12.x 1.13.x	‫1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
‏Kubernetes	‫1.24.x ‫1.25.x ‫1.26.x	‫1.25.x ‫1.26.x ‫1.27.x	‫1.26.x ‫1.27.x ‫1.28.x
kubectl			‫1.27.x ‫1.28.x ‫1.29.x
Helm	‫3.10 ומעלה	‫3.10 ומעלה	3.14.2+
Secret Store CSI driver		1.3.4	1.4.1
Vault		‫‎1.13.x	1.15.2
‫⁽¹⁾ ב-Anthos on-premises (Google Distributed Cloud) גרסה 1.13, פועלים לפי ההוראות האלה כדי למנוע התנגשות עם `cert-manager`: התקנה של cert-manager שמתנגשת עם התקנה אחרת ‫⁽²⁾ התמיכה זמינה בגרסה 1.7.2 של Apigee Hybrid ואילך. ^‫(3) תאריכי סוף החיים הרשמיים של גרסאות Apigee Hybrid 1.10 ומגרסאות ישנות יותר כבר חלפו. טלאים חודשיים רגילים כבר לא זמינים. אין יותר תמיכה רשמית בגרסאות האלה, למעט לקוחות עם חריגים מפורשים ורשמיים להמשך התמיכה. לקוחות אחרים צריכים לשדרג. ^‫(4)הסתיימה התמיכה בגרסה 1.12 ובגרסאות קודמות של Anthos on-premises (Google Distributed Cloud). אפשר לעיין במדיניות התמיכה בגרסאות של Distributed Cloud on bare metal וברשימת הגרסאות הנתמכות של Distributed Cloud on VMware. ‫⁽⁵⁾‫Google Distributed Cloud ב-bare metal או ב-VMware דורש Cloud Service Mesh בגרסה 1.14 ואילך. מומלץ לשדרג לגרסה 1.8 של Hybrid ולעבור ל-Apigee ingress gateway, שלא מחייב יותר התקנה של Cloud Service Mesh באשכול Hybrid. ‫⁽⁶⁾ תמיכה זמינה בגרסה 1.8.4 של Apigee Hybrid ובגרסאות חדשות יותר. ‫⁽⁷⁾ לא נתמך ב-Apigee Hybrid בגרסה 1.8.4 ואילך. ^‫(8) התמיכה זמינה ב-Apigee Hybrid גרסה 1.7.6 ואילך. ^‫(9) לא נתמך ב-Apigee Hybrid בגרסה 1.8.5 ואילך. ^‫(10) Cloud Service Mesh מותקן באופן אוטומטי עם Apigee Hybrid בגרסה 1.9 ואילך. ^‫(11) התמיכה זמינה בגרסה 1.9.2 של Apigee Hybrid ואילך. ‫⁽¹²⁾ מספרי הגרסאות של GKE ב-AWS משקפים עכשיו את גרסאות Kubernetes. פרטים על הגרסה ועל תיקונים מומלצים זמינים במאמר בנושא תמיכה בגרסאות ובשדרוגים של GKE Enterprise. ‫⁽¹³⁾ Vault לא מאושר ב-Google Distributed Cloud ל-VMware. ^‫(14) תמיכה זמינה בגרסה 1.10.5 של Apigee Hybrid ואילך. ‫⁽¹⁵⁾ התמיכה זמינה בגרסה 1.11.2 של Apigee Hybrid ובגרסאות חדשות יותר. ^‫(16) תמיכה זמינה ב-Apigee Hybrid גרסה 1.12.1 ואילך.

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

בגרסאות היברידיות של Apigee‏ 1.7.x ומטה, צריך להשתמש באשכולות מצורפים של GKE אם רוצים להפעיל את Apigee hybrid בהקשר של ריבוי עננים ב-Elastic Kubernetes Service‏ (EKS), ב-Azure Kubernetes Service‏ (AKS) או בספק שירותי Kubernetes אחר של צד שלישי שנתמך. צירוף אשכול מאפשר ל-Google למדוד את השימוש ב-Cloud Service Mesh.

אם אתם משתמשים ב-Cloud Service Mesh בשביל שער הכניסה, אתם צריכים אשכולות GKE מצורפים ב-Apigee hybrid בגרסה 1.8.x. אם אתם משתמשים בשער כניסה של Apigee, צירוף אשכולות הוא אופציונלי.

התקנת זמן הריצה של hybrid 1.12.4

הכנה לשדרוג של תרשימי Helm

שולפים את תרשימי Apigee Helm.

תרשימים של Apigee Hybrid מתארחים ב-Google Artifact Registry:

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

כדי להעתיק את כל תרשימי ה-Helm של Apigee hybrid לאחסון המקומי, משתמשים בפקודה pull הבאה:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.12.4
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

משדרגים את cert-manager אם צריך.
אם אתם צריכים לשדרג את הגרסה של cert-manager, אתם יכולים להתקין את הגרסה החדשה באמצעות הפקודה הבאה:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.13.0/cert-manager.yaml
```

מתקינים את ה-CRD המעודכנים של Apigee:

הערה: זו השיטה הנתמכת היחידה להתקנת CRD של Apigee. אל תשתמשו ב-kubectl apply בלי -k, ואל תשמיטו את --server-side.

כדי להשתמש בתכונה של הרצה יבשה של kubectl, מריצים את הפקודה הבאה:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run

אחרי האימות באמצעות הפקודה להרצה יבשה, מריצים את הפקודה הבאה:
```
kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false
```

מאמתים את ההתקנה באמצעות הפקודה kubectl get crds:

kubectl get crds | grep apigee

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

apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z

בודקים את התוויות בצמתי האשכול. כברירת מחדל, Apigee מתזמן את הפודים של הנתונים בצמתים עם התווית cloud.google.com/gke-nodepool=apigee-data, ואת הפודים של זמן הריצה בצמתים עם התווית cloud.google.com/gke-nodepool=apigee-runtime. אפשר להתאים אישית את תוויות מאגר הצמתים בקובץ overrides.yaml.

מידע נוסף זמין במאמר בנושא הגדרת מאגרי צמתים ייעודיים.

התקנה של תרשימי Helm של Apigee Hybrid

הערה: לפני שמריצים פקודות שדרוג או התקנה של Helm, כדאי להשתמש בתכונה Helm dry-run. כדי לעשות זאת, מוסיפים את האפשרות --dry-run בסוף הפקודה. אפשר להשתמש בפקודה helm -h כדי לראות רשימה של הפקודות, האפשרויות והשימוש הנתמכים.

אם לא, עוברים לספרייה APIGEE_HELM_CHARTS_HOME ומריצים את הפקודות הבאות מתוך הספרייה.

משדרגים את Apigee Operator/Controller:

הערה: השלב הזה דורש הרשאות גבוהות יותר באשכול. מריצים את helm -h או את helm upgrade -h כדי לקבל פרטים

הרצת בדיקה:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  --force \
  -f OVERRIDES_FILE

אימות ההתקנה של Apigee Operator:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

שדרוג מאגר הנתונים של Apigee:

הרצת בדיקה:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

כדי לוודא ש-apigeedatastore פועל, בודקים את המצב שלו:

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

שדרוג הטלמטרייה של Apigee:

הרצת בדיקה:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

שדרוג של Apigee Redis:

הרצת בדיקה:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

משדרגים את Apigee ingress manager:

הרצת בדיקה:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

משדרגים את הארגון ב-Apigee:

הרצת בדיקה:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run

שדרוג התרשים:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE

הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --force \
  -f OVERRIDES_FILE

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

kubectl -n apigee get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

משדרגים את הסביבה.
צריך להתקין סביבה אחת בכל פעם. מציינים את הסביבה באמצעות --set env=ENV_NAME:

הרצת בדיקה:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
- ‫ENV_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-env. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-env-ENV_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל זה ENV_NAME.
- ‫ENV_NAME הוא שם הסביבה שמשדרגים.
- ‫OVERRIDES_FILE הוא קובץ ההחלפות החדש שלך לגרסה 1.12.4
שדרוג התרשים:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
כדי לוודא שהיא פועלת, בודקים את המצב של סביבת ה-env המתאימה:
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
משדרגים את קבוצות הסביבות (virtualhosts).
1. צריך לשדרג קבוצת סביבות (virtualhost) אחת בכל פעם. מציינים את קבוצת הסביבות באמצעות --set envgroup=ENV_GROUP_NAME. חוזרים על הפקודות הבאות לכל קבוצת סביבות שמוזכרת בקובץ overrides.yaml:
  הרצת בדיקה:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
  ‫ENV_GROUP_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-virtualhost. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-virtualhost-ENV_GROUP_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל מדובר ב-ENV_GROUP_NAME.
  
  שדרוג התרשים:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  הערה: אם ההתקנות הועברו מ-apigeectl ל-Helm, צריך להשתמש בפקודה הבאה:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -f OVERRIDES_FILE
```
  הערה: הערך של ENV_GROUP_RELEASE_NAME צריך להיות ייחודי במרחב השמות apigee.
  לדוגמה, אם יש לכם סביבה בשם prod וקבוצת סביבות בשם prod, צריך להגדיר את הערך של ENV_GROUP_RELEASE_NAME למשהו ייחודי, כמו prod-envgroup.
2. בודקים את המצב של ApigeeRoute ‏ (AR).
  התקנת virtualhosts יוצרת ApigeeRouteConfig ‏(ARC), שיוצר באופן פנימי ApigeeRoute ‏(AR) אחרי שה-watcher של Apigee שולף פרטים שקשורים לקבוצת הסביבות ממישור הבקרה. לכן, צריך לוודא שהמצב של ה-AR התואם הוא running (פועל):
```
kubectl -n apigee get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

אימות המדיניות אחרי שדרוג לגרסה 1.12.4

אפשר להשתמש בהליך הזה כדי לאמת את ההתנהגות של מדיניות JavaCallout אחרי שדרוג מגרסה 1.12.3 או מגרסה מוקדמת יותר לגרסה 1.12.4 או לגרסה מאוחרת יותר.

בודקים אם קובצי ה-Java JAR מבקשים הרשאות מיותרות.
אחרי פריסת המדיניות, בודקים ביומני זמן הריצה אם מופיעה הודעת היומן הבאה: "Failed to load and initialize class ...". אם ההודעה הזו מופיעה, סימן שקובץ ה-JAR שנפרס ביקש הרשאות מיותרות. כדי לפתור את הבעיה, צריך לבדוק את קוד ה-Java ולעדכן את קובץ ה-JAR.
בודקים ומעדכנים את קוד Java.
בודקים את קוד ה-Java (כולל יחסי תלות) כדי לזהות את הסיבה לפעולות שאולי לא מותרות. אם נמצא, משנים את קוד המקור לפי הצורך.
בדיקת מדיניות עם הפעלת בדיקת האבטחה.
בסביבה שאינה סביבת ייצור, מפעילים את סימון בדיקת האבטחה ומפרסים מחדש את המדיניות עם קובץ JAR מעודכן. כדי להגדיר את הסימון:
- בקובץ apigee-env/values.yaml, מגדירים את conf_security-secure.constructor.only לערך true בקטע runtime:cwcAppend:. לדוגמה:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- כדי להחיל את השינוי, צריך לעדכן את התרשים apigee-env של הסביבה. לדוגמה:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
אם הודעת היומן "Failed to load and initialize class ..." עדיין מופיעה, ממשיכים לשנות ולבדוק את קובץ ה-JAR עד שהודעת היומן לא מופיעה יותר.
הפעלת בדיקת האבטחה בסביבת הייצור.
אחרי שבודקים ומאמתים את קובץ ה-JAR בסביבה שאינה סביבת ייצור, מפעילים את בדיקת האבטחה בסביבת הייצור על ידי הגדרת הדגל conf_security-secure.constructor.only לערך true ועדכון התרשים apigee-env בסביבת הייצור כדי להחיל את השינוי.

חזרה לגרסה קודמת

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

ביטול שינויים ושחזור באזור יחיד

חזרה למצב הקודם כשהמצב של `apigee-datastore` תקין

במאמר הזה מוסבר איך לבצע החזרה (rollback) של כל רכיב Apigee hybrid מגרסה 1.12 לגרסה 1.11 חוץ מapigee-datastore. רכיב v1.12 apigee-datastore תואם לאחור לרכיבי v1.11 היברידיים.

אזהרה: אי אפשר לבטל את השדרוג של apigee-datastore. אי-התאמה של נתונים בין גרסאות שונות של מסד הנתונים Cassandra מונעת חזרה לגרסה הקודמת.

כדי לחזור מגרסה 1.12 לגרסה 1.11 של ההתקנה של אזור יחיד:

לפני שמתחילים בהחזרה לגרסה קודמת, מוודאים שכל הפודים במצב פעיל:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

מאמתים את השחרור של הרכיבים באמצעות Helm:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

לדוגמה

helm -n apigee list
NAME              NAMESPACE   REVISION   UPDATED                                   STATUS     CHART                           APP VERSION
datastore         apigee      2          2024-03-29 17:08:07.917848253 +0000 UTC   deployed   apigee-datastore-1.12.0         1.12.0
ingress-manager   apigee      2          2024-03-29 17:21:02.917333616 +0000 UTC   deployed   apigee-ingress-manager-1.12.0   1.12.0
redis             apigee      2          2024-03-29 17:19:51.143728084 +0000 UTC   deployed   apigee-redis-1.12.0             1.12.0
telemetry         apigee      2          2024-03-29 17:16:09.883885403 +0000 UTC   deployed   apigee-telemetry-1.12.0         1.12.0
myhybridorg       apigee      2          2024-03-29 17:21:50.899855344 +0000 UTC   deployed   apigee-org-1.12.0               1.12.0

מבטלים את השינויים בכל רכיב חוץ מ-apigee-datastore באמצעות הפקודות הבאות:

יוצרים את משתנה הסביבה הבא:
- ‫PREVIOUS_HELM_CHARTS_HOME: הספרייה שבה מותקנים תרשימי ה-Helm הקודמים של Apigee Hybrid. זו הגרסה שאליה חוזרים.
מחזירים את המארחים הווירטואליים לגרסה קודמת. חוזרים על הפקודה הבאה לכל קבוצת סביבות שמוזכרת בקובץ ההגדרות.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
‫ENV_GROUP_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-virtualhost. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-virtualhost-ENV_GROUP_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל מדובר ב-ENV_GROUP_NAME.
מבטלים את השינויים בסביבות. חוזרים על הפקודה הבאה לכל סביבה שמוזכרת בקובץ הביטולים.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
‫ENV_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-env. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-env-ENV_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל מדובר ב-ENV_NAME.

כדי לוודא שהיא פועלת, בודקים את המצב של סביבת ה-env המתאימה:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

החזרה של הארגון לגרסה קודמת:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

מחזירים את Ingress Manager למצב קודם:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

החזרה לגרסה קודמת של Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

החזרה לגרסה קודמת של Apigee Telemetry:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

מחזירים את Apigee Controller לגרסה קודמת:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

אימות ההתקנה של Apigee Operator:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

מחזירים את ה-CRD של Apigee Hybrid למצב קודם:

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

מוודאים שכל ה-pods נמצאים במצב פעיל או במצב השלמה:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

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

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

לדוגמה

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

שחזור כשהמצב של `apigee-datastore` לא תקין

אם השדרוג של רכיב apigee-datastore לא הצליח, אי אפשר לחזור מגרסה 1.12 לגרסה 1.11.apigee-datastore במקום זאת, צריך לשחזר מגיבוי שנוצר מהתקנה של גרסה 1.11. כדי לשחזר את הגרסה הקודמת, משתמשים ברצף הבא.

אם אין לכם התקנה פעילה של Apigee Hybrid בגרסה 1.11 (לדוגמה, באזור אחר), צריך ליצור התקנה חדשה של גרסה 1.11 באמצעות התרשימים וקובצי ההחלפה שגיביתם. אפשר לעיין בהוראות ההתקנה של Apigee Hybrid בגרסה 1.11.
משחזרים את אזור v1.11 (או התקנה חדשה) מהגיבוי בהתאם להוראות שמופיעות כאן:
- גיבויים של Cloud Storage Interface ‏ (CSI): גיבוי ושחזור של Cassandra באמצעות CSI.
- גיבויים שאינם CSI: שחזור באזור אחד.
אימות התנועה בהתקנה המשוחזרת
אופציונלי: מסירים את ההתקנה של גרסה 1.12 לפי ההוראות במאמר בנושא הסרת זמן ריצה היברידי.

ביטול שינויים ושחזור במספר אזורים

חזרה למצב הקודם כשהמצב של `apigee-datastore` תקין

לפני שמתחילים בהחזרה לגרסה קודמת, מוודאים שכל הפודים במצב פעיל:
```
kubectl get pods -n APIGEE_NAMESPACE
```
```
kubectl get pods -n apigee-system
```

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

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

מציגים את רשימת ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

לדוגמה:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h
apigee-cassandra-default-3   1/1     Running   0          16m
apigee-cassandra-default-4   1/1     Running   0          14m
apigee-cassandra-default-5   1/1     Running   0          13m
apigee-cassandra-default-6   1/1     Running   0          9m
apigee-cassandra-default-7   1/1     Running   0          9m
apigee-cassandra-default-8   1/1     Running   0          8m

בודקים את מצב הצמתים של כל פוד של Cassandra באמצעות הפקודה kubectl nodetool status:

kubectl -n APIGEE_NAMESPACE exec -it CASSANDRA_POD_NAME -- nodetool -u JMX_USER -pw JMX_PASSWORD

לדוגמה:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens   Owns (effective)   Host ID                                Rack
UN  10.16.2.6    690.17 KiB  256      48.8%              b02089d1-0521-42e1-bbed-900656a58b68   ra-1
UN  10.16.4.6    705.55 KiB  256      51.6%              dc6b7faf-6866-4044-9ac9-1269ebd85dab   ra-1
UN  10.16.11.11  674.36 KiB  256      48.3%              c7906366-6c98-4ff6-a4fd-17c596c33cf7   ra-1
UN  10.16.1.11   697.03 KiB  256      49.8%              ddf221aa-80aa-497d-b73f-67e576ff1a23   ra-1
UN  10.16.5.13   703.64 KiB  256      50.9%              2f01ac42-4b6a-4f9e-a4eb-4734c24def95   ra-1
UN  10.16.8.15   700.42 KiB  256      50.6%              a27f93af-f8a0-4c88-839f-2d653596efc2   ra-1
UN  10.16.11.3   697.03 KiB  256      49.8%              dad221ff-dad1-de33-2cd3-f1.672367e6f   ra-1
UN  10.16.14.16  704.04 KiB  256      50.9%              1feed042-a4b6-24ab-49a1-24d4cef95473   ra-1
UN  10.16.16.1   699.82 KiB  256      50.6%              beef93af-fee0-8e9d-8bbf-efc22d653596   ra-1

אם לא כל ה-pods של Cassandra נמצאים במצב UN, פועלים לפי ההוראות במאמר הסרת צמתים במצב DOWN מאשכול Cassandra.

עוברים לספרייה שבה מותקנים תרשימי ה-Helm הקודמים של Apigee Hybrid

שינוי ההקשר לאזור ששודרג

kubectl config use-context UPGRADED_REGION_CONTEXT

מוודאים שכל ה-pods במצב פעיל:

kubectl get pods -n APIGEE_NAMESPACE

kubectl get pods -n apigee-system

משתמשים בפקודת helm כדי לוודא שכל הגרסאות שודרגו ל-Hybrid v1.12:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

לדוגמה

helm -n apigee list
NAME             NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore        apigee     2         2024-03-29 17:08:07.917848253 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager  apigee     2         2024-03-29 17:21:02.917333616 +0000 UTC  deployed  apigee-ingress-manager-1.12.0  1.12.0
redis            apigee     2         2024-03-29 17:19:51.143728084 +0000 UTC  deployed  apigee-redis-1.12.0            1.12.0
telemetry        apigee     2         2024-03-29 17:16:09.883885403 +0000 UTC  deployed  apigee-telemetry-1.12.0        1.12.0
myhybridorg      apigee     2         2024-03-29 17:21:50.899855344 +0000 UTC  deployed  apigee-org-1.12.0              1.12.0

מבטלים את השינויים בכל רכיב חוץ מ-apigee-datastore באמצעות הפקודות הבאות:

יוצרים את משתנה הסביבה הבא:
- ‫PREVIOUS_HELM_CHARTS_HOME: הספרייה שבה מותקנים תרשימי ה-Helm הקודמים של Apigee Hybrid. זו הגרסה שאליה חוזרים.
מחזירים את המארחים הווירטואליים לגרסה קודמת. חוזרים על הפקודה הבאה לכל קבוצת סביבות שמוזכרת בקובץ ההגדרות.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
‫ENV_GROUP_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-virtualhost. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-virtualhost-ENV_GROUP_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל מדובר ב-ENV_GROUP_NAME.
מבטלים את השינויים בסביבות. חוזרים על הפקודה הבאה לכל סביבה שמוזכרת בקובץ הביטולים.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
‫ENV_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-env. ב-hybrid v1.10, בדרך כלל זה הנתיב apigee-env-ENV_NAME. ב-Hybrid v1.11 ובגרסאות חדשות יותר, בדרך כלל מדובר ב-ENV_NAME.

בודקים את המצב של כל סביבה כדי לוודא שהיא פועלת:
```
kubectl -n apigee get apigeeenv
```
```
NAME                  STATE     AGE   GATEWAYTYPE
apigee-org1-dev-xxx   running   2d
```

החזרה של הארגון לגרסה קודמת:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

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

kubectl -n apigee get apigeeorg

NAME                STATE     AGE
apigee-org1-xxxxx   running   2d

מחזירים את Ingress Manager למצב קודם:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

החזרה לגרסה קודמת של Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

החזרה לגרסה קודמת של Apigee Telemetry:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

כדי לוודא שהיא פועלת, בודקים את המצב שלה:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

מחזירים את Apigee Controller לגרסה קודמת:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

אימות ההתקנה של Apigee Operator:

helm ls -n apigee-system

NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee-system   3          2023-06-26 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.12.4   1.12.4

כדי לוודא שהיא פועלת, בודקים את הזמינות שלה:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

מחזירים את ה-CRD של Apigee Hybrid למצב קודם:

kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

מאמתים את ההפצה של כל הרכיבים. כל הרכיבים צריכים להיות בגרסה הקודמת חוץ מdatastore:

helm -n APIGEE_NAMESPACE list

helm -n apigee-system list

לדוגמה

helm -n apigee  list
NAME              NAMESPACE  REVISION  UPDATED                                  STATUS    CHART                          APP VERSION
datastore         apigee     2         2024-03-29 18:47:55.979671057 +0000 UTC  deployed  apigee-datastore-1.12.0        1.12.0
ingress-manager   apigee     3         2024-03-14 19:14:57.905700154 +0000 UTC  deployed  apigee-ingress-manager-1.11.0  1.11.0
redis             apigee     3         2024-03-14 19:15:49.406917944 +0000 UTC  deployed  apigee-redis-1.11.0            1.11.0
telemetry         apigee     3         2024-03-14 19:17:04.803421424 +0000 UTC  deployed  apigee-telemetry-1.11.0        1.11.0
myhybridorg       apigee     3         2024-03-14 19:13:17.807673713 +0000 UTC  deployed  apigee-org-1.11.0              1.11.0

בשלב הזה, כל הגרסאות להפצה חוץ מ-datastore הוחזרו לגרסה הקודמת.

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

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

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

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

שחזור התקנה של מספר אזורים מגיבוי עם `apigee-datastore` במצב לא תקין

אם השדרוג של רכיב apigee-datastore לא הצליח, אי אפשר לחזור מגרסה 1.12 לגרסה 1.11. במקום זאת, צריך לשחזר מגיבוי שנוצר מהתקנה של גרסה 1.11. כדי לשחזר את הגרסה הקודמת, משתמשים ברצף הבא.

אם אין לכם התקנה פעילה של Apigee Hybrid בגרסה 1.11 (לדוגמה, באזור אחר), צריך ליצור התקנה חדשה של גרסה 1.11 באמצעות התרשימים וקובצי ההחלפה שגיביתם. אפשר לעיין בהוראות ההתקנה של Apigee Hybrid בגרסה 1.11.
משחזרים את אזור v1.11 (או התקנה חדשה) מהגיבוי בהתאם להוראות שמופיעות כאן:
- גיבויים של Cloud Storage Interface ‏ (CSI): גיבוי ושחזור של Cassandra באמצעות CSI.
- גיבויים שלא מבוססים על CSI: שחזור בכמה אזורים.
אימות התנועה בהתקנה המשוחזרת
במקרים של התקנות עם מספר אזורים, צריך לבנות מחדש ולשחזר את האזור הבא. הוראות מפורטות מופיעות במאמר שחזור מגיבוי בקטע שחזור במספר אזורים.
מסירים את ההתקנה של גרסה 1.12 לפי ההוראות במאמר בנושא הסרת זמן ריצה היברידי.

נספח: שחזור אזור משדרוג שנכשל

הסרת מרכז נתונים אם השדרוג מגרסה 1.11 לגרסה 1.12 נכשל.

אימות הסטטוס של אשכול Cassandra מאזור פעיל:

מעבירים את ההקשר של kubectl לאזור שרוצים להסיר:
```
kubectl config use-context CONTEXT_OF_LIVE_REGION
```

מציגים את רשימת ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE -l app=apigee-cassandra

לדוגמה:

kubectl get pods -n apigee -l app=apigee-cassandra
NAME                 READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          2h
apigee-cassandra-default-1   1/1     Running   0          2h
apigee-cassandra-default-2   1/1     Running   0          2h

מריצים exec באחד מ-pods של Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

בודקים את הסטטוס של אשכול Cassandra:

nodetool -u JMX_USER -pw JMX_PASSWORD status

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

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens       Owns (effective)  Host ID                               Rack
UN  10.48.12.16  813.84 KiB  256          100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.14.16  859.89 KiB  256          100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1
UN  10.48.0.18   888.95 KiB  256          100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1

מתארים את האשכול כדי לוודא שרואים רק כתובות IP של תרמילי Cassandra מהאזור הפעיל, וכולן באותה גרסת סכימה:

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

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

nodetool -u JMX_USER -pw JMX_PASSWORD describecluster

Schema versions:
    4bebf2de-0582-31b4-9c5f-e36f60127e1b: [10.48.14.16, 10.48.12.16, 10.48.0.18]

הסרת השכפול של מרחב המפתחות של Cassandra:

מאחזרים את משימת user-setup ומוחקים אותה. משימה חדשה של user-setup תיווצר באופן מיידי.

kubectl get jobs -n APIGEE_NAMESPACE

לדוגמה:

kubectl get jobs -n apigee
  NAME                                                           COMPLETIONS   DURATION   AGE
  apigee-cassandra-schema-setup-myhybridorg-8b3e61d          1/1           6m35s      3h5m
  apigee-cassandra-schema-val-myhybridorg-8b3e61d-28499150   1/1           10s        9m22s
 apigee-cassandra-user-setup-myhybridorg-8b3e61d            0/1           21s        21s

kubectl delete jobs USER_SETUP_JOB_NAME -n APIGEE_NAMESPACE

הפלט צריך להראות את תחילת העבודה החדשה:

kubectl delete jobs apigee-cassandra-user-setup-myhybridorg-8b3e61d -n apigee

  apigee-cassandra-user-setup-myhybridorg-8b3e61d-wl92b         0/1     Init:0/1    0               1s

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

קבלת כל מרחבי המפתחות. מבצעים exec ל-pod של cassandra-client ואז מפעילים לקוח cqlsh:

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

מתחברים לשרת Cassandra באמצעות ddl user כי יש לו את ההרשאות שנדרשות להרצת הפקודות הבאות:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

מקבלים את מרחבי המפתחות:

select * from system_schema.keyspaces;

הפלט אמור להיראות כך, כאשר dc-1 הוא בקר הדומיין הפעיל:

select * from system_schema.keyspaces;

 keyspace_name            | durable_writes | replication
--------------------------+----------------+--------------------------------------------------------------------------------
   kvm_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
              system_auth |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_schema |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
 quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
 cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   rtc_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
       system_distributed |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
                   system |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
                   perses |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
            system_traces |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   kms_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

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

kubectl exec -it -n APIGEE_NAMESPACE cassandra-client -- /bin/bash

מתחברים לשרת Cassandra באמצעות ddl user כי יש לו את ההרשאות שנדרשות להרצת הפקודות הבאות:

cqlsh apigee-cassandra-default.apigee.svc.cluster.local -u DDL_USER -p DDL_PASSWORD --ssl

מקבלים את מרחבי המפתחות:

select * from system_schema.keyspaces;

משתמשים בשמות של מרחבי המפתחות מהפקודה שלמעלה ומחליפים אותם בדוגמאות הבאות

alter keyspace quota_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kms_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace kvm_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace cache_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace perses_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace rtc_myhybridorg_hybrid WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_auth WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_distributed WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};
alter keyspace system_traces WITH replication = {'class': 'NetworkTopologyStrategy', 'LIVE_DC_NAME':'3'};

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

select * from system_schema.keyspaces;

לדוגמה:

select * from system_schema.keyspaces;

 keyspace_name           | durable_writes | replication
-------------------------+----------------+--------------------------------------------------------------------------------
kvm_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
          system_auth    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_schema    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
quota_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
cache_myhybridorg_hybrid |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
rtc_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
   system_distributed    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
               system    |           True |                        {'class': 'org.apache.cassandra.locator.LocalStrategy'}
               perses    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
        system_traces    |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}
kms_myhybridorg_hybrid   |           True | {'class': 'org.apache.cassandra.locator.NetworkTopologyStrategy', 'dc-1': '3'}

(11 rows)

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

נספח: הסרת צמתים במצב DOWN ממקבץ Cassandra

משתמשים בהליך הזה כשמבטלים פריסה של התקנה מרובת אזורים, ולא כל ה-pods של Cassandra נמצאים במצב Up / Normal ‏ (UN).

מריצים exec באחד מ-pods של Cassandra:

kubectl exec -it -n CASSANDRA_POD_NAME -- /bin/bash

בודקים את הסטטוס של אשכול Cassandra:
```
nodetool -u JMX_USER -pw JMX_PASSWORD status
```

מוודאים שהצומת באמת במצב Down ‏ (DN). מריצים exec ל-Cassandra pod באזור שבו אי אפשר להפעיל את Cassandra pod.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.15 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.21 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.18 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
DN  10.8.4.4     432.42 KiB  256     100.0%            cd672398-5c45-4c88-a424-86d757951e53  rc-1
UN  10.8.19.6    5.8 MiB     256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.21.5    5.74 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

מסירים את ההפניה לצומת למטה (DN). בדוגמה שלמעלה, נסיר את ההפניה למארח 10.8.4.4

kubectl exec -it -n apigee apigee-cassandra-default-2 -- /bin/bash
 nodetool -u JMX_USER -pw JMX_PASSWORD removenode HOST_ID

אחרי שמסירים את קובץ העזר, צריך להפסיק את הפוד. ה-pod החדש של Cassandra אמור לפעול ולהצטרף לאשכול
```
kubectl delete pod -n POD_NAME
```

מוודאים שה-Cassandra pod החדש הצטרף לאשכול.

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.48.12.16  1.16 MiB    256     100.0%            a6340ad9-37ba-4ec8-a8c2-f7b7ac931807  ra-1
UN  10.48.0.18   1.22 MiB    256     100.0%            0d57df49-52e4-4c01-832d-d9df845ab732  ra-1
UN  10.48.14.16  1.19 MiB    256     100.0%            39f03c51-e387-4dac-8360-6d8732e690a7  ra-1

Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load        Tokens  Owns (effective)  Host ID                               Rack
UN  10.8.19.6    5.77 MiB    256     100.0%            84f771f3-3632-4155-b27f-a67125d73bc5  rc-1
UN  10.8.4.5     246.99 KiB  256     100.0%            0182e675-eec8-4d68-a465-69211b621601  rc-1
UN  10.8.21.5    5.69 MiB    256     100.0%            f6f21b70-348d-482d-89fa-14b7147a5042  rc-1

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

נספח: פתרון בעיות: `apigee-datastore` במצב תקוע אחרי החזרה למצב הקודם

משתמשים בהליך הזה אם ביצעתם חזרה לגרסה 1.11 של apigee-datastore היברידית אחרי שדרוג, והיא נתקעה.

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

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

helm -n APIGEE_NAMESPACE list

לדוגמה:

helm -n apigee list
NAME              NAMESPACE  REVISION  UPDATED                                   STATUS    CHART                              APP VERSION
datastore         apigee     3         2024-04-04 22:15:08.792539892 +0000 UTC   deployed   apigee-datastore-1.11.0           1.11.0
ingress-manager   apigee     1         2024-04-02 22:24:27.564184968 +0000 UTC   deployed   apigee-ingress-manager-1.12.0     1.12.0
redis             apigee     1         2024-04-02 22:23:59.938637491 +0000 UTC   deployed   apigee-redis-1.12.0               1.12.0
telemetry         apigee     1         2024-04-02 22:23:39.458134303 +0000 UTC   deployed   apigee-telemetry-1.12             1.12.0
myhybridorg       apigee     1         2024-04-02 23:36:32.614927914 +0000 UTC   deployed   apigee-org-1.12.0                 1.12.0

קבלת הסטטוס של ה-pods של Cassandra:

kubectl get pods -n APIGEE_NAMESPACE

לדוגמה:

kubectl get pods -n apigee
NAME                         READY   STATUS             RESTARTS      AGE
apigee-cassandra-default-0   1/1     Running            0             2h
apigee-cassandra-default-1   1/1     Running            0             2h
apigee-cassandra-default-2   0/1     CrashLoopBackOff   4 (13s ago)   2m13s

בודקים שבקר apigeeds תקוע במצב שחרור:

kubectl get apigeeds -n APIGEE_NAMESPACE

לדוגמה:

kubectl get apigeeds -n apigee
NAME      STATE       AGE
default   releasing   46h

מאמתים את הסטטוס של צמתי Cassandra (שימו לב שאחד הצמתים נמצא במצב DN, כלומר הצומת תקוע במצב CrashLoopBackOff):

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

לדוגמה:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Defaulted container "apigee-cassandra" out of: apigee-cassandra, apigee-cassandra-ulimit-init (init)
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load       Tokens   Owns (effective)   Host ID                               Rack
UN   10.68.7.28    2.12 MiB   256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3  rc-1
UN   10.68.10.29   2.14 MiB   256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452  rc-1
DN   10.68.6.26    5.77 MiB   256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1

שדרוג מאגר הנתונים באמצעות התרשימים מגרסה 1.12.
הערה: הבקר יעבור שוב למצב releasing, אבל הפעם הוא ייצור פודים עם התמונות של Hybrid 1.12, הם יופעלו ו-Cassandra יצטרף לאשכול ויהפוך ל-UN (UP/NORMAL).
```
helm upgrade datastore APIGEE_HELM_1.12.0_HOME/apigee-datastore/   --install   --namespace APIGEE_NAMESPACE   -f overrides.yaml
```

מוודאים שכל ה-pods הם Running ושקלאסטר Cassandra תקין שוב.

מאמתים שוב שכל ה-pods הם READY:

kubectl get pods -n APIGEE_NAMESPACE

לדוגמה:

kubectl get pods -n apigee
NAME                         READY   STATUS    RESTARTS   AGE
apigee-cassandra-default-0   1/1     Running   0          29h
apigee-cassandra-default-1   1/1     Running   0          29h
apigee-cassandra-default-2   1/1     Running   0          60m

מאמתים את הסטטוס של אשכול Cassandra:

kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE  -- nodetool -u JMX_USER -pw JMX_PASSWORD status

לדוגמה:

kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u jmxuser -pw JMX_PASSWORD status
Datacenter: us-west1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--   Address       Load      Tokens   Owns (effective)   Host ID                                Rack
UN   10.68.4.15    2.05 MiB  256      100.0%             0fe8c2f4-40bf-4ba8-887b-9462159cac45   rc-1
UN   10.68.7.28    3.84 MiB  256      100.0%             4de9df37-3997-43e7-8b5b-632d1feb14d3   rc-1
UN   10.68.10.29   3.91 MiB  256      100.0%             a54e673b-ec63-4c08-af32-ea6c00194452   rc-1

מאמתים את הסטטוס של בקר apigeeds:

kubectl get apigeeds -n APIGEE_NAMESPACE

לדוגמה:

kubectl get apigeeds -n apigee
NAME      STATE     AGE
default   running   2d1h

בשלב הזה, מאגר הנתונים תוקן והוא אמור להיות במצב running.

שדרוג Apigee Hybrid לגרסה 1.12 קל לארגן דפים בעזרת אוספים אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.

שינויים מגרסה Apigee Hybrid v1.11

נקודות שכדאי לשים לב אליהן לפני שמתחילים שדרוג לגרסה 1.12

שיקולים לגבי Cassandra

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

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

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

מגבלות

סקירה כללית של שדרוג לגרסה 1.12.4

הכנה לשדרוג לגרסה 1.12

גיבוי של Cassandra

גיבוי של ספריות ההתקנה ההיברידית

Linux

Mac OS

Windows

Prod

Non-prod

שדרוג גרסת Kubernetes

כאן אפשר ללחוץ כדי להרחיב את רשימת הפלטפורמות הנתמכות

רכיבים

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

התקנת זמן הריצה של hybrid 1.12.4

הכנה לשדרוג של תרשימי Helm

התקנה של תרשימי Helm של Apigee Hybrid

אימות המדיניות אחרי שדרוג לגרסה 1.12.4

חזרה לגרסה קודמת

ביטול שינויים ושחזור באזור יחיד

חזרה למצב הקודם כשהמצב של apigee-datastore תקין

שחזור כשהמצב של apigee-datastore לא תקין

ביטול שינויים ושחזור במספר אזורים

חזרה למצב הקודם כשהמצב של apigee-datastore תקין

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

שחזור התקנה של מספר אזורים מגיבוי עם apigee-datastore במצב לא תקין

נספח: שחזור אזור משדרוג שנכשל

נספח: הסרת צמתים במצב DOWN ממקבץ Cassandra

נספח: פתרון בעיות: apigee-datastore במצב תקוע אחרי החזרה למצב הקודם

שדרוג Apigee Hybrid לגרסה 1.12

חזרה למצב הקודם כשהמצב של `apigee-datastore` תקין

שחזור כשהמצב של `apigee-datastore` לא תקין

חזרה למצב הקודם כשהמצב של `apigee-datastore` תקין

שחזור התקנה של מספר אזורים מגיבוי עם `apigee-datastore` במצב לא תקין

נספח: פתרון בעיות: `apigee-datastore` במצב תקוע אחרי החזרה למצב הקודם