Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Mettre à jour Apigee Edge 4.51.00, 4.52.00 ou 4.52.01 vers la version 4.52.02

Apigee permet de mettre à niveau Edge pour le cloud privé directement depuis les versions 4.51.00, 4.52.00 ou 4.52.01 vers la version 4.52.02. Cette page explique comment effectuer ces mises à niveau.

Qui peut effectuer la mise à jour ?

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

Une fois les RPM Edge installés, n'importe qui 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.

Mettre à jour les prérequis

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

Sauvegarder tous les nœuds
Avant de procéder à la mise à jour, nous vous recommandons d'effectuer une sauvegarde complète de 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 d'avoir 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 Sauvegarder et restaurer.
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
```
Remarque : Assurez-vous que la configuration edge-management-server de votre version existante s'exécute correctement, sans échec. Résolvez les éventuels échecs de configuration du serveur de gestion Edge des versions précédentes avant de poursuivre la mise à niveau.
Assurez-vous que la stratégie de compaction Cassandra est définie sur LeveledCompactionStrategy.
En fonction de votre version actuelle, apportez les modifications nécessaires à la stratégie de compaction Cassandra. Suivez les étapes ci-dessous, puis revenez à la procédure de mise à niveau principale :
- Si vous effectuez une mise à niveau depuis la version 4.51.00, consultez le document sur la stratégie de compaction Cassandra pour la version 4.51.00.
- Si vous effectuez une mise à niveau à partir de la version 4.52.00, consultez le document sur la stratégie de compaction Cassandra pour la version 4.52.00.
- Si vous effectuez une mise à niveau à partir de la version 4.52.01, consultez le document sur la stratégie de compaction Cassandra pour la version 4.52.01.

Étapes spéciales à prendre en compte pour la mise à niveau

Pour passer à Edge pour le cloud privé 4.52.02, envisagez d'exécuter des étapes spécifiques pour mettre à niveau certains logiciels. Les étapes à suivre dépendent de votre version actuelle. Consultez le tableau ci-dessous pour connaître les différents logiciels nécessitant des étapes supplémentaires, puis suivez les instructions détaillées pour chacun d'eux. Une fois les tâches nécessaires effectuées, revenez à la procédure de mise à niveau principale pour poursuivre le processus.

Version actuelle	Logiciels nécessitant des étapes spéciales pour la mise à niveau vers la version 4.52.02
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

Après avoir effectué les étapes nécessaires en fonction de votre version, revenez à la procédure de mise à niveau principale pour continuer.

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 seront conservées après la mise à jour.

Mise à niveau vers Zookeeper 3.8.3

Edge pour le cloud privé 4.52.02 n'inclut pas de mise à niveau de ZooKeeper. Toutefois, si vous effectuez une mise à niveau à partir d'une version antérieure à la version 4.52.01, vous devez suivre la procédure de mise à niveau de ZooKeeper décrite ci-dessous.

Si vous effectuez une mise à niveau à partir des versions 4.51.00 ou 4.52.00 d'Edge pour le cloud privé, reportez-vous à la procédure Mise à niveau requise vers Zookeeper 3.8.3 pour mettre à niveau Zookeeper.
Si vous effectuez une mise à niveau depuis la version 4.52.01 d'Edge pour le cloud privé, vous devriez déjà utiliser la version 3.8.3 de ZooKeeper. Vous n'avez donc pas besoin de suivre de procédure spéciale pour mettre à niveau ZooKeeper.

Remarque :

La mise à niveau d'Edge pour le cloud privé de la version 4.52.01 vers la version 4.52.02 est simplifiée, car Zookeeper et Cassandra sont généralement colocalisés sur le même hôte ou la même machine virtuelle. Il n'est donc pas nécessaire de suivre des procédures de mise à niveau distinctes pour Zookeeper en plus de la mise à niveau importante de Cassandra.

Si Zookeeper doit être mis à jour en suivant des étapes spécifiques, mettez à niveau Zookeeper dans tous les centres de données en mettant à jour un nœud à la fois. Une fois que tous les nœuds Zookeeper ont été mis à jour à l'échelle mondiale, mettez à niveau Cassandra un centre de données à la fois, en suivant la procédure décrite plus loin dans cet article.

La commande suivante facilite la mise à niveau distincte de Zookeeper :

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

Pour effectuer un rollback de Zookeeper, utilisez la procédure de rollback standard de Zookeeper. Si un rollback devient nécessaire pour Cassandra ou d'autres composants, ces composants doivent être restaurés. Un rollback de Zookeeper n'est pas nécessaire.

Passer à Postgres 14

Si vous effectuez une mise à niveau d'Edge pour le cloud privé 4.51.00 vers la version 4.52.02, vous devez suivre la procédure de mise à niveau de Postgres, même si Edge pour le cloud privé 4.52.02 n'inclut pas de mise à niveau de Postgres. La mise à niveau d'Edge pour le cloud privé 4.51.00 vers la version 4.52.02 nécessite des étapes de mise à niveau Postgres supplémentaires. Veuillez consulter la section Mise à niveau requise vers Postgres 14.
Si vous effectuez une mise à niveau d'Edge pour le cloud privé 4.52.00 ou 4.52.01 vers la version 4.52.02, aucune étape de mise à niveau de Postgres supplémentaire n'est requise.

Mettre à niveau vers Cassandra 3.11.16

Apigee Edge pour le cloud privé 4.52.02 inclut une mise à niveau de Cassandra vers la version 3.11.16. Cassandra est un composant essentiel d'Apigee. Cette mise à niveau inclut également des mises à jour du logiciel pilote dans divers composants d'exécution et de gestion utilisés pour interroger et écrire dans Cassandra.

Comme il s'agit d'une mise à niveau majeure, certaines modifications du modèle de données d'Apigee dans Cassandra ont été nécessaires pour garantir des performances optimales dans les versions plus récentes. Bien que ces modifications soient minimes, le processus de mise à niveau perturbe certaines API de gestion lorsqu'il est lancé. Les API de gestion concernées sont listées dans les sections correspondantes ci-dessous.

De plus, le processus de mise à niveau perturbe un plus grand nombre de flux de proxy d'exécution et d'API de gestion dans le centre de données en cours de mise à niveau. Il est essentiel que vous isoliez votre trafic d'exécution et de gestion du centre de données en cours de mise à niveau afin de minimiser ces perturbations. Pour en savoir plus, consultez les sections Centre de données unique et Plusieurs centres de données ci-dessous.

Remarque : L'outil cassandra-cli n'est plus compatible avec Cassandra 3.X et n'est pas disponible.

Portail des développeurs : documentation des API

Le portail des développeurs Drupal Apigee offre diverses fonctionnalités pour documenter vos API. Bien qu'il soit recommandé de ne plus utiliser le portail des développeurs basé sur Drupal 7, si vous l'utilisez toujours et que vous profitez de sa fonctionnalité SmartDocs, le document Utiliser les API SmartDocs s'applique à vous. Si vous utilisez des versions plus récentes du portail des développeurs, la mise à niveau n'aura aucun impact sur la documentation de l'API pendant cette mise à niveau.

Lorsque vous mettez à niveau Apigee vers la version 4.52.02, les modèles d'API créés à l'aide de la fonctionnalité SmartDocs du portail des développeurs Drupal 7 ne sont pas migrés automatiquement vers la version plus récente. Vous devez exporter manuellement chaque modèle à l'aide du portail des développeurs, puis l'importer à nouveau une fois la mise à niveau effectuée.

Terminologie utilisée ci-dessous

Exécution : l'exécution englobe la gestion du trafic de votre proxy d'exécution. Il inclut toutes les opérations effectuées par vos routeurs et processeurs de messages pour traiter efficacement une requête d'API d'exécution pour les proxys existants. Toutefois, il n'inclut pas le déploiement de nouveaux proxys ni de nouvelles révisions de proxys.

Gestion : la gestion inclut l'administration de votre système Apigee Edge. Cela inclut, sans s'y limiter, les déploiements, les modifications d'applications, de produits, de serveurs cibles, de keystores, etc. Toutes les API de gestion (et leurs clients tels que l'UI Apigee et le portail des développeurs) sont incluses dans ce champ d'application.

Lors de cette mise à niveau, le trafic d'exécution et de gestion est impacté dans la région ou le centre de données (CD) où la mise à jour est effectuée. Quel que soit le centre de données en cours de mise à jour, certaines API de gestion sont concernées dans tous les centres de données. Cet impact est indiqué après chaque étape.

Dans chaque étape ci-dessous, l'état de l'exécution et de la gestion est décrit à mesure que vous progressez dans les différentes étapes de la procédure de mise à niveau.

Stratégies de mise à niveau

Plusieurs centres de données

La mise à niveau doit être effectuée un centre de données à la fois pour assurer la continuité du trafic et éviter les temps d'arrêt. Avant de mettre à niveau un contrôleur de domaine, le trafic doit être redirigé vers d'autres contrôleurs de domaine fonctionnels.

Remarque :

Pour éviter tout impact sur le trafic lors de la mise à niveau, suivez une approche centre de données par centre de données en redirigeant temporairement le trafic hors du centre de données en cours de mise à niveau. Cela garantit un processus de mise à niveau contrôlé pour Cassandra, Management Server et les nœuds d'exécution tout en maintenant la disponibilité du service.

Pour une configuration à deux centres de données, suivez ces étapes générales :

Redirigez le trafic de DC-1 vers DC-2 et bloquez le trafic entrant vers DC-1.
Mettez à niveau DC-1, y compris Cassandra, Management Server et les composants d'exécution.
Redirigez le trafic vers DC-1 et bloquez le trafic entrant vers DC-2.
Mettez à niveau DC-2, y compris Cassandra, le serveur de gestion et les composants du runtime.

Ce processus assure une gestion fluide du trafic lors de la mise à niveau. Un schéma similaire doit être suivi pour les configurations comportant plus de deux centres de données, où le trafic est temporairement redirigé vers des centres de données entièrement mis à niveau ou non encore mis à niveau.

Un seul centre de données

Pour une configuration à un seul centre de données, la procédure de mise à niveau aura un impact important sur le trafic d'exécution et sur certaines API de gestion. Les options suivantes sont disponibles pour une configuration à un seul centre de données.

Développez votre cluster Edge pour le cloud privé vers un centre de données temporaire en ajoutant un centre de données à côté de celui existant pour gérer le trafic pendant la mise à niveau, puis mettez hors service l'un des centres de données une fois le processus de mise à niveau terminé.
Si vous ne pouvez pas étendre votre infrastructure à un centre de données supplémentaire, préparez-vous à un temps d'arrêt et planifiez la mise à niveau pendant les périodes de faible trafic pour minimiser l'impact sur les API de gestion et le trafic d'exécution.

Il est conseillé de s'étendre à un centre de données supplémentaire pour éviter tout impact sur le trafic d'exécution et les API de gestion. Lors de la mise à niveau, les impacts sur le centre de données mis à niveau incluent, sans s'y limiter, les domaines suivants :

Actualisation des jetons OAuth par les API Runtime
API Runtime utilisant la règle d'entité des accès
API de gestion listant les applications de développeur
API de gestion pour lister les produits

L'impact décrit ci-dessus s'ajoute à celui des API de gestion spécifiques qui resteront non fonctionnelles dans tous les centres de données jusqu'à ce qu'ils soient tous mis à niveau. Ces API de gestion sont listées dans les étapes des sections suivantes.

Restauration : vue d'ensemble

Impact pendant le rollback
Le rollback de Cassandra 3.11.x vers 2.1.x affecte le trafic d'exécution et de gestion dans le centre de données (DC) où le rollback est effectué. De plus, certaines API de gestion peuvent subir des perturbations dans tous les centres de données, quel que soit celui qui est en cours de restauration.
Suivre l'approche de rollback DC par DC
La restauration doit être effectuée un centre de données à la fois pour maintenir la continuité du service et éviter les temps d'arrêt. Avant de lancer le rollback dans un centre de données spécifique, assurez-vous que le trafic de l'application est redirigé vers un autre centre de données entièrement opérationnel.
Rétablir un cluster partiellement mis à niveau
Si au moins un centre de données reste entièrement opérationnel sur l'ancienne version de Cassandra (2.1.22), les autres CD mis à niveau peuvent être restaurés en effectuant une reconstruction à partir du CD Cassandra 2.1.X entièrement fonctionnel.
Rollback à l'échelle du cluster
Si l'ensemble du cluster Cassandra a été mis à niveau et qu'un rollback est nécessaire, il doit être effectué à l'aide de sauvegardes ou d'instantanés de VM. Cette approche est complexe et entraînera probablement un temps d'arrêt temporaire ou une perte de données.
Points à prendre en compte avant la mise à niveau
Il est important de vous familiariser avec les procédures de rétablissement 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.

Rétablir des clusters avec un seul centre de données

La mise à niveau de Cassandra de la version 2.1.x vers la version 3.11.x peut avoir un impact significatif sur le trafic d'exécution et certaines API de gestion. Ces impacts s'appliquent également lors de la restauration et peuvent entraîner des temps d'arrêt ou des pertes de données.

Pour les charges de travail de production, il est fortement recommandé de provisionner un nouveau centre de données avant la mise à niveau. Cela permet de revenir à une version antérieure de manière plus sûre, sans perte de données ni interruption du trafic d'API. Le centre de données supplémentaire peut être mis hors service une fois la mise à niveau terminée.

Si l'ajout d'un centre de données n'est pas possible, mais que la fonctionnalité de rollback est toujours requise, assurez-vous d'effectuer des sauvegardes fiables avant la mise à niveau. Il est possible de restaurer Cassandra 2.1.x à partir de sauvegardes, mais cette approche peut entraîner une indisponibilité du service et une perte de données potentielle.

Restauration de clusters avec plusieurs centres de données

La restauration de plusieurs centres de données s'effectue centre de données par centre de données. Dans cette approche, le trafic du centre de données en cours de restauration est redirigé vers d'autres centres de données fonctionnels. Cela permet de garantir un processus de restauration contrôlé et isolé pour Cassandra, Management Server et les nœuds d'exécution afin d'éviter toute interruption du trafic.

Pour en savoir plus, consultez la section Rétablir la mise à jour de Cassandra 3.11.16.

Étape 0 : État de départ

Les composants Zookeeper, Postgres et LDAP sont déjà mis à niveau vers les versions 4.52.02. Votre Edge pour un cluster de cloud privé est stable et fonctionne. Si un rollback est nécessaire, le cluster sera restauré dans cet état.
Cassandra dans Apigee s'exécute avec la version 2.1.22.
Composants Edge :

Le serveur de gestion communique avec Cassandra via un ancien protocole Thrift.
Serveurs d'exécution (processeurs de messages et routeurs) communiquant avec Cassandra via un ancien protocole Thrift.

État de l'exécution à ce stade	État de gestion à ce stade
L'exécution est entièrement fonctionnelle	Gestion entièrement fonctionnelle

É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.

Modifiez Cassandra pour qu'il utilise LeveledCompactionStrategy.
Sauvegardez Cassandra à l'aide d'Apigee.
Prenez des instantanés de VM des nœuds Cassandra (si possible).
Créez un fichier de configuration de mise à niveau Cassandra sur chaque nœud Cassandra à l'adresse /opt/apigee/apigee-cassandra/cass_upgrade.conf avec le contenu suivant :
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
Si le fichier ne peut pas être créé à l'emplacement /opt/apigee/apigee-cassandra/cass_upgrade.conf, créez le fichier /opt/silent.conf avec le même contenu sur chaque nœud Cassandra.
Attention : Le programme d'installation de la mise à niveau d'Apigee recherchera le fichier aux emplacements listés ci-dessus. Si le fichier n'est présent dans aucun des emplacements listés ci-dessus, la mise à niveau échouera et un message semblable à celui ci-dessous s'affichera :
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
Dans ce cas, la mise à niveau échouera, mais il est probable que le service Cassandra sur le nœud soit à l'arrêt. Vous pouvez démarrer le service Cassandra comme d'habitude et réessayer la mise à niveau en plaçant le fichier de configuration dans l'un des emplacements prévus. De plus, si le fichier est trouvé, mais que les configurations fournies sont incorrectes (par exemple, les identifiants Cassandra sont incorrects), la mise à niveau échouera et une erreur semblable à celle ci-dessous s'affichera :
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
Dans ce cas, de même, démarrez le service Cassandra s'il est arrêté lorsque la mise à niveau échoue, puis réessayez la mise à niveau après avoir corrigé les configurations dans le fichier.
Si vous utilisez la fonctionnalité SmartDocs du portail des développeurs Apigee Drupal 7, exportez chacun de vos modèles en les téléchargeant au format JSON depuis l'UI du portail des développeurs. Ces modèles devront être réimportés dans Apigee une fois les serveurs de gestion mis à jour.
Assurez-vous que les ports 9160 et 9042 sont accessibles depuis tous les composants Edge vers les nœuds Cassandra, si ce n'est pas déjà le cas. Pour en savoir plus, consultez Exigences concernant les ports.

Étape 2 : Redirigez le trafic hors du premier centre de données

Bloquez le trafic d'exécution et de gestion entrant depuis le premier centre de données.
Redirigez tout le trafic d'exécution et les API de gestion vers les autres centres de données fonctionnels.
Vérifiez que le trafic d'exécution et de gestion est correctement géré par les autres centres de données.

Étape 3 : Mettre à niveau tous les nœuds Cassandra du premier centre de données

Mettez à niveau tous les nœuds Cassandra du centre de données 1, un par un. Exécutez les commandes suivantes sur chaque nœud, une par une :
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```

