Cette page a été traduite par l'API Cloud Translation.

Mise à jour d'Apigee Edge 4.16.01/4.16.05 vers la version 4.17.01

Edge pour Private Cloud version 4.17.01

Quelles versions d'Edge pouvez-vous mettre à jour vers la version 4.17.01 ?

Vous pouvez mettre à jour Apigee Edge versions 4.16.01.0x et 4.16.05.x vers 4.17.01 à l'aide de ce procédure.

Si votre version d’Edge est antérieure à la version 4.16.01, vous devez d’abord migrer vers version 4.16.01, puis passer à la version 4.17.01.

Vous pouvez migrer la version 4.15.07 d'Apigee Edge vers la version 4.16.01.
Si votre version d’Edge est antérieure à la version 4.15.07, vous devez d’abord migrer vers vers la version 4.15.07, puis vers la version 4.16.01.
- Si vous effectuez une migration à partir d'Edge version 4.14.04 ou ultérieure: migrez directement vers la version 4.15.07.
- Si vous effectuez une migration à partir de la version Edge 4.14.01: vous devez d'abord migrer vers la version 4.14.04, puis migrer vers la version 4.15.07.

Qui peut effectuer la mise à jour

L'utilisateur qui exécute la mise à jour doit être celui qui a installé Edge à l'origine, ou un en tant qu'utilisateur racine.

Une fois les RPM Edge installés, n'importe quel utilisateur peut les configurer.

Quels composants devez-vous mettre à jour ?

Vous devez mettre à jour tous les composants Edge. Edge ne prend pas en charge une configuration qui contient des composants à partir de plusieurs versions.

Retour à une version antérieure de Zookeeper en cas de mise à jour depuis 4.16.01

La version du RPM Zookeeper dans Edge for Private Cloud 4.16.01 est apigee-zookeeper-3.4.5-1.0.905.noarch.rpm. Dans les versions ultérieures d'Edge, la version de ZooKeeper a été redéfinie sur apigee-zookeeper-3.4.5-0.0.94x. Cela empêche yum de mettre à niveau Zookeeper vers une version ultérieure à partir de la version 4.16.01. La façon de corriger il s'agit d'exécuter yum rétrograder apigee-zookeeper avant de mettre à jour ZooKeeper.

Vous pouvez vérifier votre version de Zookeeper à l'aide de la commande suivante:

> rpm -qa |grep apigee-zookeeper

Si cette commande renvoie la version de Zookeeper:

apigee-zookeeper-3.4.5-1.0.905

Vous devez ensuite revenir à la version antérieure.

Propagation automatique de la propriété paramètres

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

Mettre à jour les prérequis

Vérifiez les conditions préalables suivantes avant de mettre à niveau Apigee Edge:

Sauvegarder tous les nœuds
Pour des raisons de sécurité, nous vous recommandons d'effectuer une sauvegarde complète de tous les nœuds avant d'effectuer la mise à jour raisons. Utilisez la procédure relative à votre version actuelle de Edge pour effectuer la sauvegarde.

Cela vous permet de disposer d'un plan de sauvegarde, au cas où la mise à jour vers une nouvelle version fonctionne correctement. Pour en savoir plus sur la sauvegarde, consultez Sauvegarde et restauration.
Vérifier 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 statut

Gérer une mise à jour ayant échoué

Si la mise à jour échoue, vous pouvez essayer de résoudre le problème, puis exécuter update.sh à nouveau. Vous pouvez exécuter la mise à jour plusieurs fois pour qu'elle continue à l'endroit où elle s'était arrêtée désactivée.

Si l'échec nécessite un rollback vers la version précédente, consultez la section Processus de rollback de la version 4.17.01 pour obtenir plus d'informations.

Informations sur la mise à jour de la journalisation

Par défaut, le fichier update.sh écrit les informations de journal dans:

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

Si l'utilisateur exécutant l'utilitaire update.sh n'a pas accès celui-ci, il écrit le journal dans le répertoire /tmp sous la forme d'un fichier nommé update_username.log.

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

Mise à niveau requise vers la version 8 du JDK Java

