Questa pagina è stata tradotta dall'API Cloud Translation.

Eseguire l'upgrade di Apigee hybrid alla versione 1.11

Questa procedura riguarda l'upgrade da Apigee hybrid versione 1.10.x ad Apigee hybrid versione 1.11.2 e dalle versioni precedenti di hybrid 1.11.x alla versione 1.11.2.

Utilizza le stesse procedure per gli upgrade delle versioni secondarie (ad esempio dalla versione 1.10 alla 1.11) e per gli upgrade delle release di patch (ad esempio dalla versione 1.11.0 alla 1.11.2).

Se esegui l'upgrade da Apigee hybrid versione 1.9 o precedente, devi prima eseguire l'upgrade alla versione ibrida 1.10 prima di eseguire l'upgrade alla versione 1.11.2. Consulta le istruzioni per eseguire l'upgrade di Apigee Hybrid alla versione 1.10.

Panoramica dell'upgrade alla versione 1.11.2

L'upgrade ad Apigee hybrid versione 1.11 potrebbe richiedere tempi di inattività.

Quando esegui l'upgrade del controller Apigee alla versione 1.11.2, tutti i deployment Apigee vengono riavviati in sequenza. Per ridurre al minimo i tempi di inattività negli ambienti ibridi di produzione durante un riavvio graduale, assicurati di eseguire almeno due cluster (nello stesso o in un data center/regione diverso). Devia tutto il traffico di produzione a un singolo cluster, metti offline il cluster di cui stai per eseguire l'upgrade e procedi con la procedura di upgrade. Ripeti la procedura per ogni cluster.

Apigee consiglia di eseguire l'upgrade di tutti i cluster il prima possibile per ridurre le possibilità di impatto sulla produzione. Non è previsto un limite di tempo per l'upgrade di tutti i cluster rimanenti dopo l'upgrade del primo. Tuttavia, fino a quando non verrà eseguito l'upgrade di tutti i cluster rimanenti, le seguenti operazioni saranno interessate:

Il backup e il ripristino di Cassandra non possono funzionare con versioni miste. Ad esempio, un backup di Hybrid 1.10 non può essere utilizzato per ripristinare un'istanza Hybrid 1.11.
Lo streaming dei dati di Cassandra non funzionerà tra versioni ibride miste. Pertanto, i tuoi cluster Cassandra non possono essere scalati orizzontalmente.
L'espansione e il ritiro delle regioni saranno interessati, perché queste operazioni dipendono dallo streaming dei dati di Cassandra.

Controlli più rigorosi dell'istanza della classe in Hybrid 1.11.2-Hotfix.3

A partire da Apigee hybrid 1.11.2-Hotfix.3, la norma JavaCallout ora include una sicurezza aggiuntiva durante l'istanza della classe Java. La misura di sicurezza avanzata impedisce l'implementazione di criteri che tentano direttamente o indirettamente azioni che richiedono autorizzazioni non consentite.

Nella maggior parte dei casi, le norme esistenti continueranno a funzionare come previsto senza problemi. Tuttavia, è possibile che le norme che si basano su librerie di terze parti o quelle con codice personalizzato che attiva indirettamente operazioni che richiedono autorizzazioni elevate possano essere interessate.

Le procedure per l'upgrade di Apigee hybrid sono organizzate nelle seguenti sezioni:

Preparati all'upgrade.
Installa la versione 1.11.2 del runtime di hybrid.

Prerequisiti

Queste istruzioni per l'upgrade presuppongono che tu abbia installato Apigee hybrid versione 1.10.x e che tu voglia eseguire l'upgrade alla versione 1.11.2. Se esegui l'aggiornamento da una versione precedente, consulta le istruzioni per l'upgrade di Apigee hybrid alla versione 1.10.

Grafici Helm e `apigeectl`

Nella versione 1.11 puoi scegliere di installare e gestire Apigee hybrid con i grafici Helm o apigeectl. Apigee consiglia di utilizzare Helm per gestire l'installazione.

Migrazione alla versione 1.11 con Helm dalla versione 1.10 con `apigeectl`

Per eseguire l'upgrade ad Apigee hybrid v1.11 gestito da Helm da un'installazione di hybrid v1.10 gestita con apigeectl:

Innanzitutto, esegui la migrazione dell'installazione Helm v1.10 seguendo le istruzioni riportate in Eseguire la migrazione di Apigee hybrid ai grafici Helm da apigeectl.
Segui le istruzioni per i grafici Helm riportate di seguito per eseguire l'upgrade dell'installazione.
Nota: quando esegui l'upgrade di un'installazione migrata, devi inserire un flag --force nei comandi helm upgrade.

Prepararsi all'upgrade alla versione 1.11

Nota: durante la migrazione da Apigee hybrid v1.10 a v1.11, dopo la transizione da apigeectl ai grafici Helm nel passaggio precedente, devi seguire le istruzioni nella scheda Helm. Dopo la transizione a Helm, devi continuare a utilizzare Helm per gli upgrade successivi.

Eseguire il backup dell'installazione ibrida (consigliato)

Helm

