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

ההליך הזה מתייחס לשדרוג מגרסה 1.14.x של Apigee Hybrid לגרסה 1.15.6 של Apigee Hybrid, ומגרסאות קודמות של Hybrid 1.15.x לגרסה 1.15.6.

אפשר להשתמש באותן פרוצדורות לשדרוג גרסאות משניות (לדוגמה, מגרסה 1.14 לגרסה 1.15) ולשדרוג גרסאות של תיקוני אבטחה (לדוגמה, מגרסה 1.15.0 לגרסה 1.15.6).

אם אתם משדרגים מגרסה 1.13 או מגרסה ישנה יותר של Apigee Hybrid, אתם צריכים לשדרג קודם לגרסה 1.14 לפני שתשדרגו לגרסה 1.15.6. אפשר לעיין בהוראות בנושא שדרוג Apigee Hybrid לגרסה 1.14.

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

חשוב לשים לב לשינויים הבאים:

  • מודל מונטיזציה משולב ב-Apigee Hybrid: החל מגרסה 1.15.1,‏ Apigee Hybrid תומך עכשיו בחיובים חוזרים, בטעינת יתרה ובתשלום על הגדרה לצורך מונטיזציה. מידע נוסף זמין במאמר בנושא הפעלת מונטיזציה ב-Apigee Hybrid.
  • תווים כלליים לחיפוש (*) בנתיבי בסיס של שרתי proxy: החל מגרסה 1.15.1, אפשר להשתמש בתווים כלליים לחיפוש בנתיבי בסיס של שרתי proxy ב-Apigee. כדי לבצע את השינוי הזה, צריך לפעול לפי ההוראות שבקטע בעיה ידועה 378686709.
  • תמיכה במטען ייעודי (payload) גדול של הודעות: החל מגרסה 1.15 וגם בגרסת התיקון 1.14.2, ‏ Apigee תומך עכשיו במטען ייעודי (payload) של הודעות בגודל של עד 30MB. מידע נוסף זמין במאמרים הבאים:
  • בדיקות מחמירות יותר של יצירת מופע של מחלקה: ב-Apigee hybrid, המדיניות JavaCallout כוללת עכשיו אבטחה נוספת במהלך יצירת מופע של מחלקת Java. אמצעי האבטחה המשופר מונע פריסה של מדיניות שמנסה לבצע פעולות שדורשות הרשאות שאסורות, באופן ישיר או עקיף.

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

מידע נוסף על התכונות בגרסה 1.14 של Apigee Hybrid זמין בנתוני הגרסה של Apigee Hybrid v1.14.0.

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

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

לפני שמשדרגים לגרסה 1.15.6 – מגבלות והערות חשובות

  • ב-Apigee Hybrid 1.15.6 הוספנו מגבלת proxy חדשה ומשופרת לכל סביבה, שמאפשרת לפרוס יותר שרתי proxy ורכיבי Shared Flow בסביבה אחת. במאמר מגבלות: שרתי proxy ל-API מוסברות המגבלות על מספר השרתים וזרימות הנתונים המשותפות שאפשר לפרוס לכל סביבה. התכונה הזו זמינה רק בארגונים היברידיים חדשים, ולא ניתן להחיל אותה על ארגונים ששודרגו. כדי להשתמש בתכונה הזו, צריך לבצע התקנה חדשה של hybrid 1.15.6 וליצור ארגון חדש.

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

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

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

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

  • אין צורך להשעות באופן מלא את שינויי מישור הניהול במהלך שדרוג. ההשעיות הזמניות הנדרשות לשינויים במישור הניהול מצוינות בהוראות השדרוג שבהמשך.

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

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

  1. הכנות לשדרוג
  2. איך מתקינים את גרסה 1.15.6 של זמן הריצה ההיברידי

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