Cette version d'Edge nécessite que vous ayez installé la version 8 du JDK Java sur tous les appareils Edge les nœuds de traitement. Vous pouvez installer Oracle JDK 8 ou OpenJDK 8. Si Java JDK 8 n'est pas installé déjà, le script de mise à jour peut l'installer pour vous.

Dans le cadre de la mise à jour de Java 8, certains algorithmes de chiffrement TLS ne sont plus disponibles dans Oracle JDK 8. Pour la liste complète, consultez la section « Suites de chiffrement désactivées par défaut » à l'adresse http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html.

Obligatoire pour activer le dépôt EPEL

Vous devez activer les packages supplémentaires pour Enterprise Linux (ou EPEL) pour installer ou mettre à jour Edge. La commande à utiliser dépend sur votre version de RedHat/CentOS:

Pour RedHat/CentOS 7.x:
> wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; tpm -ivh epel-release-latest-7.noarch.rpm
Pour RedHat/CentOS 6.x:
wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm; tpm -ivh epel-release-latest-6.noarch.rpm

Obligatoire en cas de mise à jour lors de l'utilisation authentification externe

Vous pouvez intégrer un service d'annuaire externe dans un cloud privé Apigee Edge existant l'installation. Cette fonctionnalité est conçue pour fonctionner avec tout service d’annuaire prenant en charge LDAP, comme Active Directory, OpenLDAP, etc. Une solution LDAP externe permet aux systèmes aux administrateurs de gérer les informations d’identification des utilisateurs à partir d’un service de gestion d’annuaire centralisé, externes aux systèmes comme Apigee Edge qui les utilisent.

Consultez la page Ressources externes Configuration de l'authentification.

Lorsque l'authentification externe est activée, la plupart des clients utilisent le compte SAM Active Directory name comme nom d'utilisateur pour l'authentification, au lieu d'une adresse e-mail utilisée par Serveur Edge OpenLDAP.

Si vous avez intégré un service d'annuaire externe, ajoutez la ligne suivante au fichier votre fichier de configuration lors de la mise à jour d'Edge vers la version 4.17.01:

IS_EXTERNAL_AUTH="true"

Cette ligne configure Edge pour prendre en charge un nom de compte, plutôt qu'une adresse e-mail, comme le nom d'utilisateur.

Mise à niveau requise vers Qpid 1.35

Cette version contient une mise à jour obligatoire de Qpid 1.35. Dans le cadre de la mise à jour d'un nœud Qpid, vous devez:

Empêchez temporairement les routeurs et les processeurs de messages d'écrire sur le nœud Qpid en bloquant le port 5672 sur le nœud Qpid. Vous pouvez utiliser la commande suivante pour bloquer ce port sur Nœud Qpid:
> sudo iptables -A INPUT -p tcp --destination-port 5672 ! -s "nom d'hôte" -i eth0 -j DROP
Attendez que la file d'attente Qpid vide les messages pour vous assurer que le nœud Qpid a traité tous les avant la mise à jour. Utilisez la commande suivante pour vous assurer que la file d'attente de messages Qpid est vide:
> qpid-stat -q
Mettez à jour le nœud Qpid.
Débloquez le port 5672 sur le nœud Qpid pour permettre l'accès depuis les routeurs et les processeurs de messages. Utilisez la commande suivante pour débloquer ce port:
> sudo iptables -F

Notez que si vous utilisez iptables pour d'autres règles, vous pouvez utiliser l'option "-D" pour inverser modification spécifique:
> sudo iptables -D INPUT -p tcp --destination-port 5672 ! -s "nom d'hôte" -i eth0 -j DROP

Ce processus est décrit en détail ci-dessous pour chaque topologie de périphérie.

Mise à niveau requise vers Postgres 9.4

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

Pendant le processus de mise à jour, alors que les nœuds Postgres sont indisponibles pour la mise à jour, les données d'analyse sont toujours écrit dans les nœuds Qpid. Après la mise à jour et la remise en ligne des nœuds Postgres, les données sont ensuite envoyées aux nœuds Postgres.

Le nœud de secours Postgres supplémentaire est requis si vous devez effectuer un rollback de la mise à jour ou motif. Si vous devez effectuer un rollback de la mise à jour, le nouveau nœud de secours Postgres devient le maître Nœud Postgres après le rollback. Par conséquent, lorsque vous installez le nouveau nœud de secours Postgres, doit se trouver sur un nœud répondant à toutes les exigences matérielles d'un serveur Postgres, telles que définies dans la configuration Edge d'installation Conditions requises

Installation d'un nouveau Postgres nœud de secours

Cette procédure crée un serveur de secours Postgres sur un nouveau nœud. Veillez à installer une nouvelle serveur de secours Postgres pour votre version existante d'Edge (4.16.01 ou 4.16.05), pas pour la version 4.17.01.

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

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

Dans le tableau principal Postgres actuel, modifiez le fichier /opt/apigee/customer/application/postgresql.properties pour définir le jeton suivant. Si ce fichier n'existe pas, créez-le:

conf_pg_hba_replication.connection=host réplication apigee existing_slave_ip/32 confiance\ \nréplication de l'hôte apigee new_slave_ip/32 trust

où existing_slave_ip correspond à l'adresse IP de l'instance Postgres actuelle serveur de secours, et new_slave_ip est l'adresse IP de la nouvelle instance d'un nœud.
Redémarrez apigee-postgresql. sur l'instance maître Postgres:
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql redémarrer
Vérifiez que le nouveau nœud de secours a été ajouté en affichant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur l'instance maître. Les lignes suivantes doivent s'afficher dans ce fichier:
réplication de l'hôte apigee confiance_ip_esclave_existante/32
réplication de l'hôte apigee new_slave_ip/32 trust
Installez le nouveau serveur de secours Postgres: <ph type="x-smartling-placeholder">
1. Modifiez le fichier de configuration que vous avez utilisé pour installer votre version actuelle d'Edge pour spécifier les éléments suivants:
  
  # adresse IP du réseau maître:
  PG_MASTER=192.168.56.103
  # adresse IP du nouveau nœud de secours
  PG_STANDBY=192.168.56.102
2. Désactivez SELinux comme décrit dans la section Installer Edge utilitaire de configuration apigee.
3. Téléchargez le fichier Edge bootstrap_4.16.05.sh dans /tmp/bootstrap_4.16.05.sh:
  > curl https://software.apigee.com/bootstrap_4.16.05.sh -o /tmp/bootstrap_4.16.05.sh
  
  Remarque: Si vous effectuez la mise à jour à partir de la version 4.16.01, téléchargez le fichier Edge bootstrap.sh.
4. Installez l'utilitaire Edge apigee-service et les dépendances:
  > sudo bash /tmp/bootstrap_4.16.05.sh apigeeuser=uName apigeepassword=pWord
5. Utilisez apigee-service pour installer l'utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-setup installer
6. Installez Postgres:
  > /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
7. 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 l'instance de secours.

Mise hors service d'un système Postgres nœud

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

Vérifiez que Postgres est en cours d'exécution:
> /opt/apigee/apigee-service/bin/apigee-all statut

Si Postgres n'est pas en cours d'exécution, démarrez-le:
> /opt/apigee/apigee-service/bin/apigee-all démarrage
Obtenez l'UUID du nouveau nœud de secours en exécutant la commande cURL suivante sur le nouveau nœud de secours:
> curl -u sysAdminEmail:password http://<node_IP>:8084/v1/servers/self

L'UUID du nœud doit s'afficher à la fin du résultat, sous la forme:
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
Arrêtez le nouveau nœud de secours en exécutant la commande suivante sur le nouveau nœud de secours:
> /opt/apigee/apigee-service/bin/apigee-all stop
Sur le nœud 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 approbation de l'existing_slave_ip/32 de réplication
Redémarrez apigee-postgresql sur le maître Postgres:
> /opt/apigee/apigee-service/bin/apigee-service redémarrage d'apigee-postgresql
Vérifiez que le nouveau nœud de secours a été supprimé en affichant le fichier /opt/apigee/apigee-postgresql/conf/pg_hba.conf sur l'instance maître. Seule la ligne suivante devrait s'afficher dans ce fichier:
réplication de l'hôte apigee existing_slave_ip/32 confiance
Supprimez l'UUID du nœud de secours de ZooKeeper en effectuant la gestion Edge suivante : Appel d'API sur le nœud du serveur de gestion:
> curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/<new_slave_uuid>

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 pour faire descendre Edge.

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

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

