שדרוג של Apigee Hybrid

אתם צריכים לבצע התקנה חדשה.

שדרוג לגרסה 1.2.0

כדי לשדרג את Apigee Hybrid לגרסה 1.2.0:

שלב 1: שדרוג Kubernetes והורדה של חבילת הגרסה

  1. כדי לשדרג את פלטפורמת Kubernetes, פועלים לפי השלבים הבאים. אם אתם צריכים עזרה, תוכלו להיעזר במאמרי העזרה של הפלטפורמה:
    פלטפורמה שדרוג לגרסה
    GKE ‫1.14.x
    Anthos 1.2
    AKS ‫1.14.x
  2. מורידים את חבילת ההפצה של מערכת ההפעלה:

    Mac 64 bit:

    curl -LO \
        https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_64.tar.gz

    Linux 64 bit

    curl -LO \
        https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_64.tar.gz

    Mac 32 bit:

    curl -LO \
        https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_mac_32.tar.gz

    Linux 32 bit

    curl -LO \
        https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/1.2.0/apigeectl_linux_32.tar.gz

שלב 2: הגדרה מחדש של ספריית ההתקנה

  1. מזהים את ספריית ההתקנה הבסיסית שנוצרה כשהתקנתם את Apigee Hybrid. הספרייה הבסיסית היא הספרייה שבה נמצאת הספרייה $APIGEEGTL_HOME. בדוגמה הבאה, ספריית הבסיס היא /Users/myhome/hybrid:
    echo $APIGEECTL_HOME
    /Users/myhome/hybrid/apigeectl
  2. מחלצים את התוכן של קובץ ה-gzip שהורד אל ספריית הבסיס של Apigee Hybrid:

    tar xvzf filename.tar.gz -C path-to-base-directory
  3. cd לספריית הבסיס.
  4. כברירת מחדל, התוכן של קובץ ה-tar מורחב לתוך ספרייה עם הגרסה והפלטפורמה בשם שלה. לדוגמה: ./apigeectl_1.2.0-f7b96a8_linux_64.

  5. משנים את השם של ספריית apigeectl הנוכחית. לדוגמה, אם הגרסה הנוכחית היא 1.1.1, משנים את השם של הספרייה apigeectl ל-apigeectl_1.1.1.
  6. משנים את השם של ספריית ההתקנה שחולצה ל-apigeectl. זה המקום שאליו מצביעה הסביבה $APIGEECTL_HOME.

שלב 3: מעדכנים את קובץ ההחרגות

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

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

    • המאפיין envs[].hostAlias הוסר והוחלף במאפיין virtualhosts.hostAliases[] החדש.
    • צריך להוסיף את מאפיין ההגדרה החדש הנדרש virtualhosts.
    • צריך להעביר את הנכסים envs[].sslCertPath ו-envs[].sslKeyPath מהדומיין envs אל הדומיין virtualhosts.
    • צריך להוסיף את קטע ההגדרה virtualhosts.routingRules. המאפיין virtualhosts.routingRules מחליף את המאפיין הקודם envs[].paths. אם יש לכם envs[].paths בקובץ ההגדרות, אתם צריכים להסיר אותו. מידע נוסף על הגדרת מארחים וירטואליים זמין במאמר הגדרת מארחים וירטואליים.

    בטבלה הבאה מוצגים ההבדלים בין קובץ של גרסה 1.1.1 לבין קובץ של גרסה 1.2.0. הדוגמה נועדה להדגיש את סוגי השינויים שצריך לבצע בגרסה 1.2.0:

    הגדרה של גרסה 1.1.x הגדרות אישיות בגרסה 1.2.0
    envs:
      - name: test1
        hostAlias: "api.example.com"
        sslCertPath: ./certs/fullchain.pem
        sslKeyPath: ./certs/privkey.pem
        serviceAccountPaths:
          synchronizer: ./sa/sync.json
          udca: ./sa/udca.json
        paths:
          uri:
            prefixes:
              - /orders
              - /items
      - name: test2
        hostAlias: "api.example.com"
        sslCertPath: ./certs/fullchain.pem
        sslKeyPath: ./certs/privkey.pem
        serviceAccountPaths:
          synchronizer: ./sa/sync.json
          udca: ./sa/udca.json
        paths:
          uri:
            prefixes:
              - /v0/hello
              - /httpbin
    virtualhosts:
      - name: default
        hostAliases: ["api.example.com"]
        sslCertPath: ./certs/fullchain.pem
        sslKeyPath: ./certs/privkey.pem
        routingRules:
          - paths:
            - /orders
            - /items
            env: test1
          - paths:
            - /v0/hello
            - /httpbin
            env: test2
    
    envs:
      - name: test1
        serviceAccountPaths:
          synchronizer: ./sa/synchronizer.json
          udca: ./sa/udca.json
      - name: test2
        serviceAccountPaths:
          synchronizer: ./sa/synchronizer.json
          udca: ./sa/udca.json