גיבוי ההתקנה ההיברידית

  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%
  2. יוצרים עותק גיבוי של ספריית $APIGEE_HELM_CHARTS_HOME/ בגרסה 1.14. אפשר להשתמש בכל תהליך גיבוי. לדוגמה, אפשר ליצור קובץ tar של כל הספרייה באמצעות: 
    tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.14-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
  3. מגבים את מסד הנתונים של Cassandra לפי ההוראות במאמר בנושא גיבוי ושחזור של Cassandra.
  4. אם אתם משתמשים בקובצי אישורים של שירות (.json) בשינויים שביצעתם כדי לאמת חשבונות שירות, ודאו שקובצי האישורים של חשבונות השירות נמצאים בספרייה הנכונה של תרשים Helm. תרשימי Helm לא יכולים לקרוא קבצים מחוץ לכל ספריית תרשים.

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

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

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

שדרוג גרסת Kubernetes

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

הסרה או שדרוג של Istio CRD

במהלך שדרוג מ-Apigee hybrid בגרסה 1.14.1 או בגרסאות ישנות יותר, נוכחות של istio.io הגדרות של משאבים מותאמים אישית (CRD) באשכול Apigee hybrid עלולה לגרום לכך ש בדיקות המוכנות בdiscovery מאגרי ה- של ה-pods apigee-ingressgateway-manager ייכשלו.

אם gateway.networking.k8s.io/v1 מותקן באשכול,יכול להיות שהשדרוג של apigee-ingressgateway-manager ייכשל. לדוגמה, gateway.networking.k8s.io/v1 מותקן בדרך כלל באשכולות שפועלים ב-Google Distributed Cloud (תוכנה בלבד) בגרסה 1.32 ואילך של שרת פיזי.

יש שתי אפשרויות לפתרון הבעיות האלה:

  • מוחקים את istio.io CRD אם לא משתמשים ב-Istio לשום מטרה אחרת מלבד Apigee באשכול.
  • מעדכנים את apigee-ingressgateway-manager clusterrole כדי להוסיף הרשאות ל-istio.io.

אחרי כל אחת מהאפשרויות שלמעלה, תצטרכו להפעיל מחדש את ה-apigee-ingressgateway-manager pods.

מידע נוסף על istio.io CRD ועל gateway.networking.k8s.io/v1 ב-Apigee hybrid זמין במאמרים בעיה מוכרת 416634326 ובעיה מוכרת 419856132.

  1. כדי לבדוק אם יש לכם CRD‏ istio.io באשכול, מריצים את הפקודה הבאה: 
    kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io

    אם באשכול שלכם יש istio.io CRD, הפלט ייראה בערך כך: 

    kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io
  authorizationpolicies.security.istio.io
  destinationrules.networking.istio.io
  envoyfilters.networking.istio.io
  gateways.networking.istio.io
  peerauthentications.security.istio.io
  proxyconfigs.networking.istio.io
  requestauthentications.security.istio.io
  serviceentries.networking.istio.io
  sidecars.networking.istio.io
  telemetries.telemetry.istio.io
  virtualservices.networking.istio.io
  wasmplugins.extensions.istio.io
  workloadentries.networking.istio.io
  workloadgroups.networking.istio.io
  2. אופציונלי: שומרים את קובצי ה-CRD באופן מקומי למקרה שיהיה צורך ליצור אותם מחדש: 
    kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml

מחיקת CRD

  1. מריצים את הפקודה הבאה כדי ליצור קובץ CSV עם רשימת ה-istio.ioCRD באשכול: 
    kubectl get crd -o custom-columns=NAME:metadata.name | grep istio.io > istio-crd.csv
  2. אופציונלי: שומרים את קובצי ה-CRD באופן מקומי למקרה שיהיה צורך ליצור אותם מחדש: 
    kubectl get crd $(cat istio-crd.csv) -o yaml > istio-crd.yaml
  3. מוחקים את ה-CRD‏ istio.io:

    הרצת בדיקה:

    kubectl delete crd $(cat istio-crd.csv) --dry-run=client

    ביצוע:

    kubectl delete crd $(cat istio-crd.csv)

