Rollback d'Apigee Edge 4.52.02

Si vous rencontrez une erreur lors de la mise à jour vers Edge 4.52.02, vous pouvez annuler le composant à l'origine de l'erreur, puis réessayer la mise à jour.

Vous pouvez revenir à l'une des versions majeures suivantes d'Edge 4.52.02:

  • Version 4.52.01
  • Version 4.52.00
  • Version 4.51.00

La réversion d'une version implique la réversion de tous les composants que vous avez peut-être mis à niveau. De plus, en fonction de la version à partir de laquelle vous avez commencé, vous devrez peut-être suivre des étapes spéciales avant de rétablir certains composants logiciels. Le tableau suivant répertorie les différents composants logiciels pour lesquels des étapes spéciales peuvent être nécessaires lors du rollback:

Effectuer un rollback vers la version Considérations particulières concernant les logiciels
4.52.01 Cassandra
4.52.00 Zookeeper, Cassandra, Qpid
4.51.00 Zookeeper, Postgres, Cassandra, Qpid

Vous pouvez effectuer un rollback dans deux cas:

  1. Effectuer un rollback vers une version majeure ou mineure précédente Par exemple, de la version 4.52.02 à la version 4.52.00.
  2. Effectuez un rollback vers une version de correctif précédente de la même version. Par exemple, de 4.52.00.02 à 4.52.00.01.

Pour en savoir plus, consultez le processus de publication d'Apigee Edge.

Ordre de rollback

Le rollback des composants doit suivre l'ordre inverse de leur mise à niveau, à l'exception des serveurs de gestion, qui doivent être rétablis après Cassandra. Cassandra, les composants Runtime et le serveur de gestion doivent tous être annulés en utilisant une approche par centre de données (DC-by-DC), en redirigeant temporairement le trafic vers les centres de données fonctionnels.

L'ordre général de rollback typique pour Private Cloud 4.52.02 se présente comme suit:

Centre de données unique

Pour une configuration avec un seul centre de données, la procédure de rollback aura un impact significatif sur le trafic d'exécution et certaines API de gestion.

  1. Renvoi en arrière de Qpid et d'autres composants liés aux données analytiques
  2. Routeurs et processeurs de messages de rollback
  3. Rétablir Cassandra
  4. Rollback du serveur de gestion
  5. Rétablir Postgres et Zookeeper

Plusieurs centres de données

Dans une configuration multi-centre de données, les rollbacks doivent suivre une approche par centre de données (DC-by-DC) en redirigeant temporairement le trafic vers les centres de données fonctionnels. Cela garantit la continuité du trafic, évite les temps d'arrêt et permet un processus de rollback contrôlé pour Cassandra, le serveur de gestion et les nœuds d'exécution.

  1. Renvoi en arrière de Qpid et d'autres composants liés aux analyses sur tous les DC.
  2. Bloquez le trafic dans le premier centre de données et redirigez-le vers d'autres centres de données.
  3. Rétablir les routeurs et les processeurs de messages dans le premier centre de données.
  4. Effectuez un rollback de Cassandra dans le premier centre de données.
  5. Serveur de gestion du rollback dans le premier centre de données.
  6. Débloquez le trafic dans le premier centre de données et suivez les étapes 2 à 6 jusqu'à ce que les nœuds d'exécution, Cassandra et le serveur de gestion soient annulés dans le dernier centre de données.
  7. Effectuez un rollback de Postgres, Zookeeper et LDAP sur tous les contrôleurs de domaine.

Pour vous donner une idée, supposons que vous ayez mis à niveau l'ensemble de votre cluster Cassandra, tous les serveurs de gestion et quelques processeurs de messages d'exécution (RMP) de la version 4.52.01 à la version 4.52.02 et que vous deviez effectuer un rollback. Dans ce cas, la restauration doit être effectuée comme suit:

  1. Bloquez le trafic vers le premier centre de données (centre de données) et reroutez le trafic vers les autres centres de données actifs pour assurer la continuité de service.
  2. Rollback Routers and Message Processors (routeurs et processeurs de messages de rollback) dans le premier centre de données.
  3. Annulez la modification de Cassandra dans le premier centre de données en effectuant une restauration à partir d'une sauvegarde ou d'un instantané de VM.
  4. Annulez la modification apportée au serveur de gestion dans le premier centre de données.
  5. Débloquez le trafic vers le premier centre de données.
  6. Répétez les étapes 1 à 5 pour chaque centre de données restant jusqu'à ce que tous les nœuds d'exécution, Cassandra et les serveurs de gestion aient été annulés.