שלב 4: החלת השדרוג על האשכול

  1. אם הפעלתם את Apigee Connect בהתקנה של גרסה 1.1.1, אתם צריכים להסיר את הפריסה:
    1. קודם כול, מציגים את רשימת הפריסות של Apigee:
      kubectl -n namespace get ad
    2. מוחקים את הפריסה של Apigee Connect:
      kubectl -n namespace delete ad apigee-connect-name
  2. מציינים את רצפי המודעות:
    kubectl get pods -n namespace
  3. מוחקים את ה-Pod‏ apigee-cps-setup מהאשכול. משתמשים בשם המלא של ה-Pod, שכולל את שם הארגון, כפי שמוחזר בפקודה הקודמת. לדוגמה:
    kubectl -n namespace delete pod apigee-cps-setup-org
  4. מוחקים את פוד apigee-cps-create-user באותו מרחב שמות:
    kubectl -n namespace delete pod apigee-cps-create-user
  5. מנקים את המשימות שהושלמו במרחב השמות של זמן הריצה ההיברידי, כאשר namespace הוא מרחב השמות שצוין בקובץ ההחלפות, אם ציינתם מרחב שמות. אם לא, מרחב השמות שמוגדר כברירת מחדל הוא apigee:
    kubectl delete job -n namespace \
      $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  6. ניקוי משימות שהושלמו במרחב השמות apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  7. ניקוי משימות שהושלמו במרחב השמות istio-system:
    kubectl delete job -n istio-system \
      $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  8. cd לספרייה ./hybrid-files:
  9. מפעילים את apigeectl לגרסה החדשה:
    $APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml
  10. כדי לדעת מתי האתחול מסתיים:
    $APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml
  11. כש-check-ready משיב "All containers are ready" (כל מאגרי התגים מוכנים), אפשר לנסות התקנה של dry run. מפעילים את הפקודה apply עם הדגל --dry-run=true. הרצה יבשה מאפשרת לבדוק אם יש שגיאות לפני שמבצעים שינויים באשכול:
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
  12. אם לא מופיעות שגיאות, אפשר להחיל את רכיבי זמן הריצה הספציפיים ל-Apigee על האשכול:
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
  13. מריצים מחדש את check-ready כדי לדעת מתי השדרוג מסתיים.

החזרה למצב הקודם של שדרוג

כדי לחזור לשדרוג קודם:

  1. מנקים את המשימות שהושלמו במרחב השמות של זמן הריצה ההיברידי, כאשר namespace הוא מרחב השמות שצוין בקובץ ההחלפות, אם ציינתם מרחב שמות. אם לא, מרחב השמות שמוגדר כברירת מחדל הוא apigee:
    kubectl delete job -n namespace \
      $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. ניקוי משימות שהושלמו במרחב השמות apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  3. ניקוי משימות שהושלמו במרחב השמות istio-system:
    kubectl delete job -n istio-system \
      $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  4. מוחקים את הפריסה של Apigee Operators. לפעולה הזו לא תהיה השפעה על תנועת הגולשים בזמן הריצה:
    kubectl -n apigee-system delete deployment apigee-controller-manager
  5. משנים את המשתנה $APIGEECTL_HOME כך שיצביע על הספרייה שמכילה את הגרסה המקורית של apigeectl. לדוגמה:
    export APIGEECTL_HOME=path-to-original-apigeectl-directory
  6. בתיקיית הבסיס של ההתקנה שרוצים לחזור אליה, מריצים את הפקודה apigeectl init ואז את הפקודה apigeectl apply. חשוב להשתמש בקובץ הביטולים המקורי של הגרסה שאליה רוצים לחזור:
      $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
      $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml