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

Équilibrage de charge : plus de contrôle sur la suppression des serveurs défaillants

Lorsque vous configurez un d'un équilibreur de charge pour un proxy d'API, vous pouvez déterminer le nombre se produisent avant qu'un serveur ne soit retiré de la rotation de l'équilibrage de charge. Un échec de réponse signifie qu'Apigee ne reçoit aucune réponse d'un serveur cible. Dans ce cas, l'échec le compteur augmente d'une unité. Quand Apigee reçoit une réponse d'une cible, même si le est une erreur HTTP (500, par exemple) qui est comptabilisée comme une réponse du serveur cible, et le compteur d'échecs est réinitialisé. Pour garantir que les mauvaises réponses HTTP (telles que 500) incrémentez le compteur d'échecs pour retirer un serveur non opérationnel de la rotation de l'équilibrage de charge dès que possible, vous pouvez ajouter un élément <ServerUnhealthyResponse> avec des éléments enfants <ResponseCode> à la configuration de votre équilibreur de charge. Edge comptera également les réponses avec ces codes comme des échecs.

<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 aux règles AccessControl

La règle AccessControl détermine quelles adresses IP peuvent appeler un proxy d'API. Un nouvel élément de cette règle permet aux développeurs d'API de mieux contrôler l'identification des adresses IP à évaluer.

<IgnoreTrueClientIPHeader>: facultatif (la valeur par défaut est "false"). Lorsque vous définissez cette option 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, à la suite de la <ph type="x-smartling-placeholder"></ph> le comportement d'é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 destiné à la communauté.

Deux nouveaux éléments sont disponibles dans la stratégie RaiseFault pour rendre FaultRules une gestion plus propre et plus puissante.

• ShortFaultReason est une valeur booléenne qui, lorsqu'elle est définie 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 qui sera utilisée par d'autres stratégies dans le flux de proxy d'API.

Les limites s'appliquent désormais aux cibles hébergées. Pour en savoir plus sur les limites, consultez la section Limites.

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

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 de cette manière, en supposant que les valeurs sont stockées dans une KVM, et que vous utilisez la règle KeyValueMapOperations pour récupérer les valeurs et les attribuer les variables présenté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ès à la surveillance des API. Ils sont disponibles depuis décembre 2018.

Edge ajoute maintenant 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 mandataires d'API car ces en-têtes ne sont pas destinés à être utilisés par les clients 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 stratégie ResponseCache, NIOTheread s'exécute sans être rejeté par pool de threads

L'utilisation de plusieurs exportateurs de journaux sur les routeurs Apigee entraîne 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 Private Cloud.

Ce correctif sera inclus dans la prochaine version d'Edge pour Private Cloud.

Ce correctif sera inclus dans la prochaine version d'Edge pour Private Cloud.