Qui peut effectuer un rollback ?

L'utilisateur effectuant un rollback doit être le même que celui qui a initialement mis à jour Edge ou un utilisateur exécuté en tant que root.

Par défaut, les composants Edge s'exécutent en tant qu'utilisateur "apigee". Dans certains cas, vous pouvez exécuter des composants Edge en tant qu'utilisateurs différents. Par exemple, si le routeur doit accéder à des ports privilégiés, tels que ceux inférieurs à 1 000, vous devez exécuter le routeur en tant que root ou en tant qu'utilisateur disposant d'un accès à ces ports. Vous pouvez également exécuter un composant en tant qu'utilisateur et un autre en tant qu'utilisateur différent.

Composants avec code commun

Les composants Edge suivants partagent un code commun. Par conséquent, pour annuler l'un de ces composants sur un nœud, vous devez annuler tous ces composants sur ce nœud.

  • edge-management-server (serveur de gestion)
  • edge-message-processor (processeur de messages)
  • edge-router (routeur)
  • edge-postgres-server (Postgres Server)
  • edge-qpid-server (serveur Qpid)

Par exemple, si le serveur de gestion, le routeur et le processeur de messages sont installés sur le nœud, vous devez les désinstaller tous les trois pour annuler l'un d'entre eux.

Retour en arrière de Cassandra

Lorsqu'une mise à niveau majeure de Cassandra est effectuée sur un nœud Cassandra particulier, Cassandra modifie le schéma des données stockées sur le nœud, ce qui rend un rollback direct impossible. Il existe deux méthodes de rollback. Vous utiliserez l'une de ces méthodes en fonction de l'état de la mise à niveau que vous annulez.

Méthodes de rollback

Scénarios de rollback

Edge pour Private Cloud 4.52.02 inclut une mise à niveau de Cassandra et du pilote utilisé par le processeur de messages et le serveur de gestion pour se connecter à Cassandra. Par conséquent, les mises à niveau et le rollback de ces trois composants sont étroitement liés. Le tableau ci-dessous présente des exemples généraux de scénarios de rollback pour ces trois composants spécifiques. Le rollback des autres composants doit suivre l'ordre indiqué dans la section Ordre du rollback.

Cette section décrit différents scénarios de rollback, ainsi que la méthodologie recommandée à suivre, en fonction des approches décrites ci-dessus.