Une fois le nœud 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

La commande ci-dessus génère un résultat semblable à ce qui suit :

Cassandra version is verified - [cqlsh 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified

Une fois la mise à niveau terminée, exécutez la commande post_upgrade suivante sur chaque nœud Cassandra, un par un :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

État de l'exécution à ce stade	État de gestion à ce stade
Trafic d'exécution bloqué sur les centres de données en cours de mise à niveau L'exécution fonctionne parfaitement sur d'autres centres de données	Trafic de gestion bloqué sur les centres de données en cours de mise à niveau. La fonction de gestion suivante est dégradée après la mise à niveau de Cassandra dans d'autres centres de données : API Management pour créer un produit d'API avec un environnement API Management pour mettre à jour un produit d'API avec un environnement API Management pour supprimer une organisation

Étape 4 : Mettez à niveau tous les nœuds de gestion du premier centre de données

Mettez à niveau tous les nœuds de gestion du centre de données :

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

État de l'exécution à ce stade	État de gestion à ce stade
Trafic d'exécution bloqué sur les centres de données en cours de mise à niveau L'exécution est entièrement fonctionnelle	Trafic de gestion bloqué sur les centres de données en cours de mise à niveau. La fonction de gestion suivante est dégradée après la mise à niveau de Cassandra : API Management pour créer un produit d'API avec un environnement API Management pour mettre à jour un produit d'API avec un environnement API Management pour supprimer une organisation

Étape 5 : Mettez à niveau tous les nœuds d'exécution du premier centre de données

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

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

État de l'exécution à ce stade	État de gestion à ce stade
Trafic d'exécution bloqué sur les centres de données en cours de mise à niveau L'exécution fonctionne parfaitement sur d'autres centres de données	Trafic de gestion bloqué sur les centres de données en cours de mise à niveau. La fonction de gestion suivante est dégradée après la mise à niveau de Cassandra dans d'autres centres de données : API Management pour créer un produit d'API avec un environnement API Management pour mettre à jour un produit d'API avec un environnement API Management pour supprimer une organisation

Étape 6 : Redirigez le trafic vers le premier centre de données

Une fois le premier centre de données mis à niveau avec Cassandra, les composants d'exécution et le serveur de gestion, réactivez le trafic d'exécution et de gestion vers le premier centre de données.
Assurez-vous que le trafic d'exécution et de gestion est correctement acheminé entre les centres de données.

Étape 7 : Mettez à niveau les autres centres de données

Répétez les étapes 1 à 6 pour les autres centres de données, un par un, en redirigeant le trafic hors de ces centres de données, en mettant à jour le logiciel Apigee et en réactivant le trafic sur ces centres de données.

Étape 8 : Réexécutez l'étape de mise à niveau sur tous les nœuds de gestion

Réexécutez la commande de mise à niveau suivante sur tous les nœuds de gestion de tous les centres de données :

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

Étape 9 : [Facultatif] Importer des smartdocs précédemment exportés

Une fois tous les serveurs de gestion mis à niveau, vous pouvez importer les modèles Smart Docs que vous aviez exportés à l'étape 1. Vous pourrez le faire plus tard.

Vous ne devez effectuer cette opération que si vous utilisez un portail des développeurs basé sur Drupal 7 et la fonctionnalité SmartDocs.

État de l'exécution à ce stade	État de gestion à ce stade
L'exécution est entièrement fonctionnelle	Gestion entièrement fonctionnelle

Étape 10 : Supprimez les tables inutilisées

Exécutez la commande suivante pour supprimer les anciennes tables inutilisées du cluster Cassandra. Tant que cette commande n'est pas exécutée, vous ne pouvez pas utiliser certaines fonctionnalités de Cassandra (comme la configuration d'une nouvelle authentification : les anciens mécanismes d'authentification continueront de fonctionner). Cette commande ne peut être exécutée que sur un seul nœud du cluster.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

Étape 11 : Mettre à niveau tous les composants Edge et autres composants restants pour Private Cloud 4.52.02

Mettez à niveau tous les nœuds edge-qpid-server et edge-postgres-server restants dans toutes les régions, un par un.

À ce stade, si vous effectuez une mise à niveau à partir de versions antérieures à Edge for Private Cloud 4.52.01, suivez les étapes supplémentaires pour mettre à niveau Qpid et Postgres, respectivement, puis mettez à niveau les composants restants en suivant ces étapes.

Passer à Qpid J-Broker

Même si Edge for Private Cloud 4.52.02 n'inclut pas de mise à niveau vers Qpid, si vous effectuez une mise à niveau à partir de versions antérieures à la version 4.52.01, vous devez suivre les étapes pour mettre à niveau Qpid.

Si vous effectuez une mise à niveau d'Edge pour le cloud privé 4.51.00 ou 4.52.00 vers la version 4.52.02, vous devez suivre des étapes supplémentaires pour la mise à niveau de Qpid. Veuillez consulter la section Mettre à niveau Qpid si vous passez de la version 4.51.00 ou 4.52.00 à la version 4.52.02.
Si vous passez d'Edge for Private Cloud 4.52.01 à 4.52.02, vous devriez déjà utiliser la dernière version de Qpid Broker. Aucune étape supplémentaire de mise à niveau de Qpid n'est nécessaire.

Nouvelle interface utilisateur Edge

Cette section liste les points à prendre en compte concernant l'interface utilisateur Edge. Pour en savoir plus, consultez Nouvelle interface utilisateur Edge pour le cloud privé.

Installer l'interface utilisateur Edge

Une fois l'installation initiale terminée, Apigee vous recommande d'installer l'interface utilisateur Edge, qui est une interface utilisateur améliorée pour les développeurs et les administrateurs d'Apigee Edge pour le cloud privé.

Notez que l'UI Edge vous oblige à désactiver l'authentification de base et à utiliser un IDP tel que SAML ou LDAP.

Pour en savoir plus, consultez Installer la nouvelle interface utilisateur Edge.

Mettre à jour l'UI Edge

Pour mettre à jour le composant de l'interface utilisateur Edge, tenez compte de la version d'Edge pour le cloud privé à partir de laquelle vous effectuez la mise à niveau :

De la version 4.51.00 à la version 4.52.00 (avec la nouvelle interface utilisateur Edge déjà installée) : suivez les instructions de mise à niveau de cette section pour le composant edge-management-ui.

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 corriger le problème, puis exécuter update.sh à nouveau. Vous pouvez exécuter la mise à jour plusieurs fois. Elle reprendra là où elle s'était arrêtée.

Si l'échec vous oblige à revenir à la version précédente, consultez Effectuer un rollback vers la version 4.52.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 le nom de fichier update_username.log.

Si vous n'avez 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 à cinq nœuds ou plus.

Pour effectuer une mise à niveau sans temps d'arrêt, vous devez supprimer chaque routeur de l'équilibreur de charge, un par un. Mettez ensuite à jour le routeur et tous les autres composants sur la même machine que le routeur, puis 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 le moment est venu de 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 les machines restantes de votre installation.

Tenez compte des points suivants avant et après la mise à jour :

Sur le nœud combiné du routeur et du processeur de messages :
- Avant la mise à jour, procédez comme suit :
  1. Rendez le routeur inaccessible.
  2. Rendez le processeur de messages inaccessible.
- Après la mise à jour, procédez comme suit :
  1. Rendez le processeur de messages accessible.
  2. Rendez 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. Le fichier de configuration silencieuse doit être le même que celui que vous avez utilisé pour installer Edge 4.50.00 ou 4.51.00.

Mise à jour vers la version 4.52.02 sur un nœud avec 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 de RPM nécessite un accès racine, vous pouvez effectuer la configuration Edge sans accès racine.
Installez yum-utils et yum-plugin-priorities :
Remarque : Si votre système d'exploitation est RHEL 8.0 à 8.6, ignorez cette étape.
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
Désactivez SELinux comme décrit dans Installer l'utilitaire apigee-setup Edge.
Si vous effectuez l'installation sur Oracle 7.x, exécutez la commande suivante :
```
sudo yum-config-manager --enable ol7_optional_latest
```

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

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

Si vous utilisez actuellement Edge 4.51.00 :
1. Téléchargez le fichier Edge bootstrap_4.52.02.sh sur /tmp/bootstrap_4.52.02.sh :
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. Installez l'utilitaire apigee-service Edge 4.52.02 et les dépendances en exécutant la commande suivante :
```
sudo bash /tmp/bootstrap_4.52.02.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 1.8 est installé. Dans le cas contraire, le programme d'installation l'installera pour vous.
  
  Utilisez l'option JAVA_FIX pour spécifier comment gérer l'installation de Java. JAVA_FIX prend les valeurs suivantes :
  - I : installez OpenJDK 1.8 (par défaut).
  - C : continuer sans installer Java.
  - Q : Quitter. Pour cette option, vous devez installer Java vous-même.
3. Utilisez apigee-service pour mettre à jour l'utilitaire apigee-setup, comme dans 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 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 dans 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
```
  Procédez dans 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 :
    - cs : Cassandra
    - edge : tous les composants Edge, à l'exception de l'UI Edge : serveur de gestion, processeur de messages, routeur, serveur Qpid, serveur Postgres
    - ldap : OpenLDAP
    - ps : postgresql
    - qpid : qpidd
    - sso : Apigee SSO (si vous avez installé SSO)
    - ue : nouvelle interface utilisateur Edge
    - ui : interface utilisateur Edge classique
    - zk : ZooKeeper
  - 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.50.00 ou 4.51.00.
  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 ./sa_silent_config
```
7. Si ce n'est pas déjà fait, redémarrez les composants de l'interface utilisateur Edge sur tous les nœuds qui les exécutent :
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-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 par la suite d'annuler la mise à jour, suivez la procédure décrite dans Annuler la mise à jour 4.52.02.

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

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

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 le vôtre.

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

Créez un dépôt local 4.52.02 comme décrit dans "Créer un dépôt Apigee local" dans Installer l'utilitaire apigee-setup Edge.
REMARQUE : Si vous possédez déjà un dépôt, vous pouvez y ajouter le dépôt 4.52.02 comme décrit dans "Mettre à jour un dépôt Apigee local" sous Installer l'utilitaire Edge apigee-setup.
Pour 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.52.02.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.52.02.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 :
```
sudo bash /tmp/repos/bootstrap_4.52.02.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.
Pour installer apigee-service à l'aide du serveur Web Nginx :
1. Configurez le serveur Web Nginx comme décrit dans "Installer à partir du dépôt à l'aide du serveur Web Nginx" dans Installer l'utilitaire Edge apigee-setup.
2. Sur le nœud distant, téléchargez le fichier bootstrap_4.52.02.sh Edge vers /tmp/bootstrap_4.52.02.sh :
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
  Où uName:pWord sont le nom d'utilisateur et le mot de passe que vous avez définis précédemment pour le dépôt, et remoteRepo est l'adresse IP ou le nom DNS du nœud du dépôt.
3. Sur le nœud distant, installez l'utilitaire apigee-setup Edge et les dépendances :
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
  Où uName:pWord sont le nom d'utilisateur et le mot de passe du dépôt.
Utilisez apigee-service pour mettre à jour l'utilitaire apigee-setup, comme dans 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 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 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. Vous mettez généralement à jour les composants suivants :
  - cs : Cassandra
  - edge : tous les composants Edge, à l'exception de l'UI Edge : serveur de gestion, processeur de messages, routeur, serveur Qpid, serveur Postgres
  - ldap : OpenLDAP
  - ps : postgresql
  - qpid : qpidd
  - sso : Apigee SSO (si vous avez installé SSO)
  - ue Nouvelle interface utilisateur Edge
  - ui : interface utilisateur Edge classique
  - zk : ZooKeeper
- 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.50.00 ou 4.51.00.
  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 /tmp/sa_silent_config
```
Si ce n'est pas déjà fait, redémarrez les composants de l'UI sur tous les nœuds qui l'exécutent :
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-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 mise à jour vers la version 4.52.02.

Ordre de mise à jour de la machine : mise à niveau à partir de la version 4.51.00 (ou) 4.52.00 (ou) 4.52.01

L'ordre dans lequel vous mettez à jour les machines d'une installation Edge est important :

Vous devez mettre à jour tous les nœuds ZooKeeper dans les centres de données avant de mettre à niveau tous les autres composants. Si vous effectuez une mise à niveau depuis Edge Private Cloud 4.51.00 ou 4.52.00, vous devrez également suivre des étapes supplémentaires pour mettre à niveau ZooKeeper.
Vous devez mettre à jour PostgreSQL dans tous les centres de données. Si vous effectuez une mise à niveau depuis Edge Private Cloud 4.51.00, vous devrez également suivre des étapes supplémentaires pour mettre à niveau PostgreSQL.
Vous devez mettre à jour les nœuds LDAP dans tous les centres de données.
Vous devez mettre à jour tous les nœuds Cassandra, Management Server, Message Processor et Router, un centre de données à la fois, jusqu'à ce que tous les centres de données soient mis à niveau.
Vous devez mettre à jour les composants edge-qpid-server et edge-postgres-server dans tous les centres de données.
Vous devez mettre à niveau les nœuds Qpid dans tous les centres de données. Si vous effectuez une mise à niveau depuis Edge Private Cloud 4.51.00 ou 4.52.00, vous devrez également suivre des étapes supplémentaires pour mettre à niveau Qpid.
Mettez à jour l'UI Edge et la nouvelle UI Edge, ainsi que les nœuds SSO dans tous les centres de données.
Il n'existe pas d'étape distincte pour mettre à jour la monétisation. Il est mis à jour lorsque vous spécifiez l'option de bordure -c.
Remarque : Après avoir mis à jour le composant Edge UI, vous devez redémarrer le service Edge UI, comme décrit dans les instructions d'installation de la mise à jour.

Licence autonome à un nœud

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

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 :

Pour obtenir la liste des topologies Edge et des numéros de nœuds, consultez Topologies d'installation.

Mettez à jour Zookeeper sur la machine 1 :

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

Mettez à jour Postgres sur la machine 2 :

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

Mettez à jour LDAP sur la machine 1 :

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

Mettez à jour Cassandra sur la machine 1 :

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

Mettez à jour les composants Edge sur les machines 1 et 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 l'UI sur la machine 1 :

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

(Si vous avez installé apigee-adminapi) Mise à jour de l'utilitaire apigee-adminapi sur la machine 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Si vous avez installé Apigee SSO) Mettez à jour Apigee SSO sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
où sso_config_file est le fichier de configuration que vous avez créé lors de l'installation de l'authentification unique.

Redémarrez le composant Edge UI sur la machine 1 :

/opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Mise à niveau à cinq nœuds

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

Pour obtenir la liste des topologies Edge et des numéros de nœuds, consultez Topologies d'installation.

Mettez à jour ZooKeeper sur les machines 1, 2 et 3 :

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

Mettez à jour Postgres sur la machine 4 :

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

Mettez à jour Postgres sur la machine 5 :

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

Mettez à jour LDAP sur la machine 1 :

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

Mettez à jour Cassandra sur les machines 1, 2 et 3 :

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

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

Mettez à jour Qpid sur la machine 4 :

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

Mettez à jour Qpid sur la machine 5 :

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

Mettez à jour l'interface utilisateur Edge :
- UI classique : si vous utilisez l'UI classique, mettez à jour le composant ui sur la machine 1, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
- Nouvelle UI Edge : si vous avez installé la nouvelle UI Edge, mettez à jour le composant ue sur la machine appropriée (qui n'est pas forcément la machine 1) :
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
```
(Si vous avez installé apigee-adminapi) Mise à jour de l'utilitaire apigee-adminapi sur la machine 1 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Si vous avez installé Apigee SSO) Mettez à jour Apigee SSO sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
où sso_config_file est le fichier de configuration que vous avez créé lors de l'installation de l'authentification unique.
Redémarrez le composant d'interface utilisateur :
- UI classique : si vous utilisez l'UI classique, redémarrez le composant edge-ui sur la machine 1, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- Nouvelle interface utilisateur Edge : si vous avez installé la nouvelle interface utilisateur Edge, redémarrez le composant edge-management-ui sur la machine appropriée (il ne s'agit pas forcément de la machine 1) :
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

