Google utilise la technologie IA pour traduire le contenu dans votre langue préférée. Les traductions générées par IA peuvent contenir des erreurs.

Mettre à jour Apigee Edge 4.53.00 ou 4.53.01 vers la version 4.54.00

Apigee permet de mettre à niveau Edge for Private Cloud directement de la version 4.53.00 ou 4.53.01 vers la version 4.54.00. Cette page explique comment effectuer ces mises à niveau.

Pour obtenir un aperçu des chemins de mise à niveau compatibles, consultez la matrice de compatibilité des mises à niveau pour les versions d'Edge for Private Cloud.

Qui peut effectuer la mise à jour ?

La personne qui exécute la mise à jour doit être la même que celle qui a installé Edge à l'origine, ou une personne qui exécute la mise à jour en tant que root.

Une fois les RPM Edge installés, tout le monde peut les configurer.

Quels composants devez-vous mettre à jour

Vous devez mettre à jour tous les composants Edge. Edge n'est pas compatible avec une configuration contenant des composants de plusieurs versions.

Lectures préparatoires

Consultez les rubriques suivantes pour obtenir des informations importantes sur les modifications apportées à Edge pour Private Cloud 4.54.00 :

Modifications apportées à la version 4.54.00 : consultez les modifications apportées à TLS et à l'appel Java qui nécessitent une préparation avant la mise à niveau. Pour en savoir plus, consultez Modifications apportées à la version 4.54.00.
Architecture d'exécution Dual-Java (Java 17 et Java 21) : à partir de la version 4.54.00, Edge for Private Cloud ne prend plus en charge Java 8 et exécute les composants sur Java 17 ou Java 21. Pour en savoir plus, consultez Modifications apportées à la version 4.54.00.
Pas d'installation automatique de Java lors de l'amorçage : Edge for Private Cloud 4.54.00 peut détecter les installations Java et valide que Java 17 et Java 21 sont installés.
Nouvelle interface utilisateur Edge dans la version 4.54.00 : découvrez la transition vers la nouvelle interface utilisateur Edge en tant qu'interface de gestion par défaut et la suppression de l'interface utilisateur classique (edge-ui). Pour en savoir plus, consultez Nouvelle interface utilisateur Edge.
Apigee SSO dans la version 4.54.00 : découvrez l'architecture SSO mise à jour et les modifications de configuration pour l'authentification. Pour en savoir plus, consultez Apigee SSO.
Nginx 1.30 dans la version 4.54.00 : découvrez la mise à niveau automatique vers Nginx 1.30.x sur les routeurs Edge, les impacts potentiels sur l'exécution et les mesures d'atténuation. Pour en savoir plus, consultez Modifications apportées à Nginx 1.30.

Conditions préalables à la mise à niveau

Avant de mettre à niveau Apigee Edge, assurez-vous de remplir les conditions préalables suivantes :

Consulter les notes de version et les nouvelles fonctionnalités

Assurez-vous d'examiner et de comprendre toutes les nouvelles fonctionnalités, les changements de comportement et les suppressions détaillés dans les notes de version d'Edge for Private Cloud pour la version 4.54.00 avant de lancer le processus de mise à niveau.
Détection automatique et coexistence des binaires Java lors de la mise à niveau : installez Java à l'aide de gestionnaires de packages standards (comme yum) ou d'emplacements standards (comme /usr/lib/jvm ou update-alternatives). Vous n'avez pas besoin de configurer les deux versions sur le PATH du système simultanément. Ne désinstallez pas Java 8 avant la mise à niveau. Conservez Java 8 installé aux côtés de Java 17 et Java 21 pour que les services Edge for Private Cloud 4.53.xx existants continuent de s'exécuter sans interruption jusqu'à ce qu'ils soient mis à jour.
Sauvegarder tous les nœuds

Avant d'effectuer la mise à jour, nous vous recommandons de sauvegarder complètement tous les nœuds pour des raisons de sécurité. Utilisez la procédure correspondant à votre version actuelle d'Edge pour effectuer la sauvegarde. Cela vous permet de disposer d'un plan de secours au cas où la mise à jour vers une nouvelle version ne fonctionnerait pas correctement. Pour en savoir plus sur la sauvegarde, consultez Sauvegarde et restauration.
Sauvegarde du fichier de configuration silencieux

Assurez-vous de conserver des copies de sauvegarde des fichiers de configuration silencieuse pour Edge pour Private Cloud 4.53.00 ou 4.53.01 afin de faciliter une restauration si nécessaire.
Assurez-vous qu'Edge est en cours d'exécution.

Assurez-vous qu'Edge est opérationnel pendant le processus de mise à jour à l'aide de la commande suivante :
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Vérifier les prérequis de Cassandra

Si vous avez déjà effectué une mise à niveau d'une ancienne version d'Edge for Private Cloud vers la version 4.53.00 (ou 4.53.01) et que vous prévoyez maintenant de passer à la version 4.54.00, assurez-vous d'avoir effectué les étapes post-mise à niveau requises pour Cassandra. Ces étapes sont décrites dans la documentation de mise à niveau vers la version 4.53.00 (ou) 4.53.01, ainsi que dans la section Prérequis pour la mise à niveau de Cassandra. Si vous n'êtes pas sûr que ces étapes ont été effectuées lors de la mise à niveau précédente, effectuez-les à nouveau avant de procéder à la mise à niveau vers la version 4.54.00.
Arrêter apigee-monit : si apigee-monit est en cours d'exécution sur le nœud, arrêtez-le avec /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop avant la mise à niveau. Cela empêche apigee-monit de redémarrer automatiquement les composants pendant leur mise à niveau. Réactivez-le avec apigee-service apigee-monit start une fois la mise à niveau terminée.

Propagation automatique des paramètres de propriété

Si vous avez défini des propriétés en modifiant des fichiers .properties dans /opt/apigee/customer/application, ces valeurs sont conservées par la mise à jour.

Mettre à niveau le routeur et le processeur de messages

Mettez à niveau tous les nœuds de routeur et de processeur de messages dans les centres de données, un par un :

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

Mettre à niveau le serveur de gestion

Mettez à niveau tous les nœuds du serveur de gestion dans les centres de données, un par un :

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

Mise à niveau vers OpenLDAP 2.6.10

Edge for Private Cloud 4.54.00 introduit OpenLDAP 2.6.10. Cette mise à niveau s'applique à toutes les topologies de déploiement Apigee OpenLDAP : serveur unique, actif-passif et actif-actif (multimaître).

Préparation et installation (tous les serveurs LDAP)

Étapes à suivre pour mettre à niveau LDAP de la version 4.53.00 vers la version 4.54.00

Conditions préalables et points à prendre en compte

Sachez que pendant le processus de migration d'OpenLDAP 2.4 vers 2.6.10 (lors de la mise à niveau depuis la version 4.53.00), les API de gestion et, par conséquent, l'interface utilisateur d'Apigee ne seront pas disponibles dans toutes les régions. Toutes les tâches administratives (gestion des utilisateurs, des rôles, des applications et des organisations, par exemple) échoueront et devront être mises en pause. Le traitement du trafic de votre proxy d'API n'est pas affecté. Arrêtez toutes les instances edge-management-server et edge-ui avant de procéder à la migration LDAP.
La sauvegarde est essentielle (lors de la mise à niveau à partir de la version 4.53.00) : lors de la mise à niveau à partir d'Edge for Private Cloud 4.53.00 (OpenLDAP 2.4.46), une sauvegarde complète et validée de vos données LDAP existantes est obligatoire. Si vous continuez sans sauvegarde valide, vous perdrez définitivement vos données. Lancez la sauvegarde pendant que le service LDAP est toujours en cours d'exécution pour capturer un instantané cohérent des données LDAP à un moment précis. Sans sauvegarde, vous ne pouvez pas effectuer la migration de la version 2.4 vers la version 2.6.10 ni effectuer de rollback, car les étapes de migration de la version 4.53.00 effacent les anciens répertoires de données LDAP.

Arrêtez le serveur de gestion et l'interface utilisateur : arrêtez toutes les instances edge-management-server et edge-ui avant de procéder à la migration LDAP à partir de la version 4.53.00.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
Sauvegardez les données LDAP existantes : avant d'apporter des modifications lors de la mise à niveau depuis la version 4.53.00 (OpenLDAP 2.4.46), effectuez une sauvegarde complète des données LDAP actuelles de tous les serveurs LDAP. Cela crée un point de restauration sécurisé. (Lorsque vous effectuez une mise à niveau de la version 4.53.01 vers la version 4.54.00, cette séquence de sauvegarde, d'arrêt et de nettoyage n'est pas requise.)
- Exécutez la commande de sauvegarde. Cette action crée une archive de sauvegarde horodatée dans le répertoire /opt/apigee/backup/openldap.
```
apigee-service apigee-openldap backup
```
- Obtenir le nombre total d'enregistrements : capturez le nombre d'enregistrements dans votre annuaire pour la validation post-mise à niveau. (Le nombre d'enregistrements doit être identique sur tous les serveurs 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
```
Arrêter LDAP et nettoyer les répertoires de données : effectuez cette étape sur tous les serveurs LDAP uniquement si vous effectuez une mise à niveau à partir de la version 4.53.00 (OpenLDAP 2.4.46). N'arrêtez pas LDAP et ne supprimez pas /opt/apigee/data/apigee-openldap/* si vous effectuez une mise à niveau à partir de la version 4.53.01 (OpenLDAP 2.6.7). Pour les mises à niveau vers la version 4.53.00, cette étape est obligatoire en raison du changement de version majeure et des différences structurelles de la base de données sous-jacente. Lorsque tous les serveurs LDAP sont arrêtés, les API et l'UI de gestion commencent à être perturbées.
- Arrêtez le service LDAP.
```
apigee-service apigee-openldap stop
```
- Supprimez définitivement les anciens répertoires de données et de configuration LDAP.
```
rm -rf /opt/apigee/data/apigee-openldap/*
```
Installez et configurez la nouvelle version LDAP : sur tous les serveurs LDAP, utilisez les scripts Apigee standards pour télécharger et installer la nouvelle version du composant.
- Installez le nouveau composant LDAP : le script de mise à jour lit votre fichier de configuration et installe le nouveau package apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- Valider la nouvelle version de LDAP : une fois l'installation terminée, actualisez le profil et vérifiez que la nouvelle version de LDAP (2.6.10) est installée :
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
  Le résultat de la commande spécifiée ci-dessus doit confirmer la version 2.6.10 de LDAP, comme indiqué ci-dessous :
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```
Arrêtez LDAP sur tous les serveurs avant de restaurer les données : effectuez les étapes 5, 6 et 7 uniquement si vous effectuez une mise à niveau à partir de la version 4.53.00 (OpenLDAP 2.4.46) (si vous avez effectué une mise à niveau sur place à partir de la version 4.53.01 à l'étape 4, vos données LDAP existantes sont conservées et la mise à niveau est terminée). Avant de restaurer votre sauvegarde à partir de la version 4.53.00, assurez-vous que le service LDAP nouvellement installé est arrêté sur tous les serveurs. Sur chaque serveur LDAP, exécutez les commandes suivantes :
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*
```
Restaurer les données LDAP : la stratégie consiste à restaurer la sauvegarde sur le premier serveur actif. Ce serveur agira alors comme source de référence, en répliquant les données sur ses pairs dans une configuration multiserveur.
1. Identifiez le premier serveur actif à restaurer :
  - Pour une configuration à serveur unique : il s'agit de votre seul serveur LDAP. Vous pouvez passer directement à l'étape suivante.
  - Pour les configurations actif-passif et actif-actif : exécutez la commande de diagnostic suivante sur chaque serveur LDAP :
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
    Remarque :
    - Si la commande ci-dessus renvoie un résultat, le serveur est un serveur passif.
    - Si aucune sortie n'est renvoyée, le serveur est le serveur actif.
2. Restaurez les données de sauvegarde : avant de continuer, vérifiez que l'étape 5 a bien été effectuée sur tous les serveurs LDAP.
  - Sur le premier serveur actif que vous avez identifié ci-dessus, accédez au répertoire de sauvegarde.
```
cd /opt/apigee/backup/openldap
```
  - Exécutez la commande de restauration. Spécifiez le code temporel exact de la sauvegarde de l'étape 2 pour éviter de restaurer une version non souhaitée ou plus ancienne.
```
# 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
```
  - Une fois le processus de restauration terminé, démarrez le service LDAP sur le premier serveur actif.
```
apigee-service apigee-openldap start
```
Démarrez les serveurs LDAP restants : si vous disposez d'une configuration multiserveur, démarrez le service sur chacun des serveurs LDAP :
```
apigee-service apigee-openldap start
```
Remarque : Vous n'avez pas besoin de restaurer manuellement les données sur ces serveurs pairs. Au démarrage, ils se connecteront au premier serveur (qui contient désormais les données restaurées) et synchroniseront automatiquement l'intégralité de l'annuaire par réplication.
Validation finale : la dernière étape consiste à vérifier que la mise à niveau a réussi et que les données sont cohérentes dans l'ensemble du cluster LDAP.
- Exécutez la commande de validation sur tous les serveurs LDAP. Le nombre d'enregistrements doit être identique sur tous les serveurs et doit correspondre au nombre que vous avez enregistré à l'étape 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
```
- Une fois que vous avez vérifié que les données sont correctes et cohérentes, la mise à niveau LDAP est terminée. Vous pouvez maintenant démarrer edge-management-server, edge-ui et tous les autres composants dépendants conformément à la procédure de mise à niveau standard de votre organisation.

Étapes de mise à niveau de LDAP de la version 4.53.01 vers la version 4.54.00

Installez et configurez la nouvelle version LDAP : sur tous les serveurs LDAP, utilisez les scripts Apigee standards pour télécharger et installer la nouvelle version du composant.

Installez le nouveau composant LDAP : le script de mise à jour lit votre fichier de configuration et installe le nouveau package apigee-openldap.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
Valider la nouvelle version de LDAP : une fois l'installation terminée, actualisez le profil et vérifiez que la nouvelle version de LDAP (2.6.10) est installée :
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
Le résultat de la commande spécifiée ci-dessus doit confirmer la version 2.6.10 de LDAP, comme indiqué ci-dessous :
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```

Mettre à niveau vers la nouvelle interface utilisateur Edge et Apigee SSO (si installé)

Dans Apigee Edge for Private Cloud 4.54.00, l'UI classique (edge-ui) est supprimée et remplacée par la nouvelle UI Edge (edge-management-ui). Selon que l'authentification unique (SSO) Apigee est installée et utilisée dans votre configuration, suivez l'une des deux options ci-dessous :

Option 1 : Mettre à niveau l'UI (sans Apigee SSO)

Cette section s'applique exclusivement si Apigee SSO (apigee-sso) n'est pas configuré / installé dans votre installation Edge for Private Cloud version 4.53.00 ou 4.53.01 existante.

Lors du processus de mise à niveau vers Edge for Private Cloud version 4.54.00, l'UI classique (edge-ui) est supprimée. L'exécution de la commande de mise à niveau suivante fait passer le nœud de l'UI de l'UI classique (edge-ui) à la nouvelle UI Edge(edge-management-ui).

Étape 1 : Sauvegardez les fichiers de configuration

Avant de commencer, effectuez une sauvegarde du fichier de configuration silencieux existant (configFile) et du répertoire /opt/apigee/customer/application/ sur tous les nœuds d'interface utilisateur.

Étape 2 : Mettre à jour le fichier de configuration silencieuse pour l'authentification de base

Modifiez votre fichier de configuration silencieux (par exemple, /opt/silent.conf) et ajoutez les propriétés suivantes de la nouvelle interface utilisateur Edge pour l'authentification de 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

Étape 3 : Mettre à niveau le composant d'interface utilisateur

Exécutez le script update.sh avec le composant -c ue pour passer de l'UI classique (edge-ui) à la nouvelle UI Edge (edge-management-ui) :

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

Étape 4 : Vérifier la mise à niveau de la nouvelle interface utilisateur Edge

Une fois la mise à niveau terminée sur tous les nœuds d'interface utilisateur, vérifiez que la nouvelle interface utilisateur Edge version 4.54.00 est entièrement opérationnelle et accessible :

Vérifiez que le service edge-management-ui est en cours d'exécution :
```
apigee-service edge-management-ui status
```
Ouvrez un navigateur et accédez à :
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Une fois la vérification effectuée, ignorez l'option 2 : Mettre à niveau l'UI (avec Apigee SSO) et passez directement à la section Mise à niveau requise vers Qpid.

Option 2 : Mettre à niveau l'interface utilisateur (avec l'authentification unique Apigee)

Utilisez cette section si Apigee SSO (apigee-sso) est configuré / installé dans votre environnement Edge for Private Cloud 4.53.00 ou 4.53.01.

Dans Apigee Edge pour Private Cloud 4.54.00 :

Le service Apigee SSO sous-jacent passe de l'ancien composant apigee-sso à Apigee SSO géré sous apigee-openldap. Cette mise à niveau est obligatoire lors de la mise à niveau vers Apigee Edge for Private Cloud version 4.54.00 si l'authentification unique est activée dans Edge for Private Cloud version 4.53.00 ou 4.53.01.
L'UI classique 4.53.x (edge-ui) avec SSO et l'UI New Edge 4.53.x (edge-management-ui) avec SSO sont toutes deux mises à niveau vers l'UI New Edge 4.54.00 (edge-management-ui) avec Apigee SSO.

Lisez les articles suivants pour comprendre la nouvelle conception d'Apigee SSO et son impact sur les utilitaires et les flux d'automatisation avec l'API Management :
À propos de la nouvelle structure d'authentification unique Apigee
Tâches automatisées à l'aide de l'authentification unique

Suivez les étapes de bout en bout ci-dessous pour mettre à niveau l'interface utilisateur et l'authentification unique Apigee sans étapes de configuration en double :

Étape 1 : Sauvegardez les fichiers de configuration

Avant de continuer, sauvegardez votre fichier configFile silencieux existant et le répertoire /opt/apigee/customer/application/ sur tous les nœuds d'interface utilisateur et SSO.

Étape 2 : Supprimez les variables d'UI/SSO obsolètes et mettez à jour le fichier de configuration silencieux (`configFile`)

Avant de mettre à niveau la nouvelle interface utilisateur Edge et de configurer le module Apigee SSO, mettez à jour votre fichier de configuration silencieux (configFile) en une seule étape en fonction de votre configuration actuelle de l'interface utilisateur 4.53.x :

Supprimez ou mettez en commentaire les variables d'interface utilisateur et d'authentification unique 4.53.x obsolètes de configFile :

Si vous effectuez une mise à niveau depuis l'interface utilisateur classique (edge-ui) avec apigee-sso, supprimez ou mettez en commentaire les propriétés liées à l'interface utilisateur classique et à l'authentification unique :
```
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
```

Si vous effectuez une mise à niveau depuis la nouvelle interface utilisateur Edge (edge-management-ui) avec apigee-sso, supprimez ou mettez en commentaire les propriétés obsolètes liées à l'ancienne interface utilisateur 4.53.x, Shoehorn et 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
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=""

Utilisez la commande suivante sur le nœud apigee-openldap pour créer un utilisateur machine pour la nouvelle interface utilisateur Edge. Veillez à utiliser exactement les mêmes identifiants lorsque vous définissez la propriété dans le fichier de configuration silencieux (configFile) à l'étape suivante. Pour en savoir plus, consultez Créer un utilisateur machine pour l'UI.
```
/opt/apigee/apigee-openldap/bin/apigee-machineuser.sh add -u ui-machine-user@apigee.com -p Secret123
```

Ajoutez ou mettez à jour les propriétés requises pour Apigee SSO 4.54.00 et la nouvelle interface utilisateur Edge dans 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

Étape 3 : Mettez à niveau le composant de la nouvelle interface utilisateur Edge

Arrêtez et désinstallez les composants edge-management-ui (nouvelle UI Edge) et edge-ui (UI Shoehorn) si la nouvelle UI Edge est actuellement utilisée :

#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

Exécutez le script update.sh sur vos nœuds d'interface utilisateur classique (edge-ui) pour installer et mettre à niveau le composant de la nouvelle interface utilisateur Edge (edge-management-ui) :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```

Étape 4 : Arrêter le `apigee-sso`

Arrêtez l'ancien service apigee-sso sur tous les nœuds où il est installé :

apigee-service apigee-sso stop

Étape 5 : Créez la base de données `apigee_dex` pour Apigee SSO dans le nœud Postgres

Sur le nœud principal Postgres, connectez-vous à Postgresql à l'aide de la commande suivante :
```
psql -h $(hostname -i) -U apigee
```
Exécutez la commande suivante dans l'invite psql pour créer la base de données Apigee SSO :
```
create database apigee_dex;
```

Étape 6 : Configurer l'authentification unique Apigee sur les nœuds OpenLDAP

Exécutez la commande suivante sur le nœud apigee-openldap où l'authentification unique Apigee sera installée :

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

Étape 7 : Configurez l'UI de gestion pour Apigee SSO et redémarrez l'UI

Exécutez les commandes suivantes sur chaque nœud sur lequel Edge for Private Cloud 4.54.00 edge-management-ui est installé :

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

Étape 8 : Vérifier la mise à niveau de la nouvelle interface utilisateur Edge et d'Apigee SSO

Après avoir suivi les étapes ci-dessus, vérifiez que la nouvelle interface utilisateur Edge 4.54.00 et Apigee SSO sont en cours d'exécution et accessibles :

Vérifiez que le service edge-management-ui est en cours d'exécution :
```
apigee-service edge-management-ui status
```
Ouvrez un navigateur et accédez à l'adresse suivante :
```
http://MANAGEMENT_UI_NODE_IP:3001
```
Connectez-vous à l'aide de vos identifiants SSO configurés.

Étape 9 : Désinstaller l'ancienne version de `apigee-sso`

Sur tous les nœuds sur lesquels l'ancienne version de apigee-sso était installée, désinstallez le composant apigee-sso :

apigee-service apigee-sso uninstall

Mise à niveau vers Qpid 10.0.1

Cette méthode permet de s'assurer qu'il n'y a pas de temps d'arrêt pour votre environnement d'exécution Edge et de minimiser la perte de données d'exécution, le cas échéant, acquises pour l'analyse.

Pour effectuer une mise à niveau sur place sans temps d'arrêt vers Qpid :

Choisissez un nœud Qpid pour commencer.
Arrêtez l'agent Qpid sur le nœud :
```
apigee-service apigee-qpidd stop
```
Bloquez le trafic entrant sur le port 5672 du courtier depuis tous les processeurs de messages en appliquant un pare-feu. Vous pouvez appliquer ce pare-feu au niveau de l'instance de nœud Qpid ou d'un autre composant réseau/pare-feu externe.

Nous vous recommandons d'effectuer la même étape pour toutes les adresses IP des processeurs de messages. Par exemple, pour supprimer les requêtes provenant des adresses IP du processeur de messages vers le nœud Qpid sur le port 5672 à l'aide d'IPTables, vous pouvez utiliser une commande de ce type :
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Redémarrez le courtier Qpid pour drainer les messages existants, le cas échéant :
```
apigee-service apigee-qpidd start
```
Vérifiez que les files d'attente existantes sont vides :
```
/opt/apigee/apigee-qpidd/bin/qpid-stat -q
```
Si des messages sont bloqués dans la file d'attente de lettres mortes (DLQ) (ax-q-axgroup-001-consumer-group-001-dl), videz la file d'attente en suivant les étapes pour résoudre les problèmes de données d'analyse bloquées dans la file d'attente de lettres mortes.
Après avoir vérifié que les files d'attente ont été vidées sur l'ancien nœud, arrêtez apigee-qpidd :
```
apigee-service apigee-qpidd stop
```

Mettez à niveau Qpid sur le nœud :

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

Redémarrez edge-qpid-server :
```
apigee-service edge-qpid-server restart
```
Supprimez la règle de pare-feu appliquée à l'étape 3.

Effectuez la même étape de suppression pour toutes les adresses IP du processeur de messages auxquelles le pare-feu a été appliqué. Une fois les pare-feu supprimés, les requêtes provenant des adresses IP du processeur de messages vers le nœud Qpid sur le port 5672 seront acceptées. Si vous avez utilisé iptables pour ajouter le pare-feu, vous pouvez utiliser des commandes comme celles ci-dessous pour le supprimer et lister les paramètres existants :
```
iptables -F
iptables -L
```
Utilisez la surveillance Web pour vérifier que les files d'attente Qpid reçoivent des messages :
```
http://QPID_NODE_IP:8090
```
Répétez les étapes 1 à 9 pour chaque nœud Qpid.

Mettre à niveau vers Postgres 18.6

Cette version d'Edge inclut une mise à niveau vers Postgres 18.6. Dans le cadre de cette mise à niveau, toutes les données Postgres sont migrées vers Postgres 18.6.

La plupart des systèmes de production Edge utilisent deux nœuds Postgres configurés pour la réplication principal-veille. Pendant le processus de mise à jour, lorsque les nœuds Postgres sont indisponibles pour la mise à jour, les données d'analyse sont toujours écrites sur les nœuds Qpid. Une fois les nœuds Postgres mis à jour et de nouveau en ligne, les données analytiques sont transférées vers les nœuds Postgres.

La façon dont vous effectuez la mise à jour de Postgres dépend de la façon dont vous avez configuré le stockage de données pour vos nœuds Postgres :

Si vous utilisez le stockage de données local pour vos nœuds Postgres , vous devez installer un nouveau nœud de secours Postgres pendant la mise à niveau. Une fois la mise à niveau terminée, vous pouvez mettre hors service le nouveau nœud de secours Postgres. Le nœud de secours Postgres supplémentaire est requis si vous devez annuler la mise à jour pour une raison quelconque. Si vous devez annuler la mise à jour, le nouveau nœud de secours Postgres devient le nœud principal Postgres après l'annulation. Par conséquent, lorsque vous installez le nouveau nœud de secours Postgres, il doit se trouver sur un nœud qui répond à toutes les exigences matérielles d'un serveur Postgres, telles que définies dans les exigences d'installation d'Edge.

Dans une configuration Edge à un ou deux nœuds, les topologies utilisées pour le prototypage et les tests ne comportent qu'un seul nœud Postgres. Vous pouvez mettre à jour ces nœuds Postgres directement, sans avoir à en créer d'autres.
Si vous utilisez un stockage réseau pour vos nœuds Postgres , comme recommandé par Apigee, vous n'avez pas besoin d'installer un nouveau nœud Postgres. Dans les procédures ci-dessous, vous pouvez ignorer les étapes qui consistent à installer, puis à mettre hors service un nouveau nœud de secours Postgres. Avant de commencer le processus de mise à jour, prenez un instantané réseau du datastore utilisé par Postgres. Ensuite, si des erreurs se produisent lors de la mise à jour et que vous êtes obligé d'effectuer un rollback, vous pouvez restaurer le nœud Postgres à partir de cet instantané.

Installer un nouveau nœud Postgres de secours

Cette procédure crée un serveur de secours Postgres sur un nouveau nœud. Assurez-vous d'installer un nouveau serveur de secours Postgres pour votre version existante d'Edge (4.53.00 ou 4.53.01), et non pour la version 4.54.00.

Pour effectuer l'installation, utilisez le même fichier de configuration que celui utilisé pour installer votre version actuelle d'Edge.

Pour créer un nœud de secours Postgres :

Sur le serveur principal Postgres actuel, modifiez le fichier /opt/apigee/customer/application/postgresql.properties pour définir le jeton suivant. Si ce fichier n'existe pas, créez-le :
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust
```
Où existing_standby_ip est l'adresse IP du serveur de secours Postgres actuel et new_standby_ip est l'adresse IP du nouveau nœud de secours.

Redémarrez apigee-postgresql sur le nœud maître Postgres :

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

Vérifiez que le nouveau nœud de secours a été ajouté en consultant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nœud principal. Les lignes suivantes doivent s'afficher dans ce fichier :
```
host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
```
Installez le nouveau serveur de secours Postgres :
1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge afin de spécifier les éléments suivants :
```
# 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. Désactivez SELinux comme décrit dans Installer l'utilitaire apigee-setup d'Edge.
3. Téléchargez et exécutez le script d'amorçage en fonction de votre version actuelle d'Edge :
  - Si vous utilisez actuellement Edge 4.53.00 :
    
    Téléchargez le fichier Edge bootstrap_4.53.00.sh dans /tmp/bootstrap_4.53.00.sh :
```
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
    Installez l'utilitaire apigee-service Edge et ses dépendances :
```
bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
  - Si vous utilisez actuellement Edge 4.53.01 :
    
    Téléchargez le fichier Edge bootstrap_4.53.01.sh dans /tmp/bootstrap_4.53.01.sh :
```
curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
```
    Installez l'utilitaire apigee-service Edge et les dépendances :
```
bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord
```
4. Utilisez apigee-service pour installer l'utilitaire apigee-setup :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
5. Installez Postgres :
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. Sur le nouveau nœud de secours, exécutez la commande suivante et vérifiez qu'il s'agit du nœud standby (en veille) :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```

Effectuer une mise à niveau sur place de Postgres

Étape préliminaire

Avant d'effectuer une mise à niveau sur place vers Postgres, procédez comme suit sur l'hôte principal et l'hôte de secours pour mettre à jour la propriété max_locks_per_transaction sur apigee-postgresql :

S'il n'existe pas, créez le fichier /opt/apigee/customer/application/postgresql.properties .

Remplacez la propriété de ce fichier par apigee :

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

Ajoutez la propriété suivante au fichier :

conf/postgresql.conf+max_locks_per_transaction=30000

Configurez apigee-postgresql :

apigee-service apigee-postgresql configure

Redémarrez apigee-postgresql :

apigee-service apigee-postgresql restart

Effectuer la mise à niveau sur place

Pour effectuer une mise à niveau sur place vers Postgres 18, procédez comme suit :

Mettre à niveau Postgres sur l'hôte principal

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

Exécutez la commande de configuration sur l'hôte principal :
```
apigee-service apigee-postgresql setup -f configFile
```
Exécutez la commande de configuration sur l'hôte principal :
```
apigee-service apigee-postgresql configure
```

Redémarrez l'hôte principal :

apigee-service apigee-postgresql restart

Définissez-le comme principal :

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

Assurez-vous que l'hôte principal a démarré :
```
apigee-service apigee-postgresql wait_for_ready
```
Arrêtez la veille :
```
apigee-service apigee-postgresql stop
```
Mettez à niveau le standby.

Remarque : Si cette étape génère une erreur ou échoue, vous pouvez l'ignorer. update.sh tentera de démarrer le serveur de secours avec une configuration incorrecte. Si l'installation de Postgres est mise à niveau vers la version 18, l'erreur peut être ignorée.
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Assurez-vous que le serveur de secours est arrêté :
```
apigee-service apigee-postgresql stop
```
Supprimez l'ancienne configuration de secours :
```
rm -rf /opt/apigee/data/apigee-postgresql/
```

Configurez la réplication sur le serveur de secours :

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

Supprimez la ligne conf/postgresql.conf+max_locks_per_transaction=30000 du fichier /opt/apigee/customer/application/postgresql.properties sur l'hôte principal et l'hôte de secours. Cette ligne a été ajoutée lors de l'étape préliminaire .

Une fois cette procédure terminée, la veille démarrera correctement.

Mettre hors service un nœud Postgres

Une fois la mise à jour terminée, mettez hors service le nouveau nœud de secours :

Assurez-vous que Postgres est en cours d'exécution :
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Si Postgres n'est pas en cours d'exécution, démarrez-le :
```
/opt/apigee/apigee-service/bin/apigee-all start
```
Obtenez l'UUID du nouveau nœud de secours en exécutant la commande curl suivante sur le nouveau nœud de secours :
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
L'UUID du nœud doit s'afficher à la fin du résultat, sous la forme suivante :
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
Arrêtez le nouveau nœud de secours en exécutant la commande suivante sur le nouveau nœud de secours :
```
/opt/apigee/apigee-service/bin/apigee-all stop
```
Sur le nœud principal Postgres, modifiez /opt/apigee/customer/application/postgresql.properties pour supprimer le nouveau nœud de secours de conf_pg_hba_replication.connection :
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
```

Redémarrez apigee-postgresql sur le nœud maître Postgres :

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

Vérifiez que le nouveau nœud de secours a été supprimé en consultant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur le nœud principal. Ce fichier ne doit contenir que la ligne suivante :
```
host replication apigee existing_standby_ip/32 trust
```
Supprimez l'UUID du nœud de secours de ZooKeeper en effectuant l'appel d'API de gestion Edge suivant sur le nœud du serveur de gestion :
```
curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid
```

Étapes post-mise à niveau pour Postgres

Après une mise à niveau majeure de Postgres, les statistiques internes de Postgres sont effacées. Ces statistiques aident le planificateur de requêtes Postgres à utiliser les index et les chemins les plus optimaux pour exécuter les requêtes.

Postgres peut progressivement reconstruire ses statistiques au fil du temps, à mesure que les requêtes sont exécutées et que le daemon autovacuum s'exécute. Toutefois, tant que les statistiques ne sont pas recréées, vos requêtes peuvent être lentes.

Pour résoudre ce problème, exécutez ANALYZE sur toutes les tables de la base de données sur le nœud Postgres principal. Vous pouvez également exécuter ANALYZE pour quelques tables à la fois.

Mise à niveau vers ZooKeeper 3.8.5

Cette version d'Edge for Private Cloud inclut une mise à niveau vers ZooKeeper 3.8.5. Dans le cadre de cette mise à niveau, toutes les données ZooKeeper seront migrées vers ZooKeeper 3.8.5.

Avant de mettre à niveau ZooKeeper, lisez le guide de maintenance ZooKeeper. La plupart des systèmes de production Edge utilisent un cluster de nœuds ZooKeeper répartis sur plusieurs centres de données. Certains de ces nœuds sont configurés en tant que votants qui participent à l'élection de l'instance répliquée principale ZooKeeper, et les autres sont configurés en tant qu'observateurs. Pour en savoir plus, consultez À propos des leaders, des followers, des votants et des observateurs. Les nœuds votants élisent un leader, après quoi ils deviennent eux-mêmes des nœuds suiveurs.

Pendant le processus de mise à jour, un retard momentané ou un échec d'écriture peut se produire dans ZooKeeper lorsque le nœud leader est arrêté. Cela peut affecter les opérations de gestion qui écrivent dans ZooKeeper, telles que le déploiement d'un proxy, et les modifications de l'infrastructure Apigee, telles que l'ajout ou la suppression d'un processeur de messages, etc. Il ne devrait y avoir aucun impact sur les API d'exécution d'Apigee (sauf si ces API d'exécution appellent des API de gestion) lors de la mise à niveau de ZooKeeper en suivant la procédure ci-dessous.

Globalement, le processus de mise à niveau implique d'effectuer une sauvegarde de chaque nœud. Ensuite, tous les observateurs et followers sont mis à niveau, et enfin le nœud leader.

Effectuer une sauvegarde

Sauvegardez tous les nœuds ZooKeeper à utiliser en cas de rollback. Notez qu'un rollback restaure ZooKeeper à l'état dans lequel il se trouvait au moment de la sauvegarde.

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

Si vous utilisez des machines virtuelles et que vous en avez la possibilité, vous pouvez également créer des instantanés ou des sauvegardes de VM pour la restauration ou le rollback (si nécessaire).

Identifier le leader, les suiveurs et les observateurs

S'il n'est pas installé sur le nœud ZooKeeper, installez nc :
```
yum install nc
```
Exécutez la commande nc suivante sur le nœud, où 2181 est le port ZooKeeper :
```
echo stat | nc localhost 2181
```
Vous devriez voir une sortie semblable à ce qui suit.
```
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
```
Sur la ligne Mode du résultat pour les nœuds, vous devriez voir "observer", "leader" ou "follower" (c'est-à-dire un votant qui n'est pas le leader) selon la configuration du nœud.

Répétez les étapes 1 et 2 sur chaque nœud ZooKeeper.

Mettre à niveau ZooKeeper sur les nœuds observateur et suiveur

Mettez à niveau ZooKeeper sur chacun des nœuds d'observateur et de suiveur comme suit :

Téléchargez et exécutez le bootstrap d'Edge for Private Cloud 4.54.00, comme décrit dans Mettre à jour vers la version 4.54.00 sur un nœud disposant d'une connexion Internet externe . La procédure varie probablement selon que le nœud dispose d'une connexion Internet externe ou que vous effectuez une installation hors connexion.
Mettez à niveau le composant ZooKeeper :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file
```
Remarque : Si d'autres composants sont installés sur ces nœuds (comme Cassandra), vous pouvez également les mettre à niveau maintenant (comme avec le profil zk,cs) ou plus tard. Apigee vous recommande de ne mettre à niveau que ZooKeeper dans un premier temps et de vous assurer que votre cluster fonctionne correctement avant de mettre à niveau d'autres composants.
Répétez les étapes ci-dessus sur chaque nœud d'observateur et de follower ZooKeeper.

Désactiver le leader

Une fois que tous les nœuds observateurs et suiveurs ont été mis à niveau, arrêtez le leader. Sur le nœud identifié comme leader, exécutez la commande ci-dessous :

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

Notez que pendant cet événement, avant qu'un nouveau leader ne soit élu, il peut y avoir des retards momentanés ou des échecs d'écriture dans ZooKeeper. Cela peut affecter les opérations qui écrivent dans ZooKeeper, telles que l'action de déploiement de proxys ou les modifications de l'infrastructure Apigee, comme l'ajout ou la suppression de processeurs de messages, etc.

Vérifier que le nouveau leader est élu

En suivant la procédure de la section Identifier le leader, les suiveurs et les observateurs ci-dessus, vérifiez qu'un nouveau leader a été élu parmi les suiveurs une fois le leader existant arrêté. Notez que le leader peut avoir été élu dans un centre de données différent de celui du leader actuel.

Responsable de la migration

Suivez la même procédure que dans la section Mettre à niveau ZooKeeper sur les nœuds d'observateur et de suiveur ci-dessus.

Une fois l'ancien nœud responsable mis à niveau, vérifiez l'état du cluster et assurez-vous qu'il existe un nœud responsable.

Mettre à niveau vers Cassandra 5.0.8

Apigee Edge for Private Cloud 4.54.00 inclut une mise à niveau de Cassandra vers la version 5.0.8.

Mises à niveau et rollback

La mise à niveau de Cassandra 4.0.X vers Cassandra 5.0.X est un processus continu.
Il n'est pas possible d'effectuer un rollback direct sur place de Cassandra 5.0.X vers 4.0.X. La restauration à l'aide de répliques ou de sauvegardes est une procédure complexe qui peut entraîner des temps d'arrêt et/ou des pertes de données. Il est préférable de résoudre les problèmes et de passer à Cassandra 5.0.X plutôt que d'effectuer un rollback.
Il est important de vous familiariser avec les procédures de rollback avant de tenter la mise à niveau. Il est essentiel de tenir compte des nuances de la restauration lors de la mise à niveau pour s'assurer que les chemins de restauration appropriés sont disponibles.

Un seul centre de données

La mise à niveau de Cassandra de la version 4.0.X vers la version 5.0.X dans un seul centre de données est simple, mais le rollback est complexe et peut entraîner des temps d'arrêt et une perte de données. Pour les charges de travail de production, il est vivement conseillé d'ajouter un centre de données avec au moins des nœuds Cassandra disponibles dans le nouveau centre de données avant de lancer la mise à niveau. Cela permettra d'effectuer un rollback de Cassandra sans entraîner de perte de données ni d'interruption de votre trafic d'API. Ce centre de données supplémentaire peut être mis hors service une fois la mise à niveau terminée.

S'il n'est pas possible d'ajouter un centre de données, mais que vous souhaitez tout de même pouvoir effectuer un rollback, vous devrez effectuer des sauvegardes pour restaurer Cassandra 4.0.X. Cependant, cette méthode est susceptible d'entraîner des temps d'arrêt et une perte de données.

Plusieurs centres de données

L'exploitation de plusieurs centres de données avec Edge for Private Cloud 4.53.00 (ou 4.53.01) offre plus de flexibilité pour les rollbacks lors de la mise à niveau vers Edge for Private Cloud 4.54.00.

Les rollbacks nécessitent au moins un centre de données exécutant la version antérieure de Cassandra (4.0.X).

Méthodologie de mise à niveau recommandée

Mettez à niveau un centre de données Cassandra à la fois : commencez par mettre à niveau les nœuds Cassandra individuellement dans un seul centre de données. Effectuez la mise à niveau de tous les nœuds Cassandra d'un centre de données avant de passer au suivant.
Mettre en pause et valider : après avoir mis à niveau un centre de données, faites une pause pour vous assurer que votre cluster de cloud privé, en particulier le centre de données mis à niveau, fonctionne correctement.
Rappel : Vous ne pouvez revenir à la version précédente de Cassandra que si au moins un centre de données exécute encore l'ancienne version.
Sensible au temps : Vous pouvez suspendre la mise à niveau pendant une courte période (quelques heures sont recommandées) pour valider la fonctionnalité, mais vous ne pouvez pas rester indéfiniment dans un état de version mixte. En effet, un cluster Cassandra non uniforme (avec des nœuds sur différentes versions) présente des limites opérationnelles.
Tests approfondis : Apigee recommande vivement de tester de manière exhaustive les performances et les fonctionnalités avant de mettre à niveau le centre de données suivant. Une fois que tous les centres de données ont été mis à niveau, il est impossible de revenir à la version précédente.

Processus de rollback des points de contrôle

Point de contrôle de rollback unique : lorsque tous les composants sont mis à niveau vers la version 4.54.00, un rollback Cassandra reste possible uniquement si au moins un centre de données Cassandra continue d'exécuter l'ancienne version. Une fois le dernier centre de données Cassandra mis à niveau, la mise à niveau vers Edge for Private Cloud 4.54.00 est terminée et le rollback n'est plus possible.

Exemple

Prenons l'exemple d'un cluster à deux centres de données :

État de départ : les nœuds Cassandra des deux centres de données sont en version 4.0.X. Tous les autres nœuds sont sur Edge for Private Cloud version 4.54.00. Supposons qu'il y ait trois nœuds Cassandra par centre de données.
Mettre à niveau DC-1 : mettez à niveau les trois nœuds Cassandra de DC-1 un par un.
Mettre en veille et valider : mettez en veille pour vous assurer que le cluster, en particulier DC-1, fonctionne correctement (vérifiez les performances et les fonctionnalités). Vous pouvez revenir à l'état initial à l'aide des nœuds Cassandra dans DC-2. N'oubliez pas que cette pause doit être temporaire en raison des limites d'un cluster Cassandra à versions mixtes.
Mettre à niveau DC-2 : mettez à niveau les trois nœuds Cassandra restants dans DC-2. Une fois que tous les nœuds Cassandra de DC-2 ont été mis à niveau, la mise à niveau d'Edge for Private Cloud 4.54.00 est terminée.

Prérequis pour la mise à niveau de Cassandra

Vous devez exécuter Cassandra 4.0.X avec Edge pour Private Cloud 4.53.00 (ou 4.53.01) et vous assurer des points suivants :

Définissez Java 17 comme version Java par défaut sur le serveur : Cassandra 5.0.X ne prend plus en charge Java 8. Vous ne pouvez pas exécuter Cassandra 5.0.X ni son utilitaire nodetool avec Java 8. Assurez-vous que Java 17 est installé sur chaque nœud Cassandra et définissez Java 17 comme version Java par défaut avant d'exécuter les étapes de mise à niveau de Cassandra afin que les commandes nodetool s'exécutent avec Java 17 :
```
alternatives --set java JAVA_17_PATH/bin/java
```
Vérifiez que la version Java active par défaut est Java 17 :
```
java -version
```
L'ensemble du cluster est opérationnel et entièrement fonctionnel avec Cassandra 4.0.X.
La stratégie de compactage est définie sur LeveledCompactionStrategy (condition préalable à la mise à niveau vers la version 4.53.00 ou 4.53.01).
Vérifiez que chaque étape ci-dessous a été effectuée lors de la mise à niveau initiale de Cassandra 4.0.X dans Edge pour Private Cloud 4.53.00 (ou) 4.53.01.
- La commande post_upgrade a été exécutée sur chaque nœud Cassandra lors de la mise à niveau précédente.
- La commande drop_old_tables a été exécutée sur l'ensemble du cluster Cassandra lors de la mise à niveau précédente.

Si vous n'êtes pas sûr que les commandes post_upgrade et drop_old_tables ont été exécutées sur Cassandra 4.0.X lors de l'utilisation d'Edge for Private Cloud 4.53.00 (ou) 4.53.01, vous pouvez les réexécuter en toute sécurité avant de tenter la mise à niveau vers la version 4.54.00.

Étape 1 : Préparez la mise à niveau

Les étapes ci-dessous s'ajoutent aux fichiers standards que vous créez habituellement, tels que le fichier de configuration standard d'Apigee pour activer les mises à niveau des composants.

Sauvegardez Cassandra à l'aide d'Apigee.
Prenez des instantanés de VM des nœuds Cassandra (si possible).
Assurez-vous que le port 9042 est accessible depuis tous les composants Edge for Private Cloud, y compris le serveur de gestion, le processeur de messages, le routeur, Qpid et Postgres, vers les nœuds Cassandra, si ce n'est pas déjà fait. Pour en savoir plus, consultez les exigences concernant les ports.

Étape 2 : Mettre à niveau tous les nœuds Cassandra

Tous les nœuds Cassandra doivent être mis à jour un par un dans chaque centre de données, un centre de données à la fois. Entre les mises à niveau des nœuds d'un centre de données, attendez quelques minutes pour vous assurer qu'un nœud mis à jour a complètement démarré et rejoint le cluster avant de procéder à la mise à niveau d'un autre nœud du même centre de données.

Après avoir mis à niveau tous les nœuds Cassandra d'un centre de données, attendez un certain temps (de 30 minutes à quelques heures) avant de passer aux nœuds du centre de données suivant. Pendant cette période, examinez attentivement le centre de données qui a été mis à jour et assurez-vous que les métriques fonctionnelles et de performances de votre cluster Apigee sont intactes. Cette étape est cruciale pour assurer la stabilité du centre de données où Cassandra a été mis à niveau vers la version 5.0.X, tandis que les autres composants Apigee ont été mis à niveau vers la version 4.54.00.

Pour mettre à niveau un nœud Cassandra, exécutez la commande suivante :
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
Une fois qu'un nœud est mis à jour, exécutez la commande suivante sur le nœud pour effectuer des validations avant de continuer :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```

Le résultat ressemblera à ceci :

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

Exécutez la commande post_upgrade suivante sur le nœud Cassandra :

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

Exécutez la commande cleanup_old_index suivante sur le nœud Cassandra :

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

Exécutez les commandes nodetool suivantes pour reconstruire les index sur le nœud 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

Si vous utilisez la monétisation, exécutez également les commandes de réindexation suivantes liées aux espaces de clés de monétisation :

/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

Mettre à jour avec Apigee mTLS

Pour mettre à jour Apigee mTLS , procédez comme suit :

Restaurer une mise à jour

En cas d'échec de la mise à jour, vous pouvez essayer de résoudre le problème, puis exécuter à nouveau update.sh. Vous pouvez exécuter la mise à jour plusieurs fois. Elle reprendra là où elle s'est arrêtée.

Si l'échec nécessite de revenir à la version précédente, consultez Revenir à la version 4.54.00 pour obtenir des instructions détaillées.

Informations sur la mise à jour de la journalisation

Par défaut, l'utilitaire update.sh écrit les informations de journal dans :

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

Si la personne qui exécute l'utilitaire update.sh n'a pas accès à ce répertoire, le journal est écrit dans le répertoire /tmp sous la forme d'un fichier nommé update_username.log.

Si la personne n'a pas accès à /tmp, l'utilitaire update.sh échoue.

Mise à jour sans temps d'arrêt

Une mise à jour sans temps d'arrêt, ou mise à jour progressive, vous permet de mettre à jour votre installation Edge sans arrêter Edge.

La mise à jour sans temps d'arrêt n'est possible qu'avec une configuration de cinq nœuds ou plus.

Pour effectuer une mise à niveau sans temps d'arrêt, vous devez supprimer chaque routeur, un par un, de l'équilibreur de charge. Vous mettez ensuite à jour le routeur et tous les autres composants sur la même machine que le routeur, puis vous ajoutez à nouveau le routeur à l'équilibreur de charge.

Mettez à jour les machines dans le bon ordre pour votre installation, comme décrit dans Ordre de mise à jour des machines .
Lorsque vous devez mettre à jour les routeurs, sélectionnez-en un et rendez-le inaccessible, comme décrit dans Activer/Désactiver l'accessibilité du serveur (processeur de messages/routeur) .
Mettez à jour le routeur sélectionné et tous les autres composants Edge sur la même machine que le routeur. Toutes les configurations Edge affichent un routeur et un processeur de messages sur le même nœud.
Rendez le routeur à nouveau accessible.
Répétez les étapes 2 à 4 pour les autres routeurs.
Poursuivez la mise à jour pour toutes les machines restantes de votre installation.

Avant et après la mise à jour, tenez compte des points suivants :

Sur le nœud combiné du routeur et du processeur de messages :
- Avant la mise à jour, procédez comme suit :
  1. Rendre le routeur inaccessible.
  2. Rendez le processeur de messages inaccessible.
- Après la mise à jour, procédez comme suit :
  1. Rendre le processeur de messages accessible
  2. Rendre le routeur accessible.
Sur les nœuds de routeur uniques :
- Avant la mise à jour, rendez le routeur inaccessible.
- Après la mise à jour, rendez le routeur accessible.
Sur les nœuds de processeur de messages uniques :
- Avant la mise à jour, rendez le processeur de messages inaccessible.
- Après la mise à jour, rendez le processeur de messages accessible.

Utiliser un fichier de configuration silencieux

Vous devez transmettre un fichier de configuration silencieux à la commande de mise à jour. Bien que le fichier de configuration silencieux soit en grande partie identique à celui que vous avez utilisé pour installer Edge pour Private Cloud 4.53.00 ou 4.53.01, vous devrez peut-être apporter des modifications pour des composants tels que l'UI et l'authentification unique, comme décrit dans Mettre à niveau vers la nouvelle interface utilisateur Edge et Apigee SSO (si installé).

Mettre à jour vers la version 4.54.00 sur un nœud disposant d'une connexion Internet externe

Pour mettre à jour les composants Edge sur un nœud, procédez comme suit :

Si des tâches cron sont configurées pour effectuer une opération de réparation sur Cassandra, désactivez-les jusqu'à la fin de la mise à jour.
Connectez-vous à votre nœud en tant que root pour installer les RPM Edge.

Remarque : Bien que l'installation RPM nécessite un accès racine, vous pouvez effectuer la configuration Edge sans accès racine.
Désactivez SELinux comme décrit dans Installer l'utilitaire apigee-setup d'Edge .

Si vous effectuez l'installation sur AWS , exécutez les commandes yum-configure-manager suivantes :

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

Si vous utilisez actuellement Edge pour le cloud privé 4.53.00 ou 4.53.01 :
1. Téléchargez le fichier Edge bootstrap_4.54.00.sh dans /tmp/bootstrap_4.54.00.sh :
```
curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
2. Installez l'utilitaire apigee-service Edge 4.54.00 et les dépendances en exécutant la commande suivante :
```
bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord
```
  Où uName:pWord sont le nom d'utilisateur et le mot de passe que vous avez reçus d'Apigee. Si vous omettez pWord, vous serez invité à le saisir.
  
  Par défaut, le programme d'installation vérifie que Java 17 et 21 sont installés.
3. Utilisez apigee-service pour mettre à jour l'utilitaire apigee-setup, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. Mettez à jour l'utilitaire apigee-validate sur le serveur de gestion, comme illustré dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. Mettez à jour l'utilitaire apigee-provision sur le serveur de gestion, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. Exécutez l'utilitaire update sur vos nœuds en exécutant la commande suivante :
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  Pour ce faire, suivez l'ordre décrit dans Ordre de mise à jour des machines.
  
  Où :
  - component est le composant Edge à mettre à jour. Les valeurs possibles sont les suivantes :
    - edge : tous les composants Edge, à l'exception de la nouvelle interface utilisateur Edge : serveur de gestion, processeur de messages, routeur, serveur QPID, serveur Postgres
    - ldap : OpenLDAP
    - ue : Nouvelle UI Edge
    - qpid : Apigee Qpid
    - ps : Apigee PostgreSQL
    - zk : ZooKeeper
    - cs : Cassandra
  - configFile est le même fichier de configuration que celui que vous avez utilisé pour définir vos composants Edge lors de l'installation de la version 4.53.00 (ou) 4.53.01.
  Remarque : Le fichier de configuration doit être lisible par l'utilisateur "apigee". Pour modifier le propriétaire, utilisez la commande suivante :
```
chown apigee:apigee configFile
```
  Vous pouvez exécuter update.sh sur tous les composants en définissant component sur "all", mais uniquement si vous disposez d'un profil d'installation Edge tout-en-un (AIO). Exemple :
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
7. Si ce n'est pas déjà fait, redémarrez les composants de la nouvelle interface utilisateur Edge sur tous les nœuds qui les exécutent :
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
8. Testez la mise à jour en exécutant l'utilitaire apigee-validate sur le serveur de gestion, comme décrit dans Tester l'installation.

Si vous décidez ultérieurement d'annuler la mise à jour, suivez la procédure décrite dans Annuler la version 4.54.00.

Mettre à jour vers la version 4.54.00 à partir d'un dépôt local

Si vos nœuds Edge sont protégés par un pare-feu ou ne peuvent pas accéder au dépôt Apigee sur Internet, vous pouvez effectuer la mise à jour à partir d'un dépôt Apigee local ou d'un miroir.

Une fois que vous avez créé un dépôt Edge local, vous disposez de deux options pour mettre à jour Edge à partir du dépôt local :

Créez un fichier .tar du dépôt, copiez-le sur un nœud, puis mettez à jour Edge à partir du fichier .tar.
Installez un serveur Web sur le nœud avec le dépôt local afin que les autres nœuds puissent y accéder. Apigee vous fournit le serveur Web Nginx, mais vous pouvez également utiliser votre propre serveur Web.

Pour effectuer la mise à jour à partir d'un dépôt 4.54.00 local :

Créez un dépôt local 4.54.00 comme décrit dans la section "Créer un dépôt Apigee local" de la page Installer l'utilitaire apigee-setup d'Edge.

Remarque : Si vous disposez déjà d'un dépôt, vous pouvez y ajouter le dépôt 4.54.00, comme décrit dans la section "Mettre à jour un dépôt Apigee local" de la page Installer l'utilitaire apigee-setup d'Edge.
Installez apigee-service sur les nœuds cibles à l'aide de l'une des méthodes suivantes :
- Option 1 : Installer apigee-service à partir d'un fichier .tar
  1. Sur le nœud avec le dépôt local, utilisez la commande suivante pour empaqueter le dépôt local dans un seul fichier .tar nommé /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
  2. Copiez le fichier .tar sur le nœud sur lequel vous souhaitez mettre à jour Edge. Par exemple, copiez-le dans le répertoire /tmp du nouveau nœud.
  3. Sur le nouveau nœud, décompressez le fichier dans le répertoire /tmp :
```
tar -xzf apigee-4.54.00.tar.gz
```
    Cette commande crée un répertoire nommé "repos" dans le répertoire contenant le fichier .tar. Exemple : /tmp/repos.
  4. Installez l'utilitaire apigee-service Edge et les dépendances à partir de /tmp/repos :
```
bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
    Notez que vous incluez le chemin d'accès au répertoire des dépôts dans cette commande.
- Option 2 : Installer apigee-service à l'aide du serveur Web Nginx
  1. Configurez le serveur Web Nginx comme décrit dans la section "Installer à partir du dépôt à l'aide du serveur Web Nginx" de la page Installer l'utilitaire apigee-setup d'Edge.
  2. Sur le nœud distant, téléchargez le fichier Edge bootstrap_4.54.00.sh dans /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
```
    Où uName:pWord correspondent au nom d'utilisateur et au mot de passe que vous avez définis précédemment pour le dépôt, et remoteRepo correspond à l'adresse IP ou au nom DNS du nœud du dépôt.
  3. Sur le nœud distant, installez l'utilitaire apigee-service Edge et les dépendances :
```
bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
    Où uName:pWord correspondent au nom d'utilisateur et au mot de passe du dépôt.
Utilisez apigee-service pour mettre à jour l'utilitaire apigee-setup, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
Mettez à jour l'utilitaire apigee-validate sur le serveur de gestion, comme illustré dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
Mettez à jour l'utilitaire apigee-provision sur le serveur de gestion, comme illustré dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
Exécutez l'utilitaire update sur vos nœuds dans l'ordre décrit dans Ordre de mise à jour des machines :
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
Où :
- component est le composant Edge à mettre à jour. Les valeurs possibles sont les suivantes :
  - edge : tous les composants Edge, à l'exception de la nouvelle interface utilisateur Edge : serveur de gestion, processeur de messages, routeur, serveur QPID, serveur Postgres
  - ldap : OpenLDAP
  - ue : Nouvelle UI Edge
  - qpid : Apigee Qpid
  - ps : Apigee PostgreSQL
  - zk : ZooKeeper
  - cs : Cassandra
- configFile est le même fichier de configuration que celui que vous avez utilisé pour définir vos composants Edge lors de l'installation de la version 4.53.00 (ou) 4.53.01.
  
  Remarque : Le fichier de configuration doit être lisible par l'utilisateur "apigee". Pour modifier le propriétaire, utilisez la commande suivante :
```
chown apigee:apigee configFile
```
Vous pouvez exécuter update.sh sur tous les composants en définissant component sur "all", mais uniquement si vous disposez d'un profil d'installation Edge tout-en-un (AIO). Exemple :
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
Si ce n'est pas déjà fait, redémarrez les composants de l'interface utilisateur sur tous les nœuds qui l'exécutent :
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
Testez la mise à jour en exécutant l'utilitaire apigee-validate sur le serveur de gestion, comme décrit dans Tester l'installation.

Si vous décidez ultérieurement d'annuler la mise à jour, suivez la procédure décrite dans Annuler la version 4.54.00.

Ordre de mise à jour des machines

L'ordre dans lequel vous mettez à jour les machines dans une installation Edge est important. Mettez à niveau vos composants dans l'ordre ci-dessous.

Mettez à niveau tous les nœuds de routeur et de processeur de messages dans tous les centres de données à l'aide de l'option -c edge.
Mettez à niveau tous les nœuds du serveur de gestion dans tous les centres de données à l'aide de l'option -c edge.
Mettez à niveau tous les nœuds LDAP dans tous les centres de données. Si vous effectuez une mise à niveau depuis Edge for Private Cloud 4.53.00, vous devrez suivre des étapes supplémentaires pour la mise à niveau LDAP.
Mettez à niveau l'UI et l'authentification unique Apigee (si elle est installée) dans tous les centres de données :
1. Si apigee-sso n'est pas installé : suivez l'Option 1 : Mettre à niveau l'UI (sans Apigee SSO) pour passer à la nouvelle UI Edge.
2. Si apigee-sso est installé : suivez l'Option 2 : Mettre à niveau l'interface utilisateur (avec Apigee SSO) pour passer à la nouvelle interface utilisateur Edge et à Apigee SSO.
Mettez à niveau tous les composants Qpid et edge-qpid-server dans tous les centres de données en suivant les étapes spéciales de Qpid.
Mettez à niveau tous les composants Postgresql et edge-postgres-server dans tous les centres de données en suivant les étapes spéciales de Postgres.
Mettez à niveau tous les composants Zookeeper dans tous les centres de données en suivant les étapes spéciales de mise à niveau de Zookeeper.
Mettez à niveau tous les composants Cassandra dans tous les centres de données en suivant les étapes spéciales de mise à niveau de Cassandra.
Il n'existe pas d'étape distincte pour mettre à jour la monétisation. Il est mis à jour lorsque vous spécifiez l'option -c edge.

Mise à niveau autonome à un nœud

Pour mettre à niveau une configuration autonome à un nœud vers la version 4.54.00 :

Lorsque vous effectuez une mise à niveau depuis Edge for Private Cloud 4.53.00, vous devez d'abord mettre à niveau LDAP en suivant les étapes de mise à niveau de la version 4.53.00 vers la version 4.54.00 avant de commencer la mise à niveau de tous les composants.

Mettez à jour tous les composants :

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

(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Mise à niveau autonome à deux nœuds

Mettez à jour les composants suivants pour une installation autonome à deux nœuds :

Consultez Topologies d'installation pour obtenir la liste des topologies Edge et des numéros de nœuds.

Mettez à jour les composants Edge sur la machine 1 :

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

Mettez à jour LDAP sur la machine 1 :

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

Mettez à jour la nouvelle interface utilisateur Edge sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Remarque : Si apigee-sso est installé, veuillez consulter la Option 2 : Mettre à niveau l'UI (avec Apigee SSO) pour savoir comment le configurer sur Apigee SSO.

Mettez à jour les composants Edge sur la machine 2 :

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

Mettez à jour Qpid sur la machine 2 :

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

Mettez à jour Postgres sur la machine 2 :

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

Mettez à jour Cassandra et ZooKeeper sur la machine 1 :

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

(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi sur la machine 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Mise à niveau de 5 nœuds

Mettez à jour les composants suivants pour une installation à cinq nœuds :

Consultez Topologies d'installation pour obtenir la liste des topologies Edge et des numéros de nœuds.

Mettez à jour les composants Edge sur les machines 2, 3 et 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour LDAP sur la machine 1 :

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

Mettez à jour la nouvelle interface utilisateur Edge sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Remarque : Si apigee-sso est installé, veuillez consulter la Option 2 : Mettre à niveau l'UI (avec Apigee SSO) pour savoir comment le configurer sur Apigee SSO.
Mettez à jour les composants Edge sur les machines 4 et 5 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour Qpid sur les machines 4 et 5 :

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

Mettez à jour Postgres sur les machines 4 et 5 :

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

Mettez à jour Cassandra et ZooKeeper sur les machines 1, 2 et 3 :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi sur la machine 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Mise à niveau d'un cluster à 9 nœuds

Mettez à jour les composants suivants pour une installation en cluster à neuf nœuds :

Consultez Topologies d'installation pour obtenir la liste des topologies Edge et des numéros de nœuds.

Mettez à jour les composants Edge sur les machines 4, 5 et 1 (routeur, processeur de messages et serveur de gestion), dans cet ordre :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour LDAP sur la machine 1 :

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

Mettez à jour la nouvelle interface utilisateur Edge sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Remarque : Si apigee-sso est installé, veuillez vous reporter à l'Option 2 : Mettre à niveau l'interface utilisateur (avec Apigee SSO) pour obtenir des instructions sur la configuration d'Apigee SSO.
Mettez à jour les composants Edge sur les machines 6, 7, 8 et 9, dans cet ordre :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour Qpid sur les machines 6 et 7 :

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

Mettez à jour Postgres sur la machine 8 :

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

Mettez à jour Postgres sur la machine 9 :

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

Mettez à jour Cassandra et ZooKeeper sur les machines 1, 2 et 3 :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi sur la machine 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Mise à niveau d'un cluster de 13 nœuds

Mettez à jour les composants suivants pour une installation en cluster à 13 nœuds :

Consultez la section Topologies d'installation pour obtenir la liste des topologies Edge et des numéros de nœuds.

Mettez à jour les composants Edge sur les machines 10, 11, 6 et 7, dans cet ordre :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour LDAP sur les machines 4 et 5 :

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

Mettez à jour la nouvelle interface utilisateur Edge sur les machines 6 et 7 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
Remarque : Si apigee-sso est installé, veuillez consulter la Option 2 : Mettre à niveau l'UI (avec Apigee SSO) pour savoir comment le configurer sur Apigee SSO.
Mettez à jour les composants Edge sur les machines 12, 13, 8 et 9, dans cet ordre :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettez à jour Qpid sur les machines 12 et 13 :

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

Mettez à jour Postgres sur la machine 8 :

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

Mettez à jour Postgres sur la machine 9 :

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

Mettez à jour Cassandra et ZooKeeper sur les machines 1, 2 et 3 :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi sur les machines 6 et 7 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Mise à niveau groupée de 12 nœuds

Mettez à jour les composants suivants pour une installation en cluster de 12 nœuds :

Consultez la section Topologies d'installation pour obtenir la liste des topologies Edge et des numéros de nœuds.

Mettez à jour les composants Edge (routeur et processeur de messages) :
- Sur les machines 2 et 3 du centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- Sur les machines 8 et 9 du centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour les composants Edge (Management Server) :
- Sur la machine 1 du centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- Sur la machine 7 du centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

Mettre à jour LDAP :

Machine 1 dans le centre de données 1 :

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

Machine 7 dans le centre de données 2 :

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

Mettez à jour les composants de la nouvelle interface utilisateur Edge :
- Sur la machine 1 du centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Remarque : Si apigee-sso est installé, veuillez vous reporter à l'Option 2 : Mettre à niveau l'interface utilisateur (avec Apigee SSO) pour obtenir des instructions sur la configuration d'Apigee SSO.
- Sur la machine 7 du centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  Remarque : Si apigee-sso est installé, veuillez vous reporter à l'Option 2 : Mettre à niveau l'interface utilisateur (avec Apigee SSO) pour obtenir des instructions sur la configuration d'Apigee SSO.
Mettez à jour les composants Edge :
- Machines 4, 5 et 6 dans le centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- Machines 10, 11 et 12 dans le centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour qpidd :
- Machines 4 et 5 dans le centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
- Machines 10 et 11 dans le centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```

Mettez à jour Postgres :

Machine 6 dans le centre de données 1 :

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

Machine 12 dans le centre de données 2 :

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

Mettez à jour Cassandra et ZooKeeper :
- Machines 1, 2 et 3 dans le centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
- Sur les machines 7, 8 et 9 du centre de données 2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(Si vous avez installé apigee-adminapi) Mettez à jour l'utilitaire apigee-adminapi :
- Machine 1 dans le centre de données 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
- Machine 7 dans le centre de données 2 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

Pour une configuration non standard

Si vous disposez d'une configuration non standard, mettez à jour les composants Edge dans l'ordre suivant :

Routeur
Processeur de messages
Serveur de gestion
LDAP
UI (UI classique ou nouvelle UI)
SSO (le cas échéant)
Qpid et edge-qpid-server
Postgres et edge-postgres-server
ZooKeeper
Cassandra
apigee-adminapi

Mettre à jour Apigee Edge 4.53.00 ou 4.53.01 vers la version 4.54.00

Qui peut effectuer la mise à jour ?

Quels composants devez-vous mettre à jour

Lectures préparatoires

Conditions préalables à la mise à niveau

Propagation automatique des paramètres de propriété

Mettre à niveau le routeur et le processeur de messages

Mettre à niveau le serveur de gestion

Mise à niveau vers OpenLDAP 2.6.10

Préparation et installation (tous les serveurs LDAP)

Étapes à suivre pour mettre à niveau LDAP de la version 4.53.00 vers la version 4.54.00

Conditions préalables et points à prendre en compte

Étapes de mise à niveau de LDAP de la version 4.53.01 vers la version 4.54.00

Mettre à niveau vers la nouvelle interface utilisateur Edge et Apigee SSO (si installé)

Option 1 : Mettre à niveau l'UI (sans Apigee SSO)

Étape 1 : Sauvegardez les fichiers de configuration

Étape 2 : Mettre à jour le fichier de configuration silencieuse pour l'authentification de base

Étape 3 : Mettre à niveau le composant d'interface utilisateur

Étape 4 : Vérifier la mise à niveau de la nouvelle interface utilisateur Edge

Option 2 : Mettre à niveau l'interface utilisateur (avec l'authentification unique Apigee)

Étape 1 : Sauvegardez les fichiers de configuration

Étape 2 : Supprimez les variables d'UI/SSO obsolètes et mettez à jour le fichier de configuration silencieux (configFile)

Étape 3 : Mettez à niveau le composant de la nouvelle interface utilisateur Edge

Étape 4 : Arrêter le apigee-sso

Étape 5 : Créez la base de données apigee_dex pour Apigee SSO dans le nœud Postgres

Étape 6 : Configurer l'authentification unique Apigee sur les nœuds OpenLDAP

Étape 7 : Configurez l'UI de gestion pour Apigee SSO et redémarrez l'UI

Étape 8 : Vérifier la mise à niveau de la nouvelle interface utilisateur Edge et d'Apigee SSO

Étape 9 : Désinstaller l'ancienne version de apigee-sso

Mise à niveau vers Qpid 10.0.1

Mettre à niveau vers Postgres 18.6

Installer un nouveau nœud Postgres de secours

Effectuer une mise à niveau sur place de Postgres

Étape préliminaire

Effectuer la mise à niveau sur place

Mettre hors service un nœud Postgres

Étapes post-mise à niveau pour Postgres

Mise à niveau vers ZooKeeper 3.8.5

Effectuer une sauvegarde

Identifier le leader, les suiveurs et les observateurs

Mettre à niveau ZooKeeper sur les nœuds observateur et suiveur

Désactiver le leader

Vérifier que le nouveau leader est élu

Responsable de la migration

Mettre à niveau vers Cassandra 5.0.8

Mises à niveau et rollback

Un seul centre de données

Plusieurs centres de données

Méthodologie de mise à niveau recommandée

Processus de rollback des points de contrôle

Exemple

Prérequis pour la mise à niveau de Cassandra

Étape 1 : Préparez la mise à niveau

Étape 2 : Mettre à niveau tous les nœuds Cassandra

Mettre à jour avec Apigee mTLS

Restaurer une mise à jour

Informations sur la mise à jour de la journalisation

Mise à jour sans temps d'arrêt

Utiliser un fichier de configuration silencieux

Mettre à jour vers la version 4.54.00 sur un nœud disposant d'une connexion Internet externe

Mettre à jour vers la version 4.54.00 à partir d'un dépôt local

Ordre de mise à jour des machines

Mise à niveau autonome à un nœud

Mise à niveau autonome à deux nœuds

Mise à niveau de 5 nœuds

Mise à niveau d'un cluster à 9 nœuds

Mise à niveau d'un cluster de 13 nœuds

Mise à niveau groupée de 12 nœuds

Pour une configuration non standard

Étape 2 : Supprimez les variables d'UI/SSO obsolètes et mettez à jour le fichier de configuration silencieux (`configFile`)

Étape 4 : Arrêter le `apigee-sso`

Étape 5 : Créez la base de données `apigee_dex` pour Apigee SSO dans le nœud Postgres

Étape 9 : Désinstaller l'ancienne version de `apigee-sso`