Mettez à jour les machines dans le bon ordre pour votre installation, comme décrit ci-dessous dans la section "Commander de mise à jour de la machine.
Au moment de mettre à jour les routeurs, sélectionnez un routeur et rendez-le inaccessible, car décrits dans la section Activation/Désactivation Joignabilité du serveur (processeur de messages/routeur)
Mettez à jour le routeur sélectionné et tous les autres composants Edge sur la même machine que le routeur. Toutes les configurations Edge affichent un routeur et un processeur de messages sur le même nœud.
Rendez le routeur à nouveau accessible.
Répétez les étapes 2 à 4 pour les routeurs restants.
Continuez la mise à jour pour toutes les machines restantes de votre installation.

Prenez soin des points suivants avant/après la mise à jour:

Sur les nœuds de routeur et de processeur de messages combinés: <ph type="x-smartling-placeholder">
- Avant la mise à jour: <ph type="x-smartling-placeholder">
  1. Rendez le routeur inaccessible.
  2. Rendre le processeur de messages inaccessible.
- Après la mise à jour, procédez comme suit: <ph type="x-smartling-placeholder">
  1. Rendez le processeur de messages accessible.
  2. Rendez le routeur accessible.
Sur un nœud de routeur unique: <ph type="x-smartling-placeholder">
- Avant la mise à jour, rendez le routeur inaccessible.
- Rendez le routeur accessible après la mise à jour.
Sur un nœud de processeur de messages unique: <ph type="x-smartling-placeholder">
- 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 silencieuse

Vous devez transmettre un fichier de configuration silencieuse à la commande de mise à jour. Fichier de configuration silencieuse doit être la même que celle que vous avez utilisée pour installer Edge 4.16.01 ou 4.16.05.

Procédure pour mise à jour vers la version 4.17.01 sur un nœud avec une connexion Internet externe

Procédez comme suit pour mettre à jour les composants Edge sur un nœud:

Si vous utilisez actuellement la réplication maître Postgres, installez une nouvelle instance de secours, comme décrit ci-dessus dans la section Installer un nouveau nœud de secours Postgres.
Le cas échéant, désactivez les tâches CRON configurées pour effectuer une opération de réparation sur Cassandra. avant la fin de la mise à jour.
Connectez-vous à votre nœud en tant qu'utilisateur racine pour installer les RPM Edge.
Remarque: Bien que l'installation de RPM nécessite un accès root, vous pouvez effectuer sans accès racine.
Désactivez SELinux comme décrit dans la section Installer Edge apigee-setup utilitaire.
Téléchargez le fichier Edge 4.17.01 bootstrap_4.17.01.sh dans /tmp/bootstrap_4.17.01.sh:
> curl https://software.apigee.com/bootstrap_4.17.01.sh -o /tmp/bootstrap_4.17.01.sh
Installez l'utilitaire Edge 4.17.01 apigee-service et dépendances:
> sudo bash /tmp/bootstrap_4.17.01.sh apigeeuser=uName apigeepassword=pWord

où uName:pWord correspond au nom d'utilisateur et au mot de passe que vous avez reçus Apigee. Si vous omettez pWord, vous serez invité à le faire.

Par défaut, le programme d'installation vérifie que Java 1.8 est bien installé. Si ce n'est pas le cas, l'installe pour vous. Utilisez l'option JAVA_FIX pour spécifier comment gérer Installation de Java. JAVA_FIX accepte les valeurs suivantes:

I = Installer OpenJDK 1.8 (par défaut)
C = Continuer sans installer Java
Q = Quitter Pour cette option, vous devez installer Java vous-même.
(CentOS-6.x et RedHat-6.x uniquement) Sur tous les nœuds Qpid, exécutez la commande suivante pour vous assurer de télécharger la bonne version de Qpid:
> yum install apigee-qpidd --disablerepo=epel
Utilisez apigee-service pour Mettez à jour l'utilitaire apigee-setup: <ph type="x-smartling-placeholder">
1. Si vous avez installé la version 4.16.01 en mettant à niveau la version 4.15.07.0x d'Edge, vous devez installer L'utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-setup installer
  
  Cette commande installe l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
  
  Si vous avez déjà installé l'utilitaire apigee-setup, mettez à jour ce:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
