Annonce de NGINX Plus R20

Nous sommes heureux d'annoncer que NGINX Plus Release 20 (R20) est désormais disponible. NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un . Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités améliorées exclusives et un support primé.

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

• Surveillance et journalisation en temps réel du trafic à débit limité – Lorsque la limitation de débit est configurée, l’ API NGINX Plus indique désormais le nombre de requêtes transmises immédiatement, retardées ou rejetées. Vous pouvez également configurer le journal d’accès pour inclure des informations sur l’état de limitation de débit des demandes individuelles.
• Améliorations apportées à la limitation de connexion – Les améliorations apportées à la limitation de débit introduites dans la R19 et cette version ont été étendues à la limitation de connexion.
• Correspondance de préfixe dans le magasin clé-valeur – Les clés du magasin clé-valeur peuvent correspondre à un préfixe spécifié (caractères au début d’une chaîne). Un cas d’utilisation important est le routage dynamique des requêtes.
• Résolution DNS par groupe en amont – Vous pouvez désormais désigner un ensemble différent de serveurs DNS pour chaque groupe en amont qui utilise un nom d’hôte résoluble pour représenter les serveurs principaux du groupe.
• Variables de protocole PROXY supplémentaires – Les nouvelles variables capturent l’adresse IP et le port du serveur proxy auquel le client s’est connecté à l’origine.
• Améliorations de sécurité pour HTTP/2 – Plusieurs modifications améliorent la sécurité globale du trafic HTTP/2, notamment une meilleure détection des comportements clients incorrects ou non valides et une implémentation plus robuste de certaines directives.

Changements importants dans le comportement

• API obsolètes – NGINX Plus R13 (sorti en août 2017) a introduit la toute nouvelle API NGINX Plus<.htmlspan> pour la collecte de métriques et la reconfiguration dynamique des groupes en amont, remplaçant les API Status et Upstream Conf qui implémentaient auparavant ces fonctions. Comme annoncé à l'époque, les API obsolètes ont continué à être disponibles et prises en charge pendant une période significative, qui a pris fin avec NGINX Plus R16 . Si votre configuration inclut 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 sur la migration vers la nouvelle API NGINX Plus , veuillez consulter le guide de transition sur notre blog ou contacter 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 Hermine »)

Pour plus d'informations sur les plates-formes prises en charge, consultez les spécifications techniques de NGINX Plus et des modules dynamiques .

Nouvelles fonctionnalités en détail

Surveillance et enregistrement en temps réel du trafic à débit limité

NGINX Plus R20 introduit des fonctionnalités qui permettent aux équipes d’exploitation et de DevOps de surveiller plus facilement l’activité de limitation de débit en temps réel et de déterminer exactement quels clients ont dépassé la limite de débit.
NGINX Plus a toujours offert une grande flexibilité dans la manière dont vous définissez les types de demandes client à limiter et dans la manière dont les demandes excessives sont traitées. Chaque demande est traitée de l'une des manières suivantes :

• Passé sans délai (car le taux de requête est inférieur à la limite ou dans la taille de rafale configurée)
• Retardé jusqu'à ce qu'il soit dépassé, il n'entraîne pas de dépassement de la limite de débit (également appelé limitation )
• Rejeté 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 enregistrait le fait que les demandes étaient retardées ou rejetées, dans des entrées standardisées comme celle-ci :

2019/12/02 11:42:12 [erreur] 57#57 : *339 limitation des demandes, excès : 0,600 par zone "my_limit", client : 172.17.0.1, serveur : www.exemple.com, requête : "GET / HTTP/1.0", hôte : "www.exemple.com:80"

L’extraction d’informations utiles du journal des erreurs peut être difficile, car le format du message n’est pas structuré et non configurable. De plus, si la limite de débit est liée à une caractéristique de message autre que celles notées dans l'entrée du journal des erreurs (par exemple, les en-têtes HTTP ou les informations d'identité), vous devez alors rechercher l'entrée correspondante dans le journal d'accès pour déterminer exactement quel client a dépassé la limite de débit. Les nouvelles fonctionnalités répondent à ces problèmes.

Mesures de limitation de débit de l' API NGINX Plus

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

Dans l'exemple suivant, il y a une zone définie, my_limit :

$ curl http://localhost/api/6/http/limit_reqs { "ma_limite": { "retardé": 540, « exécution à sec retardée » : 12162, « passé » : 804541, « rejeté » : 63, « rejected_dry_run » : 1209 } }

Notez que ces compteurs incluent également des entrées pour les demandes excessives traitées en mode d’exécution à sec , qui a été introduit dans NGINX Plus R19 .

Enregistrement de l'activité de limitation du débit dans le journal d'accès

Les mesures en temps réel sont très utiles pour comprendre quand NGINX Plus traite des demandes excessives, mais elles ne vous indiquent pas qui les génère. Pour relever ce défi, NGINX Plus R20 fournit une nouvelle variable $limit_req_status . Il enregistre l'état de limitation du débit de la demande : RETARDÉ , ESSAI_À_SEC RETARDÉ , RÉUSSI , REJETÉ ou ESSAI_À_SEC REJETÉ .

Vous pouvez ensuite inclure d’autres variables dans le format du journal qui identifient de manière unique le client, l’URI et toute autre information pertinente. Dans la configuration suivante, une limite de débit stricte de 10 requêtes par seconde est appliquée pour chaque client, en fonction de la validation du jeton Web JSON (JWT) (ligne 1). Les demandes excessives sont rejetées (ligne 16) et enregistrées dans un fichier journal distinct (ligne 21), qui inclut également la variable $jwt_claim_sub pour capturer la sous -réclamation (ligne 4).

Exemples d'entrées dans le fichier reject.log :

heure=1575289305.350 client=10.0.0.1 sub=adam uri=/ statut=429 limit_req=REJECTEDheure=1575289305.395 client=10.0.0.1 sub=adam uri=/ statut=429 limit_req=REJECTED
heure=1575289305.402 client=10.0.0.1 sub=adam uri=/ statut=429 limit_req=REJECTED

Améliorations apportées à la limitation de connexion

En plus de la limitation du débit des requêtes, NGINX Plus prend en charge la limitation des connexions client avec le module Limiter les connexions . Vous pouvez définir le nombre de connexions distinctes qu'un client peut ouvrir sur NGINX Plus (ou le nombre de requêtes simultanées lors de l'utilisation de HTTP/2). Un client est généralement identifié par l'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 éventuellement partagée par plusieurs clients.

NGINX Plus R20 étend la limitation de connexion avec les mêmes améliorations de limitation de débit introduites dans NGINX Plus R19 et cette version :

• Mode d'exécution à sec avec la directive limit_conn_dry_run
• Surveillance en temps réel au point de terminaison de l' API NGINX Plus /api/ version /http/limit_conns
• Une nouvelle variable, $limit_conn_status , qui capture la décision de limitation de connexion pour chaque demande ( PASSED , REJECTED ou REJECTED_DRY_RUN ) et peut être utilisée comme décrit dans Journalisation de l'activité de limitation du débit dans le journal d'accès pour la variable $limit_req_status

La configuration suivante applique une faible bande passante aux clients qui ouvrent plus de dix connexions simultanées.

Correspondance de préfixes dans le magasin de clés-valeurs

Avec le magasin clé-valeur en mémoire pour NGINX Plus, vous pouvez utiliser l’ API NGINX Plus pour configurer dynamiquement la gestion du trafic en fonction des attributs de la demande. Les exemples de cas d’utilisation incluent la liste de refus dynamique des adresses IP , la limitation dynamique de la bande passante et la mise en cache des jetons d’authentification .

NGINX Plus R20 ajoute la prise en charge de la correspondance des clés avec un préfixe spécifié (caractères au début d'une chaîne), permettant un nouvel ensemble de cas d'utilisation pour le magasin clé-valeur. Par exemple, pouvoir faire correspondre les clés aux préfixes d'URI (chemins de base) plutôt qu'aux URI exacts signifie que vous pouvez créer une table de routage dynamique pour mapper chaque chemin de base à un groupe en amont, remplaçant ou augmentant les mappages statiques définis par les directives de localisation .

Pour activer la correspondance des préfixes, incluez 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 demande au serveur en amont.

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/paths HTTP/1.1 201 Serveur créé : nginx/1.17.6 Date : Lun, 2 déc. 2019 12:36:31 GMT Durée du contenu : 0 Emplacement : http://localhost:8080/api/6/http/keyvals/paths/ Connexion : keep-alive

Lorsque nous faisons 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 définissons :

$ curl -I http://localhost/images/sample.jpg HTTP/1.1 200 OK Serveur : nginx/1.17.6 Date : lun. 2 déc. 2019 12:27:39 GMT Type de contenu : image/jpeg Longueur du contenu : 120847 Connexion : keep-alive Cache-Control : max-age=3600

Étant donné que le magasin clé-valeur peut être synchronisé sur un cluster d’instances NGINX Plus , vous devez effectuer chaque appel d’API vers une seule instance. Cela rend le processus d’automatisation des modifications de configuration du cluster beaucoup plus simple que la coordination des modifications apportées aux fichiers de configuration .

Résolution DNS par groupe en amont

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

Pour terminer la configuration de ces groupes dynamiques en amont, vous incluez également la directive resolver pour 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 de résolution s'appliquait à tous les groupes 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 en amont.

La nouvelle flexibilité est particulièrement utile dans un environnement DevOps : elle permet aux équipes d’application de posséder une plus grande partie de leur infrastructure de distribution d’applications, y compris les serveurs DNS et les registres de services, au lieu de s’appuyer sur des services centralisés et partagés.

Vous pouvez toujours définir un résolveur global dans le contexte http de niveau supérieur et dans les blocs de serveur et d’emplacement . Si un bloc en amont n'inclut pas de directive de résolution , il hérite du paramètre de résolution du contexte ou du bloc qui inclut une directive proxy_pass référençant le groupe en amont, comme dans les versions précédentes.

Dans l'exemple suivant, le groupe en amont du site Web utilise le résolveur global tandis que mobile_app utilise son propre résolveur :

Notez que nous incluons le paramètre status_zone ( introduit dans NGINX Plus R19 ) aux deux directives de résolution , pour collecter les erreurs et d'autres mesures sur l'activité du résolveur.

Variables pour les métadonnées du serveur de protocole PROXY

Le protocole PROXY est un mécanisme par lequel un proxy de couche 4 peut transmettre des informations sur la connexion client d'origine au proxy ou à l'équilibreur de charge suivant qui gère la demande client. Ceci est particulièrement important pour les cas d'utilisation où vous devez connaître l'adresse IP du client, par exemple pour limiter le nombre de connexions effectuées par chaque client (avec la directive least_conn ) ou simplement pour enregistrer l'adresse IP réelle du client. Comme dans les versions précédentes, la variable $proxy_protocol_addr capture ces informations.

Lorsqu'il existe plusieurs proxys de couche 4 déployés dans un environnement d'application, il est parfois important pour NGINX Plus de connaître également l'adresse IP et le port du serveur proxy auquel le client s'est connecté à l'origine. Les métadonnées du protocole PROXY incluent ces informations et NGINX Plus R20 ajoute des variables pour les capturer :

• $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 les variables, vous devez explicitement activer NGINX Plus pour gérer le protocole PROXY, en ajoutant le paramètre proxy_protocol à la directive listen .

Améliorations de 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 HTTP/2 :

• Détection améliorée des comportements clients incorrects ou non valides
• Amélioration de l'envoi des réponses d'erreur HTTP/2 avant que le corps de la requête client n'ait été lu
• 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 (non corrigé) ou une version antérieure, nous vous recommandons de procéder à une mise à niveau vers 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 version0.3.7 , ajoutant la prise en charge de plus d'objets JavaScript :

• Constructeur de fonction Function()
• Méthode Object.assign()
• Méthodes numériques : toFixed() , toPrecision() et toExponential()
• Méthode Array.prototype.copyWithin()
• Paramètre d'étiquette pour la méthode console.time()

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

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R20 dès que possible. Vous bénéficierez également d'un certain nombre de correctifs et d'améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer 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 essayé NGINX Plus, nous vous encourageons à l'essayer - pour la sécurité, l'équilibrage de charge et la passerelle API, ou en tant que serveur Web entièrement pris en charge avec des API de surveillance et de gestion améliorées. 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 à fournir et à faire évoluer vos applications.