Annonce de NGINX Plus R21

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que NGINX Plus Release 21 (R21) est désormais disponible. Basé sur NGINX Open Source, NGINX Plus est la seule solution tout-en-un combinant équilibreur de charge, cache de contenu, serveur web et passerelle d’API. Avec plus de 450 millions de sites web utilisant NGINX, NGINX Plus R21 est plus fiable et plus sécurisé que jamais, et se concentre principalement sur les corrections de bugs et améliorations de la stabilité issues de NGINX Open Source.

Les nouvelles fonctionnalités de NGINX Plus R21 incluent :

• Proxy gRPC dynamique – Nous avons ajouté la prise en charge des variables lors de la transmission des connexions gRPC aux services gRPC backend. Vous pouvez ainsi acheminer dynamiquement les connexions gRPC vers des groupes de services en fonction des attributs du client.
• Améliorations du module JavaScript de NGINX – Le module JavaScript de NGINX (njs) a été mis à jour vers la version 0.3.9, avec plusieurs corrections de bogues et des améliorations fonctionnelles supplémentaires concernant les sous-requêtes et la prise en charge du système de fichiers.

Modifications importantes du comportement

• Requêtes acceptables – Conformément à la norme RFC 7230, NGINX Plus n’autorise plus les requêtes clientes comportant plusieurs en-têtes Host.
• Nouveaux systèmes d’exploitation pris en charge – Alpine Linux 3.11.
• Anciens systèmes d’exploitation qui ne sont plus pris en charge – plateformes 32 bits (architectures i386).

Investir dans la qualité

L’efficacité des logiciels et la qualité du code sont au cœur de notre approche pour développer NGINX, aussi bien dans sa version open source que dans NGINX Plus.

L’équipe NGINX utilise tous les outils modernes d’intégration et de déploiement continus (CI/CD) et de tests automatisés que l’on peut attendre d’un logiciel commercial. Les tests quotidiens de la branche de développement active révèlent une « densité de défauts » remarquablement faible, de seulement 0,01 défaut pour 1 000 lignes de code, contre une densité moyenne de 0,7 défaut pour 1 000 lignes pour des bases de code de taille similaire.

Nous faisons également réaliser des tests d’intrusion et des revues de code externes et indépendants, tant pour les composants open source que pour ceux de NGINX Plus. Les plus récents de ces tests d’intrusion et revues de code ont permis d’identifier plusieurs problèmes qui sont corrigés dans cette version.

Corrections de bugs

Au total, NGINX Plus R21 inclut des correctifs pour 14 bugs :

• Fuite de sockets lors de l’utilisation de HTTP/2 (deux bugs distincts)
• Fuite de sockets lors de l’utilisation de sous-requêtes dans le module njs et de la directive aio directive
• Risque d’épuisement de la mémoire dans le module WebDav module
• Risque de divulgation de données en mémoire dans le module MP4 module
• Le code d’état « 494 » était renvoyé au lieu de « 400 » lorsque les erreurs portant le code « 494 » étaient redirigées à l’aide de la directive « error_page »
• Un délai d’expiration peut survenir lors du traitement de requêtes en pipeline dans une connexion SSL
• Une erreur de segmentation pouvait se produire dans un processus de travail si l’agrafage OCSP était utilisé
• Une erreur de segmentation pouvait se produire au démarrage ou lors de la reconfiguration si la configuration contenait la directive « rewrite » avec une chaîne de remplacement vide
• Une erreur de segmentation pouvait se produire dans un processus de travail si la directive break était utilisée conjointement avec la directive alias, ou avec la directive proxy_pass comportant un URI
• Seul le premier en-tête de requête « Transfer-Encoding » a été traité
• La ligne d’en-tête de réponse « Location » peut contenir des données incohérentes si l’URI de la requête a été réécrite de façon à contenir un caractère nul
• Les requêtes comportant un corps étaient traitées de manière incorrecte lors du renvoi de redirections avec la directive « error_page »
• Bug dans la directive « debug_points » lors de l’utilisation de HTTP/2

Veuillez noter qu’aucun de ces bugs n’était critique et qu’aucun enregistrement CVE ne leur est associé.

Investir dans la feuille de route de NGINX Plus

Au moment de cette publication, nous travaillons activement sur notre feuille de route 2020. Plus tard dans l’année, nous prévoyons de proposer une implémentation prête pour la production de HTTP/3 (également appelé QUIC). Si vous souhaitez suivre ou tester cette technologie, restez à l’affût des correctifs expérimentaux qui seront publiés dans les semaines à venir.

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

Proxy gRPC dynamique

NGINX Plus R15 a introduit la prise en charge du routage et de la répartition de charge du trafic gRPC vers des groupes en amont. Vous pouvez utiliser NGINX Plus pour acheminer le trafic gRPC en incluant la directive grpc_pass.

