Notes de version d'Edge for Private Cloud 4.18.05

Vous consultez la documentation Apigee Edge.
Accédez à la documentation Apigee X.

Cette section décrit la version 4.18.05 de la version de fonctionnalité Edge pour le cloud privé.

Résumé de la version

Le tableau suivant récapitule les modifications apportées à cette version de fonctionnalité :

Nouvelles fonctionnalités ○ Les règles JWT sont désormais en disponibilité générale.
○ RedHat Enterprise Linux 6.9 est désormais compatible.
○ Oracle Linux 6.9 est désormais compatible.
○ CentOS 6.9 est désormais compatible.
○ Nouvelles modifications de configuration de l'installation de la nouvelle expérience Edge.
○ Les options de réessai du routeur peuvent désormais être définies au niveau de l'hôte virtuel.
Sorties incluses
○ Interface utilisateur Edge :
   18.04.04
   18.03.02
   18.02.14
   17.11.06 		○ Edge Management/Runtime :
   18.04.06
   18.04.04
   18.03.02
   18.02.02
   18.01.05
 ○ Portail :
   18.04.25.01
   18.04.25.00
   18.04.23.00
   18.03.28.00
   18.03.05.00
   18.02.15.00
   18.01.31.00
   17.12.20.00
Arrêts ○ API BaaS
○ Tableau de bord Monitoring (bêta)
Obsolescences ○ Remplacement des magasins sécurisés (coffres-forts) Apigee par des KVM
○ Ajout de chemins d'accès dans l'onglet "Performances" du proxy d'API
○ Propriété SMTPSSL pour le portail Developer Services
Correction de bugs ○ Empêcher la modification de l'adresse e-mail de l'utilisateur (65550638)
○ Faille de sécurité dans jackson-databind (69711616)
○ Fuite de mémoire dans les processeurs de messages (71612599)
Problèmes connus

Cette version présente les problèmes connus suivants :

○ La sauvegarde du processeur de messages ne sauvegarde pas le bon ensemble de fichiers (121095148)
○ Les requêtes HEAD vers les cibles Node.js sont suspendues (79993247)
○ L'option "Créer un proxy inverse via Open API" s'affiche (79949124)
○ Les noms d'hôte ne sont pas résolus (79757554)
○ Exceptions DataAccessExceptions dans les configurations multidata center (76087166)
○ Un message d'erreur d'autorisation s'affiche lors de l'arrêt d'apigee-postgresql (72379834)
○ La règle MessageLogging inclut des informations supplémentaires dans le message de journal (68722102)

Pour en savoir plus sur chacun de ces problèmes connus, y compris sur les solutions de contournement, consultez Problèmes connus.

Les sections suivantes décrivent chacun de ces thèmes en détail.

Chemins de mise à niveau

Le tableau suivant indique les chemins de mise à niveau pour cette version de fonctionnalité :

À partir de la version 4.18.01 Mise à niveau directe de la version 4.18.01 vers la version 4.18.05
À partir de la version 4.17.09 Mise à niveau directe de la version 4.17.09 vers la version 4.18.05
À partir de la version 4.17.05 Mise à niveau directe de la version 4.17.05 vers la version 4.18.05
À partir de la version 4.17.01 Mise à niveau de la version 4.17.01 vers la version 4.18.01, puis mise à niveau de la version 4.18.01 vers la version 4.18.05
À partir de la version 4.16.09 Mise à niveau de la version 4.16.09 vers la version 4.18.01, puis mise à niveau de la version 4.18.01 vers la version 4.18.05
À partir de la version 4.16.05 Mise à niveau de la version 4.16.05 vers la version 4.18.01, puis mise à niveau de la version 4.18.01 vers la version 4.18.05
À partir de la version 4.16.01 Mise à niveau de la version 4.16.01 vers la version 4.18.01, puis mise à niveau de la version 4.18.01 vers la version 4.18.05
À partir de la version 4.15.0.x Passez de la version 4.15.0x à la version 4.16.01, puis de la version 4.16.01 à la version 4.18.01, puis de la version 4.18.01 à la version 4.18.05

Nouvelles fonctionnalités

Cette section décrit les nouvelles fonctionnalités de cette version. En plus de ces fonctionnalités, cette version inclut toutes les fonctionnalités des versions de l'UI Edge, de la gestion Edge et du portail listées dans Versions incluses.

En plus des améliorations suivantes, cette version contient également de nombreuses améliorations en termes d'usabilité, de performances, de sécurité et de stabilité.

Règles JWT

Les Règles JWT suivantes ne sont plus en version bêta et sont désormais disponibles pour tous :

Logiciels compatibles

