Questa pagina è stata tradotta dall'API Cloud Translation.

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 della release

Esegui l'upgrade della piattaforma Kubernetes come segue. Consulta la documentazione della tua piattaforma se hai bisogno di aiuto:

Piattaforma	Esegui l'upgrade alla versione
GKE	1.14.x
Anthos	1.2
AKS	1.14.x

Scarica il pacchetto di rilascio 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

Identifica la directory di installazione di base creata durante l'installazione iniziale di Apigee hybrid. 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
```
Estrai i contenuti del file gzip scaricato nella directory di base di Apigee hybrid:
```
tar xvzf filename.tar.gz -C path-to-base-directory
```
cd alla directory di base.
Per impostazione predefinita, i contenuti del file tar vengono espansi in una directory con la versione e la piattaforma nel nome. Ad esempio: ./apigeectl_1.2.0-f7b96a8_linux_64.
Rinomina la directory apigeectl corrente. Ad esempio, se la versione attuale è 1.1.1, rinomina la directory apigeectl in apigeectl_1.1.1.
Rinomina la directory di installazione appena estratta in apigeectl. Ora è qui che punta l'ambiente $APIGEECTL_HOME.

Passaggio 3: aggiorna il file di override

Crea una copia del file di override e fai attenzione a salvare il vecchio file nel caso in cui dovessi eseguire il rollback. Nei passaggi successivi, apporterai le modifiche necessarie al file di override prima di applicarlo al cluster.
NOTA: per eseguire l'upgrade alla versione 1.2.0, devi apportare modifiche al file di override che non sono compatibili con le versioni precedenti. Sono necessarie le modifiche al file di override descritte nel passaggio successivo.

Aggiorna il file di override con le modifiche descritte di seguito:

Di seguito è riportato un riepilogo delle modifiche alla configurazione che devi apportare al file di override. Un esempio completo è riportato nella tabella che segue il riepilogo. 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[].
NOTA:se hai utilizzato un singolo carattere jolly "*" per l'alias host dell'ambiente in una versione precedente, nella versione 1.2.0 DEVI utilizzare un nome DNS completo o un carattere jolly per il sottodominio nella configurazione dell'alias host virtuale. Ad esempio: *.mydomain.com. La configurazione con un singolo carattere jolly hostAliases['*'] non è più supportata.
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 sezione di configurazione virtualhosts.routingRules. La proprietà virtualhosts.routingRules sostituisce la proprietà envs[].paths precedente. Se nel file di override è presente envs[].paths, devi rimuoverlo. Per saperne di più sulla configurazione degli host virtuali, consulta Configurare gli host virtuali.

La tabella seguente illustra le differenze tra un file di override 1.1.1 e un file versione 1.2.0. L'esempio ha lo scopo di evidenziare i tipi di modifiche che devi 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

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

NOTA: se non specifichi envs[].paths (come mostrato nella tabella sopra), puoi omettere la proprietà virtualhosts[].routingRules.paths[] nell'upgrade. Per impostazione predefinita, il percorso è "/". Ad esempio, se vuoi utilizzare il percorso predefinito "/", puoi configurare virtualhosts[].routingRules in questo modo:

virtualhosts:
  - name: default
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test1
  - name: prod
    hostAliases: ["api.example.com"]
    sslCertPath: ./certs/fullchain.pem
    sslKeyPath: ./certs/privkey.pem
    routingRules:
      - env: test2

Passaggio 4: applica l'upgrade al cluster

Se hai abilitato Apigee Connect nell'installazione della versione 1.1.1, devi rimuovere il 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
```
Elenca i pod:
```
kubectl get pods -n namespace
```
Elimina il pod apigee-cps-setup dal cluster. Utilizza il nome completo del pod, che include il nome della tua organizzazione, come restituito nel comando precedente. Ad esempio:
```
kubectl -n namespace delete pod apigee-cps-setup-org
```
Elimina il pod apigee-cps-create-user nello stesso spazio dei nomi:
```
kubectl -n namespace delete pod apigee-cps-create-user
```
Pulisci i job completati per lo spazio dei nomi del runtime ibrido, dove namespace è lo spazio dei nomi specificato nel file di override, se ne hai specificato uno. 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}')
```

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}')

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}')

cd alla directory ./hybrid-files:

Inizializza apigeectl per la nuova versione:

$APIGEECTL_HOME/apigeectl init -f overrides/overrides-file.yaml

Controlla per determinare quando l'inizializzazione è completa:

$APIGEECTL_HOME/apigeectl check-ready -f overrides/overrides-file.yaml

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. L'esecuzione di una prova ti consente di verificare la presenza di errori prima che vengano apportate modifiche al cluster:
```
$APIGEECTL_HOME/apigeectl apply -f overrides/overrides-file.yaml --dry-run=true
```
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
```
Esegui di nuovo check-ready per determinare quando l'upgrade è completato.

Eseguire il rollback di un upgrade

Per eseguire il rollback di un upgrade precedente:

Pulisci i job completati per lo spazio dei nomi del runtime ibrido, dove namespace è lo spazio dei nomi specificato nel file di override, se ne hai specificato uno. 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}')
```