Annonce de NGINX Plus R27

Nous sommes heureux d'annoncer la disponibilité de NGINX Plus Release 27 (R27) . Basé sur NGINX Open Source, NGINX Plus est le seul serveur Web logiciel tout-en-un , équilibreur de charge, proxy inverse, cache de contenu et passerelle API.

Les fonctionnalités nouvelles et améliorées de NGINX Plus R27 incluent :

• Connexions Keepalive pour les contrôles de santé – Dans les versions précédentes, NGINX Plus établissait une nouvelle connexion pour chaque contrôle de santé. Le nouveau paramètre keepalive_time de la directive HTTP health_check active les connexions keepalive pour les contrôles de santé et définit leur durée de vie. L'établissement de nouvelles connexions est coûteux en termes de calcul. La réutilisation des connexions peut donc réduire considérablement l'utilisation du processeur lorsqu'il existe un grand nombre de serveurs en amont.
• Prise en charge de Kernel TLS – NGINX Plus prend désormais en charge Kernel TLS (kTLS) sur trois systèmes d’exploitation qui répondent aux exigences de prise en charge : FreeBSD 13, RHEL 9.0+ et Ubuntu 22.04 LTS .
• Métriques TLS pour les serveurs en amont et virtuels – NGINX Plus génère désormais des statistiques TLS pour les serveurs en amont et virtuels individuels lorsque le proxy via HTTPS est activé, en plus des statistiques globales générées dans les versions précédentes. Disposer de mesures côté client et côté serveur est utile pour résoudre les problèmes liés aux négociations TLS.
• Personnalisation du code d'erreur des échecs de validation JWT – Dans NGINX Plus R25 et R26 , vous pouvez définir des contrôles de validation JWT personnalisés, mais le code d'erreur renvoyé pour un échec de validation est toujours 401(Non autorisé) . NGINX Plus R27 introduit le paramètre d'erreur dans la directive auth_jwt_require , vous permettant de définir le code sur401 ou 403(Interdit) pour chaque contrôle afin de mieux distinguer les erreurs d'authentification et d'autorisation.
• Améliorations apportées aux modules NGINX JavaScript et Prometheus-njs – Les améliorations apportées au module NGINX JavaScript incluent de nouvelles directives pour affiner le comportement de la fonction ngx.fetch et un nouvel objet qui signale la version njs sous forme de nombre hexadécimal. Le module Prometheus-njs peut désormais convertir des métriques NGINX Plus supplémentaires dans un format compatible Prometheus : le champ codes (qui indique le nombre de codes d'état HTTP individuels pour les serveurs en amont et virtuels) et les métriques générées par les modules Limit Connections et Limit Requests.

La version est complétée par un nouveau numéro de version (8) pour l' API NGINX Plus et une distribution plus uniforme des connexions lorsque le mode EPOLLEXCLUSIVE est utilisé dans les noyaux Linux.

Changements importants dans le comportement

Note: Si vous effectuez une mise à niveau à partir d'une version autre que NGINX Plus R26 , assurez-vous de consulter la section Modifications importantes du comportement dans les blogs d'annonces pour toutes les versions entre votre version actuelle et celle-ci.

Nouveaux systèmes d’exploitation pris en charge :

• Alpine Linux 3.16
• RHEL 9.0+ (ajouté à NGINX Plus R26 après la sortie initiale)
• Ubuntu 22.04 LTS (ajouté à NGINX Plus R26 après la sortie initiale)

Systèmes d'exploitation et architectures plus anciens supprimés :

• Alpine 3.12, qui a atteint la fin de vie (EOL) le 1er mai 2022
• CentOS 8.1+, qui a atteint sa fin de vie le 31 décembre 2021 (RHEL 8.1+ est toujours pris en charge car sa date de fin de vie est différente)
• Architecture Power 8 (ppc64le ; affecte CentOS et RHEL)

Systèmes d'exploitation et architectures plus anciens obsolètes et dont la suppression est prévue dans NGINX Plus R28 :

• Debian 10, qui atteindra sa fin de vie en août 2022

Nouvelles fonctionnalités en détail

Connexions Keepalive pour les contrôles de santé

Les connexions Keepalive entre NGINX Plus et les serveurs en amont améliorent considérablement les performances pour les cas d'utilisation de proxy inverse et d'équilibrage de charge. Pour le proxy sur HTTPS en particulier, les dépenses de calcul de la négociation TLS complète requise pour chaque nouvelle connexion peuvent mettre à rude épreuve vos ressources informatiques, en particulier dans les environnements de production avec un grand nombre de serveurs en amont.

Dans les versions précédentes, NGINX Plus n'utilisait pas de connexions keepalive pour les contrôles de santé, établissant plutôt une nouvelle connexion pour chaque sonde de santé. NGINX Plus R27 introduit les connexions keepalive pour les contrôles de santé HTTP. Le nouveau paramètre keepalive_time de la directive health_check définit la durée de vie de chaque connexion keepalive, après laquelle une nouvelle connexion est établie. Nos tests indiquent que pour le proxy sur HTTPS, les connexions keepalive réduisent l'utilisation du processeur pour les contrôles de santé d'un facteur de 10 à 20 sur les serveurs NGINX Plus. Ils économisent également les ressources CPU sur les serveurs en amont.

L'exemple suivant permet des connexions keepalive avec une durée de vie de 60 secondes. Compte tenu de la fréquence de vérification de l’état d’une seconde définie par le paramètre d’intervalle , NGINX Plus supporte les frais de négociation TLS et d’établissement de connexion une seule fois pour 60 vérifications de l’état.

Prise en charge du noyau TLS

Transport Layer Security (TLS) est le protocole standard de facto pour le cryptage des données sur Internet. Malheureusement, la protection des données ajoute également de la latence. L’implémentation de TLS dans le noyau (kTLS) améliore les performances lors de la diffusion de contenu statique en réduisant considérablement le besoin d’opérations de copie entre l’espace utilisateur et le noyau.

La combinaison de kTLS et de l'appel système sendfile() signifie que les données sont chiffrées directement dans l'espace noyau avant d'être transmises à la pile réseau pour transmission, au lieu d'être copiées dans l'espace utilisateur pour chiffrement à l'aide des bibliothèques TLS, puis recopiées dans l'espace noyau avant transmission. kTLS permet également de décharger le traitement TLS vers le matériel, y compris le déchargement du traitement de cryptographie symétrique TLS vers les périphériques réseau.

La prise en charge de kTLS nécessite trois conditions :

1. Le noyau du système d'exploitation le prend en charge
2. La distribution du système d'exploitation inclut la bibliothèque cryptographique OpenSSL 3.0+ compilée avec le support kTLS
3. NGINX Plus (ou NGINX Open Source) est construit avec la bibliothèque cryptographique OpenSSL 3.0+

En octobre 2021, nous avons ajouté la prise en charge de kTLS à NGINX Open Source 1.21.4 sur les plateformes répondant aux exigences 1 et 2. Nous ajoutons désormais la prise en charge de kTLS dans NGINX Plus sur ces plateformes :

• FreeBSD 13 (dans NGINX Plus R26 et versions ultérieures)
• RHEL 9.0+
• Ubuntu 22.04 LTS

Mesures TLS pour les serveurs en amont et virtuels

Lorsque NGINX Plus est déployé en tant que proxy inverse ou équilibreur de charge, l' API NGINX Plus fournit un riche ensemble de mesures sur le trafic, les codes de réponse et la latence pour chaque serveur en amont et virtuel, permettant aux clients d'observer et de surveiller les performances et la disponibilité du serveur.

Dans les versions précédentes, NGINX Plus générait des mesures sur l'activité et les erreurs TLS à l'échelle du système lorsque des connexions HTTPS étaient utilisées entre NGINX Plus et les serveurs en amont, dans les contextes http et stream (établis respectivement avec les directives proxy_pass https: //path-to-upstream et proxy_ssl on ). Les statistiques couvrent les poignées de main, les échecs et les réutilisations de session (comme configuré avec la directive proxy_ssl_session_reuse ).

NGINX Plus R27 génère ces métriques TLS pour les serveurs en amont individuels dont la configuration inclut la directive zone et pour les serveurs virtuels dont la configuration inclut la directive status_zone . Disposer de mesures côté client et côté serveur est utile pour résoudre les problèmes liés aux négociations TLS.

L'exemple suivant permet la collecte de statistiques sur le serveur en amont upstream1 et le serveur virtuel qui lui transmet le trafic par proxy.

Cette sortie indique que le premier serveur en amont a participé à quatre négociations TLS et à deux sessions réutilisées (par souci de concision, nous affichons une sortie partielle pour le premier serveur et omettons la sortie pour les autres serveurs en amont) :

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "pairs": [ { "id": 0, "serveur" : "127.0.0.1:8081", "nom": "127.0.0.1:8081", "sauvegarde" : faux, "poids" : 1, « état » : « en haut », « actif » : 0, "ssl": { "poignées de main": 4, « handshakes_failed » : 0, « session_reuses » : 2 } , "requêtes": 4, « header_time » : 4, « temps_de_réponse » : 4, ... } ... ] }

Cette sortie indique que NGINX Plus a participé à sept négociations TLS :

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "traitement": 0, « requêtes » : 7, "réponses": { "1xx": 0, « 2xx » : 7, « 3xx » : 0, « 4xx » : 0, « 5xx » : 0, "codes": { "200": 7 }, "totale": 7 }, "rejeté": 0, "reçu" : 546, « envoyé » : 1134, "ssl": { "poignées de main": 7, « handshakes_failed » : 0, « session_reuses » : 0 } ... }

Notez que l' API NGINX Plus collecte toujours les mesures TLS globales disponibles dans les versions précédentes de NGINX Plus :

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "poignées de main": 21, « handshakes_failed » : 0, « session_reuses » : 6 }

Personnalisation du code d'erreur pour les échecs de validation JWT

NGINX Plus R25 a introduit<.htmla> la directive auth_jwt_require pour définir des contrôles personnalisés pendant le processus de validation JWT. Dans NGINX Plus R25 et R26 , le code d'erreur renvoyé pour un échec de validation est toujours 401(Non autorisé) .

NGINX Plus R27 introduit le paramètre d'erreur dans la directive auth_jwt_require , que vous pouvez utiliser pour définir le code sur401 ou403 (Interdit) pour chaque directive indépendamment. Lorsqu'une demande d'accès d'un utilisateur échoue, le choix des codes vous permet de faire la distinction entre un échec d'authentification (le JWT n'est pas valide) et un échec d'autorisation (la revendication requise est manquante). Vous pouvez également créer des gestionnaires personnalisés pour les codes d'erreur, par exemple pour renvoyer une page spéciale expliquant l'erreur (avec la directive error_page ) ou pour rediriger la demande vers un emplacement interne nommé pour un traitement ultérieur.

Le code d'état par défaut reste401 en cas d'échec des types de contrôles JWT suivants :