Cette version de fonctionnalité inclut les modifications suivantes apportées aux logiciels compatibles :

  • Red Hat Enterprise Linux (RHEL) 6.9 est désormais compatible
  • Oracle Linux 6.9 est désormais compatible
  • CentOS 6.9 est désormais compatible
  • RHEL/CentOS/Oracle Linux 7.2 ne sont plus compatibles

Pour en savoir plus, consultez Logiciels et versions compatibles.

Modifications de la configuration d'installation de la nouvelle expérience Edge

La version 4.18.05 de la nouvelle expérience Edge contient des modifications apportées au fichier de configuration par rapport à la version 4.18.01. Les nouvelles propriétés sont décrites dans Modifications apportées à la configuration de l'installation à partir d'Edge 4.18.01.

Les options de réessai du routeur peuvent désormais être définies au niveau de l'hôte virtuel

Vous pouvez désormais définir des options de réessai pour les communications du routeur avec le processeur de messages sur l'hôte virtuel. Cela vous offre un contrôle plus précis que les options précédentes, qui ne pouvaient être définies qu'au niveau du routeur.

Pour en savoir plus, consultez Propriétés de configuration des hôtes virtuels.

Nouvelle dimension Analytics et modification de la dimension x_forwarded_for_ip

La façon dont Edge définit la dimension x_forwarded_for_ip dans Edge Analytics a changé. Auparavant, si l'en-tête X-Forwarded-For contenait plusieurs adresses IP, la dimension x_forwarded_for_ip n'affichait que la dernière adresse IP listée. Les clients utilisaient souvent la dimension x_forwarded_for_ip pour déterminer l'adresse IP du client qui envoyait la requête API à Edge.

Avec cette version, la dimension x_forwarded_for_ip contient désormais la liste complète des adresses IP de l'en-tête X-Forwarded-For.

Avertissement : L'en-tête X-Forwarded-For peut être usurpé par une adresse IP dont l'accès a été refusé, à l'exception de la dernière adresse de l'en-tête, qui correspond à l'adresse IP qu'Edge a obtenue lors du dernier handshake TCP externe. Pour déterminer l'adresse IP du client d'origine qui envoie la requête d'API à Edge, cette version ajoute une nouvelle dimension à Edge Analytics : ax_resolved_client_ip.

Vous pouvez désormais utiliser la dimension ax_resolved_client_ip dans un rapport personnalisé ou dans une condition de filtre d'un rapport personnalisé pour déterminer l'adresse IP du client qui envoie la requête API. Pour en savoir plus sur la dimension ax_resolved_client_ip, consultez la documentation de référence sur les métriques, les dimensions et les filtres d'Analytics.

