Upgrade di Apigee hybrid

Aggiornamento alla versione 1.2.0

Segui questi passaggi per eseguire l'upgrade di Apigee hybrid alla versione 1.2.0:

Passaggio 1: esegui l'upgrade di Kubernetes e scarica il pacchetto di release

  1. Esegui l'upgrade della tua piattaforma Kubernetes come segue. Segui la documentazione della piattaforma se hai bisogno di aiuto:
    Piattaforma Esegui l'upgrade alla versione
    GKE 1,14,x
    Anthos 1.2
    AKS 1,14,x
  2. Scarica il pacchetto di release per il tuo sistema operativo:

    Mac a 64 bit:

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

    Linux a 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 a 32 bit

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

Passaggio 2: riconfigura la directory di installazione

  1. Identifica la directory di installazione di base creata quando Apigee hybrid è stata installata in origine. La è la directory in cui si trova la directory $APIGEEGTL_HOME. Nell'esempio seguente, la directory di base è /Users/myhome/hybrid:
    echo $APIGEECTL_HOME
    /Users/myhome/hybrid/apigeectl
  2. Estrai il contenuto del file gzip scaricato nella directory di base ibrida di Apigee:

    tar xvzf filename.tar.gz -C path-to-base-directory
  3. cd alla directory di base.
  4. Per impostazione predefinita, i contenuti tar vengono espansi in una directory con le versioni Google Cloud nel suo nome. Ad esempio: ./apigeectl_1.2.0-f7b96a8_linux_64.

  5. Rinomina la directory apigeectl attuale. Ad esempio, se la versione corrente è 1.1.1, rinomina la directory apigeectl in apigeectl_1.1.1.
  6. Rinomina la directory di installazione appena estratta in apigeectl. Questo è a cui rimanda l'ambiente $APIGEECTL_HOME.

Passaggio 3: aggiorna il file degli override

  1. Crea una copia del file delle sostituzioni e fai attenzione a salvare il vecchio file nel caso in cui eseguire il rollback. Nei seguenti passaggi, apporterai le modifiche necessarie al file degli override prima di applicarlo al cluster.
  2. Aggiorna il file degli override con le modifiche descritte di seguito:

    Di seguito è riportato un riepilogo delle modifiche alla configurazione da apportare al file di override. Viene fornito un esempio completo nella tabella che segue il riepilogo. Come vedrai, envs[] è cambiato in modo significativo rispetto alle versioni precedenti:

    • La proprietà envs[].hostAlias è stata rimossa e sostituita da la nuova proprietà virtualhosts.hostAliases[].
    • Devi aggiungere la nuova proprietà di configurazione obbligatoria virtualhosts.
    • Devi spostare le proprietà envs[].sslCertPath e envs[].sslKeyPath da envs a virtualhosts.
    • Devi aggiungere la stanza di configurazione virtualhosts.routingRules. La proprietà virtualhosts.routingRules sostituisce la precedente envs[].paths proprietà. Se hai envs[].paths nel file di override, devi rimuoverlo. Per ulteriori informazioni sulla configurazione dell'host virtuale, consulta Configurare gli host virtuali.

    La tabella seguente illustra le differenze tra un file di override 1.1.1 e una versione 1.2.0. L'esempio ha lo scopo di evidenziare i tipi di modifiche da apportare Versione 1.2.0:

    Configurazione v1.1.x v1.2.0 Configurazione
    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
    

Passaggio 4: applica l'upgrade al cluster

  1. Se hai abilitato Apigee Connect nell'installazione della versione 1.1.1, devi rimuovere del deployment:
    1. Innanzitutto, elenca i deployment Apigee:
      kubectl -n namespace get ad
    2. Elimina il deployment di Apigee Connect:
      kubectl -n namespace delete ad apigee-connect-name
  2. Elenca i pod:
    kubectl get pods -n namespace
  3. Elimina il pod apigee-cps-setup dal cluster. Utilizza il nome completo del pod, include il nome della tua organizzazione, come restituito nel comando precedente. Ad esempio:
    kubectl -n namespace delete pod apigee-cps-setup-org
  4. Elimina il pod apigee-cps-create-user nello stesso spazio dei nomi:
    kubectl -n namespace delete pod apigee-cps-create-user
  5. Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove namespace è il specificato nel file degli override, se hai specificato uno spazio dei nomi. In caso contrario, lo spazio dei nomi predefinito è apigee:
    kubectl delete job -n namespace \
      $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  6. Esegui la pulizia dei job completati per lo spazio dei nomi apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  7. Esegui la pulizia dei job completati per lo spazio dei nomi istio-system:
    kubectl delete job -n istio-system \
      $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  8. cd alla directory ./hybrid-files:
  9. Inizializza apigeectl per la nuova versione:
    $APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml
  10. Controlla per determinare quando l'inizializzazione è completa:
    $APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml
  11. Quando check-ready risponde con "Tutti i contenitori sono pronti", puoi provare una prova installare l'app. Esegui il comando apply con il flag --dry-run=true. Eseguire un'asciugatura ti consente di verificare la presenza di eventuali errori prima di apportare modifiche al cluster:
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
  12. Se non ci sono errori, puoi applicare le previsioni specifiche di Apigee componenti runtime al cluster:
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml
  13. Esegui di nuovo check-ready per determinare quando l'upgrade è completo.

Rollback di un upgrade in corso...

Per eseguire il rollback di un upgrade precedente:

  1. Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove namespace è il specificato nel file degli override, se hai specificato uno spazio dei nomi. In caso contrario, lo spazio dei nomi predefinito è apigee:
    kubectl delete job -n namespace \
      $(kubectl get job -n namespace -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  2. Esegui la pulizia dei job completati per lo spazio dei nomi apigee-system:
    kubectl delete job -n apigee-system \
      $(kubectl get job -n apigee-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  3. Esegui la pulizia dei job completati per lo spazio dei nomi istio-system:
    kubectl delete job -n istio-system \
      $(kubectl get job -n istio-system -o=jsonpath='{.items[?(@.status.succeeded==1)].metadata.name}')
  4. Elimina il deployment degli operatori Apigee. Questa operazione non avrà alcun effetto il traffico di runtime:
    kubectl -n apigee-system delete deployment apigee-controller-manager
  5. Modifica la variabile $APIGEECTL_HOME in modo che punti alla directory che contiene l'originale di apigeectl. Ad esempio:
    export APIGEECTL_HOME=path-to-original-apigeectl-directory
  6. Nella directory root dell'installazione di cui vuoi eseguire il rollback, esegui apigeectl init quindi eseguirai apigeectl apply. Assicurati di utilizzare il file di override originale per la versione vuoi eseguire il rollback a:
      $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
      $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml