Annonce de NGINX Plus R20

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que NGINX Plus Release 20 (R20) est désormais disponible. NGINX Plus est la seule solution tout-en-un combinant équilibreur de charge, cache de contenu, serveur web et passerelle API. Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités avancées exclusives et une assistance primée.

NGINX Plus R20 s’appuie sur les améliorations apportées dans R19 à la limitation du débit et au magasin clé-valeur. Parmi les nouvelles fonctionnalités :

• Surveillance et journalisation en temps réel du trafic soumis à une limitation du débit – Lorsque la limitation du débit est configurée, l’API NGINX Plus indique désormais le nombre de requêtes traitées immédiatement, retardées ou rejetées. Vous pouvez également configurer le journal d’accès afin d’y inclure des informations sur le statut de limitation du débit de chaque requête.
• Améliorations apportées à la limitation des connexions – Les améliorations apportées à la limitation du débit dans la version R19 et dans cette version ont été étendues à la limitation des connexions.
• Correspondance de préfixe dans le magasin clé-valeur – Les clés du magasin clé-valeur peuvent être mises en correspondance avec un préfixe spécifié (caractères situés au début d’une chaîne). Le routage dynamique des requêtes constitue un cas d’utilisation important.
• Résolution DNS par groupe de serveurs en amont – Vous pouvez désormais définir un ensemble distinct de serveurs DNS pour chaque groupe de serveurs en amont qui utilise un nom d’hôte pouvant être résolu pour représenter les serveurs backend du groupe.
• Variables supplémentaires du protocole PROXY – De nouvelles variables enregistrent l’adresse IP et le port du serveur proxy auquel le client s’est initialement connecté.
• Améliorations de la sécurité pour HTTP/2 – Plusieurs modifications renforcent la sécurité globale du trafic HTTP/2, notamment grâce à une meilleure détection des comportements incorrects ou non valides des clients et à une mise en œuvre plus robuste de certaines directives.

Modifications importantes du comportement

• API obsolètes – NGINX Plus R13 (publié en août 2017) a introduit la toute nouvelle NGINX Plus API<.htmlspan> pour la collecte de métriques et la reconfiguration dynamique des groupes de serveurs en amont, remplaçant les API Status et Upstream Conf qui assuraient auparavant ces fonctions. Comme annoncé à l’époque, les API dépréciées sont restées disponibles et prises en charge pendant une période prolongée, qui a pris fin avec NGINX Plus R16. Si votre configuration comprend les directives status ou upstream_conf, vous devez les remplacer par la directive api dans le cadre de la mise à niveau vers R20. Pour obtenir des conseils et de l’aide concernant la migration vers la nouvelle NGINX Plus API, consultez le guide de transition sur notre blog ou contactez notre équipe d’assistance.
• Nouveaux systèmes d’exploitation pris en charge –
  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10 (« Eoan Ermine »)

Pour plus d’informations sur les plateformes prises en charge, consultez les spécifications techniques de NGINX Plus et des modules dynamiques.

Présentation détaillée des nouvelles fonctionnalités

Surveillance et journalisation en temps réel du trafic soumis à une limitation de débit

NGINX Plus R20 introduit des fonctionnalités qui permettent aux équipes d’exploitation et DevOps de surveiller plus facilement l’activité de limitation du débit en temps réel et de déterminer précisément quels clients ont dépassé la limite de débit.
NGINX Plus a toujours offert une grande flexibilité dans la définition des types de requêtes client auxquels appliquer une limitation du débit et dans le traitement des requêtes excessives. Chaque requête est traitée de l’une des manières suivantes :

• Acceptée sans délai (car le débit de requêtes est inférieur à la limite ou compris dans la taille de rafale configurée)
• Retardée jusqu’à ce que son traitement n’entraîne pas le dépassement de la limite de débit (également appelé « bridage »)
• Rejetée avec un code de réponse d’erreur HTTP

Dans les versions précédentes, le journal des erreurs était le seul endroit où NGINX Plus consignait le fait que des requêtes avaient été retardées ou rejetées, dans des entrées standardisées comme celle-ci :

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

Il peut être difficile d’extraire des informations utiles du journal des erreurs, car le format des messages n’est pas structuré et ne peut pas être configuré. En outre, si la limitation du débit repose sur une caractéristique de la requête autre que celles indiquées dans l’entrée du journal des erreurs – par exemple, des en-têtes HTTP ou des informations d’identité –, vous devez rechercher l’entrée correspondante dans le journal des accès afin de déterminer précisément quel client a dépassé la limite de débit. Les nouvelles fonctionnalités permettent de résoudre ces problèmes.

Métriques de limitation du débit issues de l’API NGINX Plus

Un nouveau point de terminaison de l’API NGINX Plus, /api/version/http/limit_reqs, tient à jour des compteurs pour tous les résultats des décisions de limitation du débit prises pour chaque zone définie par une directive limit_req_zone. Ces compteurs peuvent être utilisés pour surveiller en temps réel les décisions de limitation du débit et intégrés à des solutions APM afin de fournir des tableaux de bord et des alertes sur l’activité de limitation du débit.

Dans l’exemple suivant, une seule zone est définie, « my_limit » :

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

Notez que ces compteurs incluent également des entrées correspondant aux requêtes excessives traitées en mode d’exécution à blanc, introduit dans NGINX Plus R19.

Journalisation de l’activité de limitation du débit dans le journal d’accès

Les métriques en temps réel sont très utiles pour savoir quand NGINX Plus traite un nombre excessif de requêtes, mais elles ne permettent pas de savoir qui les génère. Pour remédier à ce problème, NGINX Plus R20 fournit une nouvelle variable, $limit_req_status. Celle-ci enregistre le statut de limitation du débit de la requête : DELAYED, DELAYED_DRY_RUN, PASSED, REJECTED ou REJECTED_DRY_RUN.

Vous pouvez ensuite inclure dans le format de journalisation d’autres variables permettant d’identifier de manière unique le client, l’URI et toute autre information pertinente. Dans la configuration suivante, une limite stricte de 10 requêtes par seconde est appliquée à chaque client sur la base de la validation d’un jeton Web JSON (JWT) (ligne 1). Les requêtes excédentaires sont rejetées (ligne 16) et consignées dans un fichier journal distinct (ligne 21), qui inclut également la variable $jwt_claim_sub afin de capturer la revendication sub (ligne 4).

Chargement de l’exemple de code…

Exemples d’entrées dans le fichier « reject.log » :

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

Améliorations de la limitation des connexions

Outre la limitation du débit des requêtes, NGINX Plus permet de limiter les connexions clientes à l’aide du module Limit Connections. Vous pouvez définir le nombre de connexions distinctes qu’un client peut ouvrir vers NGINX Plus (ou le nombre de requêtes simultanées avec HTTP/2). Un client est généralement identifié par son adresse IP distante (la variable $remote_addr ou $binary_remote_addr), mais vous pouvez utiliser une autre variable (telle que $jwt_claim_sub pour le nom d’utilisateur dans un JWT) lorsque l’adresse IP distante est ambiguë ou susceptible d’être partagée par plusieurs clients.

NGINX Plus R20 étend la limitation des connexions en y intégrant les mêmes améliorations que celles apportées à la limitation du débit dans NGINX Plus R19 et dans cette version :

• Mode de simulation avec la directive « limit_conn_dry_run »
• Surveillance en temps réel au niveau du point de terminaison de l’API NGINX Plus /api/version/http/limit_conns
• Une nouvelle variable, « $limit_conn_status », qui enregistre la décision de limitation des connexions pour chaque requête (PASSED, REJECTED ou REJECTED_DRY_RUN) et peut être utilisée comme décrit dans la section « Journalisation de l’activité de limitation du débit dans le journal d’accès » pour la variable $limit_req_status variable

La configuration suivante limite la bande passante des clients qui ouvrent plus de dix connexions simultanées.

Chargement de l’exemple de code…

Correspondance de préfixes dans le magasin clé-valeur

Grâce au magasin clé-valeur en mémoire de NGINX Plus, vous pouvez utiliser l’API NGINX Plus pour configurer dynamiquement la gestion du trafic en fonction des attributs de la requête. Voici quelques exemples de cas d’utilisation : mise sur liste de blocage dynamique d’adresses IP, limitation dynamique de la bande passante, et mise en cache des jetons d’authentification.

NGINX Plus R20 prend désormais en charge la mise en correspondance des clés avec un préfixe spécifié (les caractères situés au début d’une chaîne), ouvrant ainsi de nouveaux cas d’utilisation pour le magasin clé-valeur. Par exemple, la possibilité de faire correspondre les clés à des préfixes d’URI (chemins de base) plutôt qu’à des URI exacts permet de créer une table de routage dynamique qui associe chaque chemin de base à un groupe en amont, en remplacement ou en complément des mappages statiques définis par les directives location.

Pour activer la correspondance par préfixe, ajoutez le nouveau paramètre « type=prefix » à la directive keyval_zone. Dans la configuration suivante, la directive keyval associe une directive Cache-Control (telle que max-age ou no-cache) à chaque préfixe d’URI, et la directive add_header définit l’en-tête de réponse Cache-Control sur cette valeur lorsque NGINX Plus transmet la requête au serveur en amont.

Chargement de l’exemple de code…

Nous utilisons l’API NGINX Plus pour définir la valeur de l’en-tête de réponse Cache-Control pour chaque chemin de base (dans ce cas, les chemins commençant par /images/ ou /reports/) dans le magasin clé-valeur :

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

Lorsque nous effectuons une requête avec un chemin de base qui existe dans le magasin clé-valeur, la réponse inclut l’en-tête « Cache-Control » que nous avons défini :

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

Comme le magasin clé-valeur peut être synchronisé sur un cluster d’instances NGINX Plus, il suffit d’adresser chaque appel d’API à une seule instance. Cela simplifie considérablement l’automatisation des modifications de la configuration du cluster par rapport à la coordination des modifications apportées aux fichiers de configuration.

Résolution DNS par groupe de serveurs en amont

Lorsque vous utilisez NGINX Plus pour répartir la charge entre plusieurs serveurs en amont, vous pouvez définir les membres du groupe de serveurs en amont en spécifiant un nom d’hôte qui se résout en plusieurs adresses IP. Cette fonctionnalité est particulièrement utile dans les environnements dynamiques ou à mise à l’échelle automatique, où les membres du groupe de serveurs en amont peuvent changer fréquemment.

Pour terminer la configuration de ces groupes de serveurs en amont dynamiques, vous devez également inclure la directive resolver afin de désigner le ou les serveurs DNS que NGINX Plus interroge pour obtenir les adresses IP associées au nom d’hôte. Dans les versions précédentes, une directive resolver s’appliquait à tous les groupes de serveurs en amont référencés par les directives proxy_pass dans le contexte (http, server ou location) contenant la directive. Avec NGINX Plus R20, vous pouvez désormais spécifier un résolveur DNS différent pour chaque groupe de serveurs en amont.

Cette nouvelle flexibilité est particulièrement utile dans un environnement DevOps : elle permet aux équipes applicatives de mieux maîtriser leur infrastructure de mise à disposition des applications, notamment les serveurs DNS et les registres de services, au lieu de dépendre de services centralisés et partagés.

Vous pouvez toujours définir un résolveur global dans le contexte http de niveau supérieur, ainsi que dans les blocs server et location. Si un bloc upstream ne contient pas de directive resolver, il hérite du paramètre resolver du contexte ou du bloc qui contient une directive proxy_pass faisant référence au groupe upstream, comme dans les versions précédentes.

Dans l’exemple suivant, le groupe en amont website utilise le résolveur global, tandis que mobile_app utilise son propre résolveur :

Chargement de l’exemple de code…

Notez que nous incluons le paramètre « status_zone » (introduit dans NGINX Plus R19) dans les deux directives « resolver », afin de recueillir les erreurs et d’autres métriques sur l’activité du résolveur.

Variables pour les métadonnées du serveur PROXY Protocol

Le protocole PROXY est un mécanisme qui permet à un proxy de couche 4 de transmettre des informations sur la connexion d’origine du client au proxy ou à l’équilibreur de charge suivant qui traite la requête du client. Cela est particulièrement important lorsque vous devez connaître l’adresse IP du client – par exemple, pour limiter le nombre de connexions établies par chaque client (avec la directive least_conn) ou simplement pour consigner l’adresse IP réelle du client. Comme dans les versions précédentes, la variable $proxy_protocol_addr enregistre ces informations.

Lorsque plusieurs proxys de couche 4 sont déployés dans un environnement applicatif, il est parfois important que NGINX Plus connaisse également l’adresse IP et le port du serveur proxy auquel le client s’est initialement connecté. Les métadonnées du protocole PROXY contiennent ces informations, et NGINX Plus R20 ajoute des variables permettant de les récupérer :

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

Les variables sont disponibles pour les modules HTTP et Stream (TCP/UDP) et prennent en charge les versions 1 et 2 du protocole PROXY. Notez qu’avant d’utiliser ces variables, vous devez explicitement configurer NGINX Plus pour qu’il prenne en charge le protocole PROXY en ajoutant le paramètre proxy_protocol à la directive listen.

Améliorations de la sécurité pour HTTP/2

NGINX Plus R18 P1 a corrigé trois vulnérabilités de sécurité dans HTTP/2 qui ont été annoncées en août. NGINX Plus R20 inclut des modifications supplémentaires qui améliorent la sécurité globale de notre implémentation de HTTP/2 :

• Amélioration de la détection des comportements incorrects ou non valides des clients
• Amélioration de l’envoi des réponses d’erreur HTTP/2 avant la lecture du corps de la requête du client
• Amélioration de la robustesse de la directive « worker_shutdown_timeout » pour les connexions HTTP/2 de longue durée
• Amélioration de la robustesse de la directive « proxy_request_buffering » pour les clients HTTP/2

Si vous utilisez HTTP/2 en production avec NGINX Plus R18 (sans correctif) ou une version antérieure, nous vous recommandons de passer à NGINX Plus R20 dès que possible.

Mises à jour de l’écosystème NGINX Plus

Module JavaScript NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.7, avec l’ajout de la prise en charge de nouveaux objets JavaScript :

• Function() constructeur
• Object.assign() méthode
• Number : méthodes toFixed(), toPrecision() et toExponential()
• Array.prototype.copyWithin() méthode
• Paramètre d’étiquette de la méthode « console.time() »

Pour en savoir plus sur njs, consultez la page d’accueil du projet ainsi que notre blog<.htmla>.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R20 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, ce qui permettra à NGINX de mieux vous aider lorsque vous aurez besoin d’ouvrir un ticket d’assistance.

Veuillez examiner attentivement les nouvelles fonctionnalités et les changements de comportement décrits dans cet article de blog avant de procéder à la mise à niveau.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le faire, que ce soit pour la sécurité, l’équilibrage de charge et la passerelle API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer dès aujourd’hui avec un essai gratuit de 30 jours. Découvrez par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

À propos de l’auteur

Liam CrillyDirecteur senior de la gestion des produits

Autres articles de Liam Crilly