Queste istruzioni utilizzano la variabile di ambiente APIGEE_HELM_CHARTS_HOME per la directory nel file system in cui hai installato i grafici Helm. Se necessario, passa a questa directory e definisci la variabile con il seguente comando:
Linux
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Mac OS
```
export APIGEE_HELM_CHARTS_HOME=$PWD
echo $APIGEE_HELM_CHARTS_HOME
```
Windows
```
set APIGEE_HELM_CHARTS_HOME=%CD%
echo %APIGEE_HELM_CHARTS_HOME%
```
Crea una copia di backup della directory $APIGEE_HELM_CHARTS_HOME/ della versione 1.10. Puoi utilizzare qualsiasi procedura di backup. Ad esempio, puoi creare un file tar dell'intera directory con:
```
tar -czvf $APIGEE_HELM_CHARTS_HOME/../apigee-helm-charts-v1.10-backup.tar.gz $APIGEE_HELM_CHARTS_HOME
```
Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e ripristino di Cassandra.

Se utilizzi file di certificati di servizio (.json) negli override per autenticare i service account, assicurati che i file di certificati del account di servizio si trovino nella directory del grafico Helm corretta. I grafici Helm non possono leggere file al di fuori di ogni directory del grafico.

Questo passaggio non è necessario se utilizzi i secret Kubernetes o Workload Identity per autenticare i service account.

La tabella seguente mostra la destinazione di ogni file del service account, a seconda del tipo di installazione:

Prod

Service account	Nome file predefinito	Directory del grafico Helm
`apigee-cassandra`	`PROJECT_ID-apigee-cassandra.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/`
`apigee-logger`	`PROJECT_ID-apigee-logger.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-mart`	`PROJECT_ID-apigee-mart.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-metrics`	`PROJECT_ID-apigee-metrics.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/`
`apigee-runtime`	`PROJECT_ID-apigee-runtime.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env`
`apigee-synchronizer`	`PROJECT_ID-apigee-synchronizer.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-env/`
`apigee-udca`	`PROJECT_ID-apigee-udca.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`
`apigee-watcher`	`PROJECT_ID-apigee-watcher.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-org/`

Non di produzione

Crea una copia del file del account di servizio apigee-non-prod in ciascuna delle seguenti directory:

Service account	Nome file predefinito	Directory dei grafici Helm
`apigee-non-prod`	`PROJECT_ID-apigee-non-prod.json`	`$APIGEE_HELM_CHARTS_HOME/apigee-datastore/` `$APIGEE_HELM_CHARTS_HOME/apigee-telemetry/` `$APIGEE_HELM_CHARTS_HOME/apigee-org/` `$APIGEE_HELM_CHARTS_HOME/apigee-env/`

Assicurati che i file del certificato e della chiave TLS (.crt, .key e/o .pem) si trovino nella directory $APIGEE_HELM_CHARTS_HOME/apigee-virtualhost/.

`apigeectl`

Gli esempi in queste istruzioni utilizzano la seguente struttura di directory. La tua installazione potrebbe essere diversa. Modifica le istruzioni in base alla struttura dell'installazione.

hybrid-v1.11-root-directory/
└── apigeectl/
    └── config/
    └── plugins/
    └── templates/
    └── tools/
└── hybrid-files/
    └── overrides/
    └── service-accounts/
    └── certs/
hybrid-v1.10-root-directory/

Queste istruzioni utilizzano la variabile di ambiente APIGEECTL_HOME per la directory nel file system in cui hai installato apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:
Linux
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
echo %APIGEECTL_HOME%
```
Crea una copia di backup della directory $APIGEECTL_HOME/ della versione 1.10. Ad esempio:
```
tar -czvf $APIGEECTL_HOME/../apigeectl-v1.10-backup.tar.gz $APIGEECTL_HOME
```
Esegui il backup del database Cassandra seguendo le istruzioni riportate in Backup e ripristino di Cassandra.

Esegui l'upgrade della versione di Kubernetes

Controlla la versione della piattaforma Kubernetes e, se necessario, esegui l'upgrade a una versione supportata sia da ibrido 1.10 sia da ibrido 1.11. Se hai bisogno di aiuto, consulta la documentazione della tua piattaforma.

Fai clic per espandere l'elenco delle piattaforme supportate

	1,10 ⁽³⁾	1,11	1,12
GKE su Google Cloud	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE su AWS	1.13.x (K8s v1.24.x) 1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x (K8s v1.25.x) 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
GKE su Azure	1.13.x 1.14.x 1.26.x⁽¹²⁾ 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.26.x⁽¹²⁾ 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x⁽¹²⁾ 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (solo software) su VMware ⁽¹⁾ ⁽¹³⁾	1.13.x 1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
Google Distributed Cloud (solo software) su bare metal ⁽¹⁾	1.13.x 1.14.x (K8s v1.25.x) 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.27.x⁽¹²⁾^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.14.x 1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.15.x (K8s v1.26.x) 1.16.x (K8s v1.27.x) 1.28.x⁽¹²⁾ 1.29.x^{(≥ 1.12.1)}
EKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
AKS⁽⁷⁾	1.24.x 1.25.x 1.26.x 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	1.25.x 1.26.x 1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	1.26.x 1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
OpenShift⁽⁷⁾	4.11 4.12 4.14^{(≥ 1.10.5)} 4.15^{(≥ 1.10.5)}	4.12 4.13 4.14 4.15^{(≥ 1.11.2)} 4.16^{(≥ 1.11.2)}	4.12 4.13 4.14 4.15 4.16^{(≥ 1.12.1)}
Rancher Kubernetes Engine (RKE)	v1.26.2+rke2r1 1.27.x^{(≥ 1.10.5)} 1.28.x^{(≥ 1.10.5)}	v1.26.2+rke2r1 v1.27.x 1.28.x^{(≥ 1.11.2)} 1.29.x^{(≥ 1.11.2)}	v1.26.2+rke2r1 v1.27.x 1.28.x 1.29.x^{(≥ 1.12.1)}
VMware Tanzu	N/D	N/D	v1.26.x
Componenti	1,10	1,11	1,12
Anthos Service Mesh	1.17.x⁽¹⁰⁾	1.18.x⁽¹⁰⁾	1.19.x⁽¹⁰⁾
JDK	JDK 11	JDK 11	JDK 11
cert-manager	1.10.x 1.11.x 1.12.x	1.11.x 1.12.x 1.13.x	1.11.x 1.12.x 1.13.x
Cassandra	3.11	3.11	4.0
Kubernetes	1.24.x 1.25.x 1.26.x	1.25.x 1.26.x 1.27.x	1.26.x 1.27.x 1.28.x
kubectl			1.27.x 1.28.x 1.29.x
Helm	3.10+	3.10+	3.14.2+
Driver CSI Secret Store		1.3.4	1.4.1
Vault		1.13.x	1.15.2
⁽¹⁾ In Anthos on-premises (Google Distributed Cloud) versione 1.13, segui queste istruzioni per evitare conflitti con `cert-manager`: Installazione di cert-manager in conflitto ⁽²⁾ Supporto disponibile con Apigee hybrid versione 1.7.2 e successive. ⁽³⁾ Sono state raggiunte le date EOL ufficiali per le versioni 1.10 e precedenti di Apigee hybrid. Le patch mensili regolari non sono più disponibili. Queste release non sono più supportate ufficialmente, ad eccezione dei clienti con eccezioni esplicite e ufficiali per il supporto continuo. Altri clienti devono eseguire l'upgrade. ⁽⁴⁾Le versioni 1.12 e precedenti di Anthos on-premise (Google Distributed Cloud) non sono più supportate. Consulta i criteri di supporto delle versioni di Distributed Cloud su bare metal e l'elenco delle versioni supportate di Distributed Cloud su VMware. ⁽⁵⁾Google Distributed Cloud su bare metal o VMware richiede Anthos Service Mesh 1.14 o versioni successive. Ti consigliamo di eseguire l'upgrade alla versione ibrida 1.8 e passare al gateway di ingresso Apigee, che non richiede più l'installazione di Anthos Service Mesh sul cluster ibrido. ⁽⁶⁾ Supporto disponibile con Apigee hybrid versione 1.8.4 e successive. ⁽⁷⁾ Non supportato con Apigee Hybrid versione 1.8.4 e successive. ⁽⁸⁾ Supporto disponibile con Apigee hybrid versione 1.7.6 e successive. ⁽⁹⁾ Non supportato con Apigee hybrid versione 1.8.5 e successive. ⁽¹⁰⁾ Anthos Service Mesh viene installato automaticamente con Apigee hybrid 1.9 e versioni successive. ⁽¹¹⁾ Supporto disponibile con Apigee hybrid versione 1.9.2 e successive. ⁽¹²⁾ I numeri di versione di GKE su AWS ora riflettono le versioni di Kubernetes. Consulta Versione di GKE Enterprise e assistenza per l'upgrade per i dettagli della versione e le patch consigliate. ⁽¹³⁾ Vault non è certificato su Google Distributed Cloud per VMware. ⁽¹⁴⁾ Assistenza disponibile con Apigee hybrid versione 1.10.5 e successive. ⁽¹⁵⁾ Supporto disponibile con Apigee hybrid versione 1.11.2 e successive. ⁽¹⁶⁾ Supporto disponibile con Apigee hybrid versione 1.12.1 e successive.

Informazioni sui cluster collegati

Per Apigee hybrid versioni 1.7.x e precedenti, devi utilizzare cluster GKE allegati se vuoi eseguire Apigee hybrid in un contesto multicloud su Elastic Kubernetes Service (EKS), Azure Kubernetes Service (AKS) o un altro provider di servizi Kubernetes di terze parti supportato. Il collegamento del cluster consente a Google di misurare l'utilizzo di Anthos Service Mesh.

Per Apigee Hybrid versione 1.8.x, i cluster GKE collegati sono necessari se utilizzi Anthos Service Mesh per il gateway in entrata. Se utilizzi il gateway Ingress Apigee, i cluster collegati sono facoltativi.

Installa il runtime di hybrid 1.11.2

Helm

Preparati all'upgrade dei grafici Helm

Apporta la seguente modifica al file overrides.yaml per consentire ai grafici apigee-operator e apigee-env di utilizzare il tag corretto, 1.11.2-hotfix.3:
```
ao:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-operators"
    tag: "1.11.2-hotfix.3"
runtime:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-runtime"
    tag: "1.11.2-hotfix.3"
```
Consulta le note di rilascio di Apigee 1.11.2-hotfix.3.

Estrai i grafici Helm di Apigee.

I grafici di Apigee hybrid sono ospitati in Google Artifact Registry:

oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts

Utilizzando il comando pull, copia tutti i grafici Helm di Apigee Hybrid nello spazio di archiviazione locale con il seguente comando:

export CHART_REPO=oci://us-docker.pkg.dev/apigee-release/apigee-hybrid-helm-charts
export CHART_VERSION=1.11.2
helm pull $CHART_REPO/apigee-operator --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-datastore --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-env --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-ingress-manager --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-org --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-redis --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-telemetry --version $CHART_VERSION --untar
helm pull $CHART_REPO/apigee-virtualhost --version $CHART_VERSION --untar

Se necessario, installa cert-manager.
Se devi eseguire l'upgrade della versione di cert-manager, installa la nuova versione con il seguente comando:
```
kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.1/cert-manager.yaml
```

Installa le CRD Apigee aggiornate:

Nota:questo è l'unico metodo supportato per installare i CRD Apigee. Non utilizzare kubectl apply senza -k, non omettere --server-side.

Utilizza la funzionalità dry run kubectl eseguendo questo comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false --dry-run

Dopo la convalida con il comando dry run, esegui questo comando:

kubectl apply -k  apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

Convalida l'installazione con il comando kubectl get crds:

kubectl get crds | grep apigee

L'output dovrebbe essere simile al seguente:

apigeedatastores.apigee.cloud.google.com                    2023-10-09T14:48:30Z
apigeedeployments.apigee.cloud.google.com                   2023-10-09T14:48:30Z
apigeeenvironments.apigee.cloud.google.com                  2023-10-09T14:48:31Z
apigeeissues.apigee.cloud.google.com                        2023-10-09T14:48:31Z
apigeeorganizations.apigee.cloud.google.com                 2023-10-09T14:48:32Z
apigeeredis.apigee.cloud.google.com                         2023-10-09T14:48:33Z
apigeerouteconfigs.apigee.cloud.google.com                  2023-10-09T14:48:33Z
apigeeroutes.apigee.cloud.google.com                        2023-10-09T14:48:33Z
apigeetelemetries.apigee.cloud.google.com                   2023-10-09T14:48:34Z
cassandradatareplications.apigee.cloud.google.com           2023-10-09T14:48:35Z

Controlla le etichette sui nodi del cluster. Per impostazione predefinita, Apigee pianifica i pod di dati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-data e i pod di runtime vengono pianificati sui nodi con l'etichetta cloud.google.com/gke-nodepool=apigee-runtime. Puoi personalizzare le etichette del pool di nodi nel file overrides.yaml.

Per saperne di più, consulta Configurazione dei pool di nodi dedicati.

Installa i grafici Helm di Apigee hybrid

Nota: prima di eseguire uno qualsiasi dei comandi di upgrade/installazione di Helm, utilizza la funzionalità di prova di Helm aggiungendo --dry-run alla fine del comando. Consulta helm -h per elencare comandi, opzioni e utilizzo supportati.

In caso contrario, vai alla directory APIGEE_HELM_CHARTS_HOME. Esegui i seguenti comandi da questa directory.

Esegui l'upgrade dell'operatore/controller Apigee:

Nota:questo passaggio richiede autorizzazioni del cluster elevate. Esegui helm -h o helm upgrade -h per maggiori dettagli

Prova:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectla Helm, utilizza:

helm upgrade operator apigee-operator/ \
  --install \
  --create-namespace \
  --namespace apigee-system \
  --force \
  -f OVERRIDES_FILE

Verifica l'installazione dell'operatore Apigee:

helm ls -n apigee-system

NAME           NAMESPACE       REVISION        UPDATED                                 STATUS          CHART                   APP VERSION
operator    apigee-system   3               2023-06-26 00:42:44.492009 -0800 PST    deployed        apigee-operator-1.11.2   1.11.2

Verifica che sia attivo e funzionante controllando la sua disponibilità:

kubectl -n apigee-system get deploy apigee-controller-manager

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
apigee-controller-manager   1/1     1            1           7d20h

Esegui l'upgrade del datastore Apigee:

Prova:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

helm upgrade datastore apigee-datastore/ \
  --install \
  --namespace apigee \
  --force \
  -f OVERRIDES_FILE

Verifica che apigeedatastore sia attivo e funzionante controllandone lo stato:

kubectl -n apigee get apigeedatastore default

NAME      STATE       AGE
default   running    2d

Esegui l'upgrade della telemetria Apigee:

Prova:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

helm upgrade telemetry apigee-telemetry/ \
  --install \
  --namespace apigee \
  --force \
  -f OVERRIDES_FILE

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n apigee get apigeetelemetry apigee-telemetry

NAME               STATE     AGE
apigee-telemetry   running   2d

Esegui l'upgrade di Apigee Redis:

Prova:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

helm upgrade redis apigee-redis/ \
  --install \
  --namespace apigee \
  --force \
  -f OVERRIDES_FILE

Verifica che sia attivo e funzionante controllandone lo stato:

kubectl -n apigee get apigeeredis default

NAME      STATE     AGE
default   running   2d

Esegui l'upgrade di Apigee Ingress Manager:

Prova:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

helm upgrade ingress-manager apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --force \
  -f OVERRIDES_FILE

Verifica che sia attivo e funzionante controllando la sua disponibilità:

kubectl -n apigee get deployment apigee-ingressgateway-manager

NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
apigee-ingressgateway-manager   2/2     2            2           2d

Esegui l'upgrade dell'organizzazione Apigee:

Prova:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE \
  --dry-run

Esegui l'upgrade del grafico:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  -f OVERRIDES_FILE

Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:

helm upgrade ORG_NAME apigee-org/ \
  --install \
  --namespace apigee \
  --force \
  -f OVERRIDES_FILE

Verifica che sia attivo e funzionante controllando lo stato dell'organizzazione corrispondente:

kubectl -n apigee get apigeeorg

NAME                      STATE     AGE
apigee-org1-xxxxx          running   2d

Esegui l'upgrade dell'ambiente.
Devi installare un ambiente alla volta. Specifica l'ambiente con --set env=ENV_NAME:

Prova:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
- ENV_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-env. Nella versione ibrida 1.10, di solito è apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, in genere è ENV_NAME.
- ENV_NAME è il nome dell'ambiente che stai eseguendo l'upgrade.
- OVERRIDES_FILE è il nuovo file di override per la versione 1.11.2
Esegui l'upgrade del grafico:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace apigee \
  --set env=ENV_NAME \
  --force \
  -f OVERRIDES_FILE
```
Verifica che sia attivo e in esecuzione controllando lo stato dell'ambiente corrispondente:
```
kubectl -n apigee get apigeeenv
```
```
NAME                          STATE       AGE   GATEWAYTYPE
apigee-org1-dev-xxx            running     2d
```
Esegui l'upgrade dei gruppi di ambienti (virtualhosts).
1. Devi eseguire l'upgrade di un gruppo di ambienti (virtualhost) alla volta. Specifica il gruppo di ambienti con --set envgroup=ENV_GROUP_NAME. Ripeti i seguenti comandi per ogni gruppo di ambiente menzionato nel file overrides.yaml:
  Prova:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE \
  --dry-run
```
  ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. Nella versione ibrida 1.10, di solito è apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_GROUP_NAME.
  
  Esegui l'upgrade del grafico:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --set envgroup=ENV_GROUP_NAME \
  -f OVERRIDES_FILE
```
  Nota: per le installazioni di cui è stata eseguita la migrazione da apigeectl a Helm, utilizza:
```
helm upgrade ENV_GROUP_RELEASE_NAME apigee-virtualhost/ \
  --install \
  --namespace apigee \
  --set envgroup=ENV_GROUP_NAME \
  --force \
  -f OVERRIDES_FILE
```
  Nota: ENV_GROUP_RELEASE_NAME deve essere univoco all'interno dello spazio dei nomi apigee.
  Ad esempio, se hai un ambiente denominato prod e un gruppo di ambienti denominato prod, imposta il valore di ENV_GROUP_RELEASE_NAME su un valore univoco, ad esempio prod-envgroup.
2. Controlla lo stato di ApigeeRoute (AR).
  L'installazione di virtualhosts crea ApigeeRouteConfig (ARC) che crea internamente ApigeeRoute (AR) una volta che il watcher Apigee estrae i dettagli relativi al gruppo di ambienti dal control plane. Pertanto, verifica che lo stato del rispettivo AR sia in esecuzione:
```
kubectl -n apigee get arc
```
```
NAME                                STATE   AGE
apigee-org1-dev-egroup                       2d
```
```
kubectl -n apigee get ar
```
```
NAME                                        STATE     AGE
apigee-org1-dev-egroup-xxxxxx                running   2d
```

Installazione di 1.11.2-hotfix.3

Apporta la seguente modifica al file overrides.yaml per consentire a runtime di utilizzare il tag corretto, 1.11.2-hotfix.3:
```
runtime:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-runtime"
    tag: "1.11.2-hotfix.3"
```
Consulta le note di rilascio di Apigee 1.11.2-hotfix.3.

Aggiorna il grafico apigee-env con il comando helm upgrade e il file di override corrente.

Ripeti l'operazione per ogni ambiente.

helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --namespace APIGEE_NAMESPACE \
  --set env ENV_NAME \
  --atomic \
  -f OVERRIDES_FILE

`apigeectl`

Archivia il numero di versione più recente in una variabile utilizzando il seguente comando:

Linux

export VERSION=$(curl -s \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt?ignoreCache=1)

Mac OS

export VERSION=$(curl -s \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt)

Windows

for /f "tokens=*" %a in ('curl -s ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/current-version.txt') ^
do set VERSION=%a

Verifica che la variabile sia stata compilata con un numero di versione utilizzando il seguente comando. Se vuoi utilizzare una versione diversa, puoi salvarla in una variabile di ambiente.
```
echo $VERSION
```
Dovresti visualizzare l'ultima versione di Apigee Hybrid:
```
  1.11.2
```
Assicurati di trovarti nella directory di base ibrida (il genitore della directory in cui si trova il file eseguibile apigeectl):
```
cd $APIGEECTL_HOME/..
```

Scarica il pacchetto di rilascio per il tuo sistema operativo utilizzando il seguente comando. Assicurati di selezionare la tua piattaforma nella tabella seguente:

Linux

Linux a 64 bit:

curl -LO \
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/$VERSION/apigeectl_linux_64.tar.gz

Mac OS

Mac a 64 bit:

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

Windows

Windows a 64 bit:

curl -LO ^
  https://storage.googleapis.com/apigee-release/hybrid/apigee-hybrid-setup/%VERSION%/apigeectl_windows_64.zip

Rinomina la directory apigeectl/ attuale con il nome di una directory di backup. Ad esempio:

Linux

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/

Mac OS

mv $APIGEECTL_HOME/ $APIGEECTL_HOME-v1.10/

Windows

rename %APIGEECTL_HOME% %APIGEECTL_HOME%-v1.10

Estrai i contenuti del file gzip scaricato nella directory di base ibrida. La directory di base ibrida è la directory in cui si trova la directory apigeectl-v1.10 rinominata:
Linux
```
tar xvzf filename.tar.gz -C ./
```
Mac OS
```
tar xvzf filename.tar.gz -C ./
```
Windows
```
tar xvzf filename.zip -C ./
```
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.11.2-xxxxxxx_linux_64. Rinomina la directory in apigeectl utilizzando il seguente comando:
Linux
```
mv apigeectl_1.11.2-xxxxxxx_linux_64 apigeectl
```
Mac OS
```
mv apigeectl_1.11.2-xxxxxxx_mac_64 apigeectl
```
Windows
```
rename apigeectl_1.11.2-xxxxxxx_windows_64 apigeectl
```
Passa alla directory apigeectl:
```
cd ./apigeectl
```
Questa directory è la home directory di apigeectl. È la posizione del comando eseguibile apigeectl.
Queste istruzioni utilizzano la variabile di ambiente $APIGEECTL_HOME per la directory nel file system in cui è installata l'utilità apigeectl. Se necessario, cambia directory nella directory apigeectl e definisci la variabile con il seguente comando:
Linux
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Mac OS
```
export APIGEECTL_HOME=$PWD
```
```
echo $APIGEECTL_HOME
```
Windows
```
set APIGEECTL_HOME=%CD%
```
```
echo %APIGEECTL_HOME%
```
Verifica la versione di apigeectl con il comando version:
```
./apigeectl version
```
```
Version: 1.11.2
```
Crea una directory hybrid-base-directory/hybrid-files, quindi spostati al suo interno. La directory hybrid-files contiene i file di configurazione, ad esempio il file di override, i certificati e gli account di servizio. Ad esempio:
Linux
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
Mac OS
```
mkdir $APIGEECTL_HOME/../hybrid-files
```
```
cd $APIGEECTL_HOME/../hybrid-files
```
Windows
```
mkdir %APIGEECTL_HOME%/../hybrid-files
```
```
cd %APIGEECTL_HOME%/../hybrid-files
```
Verifica che kubectl sia impostato sul contesto corretto utilizzando il seguente comando. Il contesto attuale deve essere impostato sul cluster in cui esegui l'upgrade di Apigee hybrid.
```
kubectl config get-contexts | grep \*
```
Nella directory hybrid-files:
1. Aggiorna i seguenti link simbolici a $APIGEECTL_HOME. Questi link ti consentono di eseguire il comando apigeectl appena installato dalla directory hybrid-files:
```
ln -nfs $APIGEECTL_HOME/tools tools
ln -nfs $APIGEECTL_HOME/config config
ln -nfs $APIGEECTL_HOME/templates templates
ln -nfs $APIGEECTL_HOME/plugins plugins
```
2. Per verificare che i collegamenti simbolici siano stati creati correttamente, esegui questo comando e assicurati che i percorsi dei link puntino alle posizioni corrette:
```
ls -l | grep ^l
```
Esegui un'inizializzazione di prova per verificare la presenza di errori:
```
${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client
```
dove OVERRIDES_FILE è il nome del file di override, ad esempio ./overrides/overrides.yaml.

Suggerimento:puoi sostituire OVERRIDES_FILE nell'esempio di codice riportato sopra con il nome e il percorso del file di override e ogni istanza in questa pagina verrà sostituita.
Se non ci sono errori, inizializza ibrido 1.11.2:
```
$APIGEECTL_HOME/apigeectl init -f OVERRIDES_FILE
```
Nota: apigeectl installa e configura il gateway in entrata Apigee quando esegui apigeectl init.
Controlla lo stato di inizializzazione:
```
$APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
```
Se l'operazione riesce, l'output è: All containers ready.
```
kubectl describe apigeeds -n apigee
```
Nell'output, cerca State: running.
Controlla la presenza di errori con una prova dry run del comando apply utilizzando il flag --dry-run:
```
$APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --dry-run=client
```
Se non ci sono errori, applica gli override. Seleziona e segui le istruzioni per gli ambienti di produzione o non di produzione, a seconda dell'installazione.
Produzione

Per gli ambienti di produzione, esegui l'upgrade di ogni componente ibrido singolarmente e controlla lo stato del componente di cui è stato eseguito l'upgrade prima di procedere con il componente successivo.
1. Assicurati di trovarti nella directory hybrid-files.
2. Applica gli override per eseguire l'upgrade di Cassandra:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --datastore
3. Completamento del controllo:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
  Suggerimento:se check-ready non va a buon fine, puoi ottenere maggiori informazioni sui tuoi pod con:
  kubectl -n NAMESPACE get pods
  
  dove NAMESPACE è lo spazio dei nomi Apigee hybrid.
  Procedi al passaggio successivo solo quando i pod sono pronti.
4. Applica gli override per eseguire l'upgrade dei componenti di Telemetry e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --telemetry
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
5. Avvia i componenti Redis:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --redis
6. Applica gli override per eseguire l'upgrade dei componenti a livello di organizzazione (MART, Watcher e Apigee Connect) e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --org
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
7. Applica gli override per eseguire l'upgrade degli ambienti. Hai due opzioni:
  - Ambiente per ambiente: applica gli override a un ambiente alla volta e verifica il completamento. Ripeti questo passaggio per ogni ambiente:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --env ENV_NAME
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
    
    dove ENV_NAME è il nome dell'ambiente di cui stai eseguendo l'upgrade.
  - Tutti gli ambienti contemporaneamente: applica gli override a tutti gli ambienti contemporaneamente e verifica il completamento:
    $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --all-envs
    
    $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
8. Applica gli override per eseguire l'upgrade dei componenti virtualhosts e verifica il completamento:
  $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE --settings virtualhosts
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE
Non di produzione

Nella maggior parte degli ambienti non di produzione, demo o sperimentali, puoi applicare gli override a tutti i componenti contemporaneamente. Se il tuo ambiente non di produzione è grande e complesso o imita da vicino un ambiente di produzione, ti consigliamo di utilizzare le istruzioni per l'upgrade degli ambienti di produzione.
1. Assicurati di trovarti nella directory hybrid-files.
2. $APIGEECTL_HOME/apigeectl apply -f OVERRIDES_FILE
3. Controlla lo stato:
  $APIGEECTL_HOME/apigeectl check-ready -f OVERRIDES_FILE

Installazione di 1.11.2-hotfix.3

Apporta la seguente modifica al file overrides.yaml per consentire a runtime di utilizzare il tag corretto, 1.11.2-hotfix.3:
```
runtime:
  image:
    url: "gcr.io/apigee-release/hybrid/apigee-runtime"
    tag: "1.11.2-hotfix.3"
```
Consulta le note di rilascio di Apigee 1.11.2-hotfix.3.

Installa l'hotfix con apigeectl init utilizzando il file di override aggiornato.

Prova:

${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE --dry-run=client

Inizializza:

${APIGEECTL_HOME}/apigeectl init -f OVERRIDES_FILE

Applica l'hotfix con apigeectl apply.

Prova:

${APIGEECTL_HOME}/apigeectl apply -f OVERRIDES_FILE --all-envs --dry-run=client

Applica:

${APIGEECTL_HOME}/apigeectl apply -f OVERRIDES_FILE --all-envs

Convalida dei criteri dopo l'upgrade alla versione 1.11.2-hotfix.3

Utilizza questa procedura per convalidare il comportamento del criterio JavaCallout dopo l'upgrade a Hybrid 1.11.2-hotfix.3.

Verifica se i file JAR Java richiedono autorizzazioni non necessarie.
Dopo il deployment della policy, controlla i log di runtime per verificare la presenza del seguente messaggio di log: "Failed to load and initialize class ...". Se visualizzi questo messaggio, significa che il file JAR di cui è stato eseguito il deployment ha richiesto autorizzazioni non necessarie. Per risolvere il problema, analizza il codice Java e aggiorna il file JAR.
Esamina e aggiorna il codice Java.
Esamina il codice Java (incluse le dipendenze) per identificare la causa di operazioni potenzialmente non consentite. Se lo trovi, modifica il codice sorgente come richiesto.
Testa i criteri con il controllo di sicurezza abilitato.
In un ambiente non di produzione, attiva il flag di controllo di sicurezza e esegui nuovamente il deployment dei criteri con un file JAR aggiornato. Per impostare il flag:
- Nel file apigee-env/values.yaml, imposta conf_security-secure.constructor.only su true in runtime:cwcAppend:. Ad esempio:
```
# Apigee Runtime
runtime:
  cwcAppend:
    conf_security-secure.constructor.only: true
```
- Aggiorna il grafico apigee-env per l'ambiente per applicare la modifica. Ad esempio:
```
helm upgrade ENV_RELEASE_NAME apigee-env/ \
  --install \
  --namespace APIGEE_NAMESPACE \
  --set env=ENV_NAME \
  -f OVERRIDES_FILE
```
Se il messaggio di log "Failed to load and initialize class ..." è ancora presente, continua a modificare e testare il file JAR finché il messaggio di log non viene più visualizzato.
Attiva il controllo di sicurezza nell'ambiente di produzione.
Dopo aver testato e verificato a fondo il file JAR nell'ambiente non di produzione, attiva il controllo di sicurezza nell'ambiente di produzione impostando il flag conf_security-secure.constructor.only su true e aggiornando il grafico apigee-env per l'ambiente di produzione in modo da applicare la modifica.

Eseguire il rollback di un upgrade

Per eseguire il rollback di un upgrade precedente:

Helm

Per eseguire il rollback alla versione precedente, utilizza i grafici e il file di override dell' installazione precedente.

Crea la seguente variabile di ambiente:
- PREVIOUS_HELM_CHARTS_HOME: la directory in cui sono installati i grafici Helm di Apigee hybrid precedenti. Questa è la versione a cui stai eseguendo il rollback.
Esegui il rollback degli host virtuali. Ripeti il seguente comando per ogni gruppo di ambienti menzionato nel file di sostituzioni.
```
helm upgrade ENV_GROUP_RELEASE_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-virtualhost/ \
  --namespace apigee \
  --atomic \
  --set envgroup=ENV_GROUP_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_GROUP_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-virtualhost. Nella versione ibrida 1.10, di solito è apigee-virtualhost-ENV_GROUP_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_GROUP_NAME.
Esegui il rollback degli ambienti. Ripeti il seguente comando per ogni ambiente menzionato nel file di sostituzioni.
```
helm upgrade apigee-env-ENV_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-env/ \
  --install \
  --namespace apigee \
  --atomic \
  --set env=ENV_NAME \
  -f PREVIOUS_OVERRIDES_FILE
```
ENV_RELEASE_NAME è il nome con cui hai installato in precedenza il grafico apigee-env. Nella versione ibrida 1.10, di solito è apigee-env-ENV_NAME. In Hybrid v1.11 e versioni successive, di solito è ENV_NAME.

Esegui il rollback dell'organizzazione:

helm upgrade ORG_NAME $PREVIOUS_HELM_CHARTS_HOME/apigee-org/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback di Ingress Manager:

helm upgrade ingress-manager $PREVIOUS_HELM_CHARTS_HOME/apigee-ingress-manager/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback di Redis:

helm upgrade redis $PREVIOUS_HELM_CHARTS_HOME/apigee-redis/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback di Apigee Telemetry:

helm upgrade telemetry $PREVIOUS_HELM_CHARTS_HOME/apigee-telemetry/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback di Apigee Datastore (il componente del database Cassandra):

helm upgrade datastore $PREVIOUS_HELM_CHARTS_HOME/apigee-datastore/ \
  --install \
  --namespace apigee \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback del controller Apigee:

helm upgrade operator $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/ \
  --install \
  --namespace apigee-system \
  --atomic \
  -f PREVIOUS_OVERRIDES_FILE

Esegui il rollback dei CRD di Apigee hybrid:

  kubectl apply -k  $PREVIOUS_HELM_CHARTS_HOME/apigee-operator/etc/crds/default/ --server-side --force-conflicts --validate=false

`apigeectl`

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

Modifica la variabile APIGEECTL_HOME in modo che punti alla directory che contiene la versione precedente di apigeectl. Ad esempio:
```
export APIGEECTL_HOME=PATH_TO_PREVIOUS_APIGEECTL_DIRECTORY
```

Esegui i seguenti comandi nella directory principale dell'installazione a cui vuoi eseguire il rollback. Assicurati di utilizzare il file di override originale per la versione a cui vuoi eseguire il rollback:

Nella directory hybrid-files, esegui apigeectl apply:
```
$APIGEECTL_HOME/apigeectl apply -f ORIGINAL_OVERRIDES_FILE
```
Dove ORIGINAL_OVERRIDES_FILE è il percorso relativo e il nome file del file di override per l'installazione ibrida della versione precedente, ad esempio ./overrides/overrides1.10.yaml.
Controlla lo stato dei pod:
```
kubectl -n NAMESPACE get pods
```
dove NAMESPACE è lo spazio dei nomi Apigee hybrid.

Controlla lo stato di apigeeds:

kubectl describe apigeeds -n apigee

L'output dovrebbe essere simile a questo:

Status:
  Cassandra Data Replication:
  Cassandra Pod Ips:
    10.8.2.204
  Cassandra Ready Replicas:  1
  Components:
    Cassandra:
      Last Successfully Released Version:
        Revision:  v1-f8aa9a82b9f69613
        Version:   v1
      Replicas:
        Available:  1
        Ready:      1
        Total:      1
        Updated:    1
      State:        running
  Scaling:
    In Progress:         false
    Operation:
    Requested Replicas:  0
  State:                 running

Procedi al passaggio successivo solo quando il pod apigeeds è in esecuzione.

Esegui questo comando per annotare i nuovi valori del conteggio delle repliche per il processore di messaggi dopo l'upgrade. Se questi valori non corrispondono a quelli impostati in precedenza, modificali nel file di override in modo che corrispondano alla configurazione precedente.
```
apigeectl apply -f ORIGINAL_OVERRIDES_FILE --dry-run=client --print-yaml --env ENV_NAME 2>/dev/null |grep "runtime:" -A 25 -B 1| grep "autoScaler" -A 2
```
L'output dovrebbe essere simile a questo:
```
      autoScaler:
        minReplicas: 2
        maxReplicas: 10
```

Corsa apigeectl init:

$APIGEECTL_HOME/apigeectl init -f ORIGINAL_OVERRIDES_FILE

Eseguire l'upgrade di Apigee hybrid alla versione 1.11 Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Panoramica dell'upgrade alla versione 1.11.2

Controlli più rigorosi dell'istanza della classe in Hybrid 1.11.2-Hotfix.3

Prerequisiti

Grafici Helm e apigeectl

Migrazione alla versione 1.11 con Helm dalla versione 1.10 con apigeectl

Prepararsi all'upgrade alla versione 1.11

Eseguire il backup dell'installazione ibrida (consigliato)

Helm

Linux

Mac OS

Windows

Prod

Non di produzione

apigeectl

Linux

Mac OS

Windows

Esegui l'upgrade della versione di Kubernetes

Fai clic per espandere l'elenco delle piattaforme supportate

Componenti

Informazioni sui cluster collegati

Installa il runtime di hybrid 1.11.2

Helm

Preparati all'upgrade dei grafici Helm

Installa i grafici Helm di Apigee hybrid

Installazione di 1.11.2-hotfix.3

apigeectl

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Linux

Mac OS

Windows

Produzione

Non di produzione

Installazione di 1.11.2-hotfix.3

Convalida dei criteri dopo l'upgrade alla versione 1.11.2-hotfix.3

Eseguire il rollback di un upgrade

Helm

apigeectl

Eseguire l'upgrade di Apigee hybrid alla versione 1.11

Grafici Helm e `apigeectl`

Migrazione alla versione 1.11 con Helm dalla versione 1.10 con `apigeectl`

`apigeectl`

`apigeectl`

`apigeectl`