2. Si vous avez installé directement la version 4.16.01, ce qui signifie que vous n'avez pas effectué de mise à niveau 4.15.07.0x, vous devez mettre à jour l'utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
  
  Cette mise à jour de apigee-service installe le l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
3. Si vous avez installé la version 4.16.05 directement ou par le biais d'une mise à jour, vous devez mettre à jour Utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
  
  Cette mise à jour de apigee-service installe le l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
Selon votre version actuelle d'Edge, vous devez soit installer ou mettre à jour le l'utilitaire apigee-validate sur le Serveur de gestion.
1. Si vous utilisez actuellement Edge 4.16.05: mettez à jour l'utilitaire apigee-validate sur le Serveur de gestion:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour "apigee-validate"
2. Si vous utilisez actuellement Edge 4.16.01: installez l'utilitaire apigee-validate sur le Serveur de gestion:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-validate installer
  
  Remarque: Si vous avez installé l'utilitaire apigee-validate sur un objet Message lors de l'installation de la version 4.16.01, vous pouvez le mettre à jour en exécutant la commande suivante sur ce nœud:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-validate mise à jour
  
  Toutefois, à partir de la version 4.16.05, Apigee vous recommande d'installer et d'exécuter l'utilitaire apigee-validate sur le serveur de gestion.
3. Si vous effectuez une mise à niveau à partir de la version 4.16.01: modifiez le fichier de configuration transmis à utilitaire apigee-validate. Dans dans la version 4.16.01 Edge, le fichier de configuration utilisé par apigee-validate exigeait les éléments suivants propriétés:
  APIGEE_ADMINPW=sysAdminPword
  MP_POD=gateway
  REGION=dc-1
  
  Dans cette version, le fichier de configuration ne requiert que la propriété APIGEE_ADMINPW. Vous pouvez supprimer les deux autres propriétés du fichier.
Mettez à jour le apigee-provision utilitaire:
> /opt/apigee/apigee-service/bin/apigee-service mise à jour apigee-provision
Exécutez l'utilitaire de mise à jour sur vos nœuds dans l'ordre décrit ci-dessous dans "Ordre des mise à jour. ci-dessous:
> /opt/apigee/apigee-setup/bin/update.sh -c composant -f configFile

La seule condition requise sur le fichier de configuration est qu'il doit être accessible ou lisible par la fonction « apigee » utilisateur.

Utilisez l'option "-c" pour spécifier le composant à mettre à jour. La liste des possibilités composants inclut:
ldap = OpenLDAP
cs = Cassandra
zk = ZooKeeper
qpid = qpidd
ps = postgresql
edge =Tous les composants Edge à l'exception de l'interface utilisateur Edge: serveur de gestion, processeur de messages, routeur, serveur QPID, serveur Postgres
ui = Edge UI
all = mettre à jour tous les composants sur machine (à utiliser uniquement pour un profil d'installation Edge aio ou une installation API BaaS en tant que profil)
e = ElasticSearch
b = pile d'API BaaS
p = portail BaaS de l'API
ebp = ElasticSearch, API BaaS et le portail BaaS d'API sur le même nœud
Testez la mise à jour en exécutant l'utilitaire apigee-validate sur le serveur de gestion, en tant que décrit dans la section Tester l'installation.
Si vous avez installé un nouveau nœud de secours Postgres, mettez-le hors service comme décrit ci-dessus dans Mettre hors service un nœud Postgres

Pour effectuer un rollback ultérieur de la mise à jour, suivez la procédure décrite dans la section 4.16.09 Processus de rollback.

Procédure de mise à jour vers la version 4.17.01 à partir d'une version locale dépôt

Si vos nœuds périphériques se trouvent derrière un pare-feu ou s'ils ne sont pas autorisés d'une autre manière à accéder dans le dépôt Apigee sur Internet, vous pouvez alors effectuer la mise à jour ou un miroir du dépôt Apigee.

Après avoir créé un dépôt Edge local, vous avez deux options pour mettre à jour Edge à partir du dépôt local:

Créez un fichier .tar du dépôt, copiez le fichier .tar sur un nœud, puis mettez à jour Edge à partir du .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 met à votre disposition le serveur Web Nginx, mais vous pouvez aussi utiliser votre propre serveur serveur Web.

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

Si vous utilisez actuellement la réplication maître Postgres, installez une nouvelle instance de secours, comme décrit ci-dessus dans la section Installer un nouveau nœud de secours Postgres.
Créez un dépôt 4.17.01 local comme décrit dans la section "Créer un dépôt Apigee local". dans la section Installer le package Edge utilitaire.
Remarque: Si vous disposez déjà d'un dépôt 4.16.01 ou 4.16.05, vous pouvez ajouter le fichier 4.17.01, comme décrit dans la section "Mettre à jour un dépôt Apigee local" dans Installer la configuration Edge d'Apigee utilitaire.
Pour installer apigee-service à partir d'un fichier .tar: <ph type="x-smartling-placeholder">
1. Sur le nœud contenant le dépôt local, empaquetez le dépôt à l'aide de la commande suivante : dans un seul fichier .tar nommé /opt/apigee/data/apigee-mirror/apigee-4.17.01.tar.gz:
  > /opt/apigee/apigee-service/bin/apigee-service package apigee-mirror
2. Copiez le fichier .tar sur le nœud où vous souhaitez mettre à jour Edge. Par exemple, copiez-le dans le répertoire /tmp un nouveau nœud.
3. Sur le nouveau nœud, décompressez le fichier dans le répertoire /tmp:
  > tar -xzf apigee-4.17.01.tar.gz
  
  Cette commande crée un répertoire nommé "repos" dans le répertoire contenant le fichier .tar. . Par exemple, /tmp/repos.
4. Installez l'utilitaire Edge apigee-service et les dépendances à partir de /tmp/repos:
  > sudo bash /tmp/repos/bootstrap_4.17.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
  
  Notez que vous incluez dans cette commande le chemin d'accès au répertoire "dépôts".
Pour installer apigee-service à l'aide du serveur Web Nginx: <ph type="x-smartling-placeholder">
1. Configurez le serveur Web Nginx comme indiqué dans la section "Installer à partir du dépôt à l'aide de la commande webserver" dans la section Installer Edge utilitaire de configuration apigee.
2. Sur le nœud distant, téléchargez le fichier Edge bootstrap_4.17.01.sh pour /tmp/bootstrap_4.17.01.sh:
  > /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.17.01.sh -o /tmp/bootstrap_4.17.01.sh
  
  où uName:pWord est le nom d'utilisateur et le mot de passe que vous avez définis ci-dessus pour le dépôt, et remoteRepo est l'adresse IP ou le nom DNS de votre nœud de dépôt.
3. Sur le nœud distant, installez l'utilitaire Edge apigee-service et les dépendances:
  > sudo bash /tmp/bootstrap_4.17.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
  
  où uName:pWord correspond au nom d'utilisateur et au mot de passe du dépôt.
Utilisez apigee-service pour Mettez à jour l'utilitaire apigee-setup: <ph type="x-smartling-placeholder">
1. Si vous avez installé la version 4.16.01 en mettant à niveau la version 4.15.07.0x d'Edge, vous devez installer L'utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-setup installer
  
  Cette commande installe l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
  
  Si vous avez déjà installé l'utilitaire apigee-setup, mettez à jour ce:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
2. Si vous avez installé directement la version 4.16.01, ce qui signifie que vous n'avez pas effectué de mise à niveau 4.15.07.0x, vous devez mettre à jour l'utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
  
  Cette mise à jour de apigee-service installe le l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
3. Si vous avez installé la version 4.16.05 directement ou par le biais d'une mise à jour, vous devez mettre à jour Utilitaire apigee-setup:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour de apigee-setup
  
  Cette mise à jour de apigee-service installe le l'utilitaire update.sh dans /opt/apigee/apigee-setup/bin.
Selon votre version actuelle d'Edge, vous devez soit installer ou mettre à jour le l'utilitaire apigee-validate sur le Serveur de gestion.
1. Si vous utilisez actuellement Edge 4.16.05: mettez à jour l'utilitaire apigee-validate sur le Serveur de gestion:
  > /opt/apigee/apigee-service/bin/apigee-service mise à jour "apigee-validate"
2. Si vous utilisez actuellement Edge 4.16.01: installez la version "apigee-validate" sur le serveur de gestion:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-validate installer
  
  Remarque: Si vous avez installé l'utilitaire apigee-validate sur un objet Message lors de l'installation de la version 4.16.01, vous pouvez le mettre à jour en exécutant la commande suivante sur ce nœud:
  > /opt/apigee/apigee-service/bin/apigee-service apigee-validate mise à jour
  
  Toutefois, à partir de la version 4.16.05, Apigee vous recommande d'installer et d'exécuter utilitaire apigee-validate sur le serveur de gestion.
3. Si vous effectuez une mise à niveau à partir de la version 4.16.01: modifiez le fichier de configuration transmis à utilitaire apigee-validate. Dans dans la version 4.16.01 Edge, le fichier de configuration utilisé par apigee-validate exigeait les éléments suivants propriétés:
  APIGEE_ADMINPW=sysAdminPword
  MP_POD=gateway
  REGION=dc-1
  
  Dans cette version, le fichier de configuration ne requiert que la propriété APIGEE_ADMINPW. Vous pouvez supprimer les deux autres propriétés du fichier.
Mettez à jour le apigee-provision utilitaire:
> /opt/apigee/apigee-service/bin/apigee-service mise à jour apigee-provision
Exécutez l'utilitaire de mise à jour sur vos nœuds dans l'ordre décrit ci-dessous dans "Ordre des mettre à jour" ci-dessous:
> /opt/apigee/apigee-setup/bin/update.sh -c composant -f configFile

La seule condition requise sur le fichier de configuration est qu'il doit être accessible ou lisible par la fonction « apigee » utilisateur.

Utilisez l'option "-c" pour spécifier le composant à mettre à jour. La liste des possibilités composants inclut:
ldap = OpenLDAP
cs = Cassandra
zk = ZooKeeper
qpid = qpidd
ps = postgresql
edge =Tous les composants Edge à l'exception de l'interface utilisateur Edge: serveur de gestion, processeur de messages, routeur, serveur QPID, serveur Postgres
ui = Edge UI
all = mettre à jour tous les composants sur machine (à utiliser uniquement pour un profil d'installation Edge aio ou une installation API BaaS en tant que profil)
e = ElasticSearch
b = pile d'API BaaS
p = portail BaaS de l'API
ebp = ElasticSearch, API BaaS et le portail BaaS d'API sur le même nœud
Testez la mise à jour en exécutant l'utilitaire apigee-validate sur le serveur de gestion, en tant que décrit dans la section Tester l'installation.
Si vous avez installé un nouveau nœud de secours Postgres, mettez-le hors service comme décrit ci-dessus dans Mettre hors service un nœud Postgres

Pour effectuer un rollback ultérieur de la mise à jour, suivez la procédure décrite dans la section 4.16.09 Processus de rollback.

Ordre des mises à jour de la machine

L'ordre dans lequel vous mettez à jour les machines dans une installation Edge est important. Les plus les points importants à prendre en compte lors d'une mise à jour sont les suivants:

Vous devez mettre à jour tous les nœuds Cassandra et ZooKeeper avant d'effectuer la mise à jour d'autres nœuds.
Pour toute machine dotée de plusieurs composants Edge (serveur de gestion, processeur de messages, (routeur, serveur QPID, mais pas serveur Postgres), utilisez "-c Edge" permet de tous les mettre à jour en même temps.
Si une étape indique qu'elle doit être exécutée sur plusieurs machines, effectuez-la dans le l'ordre de machine spécifié.
Il n'y a pas d'étape distincte pour mettre à jour la monétisation. Elle est mise à jour lorsque vous spécifiez "-c" bord" .
(CentOS-6.x et RedHat-6.x uniquement) Sur tous les nœuds Qpid ayant un une connexion Internet externe, vérifiez que vous avez exécuté la commande suivante pour télécharger le version de Qpid correcte, comme indiqué ci-dessus:
> miam installez apigee-qpidd --disablerepo=epel