19.03.01 - Notes de version d'Apigee Edge pour le cloud public

Équilibrage de charge : plus de contrôle pour supprimer les serveurs défaillants

Lorsque vous configurez un équilibreur de charge pour un proxy d'API, vous pouvez déterminer le nombre d'échecs de réponse avant qu'un serveur ne soit supprimé de la rotation de l'équilibrage de charge. Une réponse en échec signifie qu'Apigee ne reçoit aucune réponse d'un serveur cible. Lorsque cela se produit, le compteur d'échecs augmente d'une unité. Lorsque Apigee reçoit une réponse d'une cible, même s'il s'agit d'une erreur HTTP (par exemple, une erreur 500), celle-ci est comptabilisée comme une réponse du serveur cible, et le compteur d'échecs est réinitialisé. Pour vous assurer que les réponses HTTP incorrectes (telles que les erreurs 500) incrémentent également le compteur d'échecs visant à retirer dès que possible un serveur non opérationnel de la rotation d'équilibrage de charge, vous pouvez ajouter un élément <ServerUnhealthyResponse> avec des éléments enfants <ResponseCode> à la configuration de votre équilibreur de charge. Edge comptabilise alors comme des échecs les réponses comportant ces codes.

<HTTPTargetConnection>
  <LoadBalancer>
    <Algorithm>RoundRobin</Algorithm>
    <Server name="target1" />
    <Server name="target2" />
    <ServerUnhealthyResponse>
        <ResponseCode>500</ResponseCode>
        <ResponseCode>502</ResponseCode>
        <ResponseCode>503</ResponseCode>
    </ServerUnhealthyResponse>
    <MaxFailures>5</MaxFailures>
  </LoadBalancer>
</HTTPTargetConnection>
  
  

Améliorations apportées à la règle AccessControl

La règle AccessControl détermine les adresses IP qui peuvent appeler un proxy d'API. Un nouvel élément de cette règle permet aux développeurs d'API de mieux identifier les adresses IP à évaluer.

<IgnoreTrueClientIPHeader> : facultatif (la valeur par défaut est "false"). Lorsque cette règle est définie sur "true", la règle ignore l'en-tête True-Client-IP et évalue les adresses IP dans l'en-tête X-Forwarded-For, en suivant le comportement de l'évaluation X-Forwarded-For que vous avez configuré.

<AccessControl async="false" continueOnError="false"
    enabled="true" name="Access-Control-1">
    <DisplayName>Access Control-1</DisplayName>
    <IgnoreTrueClientIPHeader>true</IgnoreTrueClientIPHeader>
    ...
</AccessControl>

Pour en savoir plus, consultez ce post de la communauté.

Deux nouveaux éléments sont disponibles dans la règle RaiseFault pour rendre la gestion des FaultRules plus propre et plus efficace.

• ShortFaultReason est un booléen qui, lorsqu'il est défini sur "true", place le nom de la règle dans la variable fault.reason.
• AssignVariable, disponible dans FaultResponse, vous permet d'attribuer la réponse d'erreur à une variable à utiliser par d'autres règles dans le flux de proxy d'API.

Des limites sont désormais appliquées aux cibles hébergées. Pour en savoir plus sur les limites, consultez Limites.

Vous pouvez désormais utiliser des variables de modèle de message pour définir des adresses IP et des masques CIDR dans la stratégie AccessControl. Par exemple, si vous souhaitez stocker une adresse IP et un masque dans un mappage clé-valeur (KVM), vous pouvez récupérer ces valeurs à partir d'une variable que vous avez définie dans le flux du proxy d'API. Cela vous permet de modifier plus facilement les valeurs d'adresse IP au moment de l'exécution sans avoir à modifier la configuration de votre règle.

Par exemple, au lieu du code suivant :

<MatchRule action="DENY">
    <SourceAddress mask="24">198.51.100.1</SourceAddress>
</MatchRule>
     

Vous pouvez configurer la règle comme suit, en supposant que les valeurs sont stockées dans un KVM et que vous utilisez la règle KeyValueMapOperations pour récupérer les valeurs et les attribuer aux variables indiquées ici :

<MatchRule action="DENY">
    <SourceAddress mask="{kvm.mask.ref}">{kvm.ip.ref}</SourceAddress>
</MatchRule>
     

API Monitoring fournit deux rôles : "Administrateur de surveillance des API" et "Utilisateur de surveillance des API", décrits dans Accéder à API Monitoring. Elles sont disponibles depuis décembre 2018.

Edge ajoute désormais l'en-tête X-Apigee.Message-Timeout à chaque requête. Cet en-tête est destiné à un usage interne par Edge. Ne vous fiez pas aux valeurs des en-têtes X-Apigee.* dans vos proxys d'API, car ces en-têtes ne sont pas destinés à un usage client et peuvent être supprimés ou modifiés par Apigee à tout moment.

Gérer les erreurs de suppression du keystore pour que l'appel d'API n'échoue pas

x-apigee.edge.execution.sense.action est toujours défini sur "null"

Dans la règle ResponseCache, NIOTheread s'exécute sans être refusé par le pool de threads

Plusieurs exportateurs de journaux sur les routeurs Apigee entraînent une utilisation élevée du processeur

Erreurs 404 intermittentes dans des organisations spécifiques

Le flux partagé déployé ne s'exécute pas sur certains processeurs de messages

Ce correctif sera inclus dans la prochaine version d'Edge pour le cloud privé.

Ce correctif sera inclus dans la prochaine version d'Edge pour le cloud privé.

Ce correctif sera inclus dans la prochaine version d'Edge pour le cloud privé.