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

Apigee permet de mettre à niveau Edge pour le cloud privé directement depuis la version 4.52.02 ou 4.53.00 vers la version 4.53.01. Cette page explique comment effectuer ces mises à niveau.

Pour obtenir une présentation des chemins de mise à niveau compatibles, consultez la matrice de compatibilité des mises à niveau pour les versions Edge pour Private Cloud.

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

Cette version corrige plusieurs problèmes de sécurité. Bien que ces améliorations de sécurité soient essentielles, elles entraînent des modifications qui ne sont pas rétrocompatibles. Cela signifie que la mise à niveau nécessitera des étapes supplémentaires pour éviter toute interruption pendant ou après la mise à niveau. Pour en savoir plus, consultez cet article lorsque vous passez à la version 4.53.01 depuis d'anciennes versions de Private Cloud.

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

• Sauvegardez tous les nœuds.
  Avant de procéder à la mise à jour, nous vous recommandons de sauvegarder 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 en cas de problème de mise à jour vers une nouvelle version. 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

• Vérifier les prérequis de Cassandra
  

  Si vous avez déjà effectué une mise à niveau d'une ancienne version d'Edge pour le cloud privé vers la version 4.52.02 et que vous prévoyez maintenant de passer à la version 4.53.01, assurez-vous d'avoir effectué les étapes requises après la mise à niveau pour Cassandra. Ces étapes sont décrites dans la documentation sur la mise à niveau vers la version 4.52.02 et sont également mentionnées dans la section Conditions préalables à 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.53.01.

• Configurer des clés et des certificats IdP dans Edge pour le cloud privé 4.53.01
  

  Dans Edge for Private Cloud 4.53.01, les clés et certificats IDP utilisés dans le composant apigee-sso sont désormais configurés via un keystore. Vous devrez exporter la clé et le certificat que vous avez utilisés précédemment dans un keystore. Suivez la procédure décrite dans la section Étapes à suivre pour mettre à jour Apigee SSO à partir d'anciennes versions pour obtenir des instructions détaillées avant de mettre à jour le composant SSO.

• Exigences concernant Python
  Avant de procéder à la mise à niveau, assurez-vous que Python 3 est installé sur tous les nœuds, y compris les nœuds Cassandra.

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

Pour passer à Edge pour Private Cloud 4.53.01, 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.

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 sont conservées par la mise à jour.

Mise à niveau requise vers OpenLDAP 2.6

Voici la procédure détaillée pour mettre à niveau le service LDAP sous-jacent d'Apigee Edge pour le cloud privé, en passant de l'ancienne version OpenLDAP 2.4 à OpenLDAP 2.6. Cette mise à niveau est obligatoire pour la mise à jour vers Apigee Edge pour le cloud privé version 4.53.01 et ultérieure. Cette mise à niveau s'applique à toutes les topologies de déploiement LDAP Apigee : serveur unique, actif-passif et actif-actif (multimaître).

Conditions préalables et points à noter

• Sachez que pendant le processus de migration LDAP, les API de gestion et, par conséquent, l'UI Apigee seront complètement indisponibles 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 ne sera pas affecté. Avant de poursuivre la mise à niveau LDAP, assurez-vous d'arrêter tous les serveurs edge-management-server et edge-ui.

• La sauvegarde est essentielle : une sauvegarde complète et validée de vos données LDAP existantes est indispensable. Si vous continuez sans sauvegarde valide, vous perdrez vos données de manière irréversible. La sauvegarde doit être lancée alors 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. Une sauvegarde est nécessaire pour effectuer la mise à niveau. Sans sauvegarde, vous ne pourrez ni effectuer la mise à niveau ni revenir à la version précédente, car les étapes de mise à niveau impliquent l'effacement des données LDAP.

Préparation et installation (tous les serveurs LDAP)

Les étapes de cette section (étapes 2 à 5) sont identiques pour toutes les topologies de déploiement LDAP. Ces actions doivent être effectuées sur chaque serveur sur lequel le composant apigee-openldap est installé, quel que soit son rôle.

1. Avant de poursuivre la mise à niveau LDAP, assurez-vous d'arrêter tous les edge-management-server et edge-ui.

   apigee-service edge-management-server stop
   apigee-service edge-ui stop

2. Sauvegarder les données LDAP existantes

   Avant d'apporter des modifications, effectuez une sauvegarde complète des données LDAP actuelles de tous les serveurs LDAP. Cela crée un point de restauration sécurisé.

   • 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

   • Obtenez le nombre total d'enregistrements : enregistrez le nombre d'enregistrements dans votre annuaire pour la validation post-migration (le nombre d'enregistrements doit être identique sur tous les serveurs LDAP). Il s'agit d'une vérification de cohérence.

     # 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

3. Arrêter LDAP et nettoyer les répertoires de données

   Cette étape doit être effectuée sur tous les serveurs LDAP. Elle est obligatoire en raison du changement de version majeure et des différences structurelles sous-jacentes. Un répertoire propre permet d'éviter les conflits. 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/*

4. Installer et configurer la nouvelle version de 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 /opt/silent.conf

   • Validez la nouvelle version LDAP : une fois l'installation terminée, rechargez le profil et vérifiez que la nouvelle version LDAP est correctement installée.

     source ~/.bash_profile
     ldapsearch -VV
     Expected output:
     ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

5. Arrêter LDAP sur tous les serveurs avant la restauration des données

   Il s'agit d'une étape de synchronisation essentielle. Avant de restaurer votre sauvegarde, vous devez vous assurer 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/*

6. Restaurer des données LDAP

   La stratégie consiste à restaurer la sauvegarde sur le premier serveur actif. Ce serveur servira ensuite de source fiable, en répliquant les données sur ses pairs dans une configuration multiserveur.

   1. Identifier 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
        Note:
        -If this command returns output, the server is a passive server.
        -If it returns no output, the server is the active server.

   2. Restaurer 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 restore. Nous vous recommandons vivement de spécifier l'horodatage exact de la sauvegarde à 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

7. Démarrer 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

8. 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 à celui 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 de votre LDAP est terminée. Vous pouvez maintenant commencer à démarrer edge-management-server et edge-ui, ainsi que tous les autres composants dépendants, conformément à la procédure de mise à niveau standard de votre organisation.

Mise à niveau requise vers Cassandra 4.0.18

Apigee Edge pour le cloud privé 4.53.01 inclut une mise à niveau de Cassandra vers la version 4.0.18.

Mises à niveau et rollback

• La mise à niveau de Cassandra 3.11.X vers Cassandra 4.0.X est un processus simple. Cassandra 4.0.X, publié avec Edge pour le cloud privé 4.53.00, est compatible avec les composants d'exécution et de gestion de Private Cloud 4.52.02.
• Il n'est pas possible d'effectuer un rollback direct sur place de Cassandra 4.0.X vers 3.11.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 4.0.X plutôt que de revenir à une version antérieure.
• 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.

Un seul centre de données

La mise à niveau de Cassandra de la version 3.11.X vers la version 4.0.X au sein d'un même centre de données est transparente, 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 fortement 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 vous permettra de rétablir Cassandra sans perdre de données ni perturber le trafic de vos API. Ce centre de données supplémentaire peut être mis hors service une fois la mise à niveau terminée ou le point de contrôle 2 atteint.

Si l'ajout d'un centre de données n'est pas possible, mais que vous souhaitez toujours pouvoir effectuer un rollback, des sauvegardes seront nécessaires pour restaurer Cassandra 3.11.X. Toutefois, cette méthode est susceptible d'entraîner des temps d'arrêt et des pertes de données.

Plusieurs centres de données

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

• Les rollbacks dépendent de la présence d'au moins un centre de données exécutant l'ancienne version de Cassandra (3.11.X).
• Si l'intégralité de votre cluster Cassandra est mise à niveau vers la version 4.0.X, vous ne devez pas revenir à la version 3.11.X de Cassandra. Vous devez continuer à utiliser la version la plus récente de Cassandra avec les autres composants de Private Cloud 4.53.00 ou 4.52.02.

Méthode de mise à niveau recommandée

1. 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. Mettez à niveau tous les nœuds Cassandra d'un centre de données avant de passer au suivant.
2. Mettez en pause et validez : après avoir mis à niveau un centre de données, mettez en pause pour vous assurer que votre cluster Private Cloud, en particulier le centre de données mis à niveau, fonctionne correctement.
3. Remarque : Vous ne pouvez revenir à la version précédente de Cassandra que si au moins un centre de données exécute toujours l'ancienne version.
4. Sensible au temps : vous pouvez faire une pause 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.
5. Tests approfondis : Apigee vous 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.

Restauration en deux points de contrôle

1. Point de contrôle 1 : état initial, avec tous les composants en version 4.52.02. Une restauration complète est possible tant qu'au moins un centre de données Cassandra reste sur l'ancienne version.
2. Point de contrôle 2 : une fois que tous les nœuds Cassandra de tous les centres de données sont mis à jour. Vous pouvez revenir à cet état, mais vous ne pouvez pas revenir au point de contrôle 1.

Exemple

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

1. État de départ : les nœuds Cassandra des deux centres de données sont en version 3.11.X. Tous les autres nœuds sont sur Edge pour le cloud privé version 4.52.02. Supposons qu'il y ait trois nœuds Cassandra par centre de données.
2. Mettez à niveau DC-1 : mettez à niveau les trois nœuds Cassandra de DC-1 un par un.
3. 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 du centre de données 2. N'oubliez pas que cette pause doit être temporaire en raison des limites d'un cluster Cassandra à versions mixtes.
4. Mettez à niveau DC-2 : mettez à niveau les trois nœuds Cassandra restants dans DC-2. Il devient votre nouveau point de contrôle de restauration.
5. Mettez à niveau les autres composants : mettez à niveau les nœuds de gestion, d'exécution et d'analyse comme d'habitude dans tous les centres de données, un nœud et un centre de données à la fois. En cas de problème, vous pouvez revenir à l'état de l'étape 4.

Conditions préalables à la mise à niveau de Cassandra

1. L'ensemble du cluster est opérationnel et entièrement fonctionnel avec Cassandra 3.11.16.
2. La stratégie de compactage est définie sur LeveledCompactionStrategy (prérequis pour la mise à niveau vers la version 4.52.02).

3. Vérifiez que chaque étape ci-dessous a été effectuée lors de la mise à niveau initiale de Cassandra 3.11 dans Edge pour le cloud privé 4.52.02.

   • 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 3.11 lors de l'utilisation d'Edge pour Private Cloud 4.52.02, vous pouvez les réexécuter sans risque avant de tenter la mise à niveau vers la version 4.53.01.

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

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

Étape 2 : Mettez à 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 démarré et rejoint le cluster avant de mettre à niveau 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, patientez 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 essentielle pour assurer la stabilité du centre de données où Cassandra a été mis à niveau vers la version 4.0.X, tandis que le reste des composants Apigee reste à la version 4.52.02.

1. Pour mettre à niveau un nœud Cassandra, exécutez la commande suivante :

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

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

3. La commande ci-dessus générera un résultat semblable à celui-ci :

   Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
   Metadata is verified

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

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

5. 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 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
   /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 cache cache_entries cache_entries_cache_name_idx
   /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 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

   Si vous utilisez la monétisation, exécutez également les commandes rebuild indices 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

Étape 3 : Mettez à niveau tous les nœuds de gestion

Mettez à niveau tous les nœuds de gestion de toutes les régions, un par un :

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

Étape 4 : Mettez à niveau tous les nœuds Runtime

Mettez à niveau tous les nœuds de routeur et de processeur de messages dans toutes les régions, un par un :

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

Étape 5 : Mettez à niveau tous les composants Edge for Private Cloud 4.53.01 restants

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

Mise à niveau requise vers Zookeeper 3.8.4

Cette version d'Edge pour le cloud privé inclut une mise à niveau vers Zookeeper 3.8.4. Dans le cadre de cette mise à niveau, toutes les données Zookeeper seront migrées vers Zookeeper 3.8.4.

Avant de mettre à niveau Zookeeper, lisez le guide de maintenance de 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 du leader Zookeeper, et les autres sont configurés en tant qu'observateurs. Pour en savoir plus, consultez À propos des responsables, des abonnés, des votants et des observateurs. Les nœuds de vote élisent un responsable, après quoi ils deviennent eux-mêmes des nœuds suiveurs.

Lors du processus de mise à jour, un délai ou un échec d'écriture dans Zookeeper peuvent se produire lorsque le nœud principal est arrêté. Cela peut affecter les opérations de gestion qui écrivent dans Zookeeper, telles que l'opération de 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.

En règle générale, le processus de mise à niveau implique la création d'une sauvegarde de chaque nœud. Ensuite, mettez à niveau tous les observateurs et les nœuds suiveurs, puis mettez à niveau le nœud principal.

Effectuer une sauvegarde

Sauvegardez tous les nœuds Zookeeper à utiliser en cas de restauration. Notez qu'une restauration rétablira l'état de Zookeeper au moment de la sauvegarde. Remarque : Tous les déploiements ou modifications d'infrastructure dans Apigee depuis la sauvegarde (dont les informations sont stockées dans Zookeeper) seront perdus lors de la restauration.

  /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 prendre des instantanés ou des sauvegardes de VM pour la restauration ou le rétablissement (si nécessaire).

Identifier le responsable, les abonnés et les observateurs

Remarque : Les exemples de commandes ci-dessous utilisent l'utilitaire nc pour envoyer des données à ZooKeeper. Vous pouvez également utiliser d'autres utilitaires pour envoyer des données à ZooKeeper.

1. Si nc n'est pas installé sur le nœud ZooKeeper, installez-le :

     sudo yum install nc

2. 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.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
     Clients:
      /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
     
     Latency min/avg/max: 0/0.2518/41
     Received: 647228
     Sent: 647339
     Connections: 4
     Outstanding: 0
     Zxid: 0x400018b15
     Mode: follower
     Node count: 100597

   Dans la ligne Mode de la sortie pour les nœuds, vous devriez voir "observer", "leader" ou "follower" (ce qui signifie un votant qui n'est pas le leader) en fonction de la configuration du nœud. Remarque : Dans une installation autonome d'Edge avec un seul nœud ZooKeeper, Mode est défini sur "standalone".

3. 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 observateurs et suiveurs comme suit :

1. Téléchargez et exécutez le bootstrap d'Edge pour le cloud privé 4.53.01, comme décrit dans Mettre à jour vers la version 4.53.01 sur un nœud avec une connexion Internet externe. Le processus varie probablement selon que le nœud dispose d'une connexion Internet externe ou que vous effectuez une installation hors connexion.
2. 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 cs,zk) ou plus tard. Apigee vous recommande de mettre à niveau Zookeeper en premier et de vous assurer que votre cluster fonctionne correctement avant de mettre à niveau d'autres composants.
3. Répétez les étapes ci-dessus sur chacun des nœuds observateur et suiveur de Zookeeper.

Arrêter le leader

Une fois que tous les nœuds observateurs et suiveurs ont été mis à niveau, arrêtez le nœud principal. 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 d'écriture dans ZooKeeper, telles que les actions de déploiement des proxys ou les modifications de l'infrastructure Apigee (ajout ou suppression de processeurs de messages, etc.).

Vérifier que le nouveau responsable a été élu

En suivant les étapes de la section Identifier le leader, les nœuds suiveurs et les observateurs ci-dessus, vérifiez qu'un nouveau leader a été élu parmi les nœuds 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.

Mettre à niveau la variante optimale

Suivez les mêmes étapes que dans Mettre à niveau Zookeeper sur les nœuds observateur et 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.

Mise à niveau de Nginx 1.26 dans Edge-Router

La mise à niveau vers Edge pour Private Cloud 4.53.01 à partir de versions précédentes ne met pas automatiquement à niveau le logiciel Nginx vers la dernière version (1.26.x). Cela permet d'éviter tout effet secondaire d'exécution accidentel suite aux modifications documentées dans Modifications de Nginx 1.26 dans Apigee Edge 4.53.01. Vous pouvez mettre à niveau manuellement Nginx de la version 1.20.x vers la version 1.26.x après la validation dans les environnements inférieurs. Pour effectuer une mise à niveau manuelle :

1. Assurez-vous que le nœud de routeur de périphérie dispose de la dernière version du logiciel 4.53.01.

   /opt/apigee/apigee-service/bin/apigee-service edge-router version

2. Vérifier la version de Nginx que vous exécutez actuellement

   /opt/nginx/sbin/nginx -V

   Si vous utilisez une ancienne version de Nginx, vous pouvez suivre les étapes ci-dessous pour mettre à niveau Nginx vers la version 1.26.X sur le nœud du routeur.

3. Arrêter le processus edge-router sur le nœud du routeur

   /opt/apigee/apigee-service/bin/apigee-service edge-router stop

4. Mettre à niveau le logiciel nginx sur le nœud du routeur

   dnf update apigee-nginx

5. Vérifier que la version Nginx a été mise à jour

   /opt/nginx/sbin/nginx -V

6. Démarrer le processus du routeur sur le nœud

   /opt/apigee/apigee-service/bin/apigee-service edge-router start

7. Répétez la procédure sur chaque nœud de routeur, un par un.

Mise à niveau requise vers Postgres 17

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

La plupart des systèmes de production Edge utilisent deux nœuds Postgres configurés pour la réplication maître-veille. Pendant le processus de mise à jour, lorsque les nœuds Postgres sont hors service pour la mise à jour, les données analytiques sont toujours écrites dans 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 des 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 durée de la mise à niveau. Une fois la mise à niveau terminée, vous pouvez désactiver le nouveau nœud de secours Postgres.

  Le nœud de secours Postgres supplémentaire est nécessaire 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 maître 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 le stockage réseau pour vos nœuds Postgres, comme le recommande 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 spécifient d'installer et de mettre hors service un nouveau nœud de secours Postgres.

  Avant de commencer le processus de mise à jour, prenez un instantané réseau du data store utilisé par Postgres. Ensuite, si des erreurs se produisent lors de la mise à jour et que vous êtes obligé d'effectuer une restauration, vous pouvez restaurer le nœud Postgres à partir de cet instantané.

Installer un nouveau nœud de secours Postgres

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.52.02 ou 4.53.00), et non pour la version 4.53.01.

Pour effectuer l'installation, utilisez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge.

Pour créer un nœud standby Postgres :

1. Sur le maître 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.

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

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

3. 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 maître. 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

4. 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 master:
      PG_MASTER=192.168.56.103
      # IP address of the new standby node
      PG_STANDBY=192.168.56.102

   2. Désactivez SELinux comme décrit dans Installer l'utilitaire Edge apigee-setup.

   3. Si vous utilisez actuellement Edge 4.52.02 :

      1. Téléchargez le fichier Edge bootstrap_4.52.02.sh dans /tmp/bootstrap_4.52.02.sh  :

         curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh

      2. Installez l'utilitaire apigee-service Edge et les dépendances :

         sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      Si vous utilisez actuellement Edge 4.53.00 :

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

      2. Installez l'utilitaire apigee-service Edge et les dépendances :

         sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

   4. Installez l'utilitaire apigee-setup à l'aide de apigee-service :

      /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 :

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      Vérifiez qu'il s'agit de la sauvegarde.

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 maître et l'hôte de secours pour mettre à jour la propriété max_locks_per_transaction sur apigee-postgresql :

1. Si ce n'est pas le cas, créez le fichier /opt/apigee/customer/application/postgresql.properties.
2. Modifiez la propriété de ce fichier et attribuez-la à apigee :

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

3. Ajoutez la propriété suivante au fichier :

   conf/postgresql.conf+max_locks_per_transaction=30000

4. Configurez apigee-postgresql :

   apigee-service apigee-postgresql configure

5. Redémarrez apigee-postgresql :

   apigee-service apigee-postgresql restart

Effectuer la mise à niveau sur place

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

1. Mettre à niveau postgres sur l'hôte maître

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

2. Exécutez la commande de configuration sur l'hôte maître :

   apigee-service apigee-postgresql setup -f /opt/silent.conf

3. Exécutez la commande de configuration sur l'hôte maître :

   apigee-service apigee-postgresql configure

4. Redémarrez l'hôte maître :

   apigee-service apigee-postgresql restart

5. Configurez-le comme maître :

   apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf

6. Assurez-vous que l'hôte maître a démarré :

   apigee-service apigee-postgresql wait_for_ready

7. Arrêtez le serveur de secours :

   apigee-service apigee-postgresql stop

8. Mettez à niveau la base de données de secours.

   Remarque : Si cette étape génère une erreur ou échoue, vous pouvez l'ignorer. update.sh tente de démarrer le serveur de secours avec une configuration incorrecte. Si l'installation de Postgres est mise à niveau vers la version 17, l'erreur peut être ignorée.

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

9. Assurez-vous que le nœud de secours est arrêté :

   apigee-service apigee-postgresql stop

10. Supprimez l'ancienne configuration de secours :

    rm -rf /opt/apigee/data/apigee-postgresql/

11. Configurez la réplication sur le serveur de secours :

    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf

12. 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, le serveur de secours démarrera correctement.

Mise hors service d'un nœud Postgres

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

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

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

   Vous devriez voir le UUID du nœud à la fin de la sortie, sous la forme suivante :

   "type" : [ "postgres-server" ],
   "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

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

4. Sur le nœud maître 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

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

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

6. 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 maître. Vous ne devriez voir que la ligne suivante dans ce fichier :

   host replication apigee existing_standby_ip/32 trust

7. Supprimez l'UUID du nœud de secours de ZooKeeper en effectuant l'appel d'API Edge Management 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 à suivre après la mise à niveau de 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 reconstruire progressivement ses statistiques au fil du temps à mesure que les requêtes sont exécutées et lorsque le démon autovacuum s'exécute. Toutefois, tant que les statistiques ne sont pas reconstruites, 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 maître Postgres. Vous pouvez également exécuter ANALYZE pour quelques tables à la fois.

Étapes à suivre pour mettre à jour Apigee SSO à partir d'anciennes versions

Dans Edge for Private Cloud 4.53.01, les clés et certificats du FIdP utilisés dans le composant apigee-sso sont désormais configurés via un keystore. Vous devrez exporter la clé et le certificat utilisés précédemment dans un keystore, le configurer, puis procéder à la mise à jour du SSO comme d'habitude.

1. Identifiez la clé et le certificat existants utilisés pour configurer l'IdP :

   1. Récupérez le certificat en recherchant la valeur de SSO_SAML_SERVICE_PROVIDER_CERTIFICATE dans le fichier de configuration de l'installation SSO ou en interrogeant le composant apigee-sso pour conf_login_service_provider_certificate.

      Utilisez la commande suivante sur le nœud SSO pour interroger apigee-sso afin d'obtenir le chemin d'accès au certificat IdP. Dans le résultat, recherchez la valeur sur la dernière ligne.

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

   2. Récupérez la clé en recherchant la valeur de SSO_SAML_SERVICE_PROVIDER_KEY dans le fichier de configuration de l'installation de l'authentification unique ou en interrogeant le composant apigee-sso pour conf_login_service_provider_key.

      Utilisez la commande suivante sur le nœud SSO pour interroger apigee-sso afin d'obtenir le chemin d'accès de la clé IdP. Dans le résultat, recherchez la valeur sur la dernière ligne.

      apigee-service apigee-sso configure -search conf_login_service_provider_key

2. Exportez la clé et le certificat vers un keystore :
   1. Exportez la clé et le certificat vers un keystore PKCS12 :

      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Paramètres :

      • certificate_path : chemin d'accès au fichier de certificat récupéré à l'étape 1.a.
      • key_path : chemin d'accès au fichier de clé privée récupéré à l'étape 1.b.
      • keystore_path : chemin d'accès au keystore nouvellement créé contenant le certificat et la clé privée.
      • alias : alias utilisé pour la paire clé/certificat dans le keystore.

      Pour en savoir plus, consultez la documentation OpenSSL.

   2. (Facultatif) Exportez la clé et le certificat de PKCS12 vers un keystore JKS :

      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Paramètres :

      • PKCS12_keystore_path : chemin d'accès au keystore PKCS12 créé à l'étape 2.a, contenant le certificat et la clé.
      • destination_keystore_path : chemin d'accès au nouveau keystore JKS dans lequel le certificat et la clé seront exportés.
      • alias : alias utilisé pour la paire clé/certificat dans le keystore JKS.

   Pour en savoir plus, consultez la documentation keytool.

3. Définissez l'utilisateur "apigee" comme propriétaire du fichier keystore de sortie :

   sudo chown apigee:apigee <keystore_file>

4. Ajoutez les propriétés suivantes dans le fichier de configuration Apigee SSO et mettez-les à jour avec le chemin d'accès au fichier keystore, le mot de passe, le type de keystore et l'alias :

   # Path to the keystore file
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
   
   # Keystore password
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore
   
   # Keystore type
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12
   
   # Alias within keystore that stores the key and certificate
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert 

5. Mettez à jour le logiciel Apigee SSO sur le nœud SSO comme d'habitude à l'aide de la commande suivante :

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

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 avec Apigee mTLS

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

• Désinstallez Apigee mTLS.
• Réinstallez Apigee mTLS.

Restaurer une mise à jour

En cas d'échec de la mise à jour, vous pouvez essayer de corriger le problème, puis exécuter à nouveau update.sh. 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 Revenir à la version 4.53.01 pour obtenir des instructions détaillées.

Informations sur la journalisation des mises à jour

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 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 à 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 de la même machine que le routeur, puis vous ajoutez à nouveau le routeur à l'équilibreur de charge.

1. Mettez à jour les machines dans le bon ordre pour votre installation, comme décrit dans Ordre de mise à jour des machines.
2. 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).
3. 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.
4. Rendez le routeur à nouveau accessible.
5. Répétez les étapes 2 à 4 pour les autres routeurs.
6. Poursuivez la mise à jour pour les machines restantes de votre installation.

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

• Sur un nœud combiné de routeur et de 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 pour le cloud privé 4.52.02 ou 4.53.00.

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

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

1. Si des tâches cron sont configurées pour effectuer une opération de réparation sur Cassandra, désactivez-les jusqu'à ce que la mise à jour soit terminée.
2. Connectez-vous à votre nœud en tant qu'utilisateur racine pour installer les RPM Edge.
3. Désactivez SELinux comme décrit dans Installer l'utilitaire apigee-setup Edge.
4. 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

5. Si vous utilisez actuellement Edge 4.52.02 ou 4.53.00 :

   1. Téléchargez le fichier Edge bootstrap_4.53.01.sh sur /tmp/bootstrap_4.53.01.sh :

      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

   2. Installez l'utilitaire apigee-service Edge 4.53.01 et les dépendances en exécutant la commande suivante :

      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      Où uName:pWord correspond au nom d'utilisateur et au 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é. Sinon, le programme d'installation l'installe 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.52.02 ou 4.53.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 vers la version 4.53.01.

Mettre à jour vers la version 4.53.01 à 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 le vôtre.

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

1. Créez un dépôt local 4.53.01 comme décrit dans "Créer un dépôt Apigee local" sur la page Installer l'utilitaire Edge apigee-setup.
2. 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.53.01.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.53.01.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.53.01.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.

3. 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 apigee-setup Edge.
   2. Sur le nœud distant, téléchargez le fichier bootstrap_4.53.01.sh Edge dans /tmp/bootstrap_4.53.01.sh :

      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.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.53.01.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.

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

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

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

7. 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.52.02 ou 4.53.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 /tmp/sa_silent_config

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

9. 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 vers la version 4.53.01.

Ordre de mise à jour de l'appareil

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

• Vous devez mettre à jour tous les nœuds LDAP avant de mettre à jour d'autres composants. Vous devrez suivre des étapes spécifiques pour mettre à niveau LDAP.
• Vous devez mettre à jour tous les nœuds Cassandra et ZooKeeper. Si vous effectuez une mise à niveau depuis la version 4.52.02, suivez les étapes spéciales pour mettre à niveau Cassandra. Vous devrez suivre la procédure spéciale pour mettre à niveau Zookeeper vers la version 4.52.02 ou 4.53.00.
• Vous devez mettre à niveau tous les serveurs de gestion, ainsi que les routeurs et les processeurs de messages à l'aide de l'option "-c edge" pour les mettre à jour.
• Vous devez mettre à niveau tous les nœuds Postgres en suivant les étapes spéciales pour mettre à niveau Postgres.
• Vous devez mettre à jour les composants edge-qpid-server et edge-postgres-server dans tous les centres de données.
• Vous devez mettre à niveau tous les nœuds Qpid.
• Vous devez mettre à niveau les nœuds de l'interface utilisateur Edge, ainsi que les nœuds de la nouvelle interface utilisateur Edge et de l'authentification unique(le cas échéant).
• 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.

Licence autonome à un nœud

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

1. Mettez à jour tous les composants :

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

2. (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.

1. Mettez à jour LDAP sur la machine 1 :

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

2. Mettez à jour Cassandra et ZooKeeper sur la machine 1 :

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

3. Mettez à jour les composants Edge sur la machine 1 :

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

4. Mettez à jour Postgres sur la machine 2 :

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

5. Mettez à jour les composants Edge sur la machine 1 :

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

6. Mettez à jour Qpid sur la machine 2 :

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

7. Mettez à jour l'UI sur la machine 1 :

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

8. (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

9. (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.

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

1. Mettez à jour LDAP sur la machine 1 :

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

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

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

3. Mettez à jour les composants Edge sur les machines 1, 2 et 3 :

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

4. Mettez à jour Postgres sur la machine 4 :

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

5. Mettez à jour Postgres sur la machine 5 :

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

6. Mettez à jour les composants Edge sur les machines 4 et 5 :

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

7. Mettez à jour Qpid sur la machine 4 :

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

8. Mettez à jour Qpid sur la machine 5 :

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

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

10. (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

11. (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.

12. 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 groupée de 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.

1. Mettez à jour LDAP sur la machine 1 :

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

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

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

3. Mettez à jour les composants Edge sur les machines 1, 4 et 5 (serveur de gestion, processeur de messages, routeur) dans cet ordre :

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

4. Mettez à jour Postgres sur la machine 8 :

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

5. Mettez à jour Postgres sur la machine 9 :

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

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

7. Mettez à jour Qpid sur les machines 6 et 7 :

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

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

9. (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

10. (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.

11. 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 groupée 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.

1. Mettez à jour LDAP sur les machines 4 et 5 :

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

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

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

3. Mettez à jour les composants Edge sur les machines 6, 7, 10 et 11, dans cet ordre :

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

4. Mettez à jour Postgres sur la machine 8 :

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

5. Mettez à jour Postgres sur la machine 9 :

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

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

7. Mettez à jour Qpid sur les machines 12 et 13 :

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

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

9. (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

10. (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.

11. 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 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 les machines 6 et 7 :

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

Mise à niveau groupée 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.

1. Mettre à jour LDAP :
   1. Machine 1 dans le centre de données 1

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

   2. Machine 7 dans le centre de données 2

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

2. Mettez à jour Cassandra et ZooKeeper :
   1. Machines 1, 2 et 3 du centre de données 1 :

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

   2. Sur les machines 7, 8 et 9 du centre de données 2 :

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

3. Mettez à jour les composants Edge :
   1. Sur les machines 1, 2 et 3 du centre de données 1 :

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

   2. Sur les machines 7, 8 et 9 du centre de données 2

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

4. Mettez à jour Postgres :
   1. Machine 6 dans le centre de données 1

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

   2. Machine 12 dans le centre de données 2

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

5. Mettez à jour les composants Edge :
   1. Machines 4, 5 et 6 du centre de données 1

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

   2. Machines 10, 11 et 12 dans le centre de données 2

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

6. Mise à jour de qpidd :
   1. Machines 4 et 5 du centre de données 1
      1. Mettez à jour qpidd sur la machine 4 :

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

      2. Mettez à jour qpidd sur la machine 5 :

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

   2. Machines 10 et 11 du centre de données 2
      1. Mettez à jour qpidd sur la machine 10 :

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

      2. Mettez à jour qpidd sur la machine 11 :

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

7. Mettez à jour la nouvelle UI (ue) ou l'UI classique (ui) :
   1. Machine 1 dans le centre de données 1 :

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

   2. Machine 7 dans le centre de données 2 :

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. (Si vous avez installé apigee-adminapi) : mise à jour de l'utilitaire apigee-adminapi :
   1. Machine 1 dans le centre de données 1 :

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

   2. Machine 7 dans le centre de données 2 :

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

9. (Si vous avez installé Apigee SSO) Mettez à jour Apigee SSO :
   1. Machine 1 dans le centre de données 1 :

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   2. Machine 7 dans le centre de données 2 :

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

10. Redémarrez le nouveau composant de l'interface utilisateur Edge (edge-management-ui) ou le composant classique de l'interface utilisateur Edge (edge-ui) sur les machines 1 et 7 :

    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

Pour une configuration non standard

Si votre configuration n'est pas standard, mettez à jour les composants Edge dans l'ordre suivant :

1. LDAP
2. Cassandra
3. ZooKeeper
4. Serveur de gestion
5. Processeur de messages
6. Routeur
7. Postgres
8. Edge, c'est-à-dire le profil "-c edge" sur tous les nœuds dans l'ordre suivant : nœuds avec serveur Qpid, serveur Edge Postgres.
9. qpidd
10. Interface utilisateur Edge (classique ou nouvelle)
11. apigee-adminapi
12. Apigee SSO

Une fois la mise à jour terminée, veillez à redémarrer le composant Edge UI sur toutes les machines sur lesquelles il est exécuté.