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
- Esegui l'upgrade della tua piattaforma Kubernetes come segue. Se hai bisogno di aiuto, segui la documentazione della piattaforma:
Piattaforma Esegui l'upgrade alla versione GKE 1,14,x Anthos 1.2 AKS 1,14,x 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
- Identifica la directory di installazione di base creata quando Apigee hybrid
è stato installato in origine. 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 il contenuto del file gzip scaricato nella directory di base ibrida di Apigee:
tar xvzf filename.tar.gz -C path-to-base-directory
cd
alla directory di base.-
Per impostazione predefinita, i contenuti tar vengono espansi in una directory il cui nome contiene la versione e la piattaforma. Ad esempio:
./apigeectl_1.2.0-f7b96a8_linux_64
. - Rinomina la directory
apigeectl
attuale. Ad esempio, se la versione corrente è 1.1.1, rinomina la directoryapigeectl
inapigeectl_1.1.1
. -
Rinomina la directory di installazione appena estratta in
apigeectl
. Questo è ora il punto a cui rimanda l'ambiente$APIGEECTL_HOME
.
Passaggio 3: aggiorna il file degli override
- 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 degli override prima di applicarlo al cluster.
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 degli 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[]
. - Devi aggiungere la nuova proprietà di configurazione obbligatoria
virtualhosts
. - Devi spostare le proprietà
envs[].sslCertPath
eenvs[].sslKeyPath
daenvs
avirtualhosts
. - Devi aggiungere la stanza di configurazione
virtualhosts.routingRules
. La proprietàvirtualhosts.routingRules
sostituisce la precedente proprietàenvs[].paths
. Se il file degli override contieneenvs[].paths
, devi rimuoverlo. Per maggiori 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 un file di versione 1.2.0. L'esempio ha lo scopo di evidenziare i tipi di modifiche da apportare per la 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
- La proprietà
Passaggio 4: applica l'upgrade al cluster
- Se hai abilitato Apigee Connect nell'installazione della versione 1.1.1, devi rimuovere
il deployment:
- Innanzitutto, elenca i deployment Apigee:
kubectl -n namespace get ad
- Elimina il deployment di Apigee Connect:
kubectl -n namespace delete ad apigee-connect-name
- Innanzitutto, elenca i deployment Apigee:
- 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
- Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove namespace è lo spazio dei nomi 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}')
- 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}')
- 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}')
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 in modalità di prova. Esegui il comandoapply
con il flag--dry-run=true
. Questa operazione 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
-
Se non ci sono 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 è completo.
Rollback di un upgrade in corso...
Per eseguire il rollback di un upgrade precedente:
- Esegui la pulizia dei job completati per lo spazio dei nomi del runtime ibrido, dove namespace è lo spazio dei nomi 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}')
- 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}')
- 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}')
- 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
- Modifica la variabile
$APIGEECTL_HOME
in modo che punti alla directory che contiene la versione originale diapigeectl
. Ad esempio:export APIGEECTL_HOME=path-to-original-apigeectl-directory
- Nella directory root dell'installazione di cui vuoi eseguire il rollback, esegui
apigeectl init
, quindi eseguiapigeectl 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