Cette modification affecte également la façon dont la règle AccessControl gère l'en-tête X-Forwarded-For. Dans cette version, Edge renseigne automatiquement l'en-tête HTTP X-Forwarded-For avec l'adresse IP unique qu'il a reçue du dernier handshake TCP externe (tel que l'adresse IP ou le routeur du client). Dans les versions précédentes, Edge définissait l'en-tête HTTP X-Forwarded-For avec l'adresse IP unique qu'il recevait du premier handshake TCP externe (tel que l'adresse IP ou le routeur du client). Pour en savoir plus, consultez À propos de l'en-tête HTTP X-Forwarded-For.

Versions incluses

Depuis la version précédente d'Edge pour le cloud privé, les versions suivantes ont été publiées et sont incluses dans cette version de fonctionnalité :

Interface utilisateur Edge Gestion/Environnement d'exécution Edge Portail
18.04.04
18.03.02
18.02.14
17.11.06 		18.04.06
18.04.04
18.03.02*
18.02.02
18.01.05
 18.04.25.01
18.04.25.00
18.04.23.00
18.03.28.00
18.03.05.00
18.02.15.00
18.01.31.00
17.12.20.00
* Le correctif 74622499 n'est pas inclus dans la version 4.18.05 d'Edge pour le cloud privé.

Cliquez sur les liens ci-dessus pour consulter les corrections de bugs et les nouvelles fonctionnalités de ces versions incluses dans cette version de fonctionnalité.

Retraits

Cette section décrit les fonctionnalités qui ont été abandonnées dans cette version des fonctionnalités.

API BaaS

API BaaS a été abandonné. Pour en savoir plus, consultez Abandons, arrêts et modifications des conditions d'utilisation d'Apigee.

Tableau de bord Monitoring (bêta)

Le tableau de bord de surveillance (bêta) a été supprimé et ne sera plus compatible. Par conséquent, les composants suivants ne font plus partie de l'installation :

  • apigee-influxdb
  • apigee-telegraf
  • apigee-grafana

Pour continuer à obtenir des métriques sur le routeur, le processeur de messages et les nœuds, Apigee vous recommande d'utiliser JMX pour intégrer les données d'Edge pour Private Cloud à vos propres outils de surveillance. Pour en savoir plus, consultez Éléments à surveiller et Comment surveiller.

Si vous mettez à niveau une installation existante vers la version 4.18.05, vous devez désinstaller le tableau de bord Monitoring. Apigee ne garantit pas qu'il continuera de fonctionner comme prévu.

Abandons

Les fonctionnalités suivantes ont été abandonnées dans cette version.

Pour en savoir plus, consultez Abandons, arrêts et modifications des conditions d'utilisation d'Apigee.

Apigee Secure Store (coffres-forts)

Le magasin sécurisé Apigee, également appelé "coffres-forts", est obsolète et sera supprimé en septembre 2018.

Au lieu d'utiliser le magasin sécurisé, utilisez des mappages clé-valeur (KVM) chiffrés, comme décrit dans Travailler avec des mappages clé-valeur. Les KVM chiffrées sont aussi sécurisées que les coffres-forts et offrent plus d'options de création et de récupération.

Ajouter des chemins d'accès dans l'onglet "Performances" du proxy d'API

Avant cette version, vous pouviez accéder à un proxy d'API dans l'interface utilisateur de gestion, puis à l'onglet Performances. Vous pouviez ensuite créer différents chemins d'accès pour une comparaison basée sur des graphiques dans l'onglet Performances du proxy et dans le tableau de bord Transactions commerciales.

Cette fonctionnalité a été abandonnée et n'est plus disponible dans l'interface utilisateur. Pour trouver une alternative à cette fonctionnalité, consultez Alternative à l'API Business Transactions.

Propriété SMTPSSL pour le portail Developer Services

Pour définir le protocole utilisé par le serveur SMTP connecté au portail, vous devez désormais utiliser la propriété SMTP_PROTOCOL au lieu de la propriété SMTPSSL. Les valeurs valides de SMTP_PROTOCOL sont "standard", "ssl" et "tls".

Pour en savoir plus, consultez Installation du portail Developer Services.

Correction de bugs

Cette section liste les bugs de Private Cloud qui ont été corrigés dans cette version de fonctionnalité. En plus des bugs listés ci-dessous, cette version de fonctionnalité inclut toutes les corrections de bugs des versions Edge UI, Edge Management et Portal indiquées dans Versions incluses.

ID du problème Description
71612599

Fuite de mémoire dans les processeurs de messages

Une fuite de mémoire a été corrigée. Elle s'est produite dans les processeurs de messages lorsque Qpidd a été arrêté.
69711616

Faille de sécurité dans jackson-databind

La bibliothèque jackson-databind a été mise à jour vers la version 2.7.9.1 pour éviter un défaut de désérialisation.
65550638

Empêcher la modification de l'adresse e-mail d'un utilisateur

Vous ne pouvez plus modifier l'adresse e-mail d'un utilisateur dans la charge utile du message envoyé à l'API Management. L'API Management n'autorise plus non plus le format XML dans le corps de la requête.

Problèmes connus

Le tableau suivant répertorie les problèmes connus dans cette version de fonctionnalité :

ID du problème Description
121095148

La sauvegarde du processeur de messages ne sauvegarde pas le bon ensemble de fichiers

Solution :

Exécutez la sauvegarde une deuxième fois. Elle devrait sauvegarder le bon ensemble de fichiers.
79993247

Les requêtes HEAD envoyées aux cibles Node.js sont suspendues

Les requêtes HEAD envoyées à une cible Node.js peuvent se bloquer, laissant des connexions en attente.

Solution :

Pour contourner ce problème, définissez un gestionnaire pour les requêtes HEAD afin de renvoyer explicitement une réponse vide.
79949124

L'option "Créer un proxy inverse via l'API Open" s'affiche.

L'assistant de proxy affiche actuellement une option permettant de créer un proxy via Open API. Cela n'est pas possible sur Edge pour le cloud privé.

Solution :

Aucune.
79757554

Noms d'hôte non résolus

Après l'installation ou la mise à niveau d'Edge pour le cloud privé, il est possible que les noms d'hôte ne soient pas résolus en adresses.

Solution :

Pour résoudre ce problème, redémarrez le composant Edge UI :

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

DataAccessException dans les configurations à plusieurs centres de données

Dans les configurations à plusieurs centres de données, si un datastore devient indisponible, l'erreur suivante peut s'afficher :

DataAccessException: Error while accessing datastore;
Please retry later

Le serveur de gestion risque de ne pas démarrer, car il tente de se connecter aux nœuds Cassandra dans dc-1 et dc-2. Le code d'erreur DataAccessExceptions se produit si un nœud Cassandra est hors service. Cela peut également entraîner une perturbation du trafic d'API, où les processeurs de messages signalent DataAccessExceptions lors de la récupération des KVM.

Notez que l'état attendu est que le serveur de gestion ne se connecte pas aux composants du datastore dans les régions.

Solution

La solution de contournement consiste à annuler l'enregistrement des types de nœuds Cassandra suivants dans le centre de données indisponible, puis à les réenregistrer une fois que les nœuds Cassandra sont à nouveau disponibles :

  • kms-datastore
  • dc-datastore
  • keyvaluemap-datastore

Pour annuler l'enregistrement et réenregistrer ces types de nœuds Cassandra :

  1. Obtenez les UUID des nœuds Cassandra à l'aide de la commande curl suivante : 
    curl -u ADMIN_EMAIL:ADMIN_PW \
  "http://MS_IP:MS_PORT/v1/servers?region=REGION&pod=GATEWAY_POD \
  &type=CASSANDRA_NODE_TYPE"

    Où :

    • ADMIN_EMAIL et ADMIN_PW sont les identifiants de votre compte Apigee.
    • MS_IP et MS_PORT sont l'adresse IP et le numéro de port du serveur de gestion.
    • REGION est le nom du centre de données dans lequel se trouve le serveur de gestion.
    • GATEWAY_POD est le nom du pod, qui est "gateway" par défaut. Vous l'avez peut-être renommé, alors vérifiez votre implémentation.
    • CASSANDRA_NODE_TYPE correspond à kms-datastore, dc-datastore ou keyvaluemap-datastore.

    Exemple : 

    curl -u nickdanger@google.com:myP@$$w0rD
  "http://192.168.0.1:8080/v1/servers?region=dc-1&pod=gateway&type=dc-datastore"

    La réponse utilise le format suivant : 

    {
  "internalIP" : "POD_IP_ADDRESS",
  "isUp" : [true|false],
  "pod" : "GATEWAY_POD",
  "reachable" : [true|false],
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "kms-datastore", "dc-datastore", "keyvaluemap-datastore" ],
    "uUID" : "POD_UUID"
}

    Exemple : 

    {
  "internalIP" : "192.168.1.11",
  "isUp" : false,
  "pod" : "gateway",
  "reachable" : false,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : "dc-datastore",
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
}

    Notez les valeurs du champ uUID dans la réponse. Vous les utiliserez pour désenregistrer les nœuds.

  2. Répétez l'étape 1 pour chaque type de nœud Cassandra : kms-datastore, dc-datastore et keyvaluemap-datastore. Veillez à noter les UUID renvoyés.
  3. Annulez l'enregistrement des nœuds à l'aide de la commande suivante : 
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers/UUID" -X DELETE

    Où UUID correspond à l'UUID renvoyé dans la réponse de la commande précédente.

  4. Répétez l'étape 3 pour chaque UUID que vous avez collecté aux étapes 1 et 2.
  5. Réenregistrez les nœuds à l'aide de la commande suivante : 
    curl -u ADMIN_EMAIL:ADMIN_PW "http://MS_IP:MS_PORT/v1/servers -d \
  "Type=kms-datastore&Type=dc-datastore&Type=keyvaluemap-datastore& \
  Type=counter-datastore&Type=cache-datastore&InternalIP=POD_IP_ADDRESS& \
  region=REGION&pod=GATEWAY_POD" -H \
  'content-type: application/x-www-form-urlencoded' -X POST

Notez que ces opérations enregistrent et désenregistrent les nœuds de ZooKeeper, et n'ont aucun impact sur le cluster Cassandra. Pour en savoir plus sur ces commandes, consultez Mettre à jour les enregistrements de data stores.
72379834

Un message d'erreur d'autorisation s'affiche lorsque vous arrêtez apigee-postgresql

Lorsque vous utilisez la commande apigee-seriver apigee-postgresql stop pour arrêter apigee-postgresql, un message peut s'afficher indiquant que apigee-serive ne peut pas passer au répertoire personnel de l'utilisateur. Vous pouvez ignorer ce message.

Solution :

N/A
68722102

Règle MessageLogging incluant des informations supplémentaires dans le message de journal

L'élément FormatMessage de la règle MessageLogging contrôle le format du message enregistré. Lorsque la valeur est FormatMessage=false, le message consigné ne doit inclure aucune information générée par Apigee. Toutefois, même si vous définissez FormatMessage=false, le message de journal inclut toujours les informations suivantes :

  • Score de priorité
  • Code temporel

Solution :

Aucune.

Étape suivante

Pour commencer à utiliser Edge pour le cloud privé 4.18.05, consultez les liens suivants :

Nouvelles installations:
Présentation de la nouvelle installation
Installations existantes:
Mettre à niveau depuis la version 4.18.01
Mettre à niveau depuis la version 4.17.05 ou 4.17.09
Mettre à niveau depuis la version 4.17.01
Mettre à niveau depuis la version 4.16.09
Mettre à niveau depuis la version 4.16.01 ou 4.16.05