עדכון של ClusterRole

  1. מקבלים את ה-clusterrole הנוכחי של apigee-ingressgateway-manager: 
    kubectl get clusterrole apigee-ingressgateway-manager-apigee -o yaml > apigee-ingressgateway-manager-apigee-clusterrole.yaml
  2. מעתיקים את ה-ClusterRole למיקום חדש: 
    cp apigee-ingressgateway-manager-apigee-clusterrole.yaml apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml
  3. מוסיפים את ההרשאות הנוספות הבאות לסוף הקובץ: 
    - apiGroups:
  - gateway.networking.k8s.io
  resources:
  - gatewayclasses
  - gateways
  - grpcroutes
  - httproutes
  - referencegrants
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - networking.istio.io
  resources:
  - sidecars
  - destinationrules
  - gateways
  - virtualservices
  - envoyfilters
  - workloadentries
  - serviceentries
  - workloadgroups
  - proxyconfigs
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - security.istio.io
  resources:
  - peerauthentications
  - authorizationpolicies
  - requestauthentications
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - telemetry.istio.io
  resources:
  - telemetries
  verbs:
  - get
  - list
  - watch
- apiGroups:
  - extensions.istio.io
  resources:
  - wasmplugins
  verbs:
  - get
  - list
  - watch
  4. החלת התפקיד: 
    kubectl -n APIGEE_NAMESPACE apply -f apigee-ingressgateway-manager-apigee-clusterrole-added-istio-permissions.yaml

אחרי שמבצעים את הפעולות שצוינו למעלה, צריך להפעיל מחדש את תרמילי ה-apigee-ingressgateway-manager.

  1. מפרטים את ה-ingress-manager pods להתקנה מחדש או ליצירה מחדש: 
    kubectl get deployments -n APIGEE_NAMESPACE

    פלט לדוגמה:

    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager       1/1     1            1           32d
apigee-ingressgateway-manager   2/2     2            2           32d
  2. מפעילים מחדש את הפודים של ingress-manager: 
    kubectl rollout restart deployment -n APIGEE_NAMESPACE apigee-ingressgateway-manager
  3. אחרי כמה דקות, עוקבים אחרי ה-apigee-ingressgateway-manager pods: 
    watch -n 10 kubectl -n APIGEE_NAMESPACE get pods -l app=apigee-ingressgateway-manager

    פלט לדוגמה:

    NAME                                             READY   STATUS    RESTARTS   AGE
apigee-ingressgateway-manager-12345abcde-678wx   3/3     Running   0          10m
apigee-ingressgateway-manager-12345abcde-901yz   3/3     Running   0          10m

התקנה של זמן הריצה של גרסה 1.15.6 של Hybrid

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

החל מ-hybrid v1.14, צינור נתונים חדש של ניתוח נתונים וניפוי באגים מופעל כברירת מחדל בכל הארגונים של Apigee hybrid. כדי להגדיר את תהליך ההרשאה, צריך לפעול לפי השלבים שמפורטים במאמר בנושא הפעלת גישה של בעלי אתרים ל-Analytics.

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

  1. שולפים את תרשימי 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.15.6
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
  2. משדרגים את cert-manager אם צריך.

    אם אתם צריכים לשדרג את הגרסה של cert-manager, אתם יכולים להתקין את הגרסה החדשה באמצעות הפקודה הבאה:

    kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.17.4/cert-manager.yaml

    רשימת הגרסאות הנתמכות מופיעה במאמר פלטפורמות וגרסאות נתמכות: cert-manager.

  3. אם מרחב השמות של Apigee הוא לא apigee, צריך לערוך את הקובץ apigee-operator/etc/crds/default/kustomization.yaml ולהחליף את הערך namespace במרחב השמות של Apigee. 
    apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