NGINX Plus R21 introduit la prise en charge des variables dans la directive grpc_pass afin de fournir des stratégies de routage dynamiques, pilotées par API et applicables aux charges de travail gRPC. Cela permet de répondre à des cas d’usage tels que :

• Tests A/B – Répartissez statistiquement les requêtes gRRC entre plusieurs serveurs en amont afin de déterminer lequel offre les meilleures performances.
• Routage de débogage – Acheminez le trafic vers un service gRPC de production, mais redirigez les requêtes présentant des attributs spécifiques (adresses IP sources, métadonnées gRPC) vers un service gRPC de débogage.

La configuration suivante est un exemple d’implémentation du routage de débogage.

Chargement de l’exemple de code…

À la ligne 1, nous définissons un magasin clé-valeur pouvant utiliser des plages réseau comme clés (fonctionnalité activée par le paramètre type=ip). La ligne 2 indique que la variable $greeter_upstream est évaluée en effectuant une recherche dans le magasin clé-valeur grpc-greeter, avec l’adresse IP du client ($remote_addr) comme clé.

À la ligne 10, nous spécifions grpc://$greeter_upstream comme paramètre de la directive grpc_pass, afin d’assurer la terminaison TLS et le routage dynamique des requêtes gRPC en fonction du sous-réseau IP du client.

Par exemple, vous pouvez exécuter la commande suivante sur l’instance NGINX Plus afin d’acheminer les requêtes provenant du sous-réseau 192.168.80.0/24 vers grpc-servers-greeter-debug :

$ curl -iX POST -d '{"192.168.80.0/24":"grpc-servers-greeter-debug"}' http://localhost:8080/api/6/http/keyvals/grpc-greeter

Pour rediriger le trafic gRPC vers le groupe de services de production (grpc-servers-greeter-prod), exécutez la commande suivante :

$ curl -iX PATCH -d '{"192.168.80.0/24":"grpc-servers-greeter-prod"}' https://localhost:8080/api/6/http/keyvals/grpc-greeter

Améliorations apportées au module JavaScript de NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.9 et bénéficie de plusieurs corrections de bugs ainsi que de quelques améliorations fonctionnelles concernant les sous-requêtes et la prise en charge du système de fichiers.

Sous-requêtes

La fonction r.subrequest permet au code njs d’effectuer des requêtes HTTP asynchrones vers n’importe quel URI. Elle offre de nombreux cas d’utilisation possibles, notamment les appels d’API vers un serveur d’authentification externe, par exemple l’introspection de jetons OAuth 2.0. Cette version apporte deux améliorations majeures aux sous-requêtes : les promesses et les sous-requêtes détachées.

[Note de la rédaction – Les deux exemples de cas d’utilisation suivants ne sont que quelques-uns des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez Cas d’utilisation du module JavaScript NGINX.]

Promesses

Les sous-requêtes comprennent généralement une fonction de rappel qui traite leur réponse. Il est désormais possible d’omettre cette fonction et d’utiliser les promesses JavaScript pour traiter les réponses directement dans le code appelant. L’exemple suivant montre comment enchaîner plusieurs sous-requêtes successives dans une même séquence de code sans utiliser de fonctions de rappel.

Chargement de l’exemple de code…

Sous-requêtes détachées

Les sous-requêtes sont asynchrones et, auparavant, elles devaient être appelées depuis une directive js_content. Désormais, elles peuvent également être déclenchées depuis une directive js_set lors de l’évaluation d’une variable. Ces sous-requêtes « détachées » continuent de fonctionner de manière asynchrone, mais ne renvoient aucune donnée à la fonction appelante, et toute réponse est ignorée.

L’exemple de code suivant utilise des sous-requêtes détachées pour envoyer une copie des en-têtes de la requête à un système de gestion des informations et des événements de sécurité (SIEM) si la quantité totale de données échangées dépasse 1 Mo.

[Éditeur – La configuration suivante a été mise à jour afin d’utiliser la directive js_import, qui a remplacé la directive js_include dans NGINX Plus R23<.htmla>. Pour plus d’informations, consultez la documentation de référence du module JavaScript NGINX – la section Exemple de configuration présente la syntaxe correcte pour les fichiers de configuration NGINX et les fichiers JavaScript.]

Chargement de l’exemple de code…

Le code JavaScript est ensuite exécuté lors de la phase de journalisation en demandant l’évaluation de la variable au moment de l’écriture du journal des accès.

Chargement de l’exemple de code…

Système de fichiers

L’objet de système de fichiers JavaScript « fs » a été amélioré afin de prendre en charge les promesses pour les opérations asynchrones. De plus, de nouvelles méthodes de système de fichiers sont disponibles : access(), realpath(), symlink(), et unlink().

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R21 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela 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 découvrir pour la sécurité, l’équilibrage de charge et la passerelle d’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