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

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

השתמשו באותם תהליכים לשדרוגים של גרסאות משניות (לדוגמה, מגרסה 1.14 לגרסה 1.15) ולשדרוגים של גרסאות תיקון (לדוגמה, מגרסה 1.15.0 לגרסה 1.15.9).

אם אתם משדרגים מגרסה 1.13 או גרסה ישנה יותר של Apigee Hybrid, קודם אתם צריכים לשדרג לגרסה 1.14 של Apigee Hybrid ורק אחר כך לגרסה 1.15.9. איך משדרגים את Apigee Hybrid לגרסה 1.14

שינויים מגרסה 1.14 של Apigee Hybrid

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

הכנה לשדרוג לגרסה 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/

    לא בסביבת ייצור

    יוצרים עותק של קובץ חשבון השירות 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, ואם צריך, משדרגים אותה לגרסה שנתמכת גם ב-Apigee Hybrid בגרסה 1.14 וגם בגרסה 1.15. אם אתם צריכים עזרה, כדאי לעיין במאמרי העזרה של הפלטפורמה.

הסרה או שדרוג של הגדרות המשאבים המותאמות אישית (CRD) של Istio

במהלך השדרוג מגרסאות Apigee Hybrid‏ 1.14.1 או גרסאות ישנות יותר, הנוכחות של הגדרות משאבים בהתאמה אישית (CRD) של istio.io באשכול 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 למטרה אחרת מלבד Apigee באשכול, מחקו את istio.io ה-CRD.
  • צריך לעדכן את apigee-ingressgateway-manager clusterrole כדי להוסיף הרשאות ל-istio.io.

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

בבעיה מוכרת 416634326 ובבעיה מוכרת 419856132 אפשר לקרוא מידע נוסף על istio.io CRDs ו-gateway.networking.k8s.io/v1 ב-Apigee hybrid.

  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. מציגים את הגדרות ה-CRD של istio.io באשכול בקובץ CSV: 
    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 שצריך להתקין מחדש או ליצור מחדש: 
    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: 
    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

התקנת סביבת זמן הריצה של Apigee Hybrid בגרסה 1.15.9

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

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

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

  1. מורידים את תרשימי Apigee Helm.

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

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

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

    export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.15.9
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. אחרי האימות באמצעות הפקודה dry-run, מריצים את הפקודה הבאה:

      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 מתזמן פודים של נתונים בצמתים עם התווית cloud.google.com/gke-nodepool=apigee-data, ופודים של זמן ריצה מתזמנים בצמתים עם התווית 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.9   1.15.9

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

    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:

    הרצת בדיקה:

    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 בהתקנה. בדרך כלל זהה ל-ENV_NAME. עם זאת, אם לסביבה יש שם זהה לשם של קבוצת הסביבות, צריך להשתמש בשמות שונים לגרסאות של הסביבה ושל קבוצת הסביבות, למשל dev-env-release ו-dev-envgroup-release. מידע נוסף על גרסאות ב-Helm זמין במאמר Three big concepts במסמכי התיעוד של Helm.
    • ‫ENV_NAME הוא שם הסביבה שמשדרגים.
    • ‫OVERRIDES_FILE הוא קובץ ההחרגות החדש שלך לגרסה 1.15.9

    כדי לשדרג את התרשים:

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

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

    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 התואם הוא "פועל": 

      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 בהתקנה. בדרך כלל זהה ל-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