Google utilizza la tecnologia AI per tradurre i contenuti nella tua lingua preferita. Le traduzioni generate dall'AI potrebbero contenere errori.

Aggiorna Apigee Edge 4.53.00 o 4.53.01 alla versione 4.54.00

Apigee supporta l'upgrade di Edge for Private Cloud direttamente dalla versione 4.53.00 o 4.53.01 alla versione 4.54.00. Questa pagina descrive come eseguire questi upgrade.

Per una panoramica dei percorsi di upgrade compatibili, consulta la matrice di compatibilità degli upgrade per le release di Edge for Private Cloud.

Chi può eseguire l'aggiornamento

La persona che esegue l'aggiornamento deve essere la stessa che ha installato originariamente Edge o una persona che esegue l'aggiornamento come utente root.

Dopo aver installato gli RPM di Edge, chiunque può configurarli.

Quali componenti devi aggiornare

Devi aggiornare tutti i componenti Edge. Edge non supporta una configurazione che contiene componenti di più versioni.

Materiali da leggere in anticipo

Consulta i seguenti argomenti per informazioni importanti sulle modifiche introdotte in Edge for Private Cloud 4.54.00:

Modifiche nella versione 4.54.00:rivedi le modifiche in TLS e callout Java che richiedono una preparazione prima dell'upgrade. Per saperne di più, consulta la sezione Modifiche nella versione 4.54.00.
Architettura di runtime Dual-Java (Java 17 e Java 21): a partire dalla versione 4.54.00, Edge for Private Cloud rimuove il supporto di Java 8 ed esegue i componenti su Java 17 o Java 21. Per saperne di più, consulta Modifiche alla versione 4.54.00.
Nessuna installazione automatica di Java durante il bootstrap: Edge for Private Cloud 4.54.00 è in grado di rilevare le installazioni di Java e verifica che siano installati sia Java 17 che Java 21.
Nuova UI Edge nella versione 4.54.00:scopri di più sulla transizione alla nuova UI Edge come interfaccia di gestione predefinita e sulla rimozione della UI classica (edge-ui). Per saperne di più, consulta Nuova UI Edge.
SSO Apigee nella versione 4.54.00:scopri l'architettura SSO aggiornata e le modifiche alla configurazione per l'autenticazione. Per saperne di più, consulta SSO Apigee.
Nginx 1.30 nella versione 4.54.00: esamina l'upgrade automatico di Nginx 1.30.x sui router Edge, i potenziali impatti sul runtime e i passaggi di mitigazione. Per saperne di più, consulta Modifiche di Nginx 1.30.

Prerequisiti per l'upgrade

Prima di eseguire l'upgrade di Apigee Edge, assicurati di soddisfare i seguenti prerequisiti:

Esaminare le note di rilascio e le nuove funzionalità

Prima di avviare il processo di upgrade, assicurati di esaminare e comprendere a fondo tutte le nuove funzionalità, le modifiche al comportamento e i ritiri descritti nelle note di rilascio di Edge for Private Cloud per la versione 4.54.00.
Rilevamento automatico e coesistenza dei file binari Java durante l'upgrade: installa Java utilizzando gestori di pacchetti standard (come yum) o posizioni standard (come /usr/lib/jvm o update-alternatives). Non è necessario configurare entrambe le versioni contemporaneamente nel PATH di sistema. Non disinstallare Java 8 prima di eseguire l'upgrade. Mantieni Java 8 installato insieme a Java 17 e Java 21 in modo che i servizi Edge for Private Cloud 4.53.xx esistenti continuino a funzionare senza interruzioni fino al loro aggiornamento.
Esegui il backup di tutti i nodi

Prima di eseguire l'aggiornamento, ti consigliamo di eseguire un backup completo di tutti i nodi per motivi di sicurezza. Utilizza la procedura per la tua versione attuale di Edge per eseguire il backup. In questo modo, avrai un piano di riserva nel caso in cui l'aggiornamento a una nuova versione non funzioni correttamente. Per ulteriori informazioni sul backup, vedi Backup e ripristino.
Backup del file di configurazione invisibile

Assicurati che le copie di backup dei file di configurazione silenziosa per Edge for Private Cloud 4.53.00 o 4.53.01 vengano conservate per facilitare un rollback, se necessario.
Assicurati che Edge sia in esecuzione

Assicurati che Edge sia in esecuzione durante la procedura di aggiornamento utilizzando il comando:
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Verifica i prerequisiti di Cassandra

Se in precedenza hai eseguito l'upgrade da una versione precedente di Edge for Private Cloud alla versione 4.53.00 (o) 4.53.01 e ora prevedi di eseguire l'upgrade alla versione 4.54.00, assicurati di aver completato i passaggi post-upgrade richiesti per Cassandra. Questi passaggi sono descritti nella documentazione di upgrade della versione 4.53.00 o 4.53.01 e sono menzionati anche in Prerequisiti per l'upgrade di Cassandra. Se non sai con certezza se questi passaggi sono stati completati durante l'upgrade precedente, completali di nuovo prima di procedere con l'upgrade alla versione 4.54.00.
Arresta apigee-monit: se apigee-monit è in esecuzione sul nodo, arrestalo con /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop prima di eseguire l'upgrade. In questo modo, apigee-monit non riavvia automaticamente i componenti durante l'upgrade. Riattivalo con apigee-service apigee-monit start al termine dell'upgrade.

Propagazione automatica delle impostazioni della proprietà

Se hai impostato delle proprietà modificando i file .properties in /opt/apigee/customer/application, questi valori vengono mantenuti dall'aggiornamento.

Esegui l'upgrade del router e del processore dei messaggi

Esegui l'upgrade di tutti i nodi dei router e dei processori di messaggi nei data center uno alla volta:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Esegui l'upgrade del server di gestione

Esegui l'upgrade di tutti i nodi del server di gestione nei data center uno alla volta:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Esegui l'upgrade a OpenLDAP 2.6.10

Edge for Private Cloud 4.54.00 introduce OpenLDAP 2.6.10. Questo upgrade si applica a tutte le topologie di deployment di Apigee OpenLDAP: server singolo, attivo-passivo e attivo-attivo (multi-master).

Preparazione e installazione (tutti i server LDAP)

Passaggi per eseguire l'upgrade di LDAP dalla versione 4.53.00 alla versione 4.54.00

Prerequisiti e considerazioni