Pour obtenir la liste des topologies Edge et des numéros de nœuds, consultez Topologies d'installation.

Mettez à jour ZooKeeper sur les machines 1, 2 et 3 :

/opt/apigee/apigee-setup/bin/update.sh -c zk -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 LDAP sur la machine 1 :

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

Mettez à jour Cassandra sur les machines 1, 2 et 3 :

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

Mettez à jour les composants Edge sur les machines 1, 4, 5, 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 la nouvelle UI (ue) ou l'UI classique (ui) sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -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
```
(Si vous avez installé Apigee SSO) Mettez à jour Apigee SSO sur la machine 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
où sso_config_file est le fichier de configuration que vous avez créé lors de l'installation de l'authentification unique.
Redémarrez le composant d'interface utilisateur :
- UI classique : si vous utilisez l'UI classique, redémarrez le composant edge-ui sur la machine 1, comme le montre l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- Nouvelle interface utilisateur Edge : si vous avez installé la nouvelle interface utilisateur Edge, redémarrez le composant edge-management-ui sur la machine appropriée (il ne s'agit pas forcément de la machine 1) :
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

Pour obtenir la liste des topologies Edge et des numéros de nœuds, consultez Topologies d'installation.

Mettez à jour ZooKeeper sur les machines 1, 2 et 3 :

/opt/apigee/apigee-setup/bin/update.sh -c zk -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 LDAP sur les machines 4 et 5 :

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

Mettez à jour Cassandra sur les machines 1, 2 et 3 :

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

Mettez à jour les composants Edge sur les machines 6, 7, 10, 11, 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 la nouvelle UI (ue) ou l'UI classique (ui) sur les machines 6 et 7 :
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(Si vous avez installé apigee-adminapi) Mise à jour de l'utilitaire apigee-adminapi sur les machines 6 et 7 :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Si vous avez installé Apigee SSO) Mettez à jour Apigee SSO sur les machines 6 et 7 :
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
où sso_config_file est le fichier de configuration que vous avez créé lors de l'installation de l'authentification unique.
Redémarrez le composant d'interface utilisateur :
- UI classique : si vous utilisez l'UI classique, redémarrez le composant edge-ui sur les machines 6 et 7, comme indiqué dans l'exemple suivant :
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- Nouvelle interface utilisateur Edge : si vous avez installé la nouvelle interface utilisateur Edge, redémarrez le composant edge-management-ui sur les machines 6 et 7 :
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

Pour obtenir la liste des topologies Edge et des numéros de nœuds, consultez Topologies d'installation.

Mettez à jour ZooKeeper sur les machines 1, 2, 3, 7, 8 et 9 dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
Mettez à jour Postgres sur les machines 6 et 12 dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Mettez à jour LDAP sur les machines 1 et 7 dans les deux contrôleurs de domaine :
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
Bloquez le trafic dans DC-1 et assurez-vous que tout le trafic est redirigé vers DC-2.
Mettez à jour Cassandra sur les machines 1, 2 et 3 du centre de données 1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
Mettez à jour le serveur de gestion sur la machine 1 dans DC-1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour le routeur et le processeur de messages sur les machines 2 et 3 dans DC-1 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Débloquez le trafic dans DC-1, validez DC-1, puis passez à DC-2 en bloquant le trafic dans DC-2 et en le redirigeant vers DC-1.
Mettez à jour Cassandra sur les machines 7, 8 et 9 dans DC-2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
Mettez à jour le serveur de gestion sur la machine 7 dans DC-2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour le routeur et le processeur de messages sur les machines 8 et 9 dans DC-2 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Débloquez le trafic dans DC-2. Les deux contrôleurs de domaine gèrent désormais le trafic.
Réexécutez la commande de mise à jour sur tous les serveurs de gestion des différents centres de données sur les machines 1 et 7 :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour edge-qpid-server et edge-postgres-server sur les machines 4, 5, 6, 10, 11 et 12 dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Mettez à jour Qpid sur les machines 4, 5, 10 et 11 dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
Mettez à jour la nouvelle interface utilisateur (ue) ou l'interface utilisateur classique (ui) dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
```
(Si vous avez installé apigee-adminapi) Mettez à jour apigee-adminapi dans les deux centres de données :
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Si vous avez installé Apigee SSO) Mettez à jour les nœuds Apigee SSO dans les deux centres de données :
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
Redémarrez le nouveau composant de l'interface utilisateur Edge (edge-management-ui) ou le composant classique de l'interface utilisateur Edge (edge-ui) dans les deux centres de données :
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```