שדרוג של 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.
    • צריך להוסיף את ה-stanza של ההגדרה virtualhosts.routingRules. המאפיין virtualhosts.routingRules מחליף את המאפיין הקודם envs[].paths. אם יש לכם envs[].paths בקובץ ההחלפות, אתם צריכים להסיר אותו. מידע נוסף על הגדרת מארחים וירטואליים זמין במאמר הגדרת מארחים וירטואליים.

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

    הגדרות בגרסה v1.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. מוחקים את ה-pod‏ 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