Upgrade di Apigee hybrid

Upgrade 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 descritto di seguito. Segui la documentazione della tua piattaforma se hai bisogno di assistenza:
    Piattaforma Esegui l'upgrade alla versione
    GKE 1,14,x
    Anthos 1.2
    AKS 1,14,x

  2. Scarica il pacchetto di rilascio per il tuo sistema operativo:

    Mac 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 è stato installato inizialmente. La directory di base è 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 base ibrida di Apigee:

    tar xvzf filename.tar.gz -C path-to-base-directory
  3. cd alla directory di base.

  4. I contenuti tar vengono, per impostazione predefinita, espansi in una directory che contiene la versione e la piattaforma nel 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. Questa è ora la destinazione a cui rimanda l'ambiente $APIGEECTL_HOME.

Passaggio 3: aggiorna il file di override

  1. Crea una copia del file di override e presta attenzione a salvare il file precedente nel caso in cui sia necessario eseguire il rollback. Nei passaggi seguenti, apporterai le modifiche necessarie al file di 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 che devi apportare al file di override. Nella tabella che segue il riepilogo è disponibile un esempio completo. Come vedrai, la proprietà envs[] è cambiata in modo significativo rispetto alle versioni precedenti:

    • La proprietà envs[].hostAlias è stata rimossa e sostituita dalla 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 proprietà envs[].paths. Se il file di override contiene envs[].paths, devi rimuoverlo. Per saperne di più 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 un file di versione 1.2.0. L'esempio ha lo scopo di evidenziare i tipi di modifiche che è necessario apportare per la versione 1.2.0:

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

Passaggio 4: applica l'upgrade al cluster

  1. Se hai abilitato Apigee Connect nell'installazione della versione 1.1.1, devi rimuovere il deployment:
    1. Per prima cosa, 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, che include il nome dell'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 è lo spazio dei nomi specificato nel file di 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. Pulisci i 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. Pulisci i 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 il completamento dell'inizializzazione: 
    $APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml
  11. Quando check-ready risponde con "Tutti i container sono pronti", puoi provare un'installazione di prova. Esegui il comando apply con il flag --dry-run=true. Una prova ti consente di verificare la presenza di eventuali errori prima che vengano apportate modifiche al cluster: 
    $APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
  12. Se non sono presenti errori, puoi applicare i componenti di runtime specifici di Apigee 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

Per eseguire il rollback di un upgrade precedente, segui questi passaggi:

  1. Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove namespace è lo spazio dei nomi specificato nel file di 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. Pulisci i 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. Pulisci i 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 sul 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 la versione 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 esegui apigeectl apply. Assicurati di utilizzare il file di override originale per la versione a cui vuoi eseguire il rollback: 
      $APIGEECTL_HOME/apigeectl init -f overrides/original-overrides.yaml
  $APIGEECTL_HOME/apigeectl apply -f overrides/original-overrides.yaml