namespace: APIGEE_NAMESPACE

    אם אתם משתמשים ב-apigee כמרחב השמות, אתם לא צריכים לערוך את הקובץ.

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

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

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

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

      kubectl apply -k  apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false
    3. מאמתים את ההתקנה באמצעות הפקודה kubectl get crds: 
      kubectl get crds | grep apigee

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

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

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

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

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

  1. אם לא, עוברים אל ספריית APIGEE_HELM_CHARTS_HOME. מריצים את הפקודות הבאות מהספרייה הזו.
  2. משדרגים את Apigee Operator/Controller:

    הרצת בדיקה:

    helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  -f OVERRIDES_FILE \
  --dry-run=server

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

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

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

    helm ls -n APIGEE_NAMESPACE

    NAME       NAMESPACE       REVISION   UPDATED                                STATUS     CHART                   APP VERSION
operator   apigee   3          2024-08-21 00:42:44.492009 -0800 PST   deployed   apigee-operator-1.15.6   1.15.6

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

    kubectl -n APIGEE_NAMESPACE get deploy apigee-controller-manager

    NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h
  3. שדרוג מאגר הנתונים של Apigee:

    הרצת בדיקה:

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

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

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

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

    kubectl -n APIGEE_NAMESPACE get apigeedatastore default

    NAME      STATE       AGE
default   running    2d
  4. שדרוג הטלמטרייה של Apigee:

    הרצת בדיקה:

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

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

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

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

    kubectl -n APIGEE_NAMESPACE get apigeetelemetry apigee-telemetry

    NAME               STATE     AGE
apigee-telemetry   running   2d
  5. שדרוג של Apigee Redis:

    הרצת בדיקה:

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

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

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

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

    kubectl -n APIGEE_NAMESPACE get apigeeredis default

    NAME      STATE     AGE
default   running   2d
  6. משדרגים את Apigee ingress manager:

    הרצת בדיקה:

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

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

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

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

    kubectl -n APIGEE_NAMESPACE get deployment apigee-ingressgateway-manager

    NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d
  7. משדרגים את הארגון ב-Apigee:

    הרצת בדיקה:

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

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

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

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

    kubectl -n APIGEE_NAMESPACE get apigeeorg

    NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d
  8. משדרגים את הסביבה.

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

    הרצת בדיקה:

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run=server
    • ‫ENV_RELEASE_NAME הוא שם שמשמש למעקב אחרי התקנות ושדרוגים של תרשים apigee-env. השם הזה צריך להיות ייחודי ולא יכול להיות זהה לשמות אחרים של Helm release בהתקנה. בדרך כלל זהה ל-ENV_NAME. עם זאת, אם לסביבה יש את אותו שם כמו לקבוצת הסביבות, צריך להשתמש בשמות שחרור שונים לסביבה ולקבוצת הסביבות, למשל dev-env-release ו-dev-envgroup-release. מידע נוסף על גרסאות ב-Helm זמין במאמר Three big concepts (שלושה מושגים חשובים) במאמרי העזרה של Helm.
    • ‫ENV_NAME הוא שם הסביבה שמשדרגים.
    • ‫OVERRIDES_FILE הוא קובץ ההחלפות החדש שלכם לגרסה 1.15.6

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

    helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE

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

    kubectl -n APIGEE_NAMESPACE get apigeeenv

    NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
  9. משדרגים את קבוצות הסביבות (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=server

      ‫ENV_GROUP_RELEASE_NAME הוא השם שבו התקנתם בעבר את תרשים apigee-virtualhost. בדרך כלל זה הנתיב ENV_GROUP_NAME.

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

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
    2. בודקים את המצב של ApigeeRoute ‏ (AR).

      התקנת virtualhosts יוצרת ApigeeRouteConfig ‏ (ARC), שיוצר באופן פנימי ApigeeRoute ‏ (AR) אחרי שה-watcher של Apigee מאחזר פרטים שקשורים לקבוצת סביבות ממישור הבקרה. לכן, צריך לבדוק שהסטטוס של ה-AR המתאים הוא running: 

      kubectl -n APIGEE_NAMESPACE get arc

      NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
       
      kubectl -n APIGEE_NAMESPACE get ar

      NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
  10. אחרי שמוודאים שכל ההתקנות שודרגו בהצלחה, מוחקים את הגרסה הישנה יותר של apigee-operator ממרחב השמות apigee-system.
    1. מסירים את הגרסה הישנה של operator: 
      helm delete operator -n apigee-system
    2. מוחקים את מרחב השמות apigee-system: 
      kubectl delete namespace apigee-system
  11. משדרגים את operator שוב במרחב השמות של Apigee כדי להתקין מחדש את המשאבים שנמחקו בהיקף האשכול: 
    helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f overrides.yaml

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

  1. בודקים אם קובצי ה-JAR של Java מבקשים הרשאות מיותרות.

    אחרי פריסת המדיניות, בודקים ביומני זמן הריצה אם מופיעה הודעת היומן הבאה: "Failed to load and initialize class ...". אם ההודעה הזו מופיעה, סימן שקובץ ה-JAR שנפרס ביקש הרשאות מיותרות. כדי לפתור את הבעיה, צריך לבדוק את קוד ה-Java ולעדכן את קובץ ה-JAR.

  2. בודקים ומעדכנים את קוד Java.

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

  3. בדיקת מדיניות עם הפעלת בדיקת האבטחה.

    בסביבה שאינה סביבת ייצור, מפעילים את דגל בדיקת האבטחה ומפרסים מחדש את המדיניות עם קובץ 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

        ‫ENV_RELEASE_NAME הוא שם שמשמש למעקב אחרי התקנות ושדרוגים של תרשים apigee-env. השם הזה צריך להיות ייחודי ולא יכול להיות זהה לשמות אחרים של Helm release בהתקנה. בדרך כלל זהה ל-ENV_NAME. עם זאת, אם לסביבה יש את אותו שם כמו לקבוצת הסביבות, צריך להשתמש בשמות שחרור שונים לסביבה ולקבוצת הסביבות, למשל dev-env-release ו-dev-envgroup-release. מידע נוסף על מהדורות ב-Helm זמין במאמר Three big concepts (שלושה מושגים חשובים) במאמרי העזרה של Helm.

    אם הודעת היומן "Failed to load and initialize class ..." עדיין מופיעה, ממשיכים לשנות ולבדוק את קובץ ה-JAR עד שהודעת היומן לא מופיעה יותר.

  4. הפעלת בדיקת האבטחה בסביבת הייצור.

    אחרי שבודקים ומאמתים את קובץ ה-JAR בסביבה שאינה סביבת ייצור, מפעילים את בדיקת האבטחה בסביבת הייצור על ידי הגדרת הדגל conf_security-secure.constructor.only לערך true ועדכון התרשים apigee-env בסביבת הייצור כדי להחיל את השינוי.

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

כדי לחזור לגרסה הקודמת, משתמשים בגרסה הקודמת של התרשים כדי לבטל את תהליך השדרוג בסדר הפוך. מתחילים עם apigee-virtualhost, עוברים אחורה עד apigee-operator, ואז משחזרים את ה-CRD.

  1. מחזירים את התרשימים למצב הקודם. הפקודות הבאות מבוססות על ההנחה שאתם משתמשים בתרשימים מהגרסה הקודמת (v1.14.x).

      מריצים את הפקודה הבאה לכל קבוצת סביבות:

      helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f 1.14_OVERRIDES_FILE

    1. מריצים את הפקודה הבאה לכל סביבה:

      helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  --set env=ENV_NAME \
  -f 1.14_OVERRIDES_FILE
      2. apigee-org: 
      helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    2. apigee-ingress-manager: 
      helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    3. apigee-redis: 
      helm upgrade redis apigee-redis/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    4. apigee-telemetry: 
      helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    5. apigee-datastore: 
      helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
    6. apigee-operator: 
      helm upgrade operator apigee-operator/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f 1.14_OVERRIDES_FILE
  2. כדי לבטל את השינויים ב-CRD, מתקינים מחדש את ה-CRD הישנים. 
    kubectl apply -k apigee-operator/etc/crds/default/ \
  --server-side \
  --force-conflicts \
  --validate=false