Scénario Stratégie de rollback
Centre de données unique, certains nœuds Cassandra mis à niveau Restauration à partir d'une sauvegarde
Centre de données unique, tous les nœuds Cassandra mis à niveau Restauration à partir d'une sauvegarde
Centre de données unique, tous les nœuds (Cassandra, serveur de gestion et nœuds d'exécution) mis à niveau
Plusieurs centres de données, mise à niveau de certains ou de tous les nœuds Cassandra du premier centre de données Réorganiser à partir d'un centre de données existant
Mise à niveau de plusieurs centres de données, de tous les nœuds Cassandra, du serveur de gestion et des nœuds d'exécution du premier centre de données

Cette opération doit être effectuée sur un seul centre de données à la fois.
Plusieurs centres de données, certains ou tous les nœuds Cassandra du dernier centre de données sont mis à niveau
  • Rétablir le dernier centre de données à l'aide d'une sauvegarde
  • Effectuez un rollback des centres de données restants à l'aide d'une sauvegarde ou d'une reconstruction, un centre de données à la fois.
Plusieurs centres de données, tous les nœuds Cassandra, le serveur de gestion et les nœuds d'exécution mis à niveau dans tous les centres de données

Cette opération doit être effectuée un centre de données à la fois.

En général, vous devez tenir compte des points suivants lors du rollback de Cassandra:

  1. Rollback des composants d'exécution ou de gestion

    Si vous devez rétablir des composants tels que le serveur de gestion Edge ou le processeur de messages Edge vers une version précédente d'Edge Private Cloud dans un centre de données (CD), assurez-vous que Cassandra est également rétabli dans ce centre de données spécifique en même temps. Cela est nécessaire pour éviter les défaillances de gestion et de trafic d'exécution.

  2. Rétrograder à l'aide de sauvegardes

    Les sauvegardes effectuées à partir de Cassandra 3.11.x ne sont pas compatibles avec celles de Cassandra 2.1.x. Pour activer le rollback à l'aide de la restauration de sauvegarde, assurez-vous que des sauvegardes de Cassandra 2.1.x sont effectuées avant d'effectuer la mise à niveau.

  3. Isoler le centre de données pour le rollback

    Pour éviter les temps d'arrêt, assurez-vous que le trafic est redirigé vers des centres de données entièrement fonctionnels et bloqué dans le centre de données en cours de rollback.

Rétablir Cassandra à l'aide d'une recompilation

Prérequis

  1. Vous utilisez un cluster Edge for Private Cloud 4.51.00 / 4.52.00 / 4.52.01 sur plusieurs centres de données.
  2. Vous êtes en train de mettre à niveau Cassandra de la version 2.1.X vers la version 3.11.X et vous rencontrez des problèmes lors de la mise à niveau.
  3. Vous disposez d'au moins un centre de données entièrement fonctionnel dans le cluster qui utilise toujours l'ancienne version de Cassandra (Cassandra 2.1.X).

Étapes principales

  1. Sélectionnez un centre de données (mis à niveau partiellement ou complètement) que vous souhaitez annuler. Rediriger tout le trafic des applications de ce centre de données vers un autre centre de données entièrement opérationnel.
  2. Si le routeur et le processeur de messages ont été mis à niveau, annulez la mise à niveau de tous les nœuds de routeur et de processeur de messages du centre de données, un par un.
  3. Arrêtez Cassandra sur un nœud, désinstallez-le et nettoyez toutes les données associées.
  4. Installez le bootstrap de la version précédente et configurez la version 2.1.x de Cassandra sur le nœud nettoyé.
  5. Recréez le nœud à partir du centre de données fonctionnel existant qui exécute toujours Cassandra 2.1.x.
  6. Exécutez les étapes 3 à 5 sur chaque nœud Cassandra restant du centre de données, un par un.
  7. Exécutez à nouveau la configuration du serveur de gestion dans le centre de données.
  8. Effectuez des tests pour valider le rollback. Une fois la validation effectuée, redirigez le trafic de l'application vers le centre de données restauré.
  9. Répétez les étapes ci-dessus pour les autres centres de données nécessitant un rollback, un par un.

Procédure détaillée pour effacer et utiliser les nœuds existants du cluster afin de reconstruire le nœud:

Commencez par le nœud que vous souhaitez annuler.

  1. Assurez-vous que le trafic est redirigé vers des centres de données entièrement fonctionnels avant de passer aux étapes suivantes.
  2. Si le routeur et le processeur de messages ont été mis à niveau, rétablissez la version précédente de tous les nœuds de routeur et de processeur de messages dans le centre de données, un par un.
  3. Arrêtez Cassandra sur le nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
  4. Désinstallez le logiciel Cassandra du nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
  5. Supprimez le répertoire de données du nœud: 
    rm -rf /opt/apigee/data/apigee-cassandra

  6. Téléchargez et exécutez le bootstrap de l'ancienne version d'Edge pour le cloud privé vers laquelle vous souhaitez effectuer le rollback:

    Exemple:Pour revenir à la version 4.52.01

  7. Téléchargez le bootstrap de la version 4.52.01: 
    curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
  8. Exécutez le bootstrap de la version 4.52.01: 
    sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
  9. Installez le logiciel Cassandra sur le nœud: 
    apigee-service apigee-cassandra install
  10. Ajoutez la propriété ci-dessous dans le fichier /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh. 
    JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>"

    Exemple : 

    JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=10.0.0.1"

  11. Configurez Cassandra sur le nœud: 
    /opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
  12. Une fois Cassandra opérationnel, supprimez le CWC ci-dessus du fichier ci-dessous:fichier /opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.
  13. Redémarrer le nœud Cassandra 
    apigee-service apigee-cassandra restart
  14. Exécutez la recréation sur le nœud en fournissant le nom du centre de données fonctionnel: 
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -h <node-IP> <functional-dc>

    Exemple : 

    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -h 10.0.0.1 dc-2

  15. Répétez les étapes ci-dessus sur chaque nœud que vous souhaitez annuler dans le centre de données, un par un.

Une fois tous les nœuds Cassandra du centre de données annulés et reconstruits

  1. Exécutez la configuration de l'un des nœuds de serveur de gestion du centre de données en cours de restauration. Assurez-vous que le serveur de gestion provient de la version annulée. Si ce n'est pas le cas, annulez également le rollback du serveur de gestion.

    2. Restaurer l'ancienne version du serveur de gestion

  2. Arrêtez le serveur de gestion: 
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
  3. Si vous utilisez la monétisation, désinstallez-la également: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Désinstallez edge-gateway et apigee-cassandra-client: 
    /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
     
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
  5. Téléchargez et exécutez le bootstrap de l'ancienne version. Par exemple, procédez comme suit pour télécharger et exécuter le bootstrap de la version 4.52.01 : 
    curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
     
    sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord

    6. Configuration du serveur de gestion

  6. Exécutez la configuration d'un nœud de serveur de gestion: 
    /opt/apigee/apigee-setup/bin/setup.sh -p mt -f configFile
  7. Une fois les étapes ci-dessus effectuées, redirigez le trafic vers le centre de données annulé.

Optimisation après la recompilation

Dans les étapes ci-dessus, toutes les données du nœud sont diffusées à partir du centre de données distant lors de la recréation. Vous pouvez optimiser ce processus à l'aide d'une réparation une fois que tous les réplicas ont été diffusés vers le centre de données local. Cela évite le streaming entre les centres de données et devrait être plus rapide que de reconstruire tous les nœuds à partir d'un centre de données distant.

Exemple:supposons que vous disposiez de six nœuds Cassandra dans le centre de données local. Par défaut, le facteur de réplication d'Apigee est de trois. Ainsi, chaque nœud possède 50% des données. Dans ce cas, vous pouvez reconstruire les nœuds 1 et 4 en suivant la procédure ci-dessus. Pour les nœuds 2, 3, 5 et 6, suivez les étapes ci-dessous pour restaurer la sauvegarde et exécuter une réparation.

  1. Suivez la procédure jusqu'à la fin des étapes ci-dessus, comme indiqué dans la documentation, pour reconstruire les réplicas dans le centre de données local.
  2. Pour les nœuds restants, suivez les étapes ci-dessous pour chacun d'eux, une par une.
  3. Restaurez la sauvegarde que vous avez effectuée sur ce nœud (remarque: cette sauvegarde contiendra probablement des données obsolètes, car elle a été effectuée avant que vous ne commenciez la mise à niveau de Cassandra): 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file

    Si vous disposez d'un instantané de VM du nœud, vous pouvez le restaurer au lieu de restaurer la sauvegarde Cassandra.

  4. Une fois la sauvegarde restaurée, démarrez le service Cassandra sur le nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
  5. Exécutez une réparation sur le nœud afin que les dernières données puissent être diffusées à partir d'un centre de données existant: 
    /opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -dc <local-dc-name>

    Exemple : 

    /opt/apigee/apigee-cassandra/bin/nodetool -h 10.0.0.1 repair -dc dc-1

  6. Répétez toutes les étapes ci-dessus mentionnées à l'étape 2 sur chaque nœud que vous souhaitez réparer.

Rétablir Cassandra à l'aide d'une sauvegarde / d'un instantané de VM

Cette procédure est la seule disponible si vous avez mis à niveau l'ensemble du cluster Cassandra et que vous souhaitez effectuer un rollback. De plus, les sauvegardes Apigee sont spécifiques au nœud. Il n'est pas possible de restaurer une sauvegarde effectuée à partir d'un nœud vers un autre. Les sauvegardes Cassandra incluent des informations de métadonnées de nœud (comme l'adresse IP, la position de l'anneau, etc.).

Prérequis

  1. Vous êtes en train de mettre à niveau Cassandra de la version 2.1.X vers la version 3.11.X dans le dernier centre de données et vous avez rencontré des problèmes lors de la mise à niveau.
  2. Vous disposez de sauvegardes du nœud avant la mise à niveau que vous annulez. La sauvegarde a été effectuée avant la tentative de mise à niveau de la version 2.1.X vers la version 3.11.X.

Étapes principales

  1. Choisissez un centre de données (mis à niveau partiellement ou complètement) à annuler. Redirigez tout le trafic d'exécution de ce centre de données vers un autre centre de données entièrement fonctionnel.
  2. Si le routeur et le processeur de messages ont été mis à niveau, annulez la mise à niveau de tous les nœuds de routeur et de processeur de messages du centre de données, un par un.
  3. Arrêtez Cassandra sur un nœud, désinstallez-le et nettoyez toutes les données associées.
  4. Installez le bootstrap de la version précédente et configurez la version 2.1.x de Cassandra sur le nœud nettoyé.
  5. Arrêtez le nœud Cassandra et nettoyez toutes les données associées.
  6. Restaurez le nœud Cassandra à partir de la sauvegarde effectuée avant la mise à niveau.
  7. Répétez les étapes 3 à 6 pour chacun des nœuds Cassandra restants du centre de données, un par un.
  8. Exécutez à nouveau la configuration du serveur de gestion dans le centre de données.
  9. Effectuez des tests pour valider le rollback. Une fois la validation effectuée, redirigez le trafic d'exécution vers le centre de données restauré.
  10. Répétez les étapes ci-dessus pour les autres centres de données nécessitant un rollback, un par un.
  11. (Facultatif) Exécutez la commande de réparation sur tous les nœuds Cassandra de tous les centres de données en cas d'incohérence de données entre eux.

Procédure détaillée pour annuler Cassandra à l'aide de sauvegardes/d'un instantané de VM

Commencez avec un seul nœud Cassandra dans le cluster

  1. Assurez-vous que le trafic est redirigé vers des centres de données entièrement fonctionnels avant de passer aux étapes suivantes.
  2. Si le routeur et le processeur de messages ont été mis à niveau, rétablissez la version précédente de tous les nœuds de routeur et de processeur de messages dans le centre de données, un par un.
  3. Arrêtez Cassandra sur le nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
  4. Désinstallez le logiciel Cassandra du nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
  5. Supprimez le répertoire de données du nœud: 
    rm -rf /opt/apigee/data/apigee-cassandra

  6. Téléchargez et exécutez le bootstrap de l'ancienne version d'Edge pour le cloud privé vers laquelle vous souhaitez effectuer le rollback:

    Exemple: Pour revenir à la version 4.52.01

  7. Téléchargez le bootstrap de la version 4.52.01: 
    curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
  8. Exécutez le bootstrap de la version 4.52.01: 
    sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
  9. Configurez Cassandra sur le nœud: 
    /opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
  10. Arrêtez Cassandra sur le nœud: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
  11. Supprimez le répertoire de données sur le nœud: 
    rm -rf /opt/apigee/data/apigee-cassandra/data
  12. Restaurer une sauvegarde: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
  13. Démarrer le service Cassandra sur le nœud 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
  14. Répétez les étapes sur chaque nœud Cassandra, une par une.
  15. Exécutez la configuration de l'un des nœuds de serveur de gestion du centre de données en cours de restauration. Assurez-vous que le serveur de gestion provient de la version annulée. Si ce n'est pas le cas, annulez également le rollback du serveur de gestion.
  16. Une fois les étapes ci-dessus effectuées, redirigez le trafic vers le centre de données annulé.
  17. (Facultatif) Exécutez la commande de réparation sur tous les nœuds Cassandra de tous les centres de données en cas d'incohérence de données entre eux. 
    /opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -pr

Effectuer un rollback de la mise à jour Zookeeper 3.8.3

Si vous effectuez un rollback vers les versions 4.52.00 ou 4.51.00, vous devrez suivre certaines étapes spéciales avant de faire un rollback de Zookeeper. Ces étapes sont décrites dans la section Rollback (Rétrogradation).

Si vous effectuez un rollback vers la version 4.52.01, effectuez un rollback de Zookeeper comme vous le feriez pour n'importe quel logiciel, comme indiqué dans la section Effectuer un rollback vers une version majeure ou mineure précédente ci-dessous.

Rollback Qpid

Si vous effectuez un rollback vers les versions 4.52.00 ou 4.51.00, vous devrez suivre certaines étapes spéciales avant de rétablir Qpid. Ces étapes sont décrites dans la section Rollback (Rétrogradation).

Si vous effectuez un rollback vers la version 4.52.01, effectuez un rollback de Qpid comme vous le feriez pour n'importe quel logiciel, comme indiqué dans la section Effectuer un rollback vers une version majeure ou mineure précédente.

Annuler la mise à jour de Postgres 10.17

Si vous effectuez un rollback vers la version 4.51.00, vous devrez suivre certaines étapes spéciales avant de rétablir Postgres. Ces étapes sont décrites dans la section Rollback (Rétrogradation).

Si vous effectuez un rollback vers la version 4.52.01 ou 4.52.00, effectuez un rollback de Postgres comme vous le feriez pour n'importe quel logiciel, comme indiqué dans la section Effectuer un rollback vers une version majeure ou mineure précédente ci-dessous.

Effectuer un rollback vers une version majeure ou mineure précédente

Pour effectuer un rollback vers une version majeure ou mineure précédente, procédez comme suit sur chaque nœud qui héberge le composant:

  1. Téléchargez le fichier bootstrap.sh de la version à laquelle vous souhaitez effectuer un rollback:

    • Pour revenir à la version 4.51.00, téléchargez bootstrap_4.51.00.sh.
  2. Arrêtez le composant pour effectuer un rollback :
    1. Pour annuler l'un des composants avec code commun sur le nœud, vous devez tous les arrêter, comme illustré dans l'exemple suivant: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. Pour annuler le rollback de tout autre composant du nœud, arrêtez uniquement ce composant: 
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. Si vous annulez la monétisation, désinstallez-la de tous les nœuds du serveur de gestion et du processeur de messages: 
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. Désinstallez le composant à annuler sur le nœud :
    1. Pour annuler l'un des composants avec code commun sur le nœud, vous devez tous les désinstaller en désinstallant le groupe de composants edge-gateway et apigee-cassandra-client, comme illustré dans l'exemple suivant: 
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Pour annuler tout autre composant du nœud, désinstallez uniquement ce composant, comme indiqué dans l'exemple suivant: 
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      où component est le nom du composant.

    3. Pour annuler la mise à niveau du routeur Edge, vous devez supprimer le contenu du fichier /opt/nginx/conf.d en plus de désinstaller le groupe de composants edge-gateway: 
      cd /opt/nginx/conf.d
rm -rf *
  5. Désinstallez la version 4.52.02 de apigee-setup: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. Installez la version 4.51.00 de l'utilitaire apigee-service et ses dépendances. L'exemple suivant installe la version 4.51.00 de apigee-service: 
    sudo bash /tmp/bootstrap_4.51.00.sh apigeeuser=uName apigeepassword=pWord

    Où uName et 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.

    Si un message d'erreur s'affiche, assurez-vous d'avoir téléchargé le fichier bootstrap.sh à l'étape 1.

  7. Installez apigee-setup : 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. Installez l'ancienne version du composant: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    où component est le composant à installer et configFile est votre fichier de configuration pour l'ancienne version.

  9. Si vous annulez Qpid, videz iptables: 
    sudo iptables -F
  10. Répétez cette procédure pour chaque nœud qui héberge le composant que vous annulez.

Effectuer un rollback vers une version de correctif précédente

Pour rétablir un composant à une version de correctif spécifique, procédez comme suit sur chaque nœud qui héberge le composant:

  1. Téléchargez la version spécifique du composant: 
    /opt/apigee/apigee-service/bin/apigee-service component_version install

    Où component_version correspond au composant et à la version du correctif à installer. Exemple :

    /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.51.05-0.0.3749 install

    Si vous utilisez le dépôt en ligne d'Apigee, vous pouvez déterminer les versions de composant disponibles à l'aide de la commande suivante: 

    yum --showduplicates list component

    Exemple :

    yum --showduplicates list edge-ui
  2. Utilisez apigee-setup pour installer le composant: 
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    Exemple :

    /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile

    Notez que vous ne devez spécifier que le nom du composant lors de son installation, et non sa version.

  3. Répétez cette procédure pour chaque nœud qui héberge le composant que vous annulez.

Rétablir mTLS

Pour annuler la mise à jour du mTLS, procédez comme suit sur tous les hôtes:

  1. Arrêtez Apigee: 
    apigee-all stop
  2. Arrêtez mTLS: 
    apigee-service apigee-mtls uninstall
  3. Réinstallez mTLS: 
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf