Annonce de NGINX Plus R15

Nous sommes heureux d’annoncer que la quinzième version de NGINX Plus, notre produit phare, est désormais disponible. Depuis notre lancement initial en 2013 , NGINX Plus a connu une croissance considérable, tant au niveau de ses fonctionnalités que de son attrait commercial. Il y a maintenant plus de [ngx_snippet name='nginx-plus-customers'] clients NGINX Plus et [ngx_snippet name='number-sites'] utilisateurs de NGINX Open Source .

Basé sur NGINX Open Source, NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un . NGINX Plus inclut des fonctionnalités améliorées exclusives conçues pour réduire la complexité de l'architecture des applications modernes, ainsi qu'un support primé.

NGINX Plus R15 introduit une nouvelle prise en charge de gRPC, un serveur HTTP/2 push, une prise en charge améliorée du clustering, une fonctionnalité de passerelle API améliorée, et bien plus encore :

• Prise en charge native de gRPC – gRPC est la nouvelle norme d’appel de procédure à distance (RPC) développée par Google. C'est un moyen léger et efficace pour les clients et les serveurs de communiquer. Avec cette nouvelle fonctionnalité, NGINX Plus peut terminer, acheminer et équilibrer la charge du trafic gRPC vers vos serveurs back-end.
• HTTP/2 server push – Avec HTTP/2 server push, NGINX Plus vous envoie les ressources avant que vous les demandiez, ce qui améliore les performances et réduit les allers-retours.
• Partage d’état sur un cluster – Avec cette version, les données de mémoire partagée utilisées pour la persistance de session Sticky Learn peuvent être partagées sur toutes les instances NGINX Plus d’un cluster. Les prochaines versions de NGINX Plus s’appuieront sur nos capacités de clustering et introduiront de nouvelles fonctionnalités prenant en charge les clusters.
• Intégration OpenID Connect – Vous pouvez désormais fournir une authentification unique (SSO) à n’importe quelle application Web avec NGINX Plus, en utilisant le flux de code d’autorisation OpenID Connect et en émettant des jetons Web JSON (JWT) aux clients. NGINX Plus s'intègre à CA Single Sign-On (anciennement SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity et d'autres fournisseurs d'identité populaires.
• Améliorations du module NGINX JavaScript (njs) – Les modules njs (anciennement nginScript) vous permettent d’exécuter du code JavaScript pendant le traitement des requêtes NGINX Plus. Le module njs pour HTTP prend désormais en charge l'émission de sous-requêtes HTTP indépendantes et asynchrones de la demande client. Cela est utile dans les cas d'utilisation de passerelle API, vous offrant la flexibilité de modifier et de consolider les appels API à l'aide de JavaScript. Les modules njs pour HTTP et TCP/UDP incluent désormais également des bibliothèques cryptographiques permettant la mise en œuvre de fonctions de hachage courantes.

La version est complétée par de nouvelles fonctionnalités , notamment une nouvelle variable ALPN, des mises à jour de plusieurs modules dynamiques, et bien plus encore.

Changements de comportement

• NGINX Plus R13 a vu l’introduction de la toute nouvelle API NGINX Plus, qui permet des fonctions qui étaient auparavant implémentées dans des API distinctes, notamment la configuration dynamique de groupes en amont et des métriques étendues. Les API précédentes, configurées avec les directives upstream_conf et status , sont obsolètes. Nous vous encourageons à vérifier votre configuration pour ces directives et à convertir vers la nouvelle directive API dès que possible (pour plus de détails, voir Annonce de NGINX Plus R13 sur notre blog). À partir de la prochaine version, NGINX Plus R16 , les API obsolètes ne seront plus fournies.
• L'API NGINX Plus est mise à jour vers la version 3 dans cette version. Les versions précédentes sont toujours prises en charge. Si vous envisagez de mettre à jour vos clients API, consultez la documentation sur la compatibilité des API .
• Les packages NGINX Plus disponibles dans le référentiel officiel disposent désormais d'un nouveau schéma de numérotation. Le package NGINX Plus et tous les modules dynamiques indiquent désormais le numéro de version NGINX Plus. Chaque version de package correspond désormais à la version NGINX Plus, afin de clarifier quelle version est installée et de simplifier les dépendances des modules. Ce changement est transparent, sauf si vous utilisez des systèmes automatisés qui référencent les packages par numéro de version. Dans ce cas, veuillez d’abord tester votre processus de mise à niveau dans un environnement non productif.

Caractéristiques détaillées de NGINX Plus R15

Prise en charge de gRPC

Avec cette version, NGINX Plus peut servir de proxy et équilibrer la charge du trafic gRPC, que de nombreuses organisations utilisent déjà pour communiquer avec les microservices. gRPC est un framework d'appel de procédure à distance (RPC) open source et hautes performances conçu par Google pour une communication de service à service hautement efficace et à faible latence. gRPC impose HTTP/2, plutôt que HTTP 1.1, comme mécanisme de transport, car les fonctionnalités de HTTP/2 (contrôle de flux, multiplexage et streaming de trafic bidirectionnel à faible latence) sont parfaitement adaptées à la connexion de microservices à grande échelle.

La prise en charge de gRPC a été introduite dans NGINX Open Source 1.13.10 et est désormais incluse dans NGINX Plus R15 . Vous pouvez désormais inspecter et acheminer les appels de méthode gRPC, ce qui vous permet de :

• Appliquez les fonctionnalités NGINX Plus – notamment le chiffrement HTTP/2 TLS, la limitation du débit, les listes de contrôle d’accès basées sur les adresses IP et la journalisation – aux services gRPC publiés.
• Publiez plusieurs services gRPC via un seul point de terminaison en inspectant et en proxyant les connexions gRPC vers les services internes.
• Faites évoluer vos services gRPC lorsque vous avez besoin de capacité supplémentaire en équilibrant la charge des connexions gRPC vers les pools backend en amont.
• Utilisez NGINX Plus comme passerelle API pour les points de terminaison gRPC et RESTful.

Pour en savoir plus, consultez Présentation de la prise en charge de gRPC avec NGINX 1.13.10 sur notre blog.

Serveur HTTP/2 Push

Les premières impressions sont importantes et le temps de chargement de la page est un facteur essentiel pour déterminer si les utilisateurs reviendront sur votre site Web. Une façon de fournir des réponses plus rapides aux utilisateurs est d'utiliser le serveur push HTTP/2, qui réduit le nombre de RTT (temps d'aller-retour, le temps nécessaire pour une demande et une réponse) que l'utilisateur doit attendre.

Le serveur push HTTP/2 a fortement mobilisé la communauté open source NGINX et a été introduit dans NGINX Open Source 1.13.9. Intégré désormais dans NGINX Plus R15, il permet au serveur d’envoyer d’emblée les données nécessaires pour compléter une requête cliente initiale. Par exemple, un navigateur a besoin de nombreuses ressources – feuilles de style, images, etc. – pour afficher une page web. Nous vous suggérons donc d’envoyer ces ressources dès la première visite, sans attendre que le navigateur les demande.

Dans l'exemple de configuration ci-dessous, nous utilisons la directive http2_push pour préparer un client avec des feuilles de style et des images dont il aura besoin pour restituer la page Web de démonstration :

Dans certains cas, il est impossible de déterminer précisément les ressources requises par les clients, ce qui rend impraticable la liste de fichiers spécifiques dans le fichier de configuration NGINX. Vous pouvez alors configurer NGINX pour qu’il intercepte les en-têtes HTTP Link et envoie les ressources marquées preload. Pour activer l’interception des en-têtes Link, réglez la directive http2_push_preload sur on.

Pour en savoir plus, consultez Présentation de HTTP/2 Server Push avec NGINX 1.13.9 sur notre blog.

Partage d'état dans un cluster

La configuration de plusieurs serveurs NGINX Plus dans un cluster haute disponibilité rend vos applications plus résilientes et élimine les points de défaillance uniques dans votre pile d’applications. Le clustering NGINX Plus est conçu pour les déploiements de production critiques où la résilience et la haute disponibilité sont primordiales. Il existe de nombreuses solutions pour déployer un clustering haute disponibilité avec NGINX Plus .

La prise en charge du clustering a été introduite dans les versions précédentes de NGINX Plus, offrant deux niveaux de clustering :

• Résilience du réseau à l’aide du package keepalived – Gère le basculement en cas de panne d’un serveur NGINX Plus.
• Synchronisation de la configuration à l’aide du package nginx-sync – Garantit que la configuration est synchronisée sur tous les serveurs NGINX Plus.

NGINX Plus R15 introduit un troisième niveau de clustering : le partage d’état pendant l’exécution, vous permettant de synchroniser les données dans les zones de mémoire partagée entre les nœuds du cluster. Plus précisément, les données stockées dans les zones de mémoire partagée pour la persistance des sessions Sticky Learn peuvent désormais être synchronisées sur tous les nœuds du cluster à l'aide du nouveau module zone_sync pour le trafic TCP/UDP.

Nouveau module zone_sync

Avec le partage d’état, il n’y a pas de nœud principal : tous les nœuds sont des pairs et échangent des données dans une topologie en maillage complet . De plus, la solution de clustering de partage d’état est indépendante de la solution de haute disponibilité pour la résilience du réseau. Par conséquent, un cluster de partage d’état peut s’étendre sur plusieurs emplacements physiques.

Un cluster de partage d’état NGINX Plus doit répondre à trois exigences :

• Connectivité réseau entre tous les nœuds du cluster
• Horloges synchronisées
• La configuration sur chaque nœud active le module zone_sync , comme dans ce qui suit :

La directive zone_sync permet la synchronisation des zones de mémoire partagée dans un cluster. La directive zone_sync_server identifie les autres instances NGINX Plus dans le cluster. NGINX Plus prend en charge la découverte de services DNS afin que les membres du cluster puissent être identifiés par nom d'hôte et que la configuration soit identique pour chaque membre du cluster.

La configuration minimale ci-dessus ne dispose pas des contrôles de sécurité nécessaires pour protéger les données de synchronisation dans un déploiement de production. L'extrait de configuration suivant utilise plusieurs de ces mesures de protection :

• Cryptage SSL/TLS des données de synchronisation
• Authentification par certificat client, afin que chaque nœud du cluster s'identifie auprès des autres (TLS mutuel)
• Listes de contrôle d'accès (ACL) utilisant des adresses IP, afin que seuls les nœuds NGINX Plus sur le même réseau physique puissent se connecter pour la synchronisation

Partage d'état pour la persistance des sessions Sticky Learn

La première fonctionnalité NGINX Plus prise en charge qui utilise les données d’état partagées sur un cluster est la persistance de session Sticky Learn . La persistance de session signifie que les demandes d'un client sont toujours transmises au serveur qui a répondu à la première demande du client, ce qui est utile lorsque l'état de session est stocké au niveau du backend.

Dans la configuration suivante, la directive sticky learn définit une zone de mémoire partagée appelée sessions . Le paramètre de synchronisation permet le partage d’état à l’échelle du cluster en demandant à NGINX Plus de publier des messages sur le contenu de sa zone de mémoire partagée sur les autres nœuds du cluster.

Notez que pour que la synchronisation des données d'état fonctionne correctement, la configuration sur chaque nœud NGINX Plus du cluster doit inclure le même bloc en amont avec la directive sticky learn , ainsi que les directives qui activent le module zone_sync (décrit ci-dessus ).

Note : La prise en charge du clustering et la persistance des sessions Sticky Learn sont exclusives à NGINX Plus.

Intégration OpenID Connect

De nombreuses entreprises utilisent des solutions de gestion des identités et des accès (IAM) pour gérer les comptes d’utilisateurs et fournir un environnement d’authentification unique (SSO) pour plusieurs applications. Ils cherchent souvent à étendre l’authentification unique aux applications nouvelles et existantes afin de minimiser la complexité et les coûts.

NGINX Plus R10 a introduit la prise en charge de la validation des jetons OpenID Connect . Dans cette version, nous étendons cette capacité afin que NGINX Plus puisse également contrôler le flux de code d'autorisation pour l'authentification avec OpenID Connect 1.0 , en communiquant avec le fournisseur d'identité et en émettant le jeton d'accès au client. Cela permet l’intégration avec la plupart des principaux fournisseurs d’identité, notamment CA Single Sign-On (anciennement SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin et Ping Identity. La nouvelle fonctionnalité étendue vous permet également :

• Étendre l'authentification unique aux applications existantes sans modifier ni moderniser ces applications
• Intégrer SSO dans de nouvelles applications sans implémenter SSO ou l'authentification dans le code de l'application
• Éliminez le verrouillage des fournisseurs ; vous obtenez une authentification unique basée sur des normes sans avoir à déployer un logiciel d'agent de fournisseur IAM propriétaire avec l'application

L'intégration d'OpenID Connect avec NGINX Plus est disponible en tant qu'implémentation de référence sur GitHub. Le référentiel GitHub inclut un exemple de configuration avec des instructions sur l'installation, la configuration et le réglage fin pour des cas d'utilisation spécifiques.

Améliorations apportées au module JavaScript NGINX

[ Éditeur – Les exemples 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 .

Le code de cette section est mis à jour comme suit pour refléter les modifications apportées à l'implémentation de NGINX JavaScript depuis la publication initiale du blog :

• Pour utiliser l'objet de session ( s ) refactorisé pour le module Stream, qui a été introduit dans NGINX JavaScript 0.2.4 .
• Pour utiliser la directive js_import , qui remplace la directive js_include dans NGINX Plus R23 et versions ultérieures. Pour plus d’informations, consultez la documentation de référence du module JavaScript NGINX – la section Exemple de configuration affiche la syntaxe correcte pour les fichiers de configuration NGINX et JavaScript.

]

Avec le module JavaScript NGINX, njs (anciennement nginScript), vous pouvez inclure du code JavaScript dans votre configuration NGINX afin qu'il soit évalué au moment de l'exécution, lorsque les requêtes HTTP ou TCP/UDP sont traitées. Cela permet une large gamme de cas d'utilisation potentiels tels que l'obtention d'un contrôle plus précis du trafic, la consolidation des fonctions JavaScript dans les applications et la défense contre les menaces de sécurité.

NGINX Plus R15 inclut deux mises à jour importantes de njs : les sous-requêtes et les fonctions de hachage .

Sous-requêtes

Vous pouvez désormais émettre des requêtes HTTP simultanées qui sont indépendantes et asynchrones de la requête client. Cela permet une multitude de cas d’utilisation avancés.

L'exemple de code JavaScript suivant émet une requête HTTP vers deux backends différents simultanément. La première réponse est envoyée à NGINX Plus pour être transmise au client et la deuxième réponse est ignorée.

La directive js_import dans la configuration NGINX Plus correspondante lit le code JavaScript de faster_wins.js . Toutes les requêtes correspondant à l'emplacement racine ( / ) sont transmises à la fonction sendFastest() qui génère des sous-requêtes vers les emplacements /server_one et /server_two . L'URI d'origine avec les paramètres de requête est transmis aux serveurs back-end correspondants. Les deux sous-requêtes exécutent la fonction de rappel done . Cependant, comme cette fonction inclut r.return() , seule la sous-requête qui se termine en premier envoie sa réponse au client.

Fonctions de hachage

Les modules njs pour le trafic HTTP et TCP/UDP incluent désormais une bibliothèque cryptographique avec des implémentations de :

• Fonctions de hachage : MD5, SHA‑1, SHA‑256
• HMAC utilisant : MD5, SHA‑1, SHA‑256
• Formats de résumés : Base64, URL Base64, hexadécimal

Un exemple de cas d’utilisation des fonctions de hachage consiste à ajouter l’intégrité des données aux cookies d’application. L'exemple de code njs suivant inclut une fonction signCookie() pour ajouter une signature numérique à un cookie et une fonction validateCookieSignature() pour valider les cookies signés.

La configuration NGINX Plus suivante utilise le code njs pour valider les signatures de cookies dans les requêtes HTTP entrantes et renvoyer un message d'erreur au client si la validation échoue. NGINX Plus proxy la requête si la validation réussit ou si aucun cookie n'est présent.

Nouvelles fonctionnalités supplémentaires dans NGINX Plus R15

Variable ALPN pour les modules de flux

La négociation du protocole de couche d'application (ALPN) est une extension de TLS qui permet à un client et à un serveur de négocier pendant la négociation TLS quel protocole sera utilisé pour la connexion en cours d'établissement, évitant ainsi des allers-retours supplémentaires qui pourraient entraîner une latence et dégrader l'expérience utilisateur. Le cas d'utilisation le plus courant d'ALPN est la mise à niveau automatique des connexions de HTTP vers HTTP/2 lorsque le client et le serveur prennent en charge HTTP/2.

La nouvelle variable NGINX $ssl_preread_alpn_protocols , introduite pour la première fois dans NGINX Open Source 1.13.10, capture la liste des protocoles annoncés par le client dans son message ClientHello lors de la phase de prélecture ALPN. Compte tenu de la configuration ci-dessous, un client XMPP peut se présenter via ALPN de telle sorte que NGINX Plus achemine le trafic XMPP vers le groupe en amont xmpp_backend , le trafic gRPC vers grpc_backend et tout autre trafic vers http_backend , le tout via un seul point de terminaison.

Pour permettre à NGINX Plus d'extraire des informations du message ClientHello et de renseigner la variable $ssl_preread_alpn_protocols , vous devez également inclure la directive ssl_preread on .

Pour en savoir plus, consultez la documentation du module ngx_stream_ssl_preread .

Variable de temps de file d'attente

NGINX Plus prend en charge la mise en file d'attente en amont afin que les demandes des clients ne soient pas rejetées immédiatement lorsque tous les serveurs du groupe en amont ne sont pas disponibles pour accepter de nouvelles demandes.

Un cas d’utilisation typique de la mise en file d’attente en amont consiste à protéger les serveurs principaux contre les surcharges sans avoir à rejeter immédiatement les demandes si tous les serveurs sont occupés. Vous pouvez définir le nombre maximal de connexions simultanées pour chaque serveur en amont avec le paramètre max_conns de la directive server . La directive queue place ensuite les requêtes dans une file d'attente lorsqu'aucun backend n'est disponible, soit parce qu'elles ont atteint leur limite de connexion, soit parce qu'elles ont échoué à un contrôle de santé .

Dans cette version, la nouvelle variable NGINX $upstream_queue_time , introduite pour la première fois dans NGINX Open Source 1.13.9, capture le temps qu'une requête passe dans la file d'attente. La configuration ci-dessous inclut un format de journal personnalisé qui capture diverses mesures de synchronisation pour chaque demande ; les mesures peuvent ensuite être analysées hors ligne dans le cadre du réglage des performances. Nous limitons le nombre de requêtes en file d'attente pour le groupe en amont my_backend à 20. Le paramètre timeout définit la durée pendant laquelle les requêtes sont conservées dans la file d'attente avant qu'un message d'erreur ne soit renvoyé au client (503 par défaut). Ici, nous le définissons sur 5 secondes (la valeur par défaut est 60 secondes).

Pour en savoir plus, consultez la documentation de la directive queue .

Accéder aux journaux sans s'échapper

Vous pouvez désormais désactiver l'échappement dans le journal d'accès NGINX Plus. Le nouveau paramètre escape=none de la directive log_format , introduit pour la première fois dans NGINX Open Source 1.13.10, spécifie qu'aucun échappement n'est appliqué aux caractères spéciaux dans les variables.

Mise à jour de l'implémentation de référence d'authentification LDAP

Notre implémentation de référence pour l'authentification des utilisateurs à l'aide d'un système d'authentification LDAP a été mise à jour pour résoudre les problèmes et corriger les bogues. Découvrez-le sur GitHub .

Proxy transparent sans privilège root

Vous pouvez utiliser NGINX Plus comme proxy transparent en incluant le paramètre transparent à la directive proxy_bind . Les processus de travail peuvent désormais hériter de la capacité Linux CAP_NET_RAW du processus maître afin que NGINX Plus ne nécessite plus de privilèges spéciaux pour le proxy transparent.

Note : Cette fonctionnalité s'applique uniquement aux plates-formes Linux.

Période de grâce JWT

Si un JWT inclut une revendication basée sur le temps ( nbf (pas avant la date), exp (date d'expiration) ou les deux), la validation du JWT par NGINX Plus inclut une vérification que l'heure actuelle se situe dans l'intervalle de temps spécifié. Toutefois, si l'horloge du fournisseur d'identité n'est pas synchronisée avec l'horloge de l'instance NGINX Plus, les jetons peuvent expirer de manière inattendue ou sembler démarrer dans le futur. Pour définir le décalage maximal acceptable entre les deux horloges, utilisez la directive auth_jwt_leeway .

Module dynamique d'indicateur de cookie

Le module tiers permettant de définir des indicateurs de cookies est désormais disponible en tant que module dynamique Cookie-Flag dans le référentiel NGINX et est couvert par votre contrat de support NGINX Plus. Vous pouvez utiliser votre outil de gestion de paquets pour l'installer :

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Mise à jour du module WAF NGINX ModSecurity

NGINX ModSecurity WAF , un module dynamique pour NGINX Plus basé sur ModSecurity 3.0, a été mis à jour avec les améliorations suivantes :

• Améliorations des performances dans libmodsecurity
• Corrections de fuites de mémoire dans ModSecurity-nginx

[ Éditeur – NGINX ModSecurity WAF est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

Mettre à niveau ou essayer NGINX Plus

NGINX Plus R15 inclut des capacités d'authentification améliorées pour vos applications clientes, des capacités de clustering supplémentaires, des améliorations njs et des corrections de bogues notables .

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à niveau vers la version 15 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et la mise à niveau nous aidera à vous aider lorsque vous aurez besoin de créer un ticket d'assistance. Les instructions d'installation et de mise à niveau de NGINX Plus R15 sont disponibles sur le portail client .

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 utilisé NGINX Plus , nous vous encourageons à l'essayer – pour l'accélération Web, l'équilibrage de charge et la diffusion d'applications, 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 gratuitement dès aujourd'hui avec une évaluation gratuite de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.