• Les contrôles (non personnalisés) qui sont toujours effectués
• Vérifications personnalisées configurées avec auth_jwt_require mais pas le paramètre d'erreur

S'il existe plusieurs directives auth_jwt_require dans un bloc d'emplacement , elles sont évaluées dans l'ordre dans lequel elles apparaissent. Le traitement s’arrête au premier échec et le code d’erreur spécifié est renvoyé.

Dans cet exemple, la directive auth_jwt_require renvoie403 si $req1 ou $req2 est évalué à une valeur vide ou0 (zéro).

Améliorations apportées aux modules NGINX JavaScript et Prometheus-njs

NGINX Plus R27 intègre des versions0.7.3 et0.7.4 du module JavaScript NGINX et inclut les améliorations suivantes.

Directives supplémentaires pour l'API Fetch njs

NGINX Javascript 0.5.3, intégré à NGINX Plus R24 , a introduit la fonction ngx.fetch (également appelée API Fetch) pour instancier un client HTTP simple dans le contexte d'une connexion TCP/UDP. (Pour une discussion sur les cas d'utilisation de la fonction, voir Tirer parti des services HTTP pour TCP.htmlUDP avec un client HTTP simple sur notre blog.)

NGINX Plus R27 introduit les directives suivantes pour affiner le comportement de l'API Fetch :

• js_fetch_buffer_size [ HTTP ][ Stream ] – Définit la taille du tampon utilisé pour la lecture et l’écriture.
• js_fetch_max_response_buffer_size [ HTTP ][ Stream ] – Définit la taille maximale de la réponse reçue avec l'API Fetch.
• js_fetch_timeout [ HTTP ][ Stream ] – Définit le délai d’expiration pour la lecture et l’écriture entre deux opérations de lecture ou d’écriture successives (pas pour la réponse entière). Si aucune donnée n'est transmise dans le délai imparti, la connexion est fermée.
• js_fetch_verify [ HTTP ][ Stream ] – Active ou désactive la vérification du certificat du serveur HTTPS.

Numéro de version indiqué sous forme de nombre hexadécimal

Le nouvel objet njs.version_number signale la version du module njs sous forme de nombre hexadécimal. (L'objet njs.version existant renvoie la version sous forme de chaîne de caractères.)

Le module Prometheus-njs convertit des métriques supplémentaires

Le module Prometheus-njs , qui convertit les métriques NGINX Plus dans un format compatible Prometheus, peut désormais convertir les métriques exposées à ces points de terminaison supplémentaires :

• /http/limit_conns
• /http/limit_reqs
• Le champ codes (qui indique le nombre de codes d'état HTTP individuels<.htmla>) sous /http/server_zones et /http/upstreams
• /stream/limit_conns

Autres améliorations dans NGINX Plus R27

Modification de la version de l'API NGINX Plus

Le numéro de version de l' API NGINX Plus est mis à jour de 7 à 8 pour refléter l'ajout du champ SSL aux mesures signalées pour les serveurs en amont et virtuels, comme décrit dans Mesures TLS pour les serveurs en amont et virtuels . Les numéros de version précédents fonctionnent toujours, mais la sortie n'inclut pas les métriques ajoutées dans les versions ultérieures de l'API.

Meilleure répartition des connexions en mode Linux EPOLLEXCLUSIVE

NGINX Plus R27 répartit les connexions de manière plus uniforme entre les processus de travail NGINX lorsque le mode EPOLLEXCLUSIVE est utilisé dans les noyaux Linux. Normalement, dans ce mode, le noyau notifie uniquement le processus qui a été le premier à ajouter le socket d'écoute à l'instance EPOLL. Par conséquent, la plupart des connexions sont gérées par le premier processus de travail. NGINX rajoute désormais périodiquement le socket pour donner aux autres processus de travail une chance d’accepter les connexions.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R27 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela aidera NGINX à vous aider lorsque vous aurez besoin de créer un ticket d'assistance.

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 .