Annonce de NGINX Plus R21

Nous sommes heureux d'annoncer que NGINX Plus Release 21 (R21) est désormais disponible. Basé sur NGINX Open Source, NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un . Avec plus de 450 millions de sites Web s'appuyant sur NGINX , NGINX Plus R21 est plus fiable et plus sécurisé que jamais, se concentrant principalement sur les corrections de bugs et les améliorations de stabilité de NGINX Open Source.

Les nouvelles fonctionnalités de NGINX Plus R21 incluent :

• Proxy gRPC dynamique – Nous avons ajouté une prise en charge variable lors de la transmission de connexions gRPC aux services gRPC back-end. Cela vous permet d'acheminer dynamiquement les connexions gRPC vers des groupes de services en fonction des attributs client.
• Améliorations du module JavaScript NGINX – Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.9, avec plusieurs corrections de bogues et des améliorations fonctionnelles supplémentaires liées aux sous-requêtes et à la prise en charge du système de fichiers.

Changements importants dans le comportement

• Requêtes acceptables – Conformément à la RFC 7230 , NGINX Plus n’autorise plus les demandes client avec plusieurs en-têtes d’hôte .
• Nouveaux systèmes d’exploitation pris en charge – Alpine Linux 3.11.
• Les anciens systèmes d’exploitation ne sont plus pris en charge – plates-formes 32 bits (architectures i386).

Investir dans la qualité

L'efficacité des logiciels et la qualité du code sont des principes fondamentaux de la manière dont nous construisons NGINX, à la fois open source et NGINX Plus.

L'équipe NGINX utilise tous les outils modernes de CI/CD et de tests automatisés que vous attendez de tout logiciel commercial. Les tests quotidiens de la branche de développement active montrent une « densité de défauts » remarquablement faible de seulement 0,01 défaut pour 1 000 lignes de code, par rapport à une densité moyenne de 0,7 défaut pour 1 000 lignes pour des bases de code de taille similaire.

Nous commandons également des tests de pénétration et des revues de code externes et indépendants pour les composants open source et NGINX Plus. Les tests de pénétration et les revues de code les plus récents ont identifié plusieurs problèmes qui sont traités dans cette version.

Corrections de bugs

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

• Fuite de socket lors de l'utilisation de HTTP/2 (deux bugs distincts)
• Fuite de socket lors de l'utilisation de sous-requêtes dans le module njs et la directive aio
• Épuisement potentiel de la mémoire dans le module WebDav
• Divulgation potentielle de mémoire dans le module MP4
• Code d'état494 a été renvoyé à la place de400 en cas d'erreurs avec le code494 ont été redirigés avec la directive error_page
• Un dépassement de délai peut se produire lors du traitement des requêtes en pipeline dans une connexion SSL
• Une erreur de segmentation peut se produire dans un processus de travail si l'agrafage OCSP a été utilisé
• Une erreur de segmentation peut se produire au démarrage ou pendant la reconfiguration si la configuration incluait la directive de réécriture avec une chaîne de remplacement vide
• Une erreur de segmentation peut se produire dans un processus de travail si la directive break a été utilisée conjointement avec la directive alias ou conjointement avec la directive proxy_pass avec un URI
• Seul le premier en-tête de demande Transfer-Encoding a été traité
• La ligne d'en-tête de réponse Location peut contenir des données inutiles si l'URI de la demande a été réécrite en une URI contenant un caractère nul
• Les requêtes avec corps étaient traitées de manière incorrecte lors du retour 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'il n'y a pas d'enregistrement CVE associé.

Investir dans la feuille de route NGINX Plus

Au moment de la publication de cette publication, nous travaillons dur sur notre feuille de route 2020. Plus tard cette année, nous prévoyons de rendre disponible une implémentation de niveau production de HTTP/3 (alias QUIC). Si vous souhaitez suivre ou tester cette technologie, soyez attentifs aux correctifs expérimentaux dans les semaines à venir.

Nouvelles fonctionnalités en détail

Proxy gRPC dynamique

NGINX Plus R15 a introduit la prise en charge du routage et de l'équilibrage de charge du trafic gRPC vers les groupes en amont. Vous pouvez exploiter 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 pour fournir des politiques de routage dynamiques pilotées par API qui s'étendent 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 sur plusieurs flux en amont pour déterminer lequel est le plus performant.
• Routage de débogage – Acheminez le trafic vers un service gRPC de production, mais acheminez les requêtes avec 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.

Dans la ligne 1, nous définissons un magasin clé-valeur qui peut utiliser des plages réseau comme clé (activé par le paramètre type=ip ). La ligne 2 spécifie que la variable $greeter_upstream est évaluée en effectuant une recherche dans le magasin de clés-valeurs grpc-greeter , en utilisant l'adresse IP du client ( $remote_addr ) comme clé.

Sur la ligne 10, nous spécifions grpc://$greeter_upstream comme paramètre de la directive grpc_pass , pour 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 pour 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 basculer 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 NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.9 avec plusieurs corrections de bugs et quelques améliorations fonctionnelles liées aux 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. Cela présente de nombreux cas d'utilisation possibles, un exemple notable étant les appels d'API vers un serveur d'authentification externe, par exemple l'introspection du jeton OAuth 2.0 . Cette version apporte deux améliorations significatives aux sous-requêtes : les promesses et les sous-requêtes détachées.

[ Éditeur – Les deux exemples de cas d’utilisation suivants ne sont que quelques-uns des nombreux cas d’utilisation du module JavaScript NGINX. Pour une liste complète, voir Cas d'utilisation du module JavaScript NGINX . ]

Promesses

Les sous-requêtes incluent généralement une fonction de rappel qui traite la réponse de la sous-requête. Une fonction de rappel peut désormais être omise, en utilisant les promesses JavaScript comme moyen de traiter les réponses en ligne avec le code appelant. L'exemple suivant illustre comment des sous-requêtes successives peuvent être enchaînées dans une seule séquence de code sans utiliser de rappels.

Sous-requêtes détachées

Les sous-requêtes sont asynchrones et devaient auparavant être invoquées à partir d'une directive js_content . Désormais, les sous-requêtes peuvent également être déclenchées à partir d'une directive js_set lors de l'évaluation d'une variable. Ces sous-requêtes « détachées » fonctionnent toujours 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 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 pour 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 montre la syntaxe correcte pour la configuration NGINX et les fichiers JavaScript.]

Le code JavaScript est ensuite exécuté lors de la phase de log en demandant l'évaluation des variables lorsque nous écrivons le journal d'accès.

Système de fichiers

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

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R21 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.