Tieni presente che durante il processo di migrazione da OpenLDAP 2.4 a 2.6.10 (durante l'upgrade dalla versione 4.53.00), le API di gestione e di conseguenza la UI di Apigee non saranno disponibili in tutte le regioni. Tutte le attività amministrative, come la gestione di utenti, ruoli, app e organizzazioni, non andranno a buon fine e dovranno essere messe in pausa. Non ci sarà alcun impatto sull'elaborazione del traffico del proxy API. Arresta tutte le istanze edge-management-server ed edge-ui prima di procedere con la migrazione LDAP.
Il backup è fondamentale (quando esegui l'upgrade dalla versione 4.53.00): quando esegui l'upgrade da Edge for Private Cloud 4.53.00 (OpenLDAP 2.4.46), è obbligatorio un backup completo e convalidato dei dati LDAP esistenti. Se procedi senza un backup valido, i dati andranno persi in modo irreversibile. Avvia il backup mentre il servizio LDAP è ancora in esecuzione per acquisire uno snapshot coerente e point-in-time dei dati LDAP. Senza un backup, non puoi eseguire la migrazione dalla versione 2.4 alla versione 2.6.10 o il rollback, perché i passaggi di migrazione alla versione 4.53.00 cancellano le directory di dati LDAP legacy.

Arresta il server di gestione e l'interfaccia utente:arresta tutte le istanze di edge-management-server e edge-ui prima di procedere con la migrazione LDAP dalla versione 4.53.00.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Esegui il backup dei dati LDAP esistenti: prima di apportare modifiche durante l'upgrade dalla versione 4.53.00 (OpenLDAP 2.4.46), esegui un backup completo dei dati LDAP attuali da tutti i server LDAP. In questo modo viene creato un punto di ripristino sicuro. (Quando esegui l'upgrade dalla versione 4.53.01 alla 4.54.00, questa sequenza di backup, arresto e pulizia non è necessaria.)
- Esegui il comando di backup. Questa azione crea un archivio di backup con timestamp all'interno della directory /opt/apigee/backup/openldap.
```
apigee-service apigee-openldap backup
```
- Ottieni il numero totale di record:acquisisci il numero di record nella directory per la convalida post-upgrade. Il conteggio dei record deve corrispondere su tutti i server LDAP.
```
# Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
Arresta LDAP e pulisci le directory di dati: esegui questo passaggio su tutti i server LDAP solo se stai eseguendo l'upgrade dalla versione 4.53.00 (OpenLDAP 2.4.46). Non interrompere LDAP o eliminare /opt/apigee/data/apigee-openldap/* se esegui l'upgrade dalla versione 4.53.01 (OpenLDAP 2.6.7). Per gli upgrade alla versione 4.53.00, questo passaggio è obbligatorio a causa della modifica della versione principale e delle differenze strutturali del database sottostante. Quando tutti i server LDAP vengono arrestati, iniziano le interruzioni delle API di gestione e della UI.
- Arresta il servizio LDAP.
```
apigee-service apigee-openldap stop
```
- Rimuovi definitivamente le vecchie directory di dati e configurazione LDAP.
```
rm -rf /opt/apigee/data/apigee-openldap/*
```
Installa e configura la nuova versione di LDAP Su tutti i server LDAP, utilizza gli script Apigee standard per scaricare e installare la nuova versione del componente.
- Installa il nuovo componente LDAP: lo script di aggiornamento legge il file di configurazione e installa il nuovo pacchetto apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- Convalida la nuova versione di LDAP:al termine dell'installazione, ricarica il profilo e verifica che sia installata la nuova versione di LDAP (2.6.10):
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
  L'output del comando specificato sopra deve verificare la versione LDAP 2.6.10, come mostrato di seguito:
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```
Arresta LDAP su tutti i server prima del ripristino dei dati: esegui i passaggi 5, 6 e 7 solo se esegui l'upgrade dalla versione 4.53.00 (OpenLDAP 2.4.46) (se hai eseguito l'upgrade in loco dalla versione 4.53.01 nel passaggio 4, i dati LDAP esistenti vengono conservati e l'upgrade è completo). Prima di ripristinare il backup dalla versione 4.53.00, assicurati che il servizio LDAP appena installato sia arrestato su tutti i server. Su ogni server LDAP, esegui i seguenti comandi:
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*
```
Ripristina i dati LDAP: la strategia consiste nel ripristinare il backup sul primo server attivo. Questo server fungerà quindi da fonte attendibile, replicando i dati sui suoi peer in una configurazione multiserver.
1. Identifica il primo server attivo per il ripristino:
  - Per la configurazione a server singolo:questo è l'unico server LDAP. Puoi procedere direttamente al passaggio successivo.
  - Per le configurazioni attivo-passivo e attivo-attivo: esegui il seguente comando di diagnostica su ciascun server LDAP:
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
    Nota:
    - Se il comando precedente restituisce un output, il server è un server passivo.
    - Se non restituisce alcun output, il server è quello attivo.
2. Ripristina i dati di backup:prima di procedere, verifica che il passaggio 5 sia stato completato correttamente su tutti i server LDAP.
  - Sul primo server attivo identificato sopra, vai alla directory di backup.
```
cd /opt/apigee/backup/openldap
```
  - Esegui il comando di ripristino. Specifica il timestamp esatto del backup del passaggio 2 per evitare di ripristinare una versione precedente o non intenzionale.
```
# To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
```
  - Al termine del processo di ripristino, avvia il servizio LDAP sul primo server attivo.
```
apigee-service apigee-openldap start
```
Avvia i server LDAP rimanenti:se hai una configurazione multi-server, avvia il servizio su ciascuno dei server LDAP:
```
apigee-service apigee-openldap start
```
Nota: non è necessario ripristinare manualmente i dati su questi server peer. All'avvio, si connetteranno al primo server (che ora contiene i dati ripristinati) e sincronizzeranno automaticamente l'intera directory tramite la replica.
Convalida finale: l'ultimo passaggio consiste nel verificare che l'upgrade sia riuscito e che i dati siano coerenti nell'intero cluster LDAP.
- Esegui il comando di convalida su tutti i server LDAP. Il numero di record deve essere identico su tutti i server e deve corrispondere al numero acquisito nel passaggio 2:
```
# Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
- Una volta confermato che i dati sono corretti e coerenti, l'upgrade di LDAP è completato. Ora puoi avviare edge-management-server, edge-ui e qualsiasi altro componente dipendente in base alla procedura di upgrade standard della tua organizzazione.

Passaggi per eseguire l'upgrade di LDAP dalla versione 4.53.01 alla versione 4.54.00

Installa e configura la nuova versione di LDAP Su tutti i server LDAP, utilizza gli script Apigee standard per scaricare e installare la nuova versione del componente.

Installa il nuovo componente LDAP: lo script di aggiornamento legge il file di configurazione e installa il nuovo pacchetto apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
Convalida la nuova versione di LDAP:al termine dell'installazione, ricarica il profilo e verifica che sia installata la nuova versione di LDAP (2.6.10):
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
L'output del comando specificato sopra deve verificare la versione LDAP 2.6.10, come mostrato di seguito:
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```

Esegui l'upgrade alla nuova UI Edge e all'SSO Apigee (se installato)

In Apigee Edge for Private Cloud 4.54.00, la UI classica (edge-ui) viene rimossa e sostituita dalla nuova UI Edge (edge-management-ui). A seconda che Apigee Single Sign-On (SSO) sia installato e utilizzato nella configurazione, segui una delle due opzioni riportate di seguito:

Opzione 1: esegui l'upgrade della UI (senza SSO Apigee)

Questa sezione si applica esclusivamente se l'SSO Apigee (apigee-sso) non è configurato / installato nella tua installazione esistente di Edge for Private Cloud versione 4.53.00 o 4.53.01

Nell'ambito del processo di upgrade di Edge for Private Cloud versione 4.54.00, la UI classica (edge-ui) viene rimossa. L'esecuzione del seguente comando di upgrade esegue la transizione del nodo UI dalla UI classica (edge-ui) alla nuova UI Edge(edge-management-ui).

Passaggio 1: esegui il backup dei file di configurazione

Prima dell'avvio, esegui un backup del file di configurazione silenziosa esistente (configFile) e della directory /opt/apigee/customer/application/ su tutti i nodi della UI.

Passaggio 2: aggiorna il file di configurazione invisibile per l'autenticazione di base

Modifica il file di configurazione silenziosa (ad esempio /opt/silent.conf) e aggiungi le seguenti proprietà della nuova UI di Edge per l'autenticazione di base:

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

Passaggio 3: esegui l'upgrade del componente UI

Esegui lo script update.sh con il componente -c ue per eseguire l'upgrade dalla UI classica (edge-ui) alla nuova UI di Edge (edge-management-ui):

/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

Passaggio 4: verifica l'upgrade della nuova UI di Edge

Una volta completato correttamente il processo di upgrade su tutti i nodi UI, verifica che la nuova UI Edge versione 4.54.00 sia completamente operativa e accessibile:

Verifica che il servizio edge-management-ui sia in esecuzione:
```
apigee-service edge-management-ui status
```
Apri un browser e vai all'indirizzo:
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Una volta verificato, salta l'Opzione 2: esegui l'upgrade della UI (con SSO Apigee) e vai direttamente all'Upgrade obbligatorio a Qpid.

Opzione 2: esegui l'upgrade della UI (con SSO Apigee)

Utilizza questa sezione se l'SSO Apigee (apigee-sso) è configurato / installato nel tuo ambiente Edge for Private Cloud 4.53.00 o 4.53.01.

In Apigee Edge for Private Cloud 4.54.00:

Il servizio SSO Apigee sottostante passa dal componente apigee-sso legacy a SSO Apigee gestito in apigee-openldap. Questo upgrade è obbligatorio quando esegui l'upgrade ad Apigee Edge for Private Cloud versione 4.54.00 se SSO è abilitato in Edge for Private Cloud versione 4.53.00 o 4.53.01.
Sia la UI classica 4.53.x (edge-ui) con SSO sia la nuova UI di Edge 4.53.x (edge-management-ui) con SSO eseguono l'upgrade alla nuova UI di Edge 4.54.00 (edge-management-ui) con SSO Apigee.

Leggi i seguenti articoli per comprendere il nuovo design di SSO Apigee e il suo impatto sulle utilità e sui flussi di automazione con l'API di gestione:
Informazioni sulla nuova struttura SSO Apigee
Attività automatizzate tramite SSO

Segui i passaggi end-to-end consolidati riportati di seguito per eseguire l'upgrade della UI e del SSO Apigee in modo pulito senza passaggi di configurazione duplicati:

Passaggio 1: esegui il backup dei file di configurazione

Prima di procedere, esegui il backup del file silent configFile esistente e della directory /opt/apigee/customer/application/ su tutti i nodi UI e SSO.

Passaggio 2: rimuovi le variabili UI/SSO ritirate e aggiorna il file di configurazione invisibile (`configFile`)

Prima di eseguire l'upgrade della nuova UI Edge e configurare il modulo SSO Apigee, aggiorna il file di configurazione silenziosa (configFile) in un unico passaggio in base alla configurazione attuale della UI 4.53.x:

Rimuovi o commenta le variabili di UI e SSO 4.53.x ritirate da configFile:

Se esegui l'upgrade dalla UI classica (edge-ui) con apigee-sso: rimuovi o commenta le proprietà relative alla UI classica e al SSO:

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS

Se esegui l'upgrade dalla nuova UI di Edge (edge-management-ui) con apigee-sso: rimuovi o commenta le proprietà obsolete relative a SSO, Shoehorn e UI classica 4.53.x:

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS
EDGEUI_ENABLE_UNIFIED_UI=n
SHOEHORN_SCHEME=$MANAGEMENT_UI_SCHEME
SHOEHORN_IP=$MANAGEMENT_UI_IP
SHOEHORN_PORT=9000
CLASSIC_UI_SCHEME=http
CLASSIC_UI_PORT=9000
MANAGEMENT_UI_PUBLIC_URIS=http://Public_IP:3001
MANAGEMENT_UI_SSO_REGISTERD_PUBLIC_URIS=$MANAGEMENT_UI_PUBLIC_URIS
ROUTES_CLASSICUI=""
ROUTES_SHOEHORN=""

Utilizza il seguente comando sul nodo apigee-openldap per creare un utente macchina per la nuova UI Edge e assicurati di utilizzare esattamente le stesse credenziali quando definisci la proprietà nel file di configurazione invisibile all'utente (configFile) nel passaggio successivo. Per saperne di più, consulta Crea un utente macchina per la UI.
```
/opt/apigee/apigee-openldap/bin/apigee-machineuser.sh add -u ui-machine-user@apigee.com -p Secret123
```

Aggiungi o aggiorna le proprietà obbligatorie di SSO Apigee 4.54.00 e della nuova UI di Edge in configFile:

# ==========================================
# SSO Enablement
# ==========================================
ENABLE_SSO=y

# ==========================================
# SSO Hostname/IP and Port config for Apigee SSO
# ==========================================
SSO_PUBLIC_URL_SCHEME=http
SSO_PUBLIC_URL_HOSTNAME=YOUR_SSO_NODE_IP_OR_HOSTNAME #Replace YOUR_SSO_NODE_IP_OR_HOSTNAME with the IP address or hostname of the SSO node.
SSO_PUBLIC_URL_PORT=9099

# ==========================================
# Static Client UI credentials
# ==========================================
MANAGEMENT_UI_SSO_CLIENT_ID=YOUR_SSO_CLIENT_ID #Example : MANAGEMENT_UI_SSO_CLIENT_ID=unifiedui
MANAGEMENT_UI_SSO_CLIENT_SECRET=YOUR_SSO_CLIENT_SECRET #Example : MANAGEMENT_UI_SSO_CLIENT_SECRET=secret123

# ==========================================
# Management UI & SSO redirect URLs
# ==========================================
MANAGEMENT_UI_SCHEME=http
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_PORT=3001

# ==========================================
# Management Server parameters (Required for SSO registration)
# ==========================================
MSIP=MS_IP_OR_HOSTNAME #Replace MS_IP_OR_HOSTNAME with the IP address or hostname of the Management Server node.
ADMIN_EMAIL=your@email.com
APIGEE_ADMINPW=your_password

# ==========================================
# Machine user for UI
# ==========================================
UI_MACHINE_USER=ui-machine-user@apigee.com
UI_MACHINE_PWD=Secret123

# ==========================================
# Postgres connection parameters
# ==========================================
# Postgres username and password as set when you installed Edge.
PG_HOST=PG_IP_OR_HOSTNAME
PG_USER=apigee
PG_PWD=YOUR_PG_PASSWORD

# ==========================================
# Other UI Parameters
# ==========================================
AUTH_MODE=sso

# Y to use Internal/Local LDAP for authentication, N to use external IDP
SSO_LOCAL_LDAP=y

MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_SSO_ENABLED=y
MANAGEMENT_UI_SSO_CSRF_SECRET=YOUR_CSRF_SECRET
MANAGEMENT_UI_SSO_CSRF_EXPIRATION_HOURS=24
MANAGEMENT_UI_SSO_STRICT_TRANSPORT_SECURITY_AGE_HOURS=24
MANAGEMENT_UI_SSO_PUBLIC_KEY_CACHE_HOURS=0.5

Passaggio 3: esegui l'upgrade del componente della nuova UI di Edge

Arresta e disinstalla i componenti edge-management-ui (nuova UI Edge) ed edge-ui (UI Shoehorn), se la nuova UI Edge è attualmente in uso :

#Remove 4.53.xx New Edge UI from installation node 
apigee-service edge-management-ui stop
apigee-service edge-management-ui uninstall

#Remove Shoehorn UI from the node with 4.53.xx New Edge UI
apigee-service edge-ui stop
apigee-service edge-ui uninstall

Esegui lo script update.sh sui nodi della UI classica (edge-ui) per installare ed eseguire l'upgrade al componente della nuova UI Edge (edge-management-ui):
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```

Passaggio 4: interrompi `apigee-sso`

Interrompi il servizio apigee-sso legacy su tutti i nodi in cui è installato:

apigee-service apigee-sso stop

Passaggio 5: crea il database `apigee_dex` per SSO Apigee nel nodo Postgres

Sul nodo principale Postgres, accedi a Postgresql utilizzando il seguente comando:
```
psql -h $(hostname -i) -U apigee
```
Esegui il comando seguente al prompt psql per creare il database SSO Apigee:
```
create database apigee_dex;
```

Passaggio 6: configura l'SSO Apigee sui nodi OpenLDAP

Esegui questo comando sul nodo apigee-openldap in cui verrà installato l'SSO Apigee:

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

Passaggio 7: configura la UI di gestione per Apigee SSO e riavvia la UI

Esegui questi comandi su ogni nodo in cui è installato Edge for Private Cloud 4.54.00 edge-management-ui:

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

Passaggio 8: verifica l'upgrade della nuova UI di Edge e dell'SSO Apigee

Dopo aver completato i passaggi precedenti, verifica che la nuova UI di Edge 4.54.00 e l'SSO Apigee siano in esecuzione e accessibili:

Verifica che il servizio edge-management-ui sia in esecuzione:
```
apigee-service edge-management-ui status
```
Apri un browser e vai all'indirizzo:
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Accedi utilizzando le credenziali SSO configurate.

Passaggio 9: disinstalla la versione precedente di `apigee-sso`

Su tutti i nodi in cui è stato installato apigee-sso legacy, disinstalla il componente apigee-sso:

apigee-service apigee-sso uninstall

Esegui l'upgrade a Qpid 10.0.1

Questo metodo garantisce che non si verifichino tempi di inattività per l'ambiente di runtime Edge e riduce al minimo la perdita di dati di runtime, se presenti, acquisiti per l'analisi.

Per eseguire un upgrade in loco senza tempi di inattività a Qpid:

Scegli un nodo Qpid con cui iniziare.
Arresta il broker Qpid sul nodo:
```
apigee-service apigee-qpidd stop
```
Blocca il traffico in entrata sulla porta del broker 5672 da tutti i processori di messaggi applicando un firewall. Puoi applicare questo firewall a livello dell'istanza del nodo Qpid o di un altro componente di rete/firewall esterno.

Ti consigliamo di eseguire lo stesso passaggio per tutti gli indirizzi IP del processore di messaggi. Ad esempio, per eliminare le richieste provenienti dagli indirizzi IP del processore di messaggi al nodo Qpid sulla porta 5672 utilizzando IPTables, puoi utilizzare un comando come questo:
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Avvia di nuovo il broker Qpid per svuotare i messaggi esistenti, se presenti:
```
apigee-service apigee-qpidd start
```
Verifica che le code esistenti siano vuote:
```
/opt/apigee/apigee-qpidd/bin/qpid-stat -q
```
Se i messaggi sono bloccati nella coda di messaggi non recapitabili (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), svuota la coda seguendo i passaggi per risolvere i problemi relativi ai dati di analisi bloccati nella coda di messaggi non recapitabili.
Dopo aver verificato che le code sono state svuotate sul nodo precedente, interrompi apigee-qpidd:
```
apigee-service apigee-qpidd stop
```

Esegui l'upgrade di Qpid sul nodo:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Riavvia edge-qpid-server:
```
apigee-service edge-qpid-server restart
```
Rimuovi la regola firewall applicata nel passaggio 3.

Esegui lo stesso passaggio di rimozione per tutti gli indirizzi IP dei processori di messaggi a cui è stato applicato il firewall. Una volta rimossi i firewall, le richieste provenienti dagli indirizzi IP del processore di messaggi al nodo Qpid sulla porta 5672 verranno accettate. Se hai utilizzato iptables per aggiungere il firewall, per rimuoverlo ed elencare le impostazioni esistenti puoi utilizzare comandi come i seguenti:
```
iptables -F
iptables -L
```
Utilizza il monitoraggio web per verificare che le code Qpid ricevano i messaggi:
```
http://QPID_NODE_IP:8090
```
Ripeti i passaggi da 1 a 9 per ogni nodo Qpid.

Esegui l'upgrade a Postgres 18.6

Questa release di Edge include un upgrade a Postgres 18.6. Nell'ambito di questo upgrade, viene eseguita la migrazione di tutti i dati Postgres a Postgres 18.6

La maggior parte dei sistemi di produzione Edge utilizza due nodi Postgres configurati per la replica principale-standby. Durante il processo di aggiornamento, mentre i nodi Postgres sono inattivi per l'aggiornamento, i dati di analisi vengono comunque scritti nei nodi Qpid. Una volta aggiornati e di nuovo online, i nodi Postgres vengono inviati ai dati di analisi.

Il modo in cui esegui l'aggiornamento di Postgres dipende da come hai configurato l'archiviazione dei dati per i nodi Postgres:

Se utilizzi l'archiviazione locale dei dati per i nodi Postgres , devi installare un nuovo nodo di standby Postgres per la durata dell'upgrade. Al termine dell'upgrade, puoi dismettere il nuovo nodo di standby Postgres. Il nodo di standby Postgres aggiuntivo è necessario se devi eseguire il rollback dell'aggiornamento per qualsiasi motivo. Se devi eseguire il rollback dell'aggiornamento, il nuovo nodo Postgres di standby diventa il nodo Postgres principale dopo il rollback. Pertanto, quando installi il nuovo nodo di standby Postgres, questo deve trovarsi su un nodo che soddisfi tutti i requisiti hardware di un server Postgres, come definito nei requisiti di installazione di Edge.

In una configurazione di Edge a 1 nodo e 2 nodi, le topologie utilizzate per la prototipazione e i test, hai un solo nodo Postgres. Puoi aggiornare questi nodi Postgres direttamente senza dover creare un nuovo nodo Postgres.
Se utilizzi lo spazio di archiviazione di rete per i nodi Postgres , come consigliato da Apigee, non devi installare un nuovo nodo Postgres. Nelle procedure riportate di seguito, puoi saltare i passaggi che specificano di installare e dismettere in un secondo momento un nuovo nodo di standby Postgres. Prima di iniziare la procedura di aggiornamento, acquisisci uno snapshot di rete del datastore utilizzato da Postgres. In questo modo, se si verificano errori durante l'aggiornamento e devi eseguire un rollback, puoi ripristinare il nodo Postgres da quello snapshot.

Installazione di un nuovo nodo standby Postgres

Questa procedura crea un server di standby Postgres su un nuovo nodo. Assicurati di installare un nuovo server Postgres in standby per la versione esistente di Edge (4.53.00 o 4.53.01), non per la versione 4.54.00.

Per eseguire l'installazione, utilizza lo stesso file di configurazione che hai utilizzato per installare la versione attuale di Edge.

Per creare un nuovo nodo standby Postgres:

Nel database primario Postgres corrente, modifica il file /opt/apigee/customer/application/postgresql.properties per impostare il token seguente. Se il file non esiste, crealo:
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust
```
dove existing_standby_ip è l'indirizzo IP del server di standby Postgres attuale e new_standby_ip è l'indirizzo IP del nuovo nodo di standby.

Riavvia apigee-postgresql sul database PostgreSQL primario:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Verifica che il nuovo nodo in standby sia stato aggiunto visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul nodo primario. Dovresti vedere le seguenti righe nel file:
```
host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
```
Installa il nuovo server di standby Postgres:
1. Modifica il file di configurazione utilizzato per installare la versione attuale di Edge per specificare quanto segue:
```
# IP address of the current primary(master):
PG_MASTER=PG_MASTER_NODE_IP
# IP address of the new standby node
PG_STANDBY=PG_STANDBY_NODE_IP
```
2. Disattiva SELinux come descritto in Installa l'utilità apigee-setup di Edge.
3. Scarica ed esegui lo script di bootstrap in base alla tua versione attuale di Edge:
  - Se al momento utilizzi Edge 4.53.00:
    
    Scarica il file bootstrap_4.53.00.sh di Edge in /tmp/bootstrap_4.53.00.sh:
```
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
    Installa l'utilità Edge apigee-service e le dipendenze:
```
bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
  - Se al momento utilizzi Edge 4.53.01:
    
    Scarica il file Edge bootstrap_4.53.01.sh in /tmp/bootstrap_4.53.01.sh:
```
curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
```
    Installa l'utilità Edge apigee-service e le dipendenze:
```
bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord
```
4. Utilizza apigee-service per installare l'utilità apigee-setup:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
5. Installa Postgres:
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Sul nuovo nodo di standby, esegui questo comando e verifica che sia lo standby:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```

Esecuzione di un upgrade in loco di Postgres

Passaggio preliminare

Prima di eseguire un upgrade in loco a Postgres, segui questi passaggi sia sull'host principale che su quello in standby per aggiornare la proprietà max_locks_per_transaction su apigee-postgresql:

Se non è presente, crea il file /opt/apigee/customer/application/postgresql.properties .

Modifica la proprietà di questo file in apigee :

chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

Aggiungi la seguente proprietà al file:

conf/postgresql.conf+max_locks_per_transaction=30000

Configura apigee-postgresql :

apigee-service apigee-postgresql configure

Riavvia apigee-postgresql :

apigee-service apigee-postgresql restart

Esegui l'upgrade in loco

Per eseguire un upgrade in loco a Postgres 18, segui questi passaggi:

Esegui l'upgrade di Postgres sull'host principale

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Esegui il comando di configurazione sull'host principale:
```
apigee-service apigee-postgresql setup -f configFile
```
Esegui il comando di configurazione sull'host principale:
```
apigee-service apigee-postgresql configure
```

Riavvia l'host principale:

apigee-service apigee-postgresql restart

Configuralo come principale:

apigee-service apigee-postgresql setup-replication-on-master -f configFile

Assicurati che l'host primario sia stato avviato:
```
apigee-service apigee-postgresql wait_for_ready
```
Interrompi lo standby:
```
apigee-service apigee-postgresql stop
```
Esegui l'upgrade della modalità standby.

Nota:se questo passaggio genera errori o non va a buon fine, può essere ignorato. update.sh tenterà di avviare il server di standby con una configurazione errata. Se l'installazione di Postgres viene aggiornata alla versione 18, l'errore può essere ignorato.
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Assicurati che la modalità standby sia disattivata:
```
apigee-service apigee-postgresql stop
```
Rimuovi la vecchia configurazione di standby:
```
rm -rf /opt/apigee/data/apigee-postgresql/
```

Configura la replica sul server in standby:

apigee-service apigee-postgresql setup-replication-on-standby -f configFile

Rimuovi la riga conf/postgresql.conf+max_locks_per_transaction=30000 dal file /opt/apigee/customer/application/postgresql.properties sia sull'host principale che su quello in standby. Questa riga è stata aggiunta nel passaggio preliminare .

Dopo aver completato questa procedura, lo standby verrà avviato correttamente.

Disattivazione di un nodo Postgres

Al termine dell'aggiornamento, dismetti il nuovo nodo di standby:

Assicurati che Postgres sia in esecuzione:

/opt/apigee/apigee-service/bin/apigee-all status

Se Postgres non è in esecuzione, avvialo:

/opt/apigee/apigee-service/bin/apigee-all start

Recupera l'UUID del nuovo nodo in standby eseguendo il seguente comando curl sul nuovo nodo in standby:
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
Dovresti vedere l'UUID del nodo alla fine dell'output, nel formato:
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Arresta il nuovo nodo standby eseguendo questo comando sul nuovo nodo standby:
```
/opt/apigee/apigee-service/bin/apigee-all stop
```
Sul nodo principale Postgres, modifica /opt/apigee/customer/application/postgresql.properties per rimuovere il nuovo nodo in standby da conf_pg_hba_replication.connection:
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
```

Riavvia apigee-postgresql sul Postgres primario:

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

Verifica che il nuovo nodo di standby sia stato rimosso visualizzando il file /opt/apigee/apigee-postgresql/conf/pg_hba.conf sul nodo primario. In questo file dovresti vedere solo la seguente riga:
```
host replication apigee existing_standby_ip/32 trust
```
Elimina l'UUID del nodo di standby da ZooKeeper effettuando la seguente chiamata API di gestione Edge sul nodo del server di gestione:
```
curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid
```

Passaggi successivi all'upgrade per Postgres

Dopo un upgrade principale di Postgres, le statistiche interne di Postgres vengono cancellate. Queste statistiche aiutano il pianificatore di query Postgres a utilizzare gli indici e i percorsi più ottimali per eseguire le query.

PostgreSQL può ricostruire gradualmente le statistiche nel tempo man mano che le query vengono eseguite e quando viene eseguito il daemon autovacuum. Tuttavia, finché le statistiche non vengono ricostruite, le query potrebbero essere lente.

Per risolvere il problema, esegui ANALYZE su tutte le tabelle del database nel nodo Postgres principale. In alternativa, puoi eseguire ANALYZE per alcune tabelle alla volta.

Esegui l'upgrade a ZooKeeper 3.8.5

Questa release di Edge for Private Cloud include un upgrade a ZooKeeper 3.8.5. Nell'ambito di questo upgrade, tutti i dati di ZooKeeper verranno migrati a ZooKeeper 3.8.5.

Prima di eseguire l'upgrade di ZooKeeper, leggi la guida alla manutenzione di ZooKeeper. La maggior parte dei sistemi di produzione Edge utilizza un cluster di nodi ZooKeeper distribuiti su più data center. Alcuni di questi nodi sono configurati come votanti che partecipano all'elezione del leader di ZooKeeper, mentre gli altri sono configurati come osservatori. Per saperne di più, consulta la sezione Informazioni su leader, follower, votanti e osservatori. I nodi votanti eleggono un leader, dopodiché diventano follower.

Durante il processo di aggiornamento, potrebbe verificarsi un ritardo momentaneo o un errore di scrittura in ZooKeeper quando il nodo leader viene arrestato. Ciò potrebbe influire sulle operazioni di gestione che scrivono in ZooKeeper, come l'operazione di deployment di un proxy, e sulle modifiche all'infrastruttura Apigee, come l'aggiunta o la rimozione di un processore di messaggi e così via. Non dovrebbe esserci alcun impatto sulle API di runtime di Apigee (a meno che queste API di runtime non chiamino le API di gestione) durante l'upgrade di ZooKeeper seguendo la procedura riportata di seguito.

A livello generale, la procedura di upgrade prevede l'esecuzione di un backup di ogni nodo. Seguono l'upgrade di tutti gli osservatori e follower e, infine, l'upgrade del nodo leader.

Esegui un backup

Esegui un backup di tutti i nodi di ZooKeeper da utilizzare nel caso in cui sia necessario un rollback. Tieni presente che il rollback ripristinerà ZooKeeper allo stato in cui si trovava al momento del backup.

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

Se utilizzi macchine virtuali e hai la possibilità, puoi anche eseguire snapshot o backup delle VM per il ripristino o il rollback (se necessario).

Identifica leader, follower e osservatori

Se non è installato sul nodo ZooKeeper, installa nc:
```
yum install nc
```

Esegui questo comando nc sul nodo, dove 2181 è la porta ZooKeeper:

echo stat | nc localhost 2181

Dovresti vedere un output simile al seguente:

Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
Clients:
 /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 3/4.3333/6
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x500000005
Mode: follower

Nella riga Mode dell'output per i nodi, dovresti vedere observer, leader o follower (ovvero un votante che non è il leader) a seconda della configurazione del nodo.

Ripeti i passaggi 1 e 2 su ogni nodo ZooKeeper.

Esegui l'upgrade di ZooKeeper sui nodi observer e follower

Esegui l'upgrade di ZooKeeper su ciascuno dei nodi observer e follower come segue:

Scarica ed esegui il bootstrap di Edge per Private Cloud 4.54.00, come descritto in Aggiornamento alla versione 4.54.00 su un nodo con una connessione internet esterna . La procedura probabilmente varierà a seconda che il nodo abbia una connessione a internet esterna o che tu stia eseguendo un'installazione offline.
Esegui l'upgrade del componente ZooKeeper:
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file
```
Nota: se su questi nodi sono installati altri componenti (come Cassandra), puoi eseguire l'upgrade anche di questi (ad esempio con il profilo zk,cs) o puoi eseguire l'upgrade degli altri componenti in un secondo momento. Apigee consiglia di eseguire l'upgrade di ZooKeeper solo prima e di assicurarsi che il cluster funzioni correttamente prima di eseguire l'upgrade di altri componenti.
Ripeti i passaggi precedenti su ciascun nodo osservatore e follower di ZooKeeper.

Spegnere il leader

Una volta aggiornati tutti i nodi osservatore e follower, spegni il leader. Sul nodo identificato come leader, esegui il comando seguente:

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

Tieni presente che durante questo evento, prima dell'elezione di un nuovo leader, potrebbero verificarsi ritardi momentanei o errori di scrittura in ZooKeeper. Ciò potrebbe influire sulle operazioni che scrivono in ZooKeeper, come l'azione di deployment dei proxy o le modifiche all'infrastruttura Apigee, come l'aggiunta o la rimozione di processori di messaggi e così via.

Verifica che il nuovo leader sia stato eletto

Segui i passaggi descritti nella sezione Identificare il leader, i follower e gli osservatori riportata sopra per verificare che, una volta interrotta l'esecuzione del leader esistente, sia stato eletto un nuovo leader tra i follower. Tieni presente che il leader potrebbe essere stato eletto in un data center diverso da quello attuale.

Leader dell'upgrade

Segui gli stessi passaggi descritti in precedenza nella sezione Esegui l'upgrade di ZooKeeper sui nodi osservatore e follower.

Una volta eseguito l'upgrade anche del vecchio nodo leader, verifica l'integrità del cluster e assicurati che sia presente un nodo leader.

Esegui l'upgrade a Cassandra 5.0.8

Apigee Edge for Private Cloud 4.54.00 include un upgrade di Cassandra alla versione 5.0.8.

Upgrade e rollback

L'upgrade da Cassandra 4.0.X a Cassandra 5.0.X è un processo in sequenza.
Il rollback diretto in loco da Cassandra 5.0.X a 4.0.X non è possibile. Il rollback utilizzando repliche o backup è una procedura complessa e potrebbe comportare tempi di inattività e/o perdita di dati. È preferibile risolvere i problemi ed eseguire l'upgrade a Cassandra 5.0.X anziché eseguire il rollback.
È importante acquisire familiarità con le procedure di rollback prima di tentare l'upgrade. Considerare le sfumature del rollback durante l'upgrade è fondamentale per garantire la disponibilità di percorsi di rollback appropriati.

Singolo data center

L'upgrade di Cassandra dalla versione 4.0.X alla 5.0.X all'interno di un singolo data center è semplice, ma il rollback è complesso e potrebbe comportare tempi di inattività e perdita di dati. Per i carichi di lavoro di produzione, è vivamente consigliabile aggiungere un nuovo data center con almeno nodi Cassandra disponibili nel nuovo data center prima di avviare l'upgrade. In questo modo, potrai eseguire il rollback di Cassandra senza incorrere in perdite di dati o interruzioni del traffico API. Questo data center aggiuntivo può essere ritirato al termine dell'upgrade.

Se l'aggiunta di un nuovo data center non è fattibile, ma la funzionalità di rollback è comunque desiderata, i backup saranno necessari per il ripristino di Cassandra 4.0.X. Tuttavia, questo metodo probabilmente comporterà sia tempi di inattività sia perdita di dati.

Più data center

La gestione di più data center con Edge for Private Cloud 4.53.00 (o) 4.53.01 offre maggiore flessibilità per i rollback durante l'upgrade a Edge for Private Cloud 4.54.00.

I rollback richiedono almeno un data center che esegua la versione precedente di Cassandra (4.0.X).

Metodologia di upgrade consigliata

Esegui l'upgrade di un data center Cassandra alla volta: inizia eseguendo l'upgrade dei nodi Cassandra singolarmente all'interno di un singolo data center. Completa gli upgrade di tutti i nodi Cassandra in un data center prima di procedere con il successivo.
Metti in pausa e convalida: dopo aver eseguito l'upgrade di un data center, metti in pausa per assicurarti che il cluster Private Cloud, in particolare il data center di cui è stato eseguito l'upgrade, funzioni correttamente.
Ricorda: puoi eseguire il rollback alla versione precedente di Cassandra solo se hai almeno un data center che esegue ancora la versione precedente.
Sensibile al fattore tempo: anche se puoi mettere in pausa per un breve periodo (si consiglia qualche ora) per convalidare la funzionalità, non puoi rimanere in uno stato di versioni miste a tempo indeterminato. Questo perché un cluster Cassandra non uniforme (con nodi su versioni diverse) presenta limitazioni operative.
Test approfonditi: Apigee consiglia vivamente di eseguire test completi delle prestazioni e della funzionalità prima di eseguire l'upgrade del data center successivo. Una volta eseguito l'upgrade di tutti i data center, non è possibile eseguire il rollback alla versione precedente.

Processo di checkpoint del rollback

Punto di controllo di rollback singolo: quando viene eseguito l'upgrade di tutti i componenti alla versione 4.54.00, il rollback di Cassandra rimane possibile solo se almeno un data center Cassandra continua a eseguire la versione precedente. Una volta eseguito l'upgrade del data center Cassandra finale, l'upgrade a Edge for Private Cloud 4.54.00 è completo e il rollback non è più possibile.

Esempio

Considera un cluster con due data center (DC):

Stato iniziale:i nodi Cassandra in entrambi i data center utilizzano la versione 4.0.X. Tutti gli altri nodi sono su Edge for Private Cloud versione 4.54.00. Supponi tre nodi Cassandra per DC.
Esegui l'upgrade di DC-1: esegui l'upgrade dei tre nodi Cassandra in DC-1 uno alla volta.
Metti in pausa e convalida: metti in pausa per assicurarti che il cluster, in particolare DC-1, funzioni correttamente (controlla le prestazioni e la funzionalità). Puoi eseguire il rollback allo stato iniziale utilizzando i nodi Cassandra in DC-2. Ricorda che questa pausa deve essere temporanea a causa delle limitazioni di un cluster Cassandra con versioni miste.
Esegui l'upgrade di DC-2: esegui l'upgrade dei restanti tre nodi Cassandra in DC-2. Una volta eseguito l'upgrade di tutti i nodi Cassandra in DC-2, l'upgrade di Edge for Private Cloud 4.54.00 è completato.

Prerequisiti per l'upgrade di Cassandra

Devi eseguire Cassandra 4.0.X con Edge per Private Cloud 4.53.00 (o) 4.53.01 e assicurarti che:

Imposta Java 17 come versione Java predefinita sul server: Cassandra 5.0.X rimuove il supporto di Java 8. Non puoi eseguire Cassandra 5.0.X o la sua utilità nodetool con Java 8. Assicurati che Java 17 sia installato su ogni nodo Cassandra e impostalo come versione Java predefinita prima di eseguire i passaggi di upgrade di Cassandra, in modo che i comandi nodetool vengano eseguiti con Java 17:
```
alternatives --set java JAVA_17_PATH/bin/java
```
Verifica che la versione Java predefinita attiva sia Java 17:
```
java -version
```
L'intero cluster è operativo e perfettamente funzionante con Cassandra 4.0.X.
La strategia di compattazione è impostata su LeveledCompactionStrategy (un prerequisito per l'upgrade alla versione 4.53.00 o 4.53.01).
Verifica che ogni passaggio riportato di seguito sia stato completato nell'ambito dell'upgrade iniziale di Cassandra 4.0.X in Edge for Private Cloud 4.53.00 (o) 4.53.01.
- Il comando post_upgrade è stato eseguito su ogni nodo Cassandra durante l'upgrade precedente
- Il comando drop_old_tables è stato eseguito sull'intero cluster Cassandra durante l'upgrade precedente.

Se non hai la certezza che i comandi post_upgrade e drop_old_tables siano stati eseguiti su Cassandra 4.0.X durante l'utilizzo di Edge for Private Cloud 4.53.00 (o) 4.53.01, puoi eseguirli nuovamente in sicurezza prima di tentare l'upgrade alla versione 4.54.00.

Passaggio 1: preparati per l'upgrade

I passaggi riportati di seguito si aggiungono ai file standard che in genere crei, ad esempio il file di configurazione standard di Apigee per abilitare gli upgrade dei componenti.

Esegui il backup di Cassandra utilizzando Apigee.
Acquisisci snapshot delle VM dei nodi Cassandra (se possibile).
Se non è già configurata, assicurati che la porta 9042 sia accessibile da tutti i componenti di Edge for Private Cloud, inclusi Management Server, processore di messaggi, Router, Qpid e Postgres, ai nodi Cassandra. Per saperne di più, consulta i requisiti relativi alle porte.

Passaggio 2: esegui l'upgrade di tutti i nodi Cassandra

Tutti i nodi Cassandra devono essere aggiornati uno alla volta in ogni data center, un data center alla volta. Tra gli upgrade dei nodi all'interno di un data center, attendi qualche minuto per assicurarti che un nodo aggiornato sia stato avviato completamente e si sia unito al cluster prima di procedere con l'upgrade di un altro nodo nello stesso data center.

Dopo aver eseguito l'upgrade di tutti i nodi Cassandra all'interno di un data center, attendi un po' di tempo (da 30 minuti a qualche ora) prima di procedere con i nodi nel data center successivo. Durante questo periodo, esamina attentamente il data center aggiornato e assicurati che le metriche funzionali e di rendimento del tuo cluster Apigee siano intatte. Questo passaggio è fondamentale per garantire la stabilità del data center in cui è stato eseguito l'upgrade di Cassandra alla versione 5.0.X, mentre è stato eseguito l'upgrade degli altri componenti Apigee alla versione 4.54.00.

Per eseguire l'upgrade di un nodo Cassandra, esegui questo comando:
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
Una volta aggiornato un nodo, esegui questo comando sul nodo per eseguire alcune convalide prima di procedere:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```

Il comando precedente genererà un output simile al seguente:

Cassandra version is verified - [cqlsh 6.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
Metadata is verified

Esegui il seguente comando post_upgrade sul nodo Cassandra:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

Esegui il seguente comando cleanup_old_index sul nodo Cassandra:

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

Esegui i seguenti comandi nodetool per ricostruire gli indici sul nodo Cassandra:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx    
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx

Se utilizzi la monetizzazione, esegui anche i seguenti comandi di ricostruzione degli indici relativi ai keyspace di monetizzazione:

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

Esegui l'aggiornamento con Apigee mTLS

Per aggiornare Apigee mTLS , segui questi passaggi:

Rollback di un aggiornamento

In caso di errore di aggiornamento, puoi provare a correggere il problema e poi eseguire nuovamente update.sh. Puoi eseguire l'aggiornamento più volte e l'operazione continuerà dall'ultimo punto in cui è stata interrotta.

Se l'errore richiede di eseguire il rollback dell'aggiornamento alla versione precedente, consulta Eseguire il rollback della versione 4.54.00 per istruzioni dettagliate.

Informazioni sull'aggiornamento del logging

Per impostazione predefinita, l'utilità update.sh scrive le informazioni di log in:

/opt/apigee/var/log/apigee-setup/update.log

Se la persona che esegue l'utilità update.sh non ha accesso a questa directory, il log viene scritto nella directory /tmp come file denominato update_username.log.

Se la persona non ha accesso a /tmp, l'utilità update.sh non va a buon fine.

Aggiornamento senza tempi di inattività

Un aggiornamento senza tempi di inattività o un aggiornamento in sequenza ti consente di aggiornare l'installazione di Edge senza arrestare Edge.

L'aggiornamento senza tempi di inattività è possibile solo con una configurazione a 5 nodi o più.

La chiave per l'upgrade senza tempi di inattività è rimuovere ogni router, uno alla volta, dal bilanciatore del carico. Quindi, aggiorna il router e tutti gli altri componenti sulla stessa macchina del router, quindi aggiungi nuovamente il router al bilanciatore del carico.

Aggiorna le macchine nell'ordine corretto per l'installazione, come descritto in Ordine di aggiornamento delle macchine .
Quando è il momento di aggiornare i router, seleziona un router e rendilo non raggiungibile, come descritto in Attivazione/disattivazione della raggiungibilità del server (processore di messaggi/router) .
Aggiorna il router selezionato e tutti gli altri componenti Edge sulla stessa macchina del router. Tutte le configurazioni Edge mostrano un router e un processore di messaggi sullo stesso nodo.
Rendi di nuovo raggiungibile il router.
Ripeti i passaggi da 2 a 4 per i router rimanenti.
Continua l'aggiornamento per le macchine rimanenti nell'installazione.

Prima e dopo l'aggiornamento, tieni presente quanto segue:

Sul nodo combinato Router e processore di messaggi:
- Prima dell'aggiornamento, esegui queste operazioni:
  1. Rendi il router non raggiungibile.
  2. Rendi irraggiungibile il processore di messaggi.
- Dopo l'aggiornamento, procedi come segue:
  1. Rendi raggiungibile il processore di messaggi.
  2. Rendere raggiungibile il router.
Sui nodi del router singolo:
- Prima dell'aggiornamento, rendi il router non raggiungibile.
- Dopo l'aggiornamento, rendi raggiungibile il router.
Sui singoli nodi Processore di messaggi:
- Prima dell'aggiornamento, rendi irraggiungibile il processore di messaggi.
- Dopo l'aggiornamento, rendi raggiungibile il processore di messaggi.

Utilizzare un file di configurazione automatica

Devi trasmettere un file di configurazione silenziosa al comando di aggiornamento. Sebbene il file di configurazione silenziosa sia per lo più simile a quello utilizzato per installare Edge for Private Cloud 4.53.00 o 4.53.01, potrebbe essere necessario apportare modifiche per componenti come l'interfaccia utente e l'SSO, come descritto in Esegui l'upgrade alla nuova UI di Edge e all'SSO Apigee (se installato).

Aggiorna alla versione 4.54.00 su un nodo con una connessione a internet esterna

Utilizza la seguente procedura per aggiornare i componenti Edge su un nodo:

Se presenti, disattiva tutti i job cron configurati per eseguire un'operazione di riparazione su Cassandra fino al completamento dell'aggiornamento.
Accedi al nodo come root per installare gli RPM di Edge.

Nota: mentre l'installazione RPM richiede l'accesso root, puoi eseguire la configurazione di Edge senza l'accesso root.
Disattiva SELinux come descritto in Installa l'utilità apigee-setup di Edge .

Se l'installazione avviene su AWS , esegui i seguenti comandi yum-configure-manager:

yum update rh-amazon-rhui-client.noarch
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Se attualmente utilizzi Edge for Private Cloud 4.53.00 o 4.53.01:
1. Scarica il file bootstrap_4.54.00.sh di Edge in /tmp/bootstrap_4.54.00.sh :
```
curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
2. Installa l'utilità Edge 4.54.00 apigee-service e le dipendenze eseguendo questo comando:
```
bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord
```
  Dove uName:pWord sono il nome utente e la password che hai ricevuto da Apigee. Se ometti pWord, ti verrà chiesto di inserirlo.
  
  Per impostazione predefinita, il programma di installazione verifica che siano installate le versioni Java 17 e 21.
3. Utilizza apigee-service per aggiornare l'utilità apigee-setup, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. Aggiorna l'utilità apigee-validate sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. Aggiorna l'utilità apigee-provision sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. Esegui l'utilità update sui tuoi nodi utilizzando il seguente comando:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  Segui l'ordine descritto in Ordine di aggiornamento delle macchine.
  
  Dove:
  - component è il componente Edge da aggiornare. I valori possibili sono:
    - edge : tutti i componenti Edge ad eccezione della nuova UI Edge: server di gestione, processore di messaggi, router, server QPID, server Postgres
    - ldap : OpenLDAP
    - ue : nuova UI di Edge
    - qpid : Apigee Qpid
    - ps : Apigee Postgresql
    - zk : ZooKeeper
    - cs : Cassandra
  - configFile è lo stesso file di configurazione che hai utilizzato per definire i componenti Edge durante l'installazione della versione 4.53.00 o 4.53.01.
  Nota: il file di configurazione deve essere leggibile dall'utente "apigee". Per cambiare il proprietario, utilizza il seguente comando:
```
chown apigee:apigee configFile
```
  Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione all-in-one (AIO) di Edge. Ad esempio:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
7. Se non l'hai ancora fatto, riavvia i componenti della nuova UI Edge su tutti i nodi su cui sono in esecuzione:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
8. Testa l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Testare l'installazione.

Se in un secondo momento decidi di eseguire il rollback dell'aggiornamento, utilizza la procedura descritta in Esegui il rollback della versione 4.54.00.

Esegui l'aggiornamento alla versione 4.54.00 da un repository locale

Se i nodi Edge si trovano dietro un firewall o se in qualche altro modo non possono accedere al repository Apigee tramite internet, puoi eseguire l'aggiornamento da un repository locale o da un mirror del repository Apigee.

Dopo aver creato un repository Edge locale, hai due opzioni per aggiornare Edge dal repository locale:

Crea un file .tar del repository, copia il file .tar in un nodo, quindi aggiorna Edge dal file .tar.
Installa un web server sul nodo con il repository locale in modo che gli altri nodi possano accedervi. Apigee fornisce il server web Nginx, ma puoi anche utilizzare il tuo server web.

Per eseguire l'aggiornamento da un repository 4.54.00 locale:

Crea un repository 4.54.00 locale come descritto in "Crea un repository Apigee locale" in Installa l'utilità apigee-setup di Edge.

Nota:se hai già un repository esistente, puoi aggiungervi il repository 4.54.00 come descritto in "Aggiornare un repository Apigee locale" in Installare l'utilità apigee-setup di Edge.
Installa apigee-service sui nodi di destinazione utilizzando uno dei seguenti metodi:
- Opzione 1: installa apigee-service da un file .tar
  1. Sul nodo con il repository locale, utilizza il seguente comando per creare il pacchetto del repository locale in un unico file .tar denominato /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
  2. Copia il file .tar nel nodo in cui vuoi aggiornare Edge. Ad esempio, copialo nella directory /tmp del nuovo nodo.
  3. Sul nuovo nodo, decomprimi il file nella directory /tmp:
```
tar -xzf apigee-4.54.00.tar.gz
```
    Questo comando crea una nuova directory, denominata repos, nella directory contenente il file .tar. Ad esempio /tmp/repos.
  4. Installa l'utilità Edge apigee-service e le dipendenze da /tmp/repos:
```
bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
    Tieni presente che in questo comando includi il percorso della directory dei repository.
- Opzione 2: installa apigee-service utilizzando il server web Nginx
  1. Configura il server web Nginx come descritto in "Installa dal repository utilizzando il server web Nginx" in Installa l'utilità apigee-setup di Edge.
  2. Sul nodo remoto, scarica il file Edge bootstrap_4.54.00.sh in /tmp/bootstrap_4.54.00.sh:
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
    Dove uName:pWord sono il nome utente e la password impostati in precedenza per il repository e remoteRepo è l'indirizzo IP o il nome DNS del nodo del repository.
  3. Sul nodo remoto, installa l'utilità Edge apigee-service e le dipendenze:
```
bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
    Dove uName:pWord sono il nome utente e la password del repository.
Utilizza apigee-service per aggiornare l'utilità apigee-setup, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
Aggiorna l'utilità apigee-validate sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Aggiorna l'utilità apigee-provision sul server di gestione, come mostrato nell'esempio seguente:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
Esegui l'utilità update sui nodi nell'ordine descritto in Ordine di aggiornamento della macchina:
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Dove:
- component è il componente Edge da aggiornare. I valori possibili sono:
  - edge : tutti i componenti Edge ad eccezione della nuova UI Edge: server di gestione, processore di messaggi, router, server QPID, server Postgres
  - ldap : OpenLDAP
  - ue : nuova UI di Edge
  - qpid : Apigee Qpid
  - ps : Apigee Postgresql
  - zk : ZooKeeper
  - cs : Cassandra
- configFile è lo stesso file di configurazione che hai utilizzato per definire i componenti Edge durante l'installazione della versione 4.53.00 (o) 4.53.01.
  
  Nota:il file di configurazione deve essere leggibile dall'utente "apigee". Per cambiare il proprietario, utilizza il seguente comando:
```
chown apigee:apigee configFile
```
Puoi eseguire update.sh su tutti i componenti impostando component su "all", ma solo se hai un profilo di installazione all-in-one (AIO) di Edge. Ad esempio:
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
Se non l'hai ancora fatto, riavvia i componenti della UI su tutti i nodi in cui è in esecuzione:
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
Testa l'aggiornamento eseguendo l'utilità apigee-validate sul server di gestione, come descritto in Testare l'installazione.

Se in un secondo momento decidi di eseguire il rollback dell'aggiornamento, utilizza la procedura descritta in Esegui il rollback della versione 4.54.00.

Ordine di aggiornamento della macchina

L'ordine in cui aggiorni le macchine in un'installazione di Edge è importante. Esegui l'upgrade dei componenti nella sequenza riportata di seguito.

Esegui l'upgrade di tutti i nodi Router e processore di messaggi in tutti i data center utilizzando l'opzione -c edge.
Esegui l'upgrade di tutti i nodi del server di gestione in tutti i data center utilizzando l'opzione -c edge.
Esegui l'upgrade di tutti i nodi LDAP in tutti i data center. Se esegui l'upgrade da Edge for Private Cloud 4.53.00, dovrai seguire ulteriori passaggi per i passaggi speciali dell'upgrade LDAP
Esegui l'upgrade della UI e del Single Sign-On Apigee (se installato) in tutti i data center:
1. Se apigee-sso non è installato: segui l'Opzione 1: esegui l'upgrade della UI (senza SSO Apigee) per eseguire l'upgrade alla nuova UI Edge.
2. Se apigee-sso è installato: segui l'Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per eseguire l'upgrade alla nuova UI Edge e a SSO Apigee.
Esegui l'upgrade di tutti i componenti Qpid ed edge-qpid-server in tutti i data center seguendo i passaggi speciali di Qpid.
Esegui l'upgrade di tutti i componenti Postgresql e edge-postgres-server in tutti i data center seguendo i passaggi speciali di Postgres
Esegui l'upgrade di tutti i componenti ZooKeeper in tutti i data center seguendo i passaggi speciali per l'upgrade di ZooKeeper.
Esegui l'upgrade di tutti i componenti Cassandra in tutti i data center seguendo i passaggi speciali dell'upgrade di Cassandra.
Non è previsto un passaggio separato per l'aggiornamento della monetizzazione. Viene aggiornato quando specifichi l'opzione -c edge.

Upgrade autonomo a 1 nodo

Per eseguire l'upgrade di una configurazione autonoma a 1 nodo alla versione 4.54.00:

Quando esegui l'upgrade da Edge for Private Cloud 4.53.00, devi prima eseguire l'upgrade di LDAP seguendo i passaggi per eseguire l'upgrade dalla versione 4.53.00 alla versione 4.54.00 prima di avviare l'upgrade di tutti i componenti.

Aggiorna tutti i componenti:

/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade autonomo di 2 nodi

Aggiorna i seguenti componenti per un'installazione autonoma a 2 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

Aggiorna i componenti Edge sulla macchina 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna LDAP sulla macchina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Aggiorna la nuova UI di Edge sulla macchina 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Nota: se apigee-sso è installato, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni su come configurarlo per SSO Apigee.

Aggiorna i componenti Edge sulla macchina 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna Qpid sulla macchina 2:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Aggiorna Postgres sulla macchina 2:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Cassandra e ZooKeeper sulla macchina 1:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sulla macchina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade di 5 nodi

Aggiorna i seguenti componenti per un'installazione a 5 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

Aggiorna i componenti Edge sulle macchine 2, 3, 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna LDAP sulla macchina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Aggiorna la nuova UI di Edge sul computer 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Nota:se è installato apigee-sso, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni sulla configurazione di SSO Apigee.

Aggiorna i componenti Edge sulla macchina 4, 5:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna Qpid sulla macchina 4, 5:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Aggiorna Postgres sulle macchine 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sulla macchina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade di un cluster di 9 nodi

Aggiorna i seguenti componenti per un'installazione in cluster di 9 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

Aggiorna i componenti Edge sulle macchine 4, 5 e 1 (router, processore di messaggi e server di gestione) in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna LDAP sulla macchina 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Aggiorna la nuova UI Edge nella macchina 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Nota:se è installato apigee-sso, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni sulla configurazione di SSO Apigee.
Aggiorna i componenti Edge sulle macchine 6, 7, 8 e 9 in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna Qpid sulle macchine 6 e 7:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Aggiorna Postgres sulla macchina 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Postgres sulla macchina 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sulla macchina 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade di un cluster di 13 nodi

Aggiorna i seguenti componenti per un'installazione in cluster con 13 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

Aggiorna i componenti Edge sulle macchine 10, 11, 6 e 7 in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna LDAP sulle macchine 4 e 5:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Aggiorna la nuova UI Edge nelle macchine 6 e 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Nota: se apigee-sso è installato, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni su come configurarlo per SSO Apigee.
Aggiorna i componenti Edge sulle macchine 12, 13, 8 e 9 in questo ordine:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna Qpid sulle macchine 12 e 13:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Aggiorna Postgres sulla macchina 8:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Postgres sulla macchina 9:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Cassandra e ZooKeeper sulle macchine 1, 2 e 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi sulle macchine 6 e 7:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Upgrade di un cluster di 12 nodi

Aggiorna i seguenti componenti per un'installazione in cluster con 12 nodi:

Consulta Topologie di installazione per l'elenco delle topologie Edge e dei numeri di nodi.

Aggiorna i componenti Edge (router e processore di messaggi):
- Sulle macchine 2 e 3 nel data center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- Sulle macchine 8 e 9 nel data center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Aggiorna i componenti Edge (Management Server):

Sulla macchina 1 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Sulla macchina 7 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna LDAP:

Macchina 1 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Macchina 7 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

Aggiorna i componenti della nuova UI di Edge:
- Sulla macchina 1 nel data center 1:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Nota: se apigee-sso è installato, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni su come configurarlo per SSO Apigee.
- Sulla macchina 7 nel data center 2:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Nota: se apigee-sso è installato, consulta Opzione 2: esegui l'upgrade della UI (con SSO Apigee) per istruzioni su come configurarlo per SSO Apigee.

Aggiorna i componenti Edge:

Macchine 4, 5, 6 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Macchine 10, 11, 12 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

Aggiorna qpidd:

Macchine 4 e 5 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Macchine 10 e 11 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Aggiorna Postgres:

Macchina 6 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Macchina 12 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Aggiorna Cassandra e ZooKeeper:

Macchine 1, 2 e 3 nel data center 1:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

Sulle macchine 7, 8 e 9 nel data center 2:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(Se hai installato apigee-adminapi) Aggiorna l'utilità apigee-adminapi:

Macchina 1 nel data center 1:

/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Macchina 7 nel data center 2:

/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Per una configurazione non standard

Se hai una configurazione non standard, aggiorna i componenti Edge nel seguente ordine:

Router
processore di messaggi
Server di gestione
LDAP
UI (UI classica o nuova UI)
SSO (se applicabile)
Qpid ed edge-qpid-server
Postgres e edge-postgres-server
ZooKeeper
Cassandra
apigee-adminapi

Aggiorna Apigee Edge 4.53.00 o 4.53.01 alla versione 4.54.00

Chi può eseguire l'aggiornamento

Quali componenti devi aggiornare

Materiali da leggere in anticipo

Prerequisiti per l'upgrade

Propagazione automatica delle impostazioni della proprietà

Esegui l'upgrade del router e del processore dei messaggi

Esegui l'upgrade del server di gestione

Esegui l'upgrade a OpenLDAP 2.6.10

Preparazione e installazione (tutti i server LDAP)

Passaggi per eseguire l'upgrade di LDAP dalla versione 4.53.00 alla versione 4.54.00

Prerequisiti e considerazioni

Passaggi per eseguire l'upgrade di LDAP dalla versione 4.53.01 alla versione 4.54.00

Esegui l'upgrade alla nuova UI Edge e all'SSO Apigee (se installato)

Opzione 1: esegui l'upgrade della UI (senza SSO Apigee)

Passaggio 1: esegui il backup dei file di configurazione

Passaggio 2: aggiorna il file di configurazione invisibile per l'autenticazione di base

Passaggio 3: esegui l'upgrade del componente UI

Passaggio 4: verifica l'upgrade della nuova UI di Edge

Opzione 2: esegui l'upgrade della UI (con SSO Apigee)

Passaggio 1: esegui il backup dei file di configurazione

Passaggio 2: rimuovi le variabili UI/SSO ritirate e aggiorna il file di configurazione invisibile (configFile)

Passaggio 3: esegui l'upgrade del componente della nuova UI di Edge

Passaggio 4: interrompi apigee-sso

Passaggio 5: crea il database apigee_dex per SSO Apigee nel nodo Postgres

Passaggio 6: configura l'SSO Apigee sui nodi OpenLDAP

Passaggio 7: configura la UI di gestione per Apigee SSO e riavvia la UI

Passaggio 8: verifica l'upgrade della nuova UI di Edge e dell'SSO Apigee

Passaggio 9: disinstalla la versione precedente di apigee-sso

Esegui l'upgrade a Qpid 10.0.1

Esegui l'upgrade a Postgres 18.6

Installazione di un nuovo nodo standby Postgres

Esecuzione di un upgrade in loco di Postgres

Passaggio preliminare

Esegui l'upgrade in loco

Disattivazione di un nodo Postgres

Passaggi successivi all'upgrade per Postgres

Esegui l'upgrade a ZooKeeper 3.8.5

Esegui un backup

Identifica leader, follower e osservatori

Esegui l'upgrade di ZooKeeper sui nodi observer e follower

Spegnere il leader

Verifica che il nuovo leader sia stato eletto

Leader dell'upgrade

Esegui l'upgrade a Cassandra 5.0.8

Upgrade e rollback

Singolo data center

Più data center

Metodologia di upgrade consigliata

Processo di checkpoint del rollback

Esempio

Prerequisiti per l'upgrade di Cassandra

Passaggio 1: preparati per l'upgrade

Passaggio 2: esegui l'upgrade di tutti i nodi Cassandra

Esegui l'aggiornamento con Apigee mTLS

Rollback di un aggiornamento

Informazioni sull'aggiornamento del logging

Aggiornamento senza tempi di inattività

Utilizzare un file di configurazione automatica

Aggiorna alla versione 4.54.00 su un nodo con una connessione a internet esterna

Esegui l'aggiornamento alla versione 4.54.00 da un repository locale

Ordine di aggiornamento della macchina

Upgrade autonomo a 1 nodo

Upgrade autonomo di 2 nodi

Upgrade di 5 nodi

Upgrade di un cluster di 9 nodi

Upgrade di un cluster di 13 nodi

Upgrade di un cluster di 12 nodi

Per una configurazione non standard

Passaggio 2: rimuovi le variabili UI/SSO ritirate e aggiorna il file di configurazione invisibile (`configFile`)

Passaggio 4: interrompi `apigee-sso`

Passaggio 5: crea il database `apigee_dex` per SSO Apigee nel nodo Postgres

Passaggio 9: disinstalla la versione precedente di `apigee-sso`