Annonce de NGINX Plus R31

Prabhat Dixit

Nous sommes heureux d’annoncer la disponibilité de NGINX Plus Release 31 (R31). Basé sur NGINX Open Source, NGINX Plus est la seule solution logicielle tout-en-un faisant office de serveur web, d’équilibreur de charge, de proxy inverse, de cache de contenu et de passerelle API.

Les fonctionnalités nouvelles et améliorées de NGINX Plus R31 comprennent :

• Rapports natifs sur l’utilisation de NGINX – NGINX Plus prend désormais en charge nativement la création de rapports sur les déploiements NGINX dans l’ensemble de votre organisation, offrant ainsi une vue consolidée de votre infrastructure NGINX dans NGINX Instance Manager. Cette fonctionnalité permet une gouvernance renforcée des instances NGINX à des fins de conformité.
• Améliorations apportées à la configuration SNI – Auparavant, le nom de serveur transmis via l’indication du nom du serveur (SNI) était défini par la directive proxy_ssl_name et utilisé par tous les serveurs du groupe en amont. NGINX Plus R31 permet désormais de définir cette SNI pour un serveur en amont sélectionné.
• Exécution périodique de tâches avec NGINX JavaScript – NGINX JavaScript introduit la directive js_periodic, qui permet d’exécuter du contenu à intervalles réguliers. Cette amélioration évite d’avoir à configurer une tâche cron et peut être paramétrée pour s’exécuter sur tous les processus de travail ou uniquement sur certains d’entre eux afin d’optimiser les performances.
• Une meilleure expérience de démarrage de NGINX – NGINX Plus R31 améliore l’expérience globale de démarrage de NGINX lorsque la configuration comporte un grand nombre de « locations ».
• Optimisations et améliorations de QUIC+HTTP/3 – NGINX Plus R31 apporte de nombreuses améliorations et optimisations des performances à l’implémentation de QUIC, notamment la prise en charge de la découverte de l’unité de transmission maximale (MTU) du chemin, des améliorations du contrôle de congestion et la possibilité de réutiliser le contexte cryptographique pendant toute la session QUIC.

Cette version est complétée par de nouvelles fonctionnalités et des corrections de bogues héritées de NGINX Open Source, ainsi que par des mises à jour du module JavaScript NGINX.

Modifications importantes du comportement

Remarque : Si vous effectuez une mise à niveau depuis une version autre que NGINX Plus R30, veillez à consulter la section « Modifications importantes du comportement » dans les précédents billets d’annonce pour toutes les versions comprises entre votre version actuelle et celle-ci.

Abandon du module OpenTracing

Le module OpenTracing, introduit dans NGINX Plus R18, est désormais obsolète. Sa suppression est prévue à partir de la future version NGINX Plus R34. D’ici là, le paquet restera disponible avec toutes les versions de NGINX Plus. Il est vivement recommandé d’utiliser le module OpenTelemetry introduit dans NGINX Plus R29.

Message d’avertissement en cas de non-transmission des données d’utilisation de NGINX

Les utilisateurs de NGINX Plus sont tenus de communiquer à F5 leurs données d’utilisation de NGINX à des fins de conformité. Depuis la sortie de NGINX Plus R31, la fonctionnalité permettant de communiquer vos données d’utilisation de NGINX à NGINX Instance Manager est intégrée nativement et activée par défaut. Un message d’avertissement est consigné si l’instance NGINX n’est pas en mesure de transmettre ses données d’utilisation à NGINX Instance Manager, quelle qu’en soit la raison.

Consultez la section « Rapports natifs sur l’utilisation de NGINX » pour savoir comment configurer cette fonctionnalité dans votre environnement.

Modifications de la prise en charge des plateformes

Nouveaux systèmes d’exploitation pris en charge :

• FreeBSD 14
• Alpine 3.19

Anciens systèmes d’exploitation supprimés :

• Alpine 3.15, dont la fin de vie (EOL) a été atteinte le 1er novembre 2023

Anciens systèmes d’exploitation obsolètes et dont la suppression est prévue dans NGINX Plus R32 :

• FreeBSD 12, dont la fin de vie est prévue le 31 décembre 2023

Nouvelles fonctionnalités en détail

Rapports natifs sur l’utilisation de NGINX

NGINX Plus R31 introduit une communication native avec NGINX Instance Manager sur votre réseau afin d’automatiser la conformité des licences. Si vous participez au programme « F5 Flex Consumption Program », vous n’aurez plus besoin d’effectuer manuellement le suivi de vos instances NGINX Plus.

Par défaut, NGINX Plus tentera de détecter NGINX Instance Manager au démarrage en effectuant une recherche DNS du nom d’hôte nginx-mgmt.local. Bien que le nom d’hôte soit configurable, nous vous recommandons, par souci de simplicité, d’ajouter un enregistrement A à votre DNS local afin d’associer le nom d’hôte par défaut à l’adresse IP du système exécutant NGINX Instance Manager. NGINX Plus établira ensuite une connexion TLS à NGINX Instance Manager et lui transmettra toutes les trente minutes son numéro de version, son nom d’hôte et son identifiant unique.

Pour renforcer la sécurité, nous vous recommandons également de sécuriser cette connexion avec mTLS à l’aide du mgmt bloc de configuration facultatif. À intervalles réguliers, NGINX Instance Manager transmettra alors à un service F5 l’utilisation totale des instances NGINX Plus.

Un message d’avertissement s’affichera dans votre journal d’erreurs si NGINX Plus rencontre des problèmes lors de la résolution du nom d’hôte nginx-mgmt.local ou de la communication avec NGINX Instance Manager.

Voici un exemple de message d’erreur indiquant que l’instance NGINX Plus ne parvient pas à résoudre nginx-mgmt.local :

2023/12/21 21:02:01 [avertissement] 3050#3050 : rapport d’utilisation : hôte introuvable lors de la résolution du point de terminaison "nginx-mgmt.local”

Voici un exemple de message d’erreur indiquant que l’instance NGINX Plus rencontre des difficultés pour communiquer avec NGINX Instance Manager :

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

Personnalisation des paramètres du bloc de configuration mgmt Configuration Block Settings

Si vous préférez affiner la manière dont votre instance NGINX Plus communique avec NGINX Instance Manager, vous pouvez choisir d’utiliser le nouveau bloc de configuration « mgmt » et les directives associées. Vous pourrez ainsi définir un résolveur personnalisé, utiliser une adresse IP ou un autre nom d’hôte pour identifier votre système NGINX Instance Manager, spécifier des options TLS, utiliser le protocole mTLS pour renforcer la sécurité et définir d’autres paramètres personnalisés.

Voici un exemple de configuration personnalisée :

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP

    uuid_file /var/lib/nginx/nginx.id;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers DEFAULT;

    ssl_certificate          client.pem;
    ssl_certificate_key      client.key;

    ssl_trusted_certificate  trusted_ca_cert.crt;
    ssl_verify               on;
    ssl_verify_depth         2;
}

Pour plus de détails sur ces directives, veuillez consulter la documentation du produit.

Pour plus d’informations sur le téléchargement et l’installation de NGINX Instance Manager, consultez le guide d’installation.

Remarque : Si vous utilisez une version antérieure de NGINX Plus, vous pouvez toujours déclarer vos instances en suivant ces instructions.

Améliorations apportées à la configuration SNI

Avant cette version, NGINX Plus supposait que tous les serveurs d’un groupe en amont étaient identiques. Cela signifie qu’ils devaient être capables de répondre aux mêmes requêtes, de répondre au même nom SNI (lorsque proxy_ssl_server_name est utilisé) et de renvoyer des certificats SSL correspondant au même nom.

Cependant, dans certains cas, ce comportement ne suffit pas. Par exemple, lorsque plusieurs serveurs virtuels sont hébergés derrière un serveur en amont et doivent être différenciés par un SNI et/ou un en-tête Host distinct afin d’acheminer les requêtes vers des ressources spécifiques. Il est également possible que le même certificat ne puisse pas être utilisé sur tous les serveurs du groupe en amont, ou que certaines contraintes empêchent de répartir les serveurs en amont dans des groupes distincts.

NGINX Plus R31 permet désormais de configurer le SNI pour chaque serveur en amont. La variable « $upstream_last_server_name » désigne le nom du serveur en amont sélectionné, qui peut ensuite être transmis au serveur mandataire à l’aide des directives « proxy_ssl_server_name » et « proxy_ssl_name ».

Voici comment définir proxy_ssl_server_name sur on, afin de permettre la transmission d’un nom de serveur via SNI :
proxy_ssl_server_name on;

Et voici comment transmettre le nom du serveur en amont sélectionné à l’aide de proxy_ssl_name :
proxy_ssl_name $upstream_last_server_name;

Exécution périodique de tâches avec NGINX JavaScript

NGINX JavaScript v0.8.1 a introduit une nouvelle directive, « js_periodic », disponible dans les contextes http et stream. Cette directive permet de spécifier un gestionnaire de contenu JavaScript à exécuter à intervalles réguliers. Elle est utile lorsqu’un code personnalisé doit être exécuté périodiquement et peut nécessiter l’accès aux variables NGINX. Le gestionnaire de contenu reçoit un objet de session en argument et a également accès aux objets globaux.

Par défaut, le gestionnaire de contenu s’exécute sur le processus de travail 0, mais il peut être configuré pour s’exécuter sur certains processus de travail ou sur tous.

Cette directive est disponible dans le contexte location :

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 3
    js_periodic main.handler interval=900s worker_affinity=0101;

    resolver 10.0.0.1;
    js_fetch_trusted_certificate /path/to/certificate.pem;
}

example.js:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();

    ngx.log(ngx.INFO, body);
}

Pour plus de détails sur la syntaxe et la configuration, consultez la documentation JavaScript de NGINX.

Une meilleure expérience de démarrage de NGINX

Dans les cas où une configuration NGINX contient un grand nombre de « locations », le démarrage de NGINX peut prendre beaucoup de temps. Dans de nombreux cas, cela peut s’avérer inacceptable. Le problème vient principalement de l’algorithme de tri utilisé pour trier la liste des locations.

NGINX R31 introduit une amélioration qui remplace l’algorithme de tri existant, à savoir le tri par insertion, dont la complexité temporelle est de O(n2), par le tri fusion, dont la complexité temporelle est de O(n*log n).

Dans une configuration de test comportant 20 000 emplacements, il a été constaté que cette mise à jour avait réduit le temps de démarrage total de 8 secondes à 0,9 seconde.

Optimisations et améliorations de QUIC+HTTP/3

NGINX Plus R31 apporte plusieurs améliorations et optimisations des performances à l’implémentation de QUIC+HTTP/3, notamment :

• Découverte de l’unité de transmission maximale (MTU) du chemin lors de l’utilisation de QUIC+HTTP/3 – La MTU du chemin correspond à la taille maximale, mesurée en octets, d’une trame ou d’un paquet de données pouvant être transmis sur un réseau. Avant cette modification, l’implémentation de QUIC utilisait une MTU de chemin de 1 200 octets pour tous les datagrammes. NGINX Plus prend désormais en charge la découverte de la taille de la MTU du chemin, qui est ensuite utilisée pour tous les datagrammes sortants.
• Réutilisation du contexte cryptographique pendant toute la session QUIC – Cette optimisation concerne le chiffrement et le déchiffrement des paquets QUIC. Auparavant, un contexte cryptographique distinct était créé pour chaque opération de chiffrement ou de déchiffrement. Désormais, le même contexte est utilisé pendant toute la session QUIC, ce qui améliore les performances.

Parmi les autres optimisations des performances figurent la réduction des délais potentiels lors de l’envoi de paquets d’accusé de réception, le placement des trames d’accusé de réception (ACK) en tête de file d’attente afin de réduire les retransmissions de trames et les délais de livraison des trames ACK, ainsi que l’amélioration du comportement du contrôle de congestion en mode Generic Segmentation Offload (GSO).

Autres améliorations et corrections de bugs dans NGINX Plus R31

Module mgmt supplémentaire

Dans NGINX Plus R31, ngx_mgmt_module vous permet de transmettre des informations sur l’utilisation de NGINX à NGINX Instance Manager. Ces informations comprennent le nom d’hôte NGINX, la version de NGINX et un identifiant d’instance unique.

Le module fournit plusieurs directives permettant d’ajuster précisément la manière dont votre instance NGINX communique avec NGINX Instance Manager. Pour obtenir la liste complète des directives et des options de configuration disponibles, consultez la documentation NGINX.

Corrections de bugs dans le module MQTT

La prise en charge du protocole Message Queuing Telemetry Transport (MQTT) a été introduite dans NGINX Plus R29 et cette version contient quelques correctifs pour des problèmes observés dans le module MQTT.

Un correctif important résout un problème entraînant le rejet des messages CONNECT lorsqu’aucun mot de passe n’était fourni. Auparavant, nous supposions systématiquement que le champ du nom d’utilisateur serait suivi d’un mot de passe. Cependant, la spécification MQTT prévoit des cas particuliers, tels que l’authentification anonyme, dans lesquels la saisie d’un mot de passe n’est pas obligatoire. Le correctif vérifie de manière conditionnelle si un mot de passe est attendu ou non en examinant le champ cflags du paquet. Si l’indicateur n’est pas défini, cela signifie que le mot de passe n’est pas obligatoire.

Un autre correctif interrompt l’analyse des messages MQTT CONNECT lorsque la longueur du message est inférieure au nombre d’octets reçus.

HTTP/3 server_tokens : prise en charge des variables

NGINX Plus R31 prend désormais en charge les variables server_tokens manquantes pour les connexions HTTP/3. Le champ string permet de définir explicitement la signature affichée sur les pages d’erreur ainsi que la valeur du champ d’en-tête de réponse « Server ». Si le champ string est vide, l’émission du champ « Server » est désactivée.

Modifications héritées de NGINX Open Source

NGINX Plus R31 repose sur NGINX Open Source 1.25.3 et bénéficie des changements fonctionnels, des nouvelles fonctionnalités et des corrections de bogues apportés depuis la sortie de NGINX Plus R30 (dans NGINX 1.25.2 et 1.25.3).

Fonctionnalités

• Découverte de la MTU du chemin lors de l’utilisation de QUIC – Auparavant, une MTU par défaut de 1 200 octets était utilisée pour tous les datagrammes. Dans le cadre des améliorations apportées à QUIC+HTTP/3, nous avons ajouté la prise en charge de la découverte de la MTU du chemin, qui est ensuite utilisée pour tous les datagrammes sortants.
• Optimisations des performances de QUIC – La version 1.25.2 de la branche principale de NGINX a introduit des optimisations dans l’implémentation de QUIC afin de réutiliser le contexte cryptographique pendant toute la session QUIC. Cela réduit les délais d’envoi des paquets ACK et place les trames ACK en tête de la file d’attente afin de limiter les retransmissions de trames et les délais de livraison des trames ACK.
• Prise en charge de la suite de chiffrement TLS_AES_128_CCM_SHA256 lors de l’utilisation de HTTP/3 – Cette amélioration ajoute à QUIC la prise en charge de TLS_AES_128_CCM_SHA256, qui est actuellement la seule suite de chiffrement non prise en charge par l’implémentation QUIC de NGINX. Elle est désactivée par défaut dans OpenSSL et peut être activée à l’aide de cette directive : ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• Fourniture de l’appName nginx lors du chargement des configurations OpenSSL – Lors de l’utilisation de l’interface OPENSSL_init_ssl(), au lieu de vérifier OPENSSL_VERSION_NUMBER, NGINX vérifie désormais que OPENSSL_INIT_LOAD_CONFIG est défini et vrai. Cela garantit que l’interface n’est pas utilisée avec BoringSSL et LibreSSL, car ces bibliothèques ne fournissent pas de paramètres d’initialisation supplémentaires (notamment l’appel à OPENSSL_INIT_set_config_appname()).

Modifications

• Modification de l’algorithme de tri de la file d’attente NGINX – Comme indiqué ci-dessus, NGINX utilise désormais le tri fusion, dont la complexité temporelle est de O(n*log n). Cela permet un meilleur démarrage de NGINX, en particulier lorsque la configuration contient un très grand nombre d’« emplacements ».
• Limite de traitement des flux par itération HTTP/2 – Cette amélioration permet de détecter rapidement les attaques par saturation visant NGINX en limitant le nombre de nouveaux flux pouvant être introduits au cours d’une même itération de la boucle d’événements. Cette limite correspond au double de la valeur configurée à l’aide de http2_max_concurrent_streams. Elle s’applique même si le seuil maximal de flux simultanés autorisés n’est jamais atteint, afin de tenir compte des cas où les flux sont réinitialisés immédiatement après l’envoi des requêtes.

Corrections de bugs

• Correction de la gestion des tampons avec la détection automatique de HTTP/2 – Dans le cadre de la détection automatique de HTTP/2 sur les connexions TCP simples, les données initiales sont d’abord lues dans un tampon défini par la directive client_header_buffer_size, qui ne réserve pas d’espace pour l’état. Par conséquent, le tampon pouvait être lu au-delà de ses limites lors de l’enregistrement de l’état. Ce correctif limite la lecture à la taille de tampon disponible plutôt qu’à la taille de tampon fixe. Ce bug est apparu pour la première fois dans la version mainline 1.25.1 de NGINX (NGINX Plus R30).
• Mode de transport incorrect en mode de compatibilité OpenSSL – Avant cette version, la couche de compatibilité OpenSSL retardait la connexion lorsqu’un paramètre de transport incorrect était envoyé par le client. Ce correctif gère désormais ce comportement en informant d’abord l’utilisateur du paramètre incorrect, puis en fermant la connexion.
• Correction de la gestion des en-têtes Status sans phrase de motif – Un en-tête de statut comportant une « phrase de motif » vide, tel que Status: 404, était valide selon la spécification Common Gateway Interface (CGI), mais perdait l’espace final lors de l’analyse. Cela produisait une ligne de statut HTTP/1.1 404 dans la réponse, ce qui enfreint la spécification HTTP en raison de l’absence d’espace final. Grâce à ce correctif, seul le code de statut est utilisé pour ces lignes d’en-tête Status abrégées. NGINX génère ainsi lui-même la ligne de statut avec l’espace et, le cas échéant, la phrase de motif appropriée.
• Correction d’une fuite de mémoire lors du rechargement de la configuration avec PCRE2 – Ce problème se produisait lorsque NGINX était configuré pour utiliser PCRE2 dans la version 1.21.5 ou une version ultérieure.

Pour obtenir la liste complète des nouveautés, fonctionnalités, corrections de bogues et solutions de contournement héritées des versions récentes, consultez le fichier CHANGES de NGINX.

Modifications apportées au module JavaScript de NGINX

NGINX Plus R31 intègre les modifications apportées par la version 0.8.2 du module JavaScript NGINX (njs). Voici la liste des changements notables apportés à njs depuis la version 0.8.0 (qui faisait partie de la version R30 de NGINX Plus).

Fonctionnalités

• Introduction de l’objet console. Les méthodes suivantes ont été ajoutées : error(), info(), log(), time(), timeEnd() et warn().
• Introduction de la directive « js_periodic » pour les modules « http » et « stream », qui permet de spécifier un gestionnaire JS à exécuter à intervalles réguliers.
• Implémentation de la méthode items() d’un dictionnaire partagé. Cette méthode renvoie toutes les paires clé-valeur non expirées.

Modifications

• Extension du module « fs ». Ajout de la méthode existsSync().

Corrections de bugs

• Correction du module « xml ». Correction de la gestion défaillante des exceptions XML dans la méthode parse().
• Correction de « RegExp.prototype.exec() » avec une expression régulière globale (regexp) et une entrée Unicode.
• Correction des méthodes size() et keys() d’un dictionnaire partagé.
• Correction d’une exception erronée dans r.internalRedirect() introduite dans la version 0.8.0.
• Correction de l’ordre incorrect des clés dans « Object.getOwnPropertyNames() ».
• Correction de la gestion des réponses HEAD avec une valeur Content-Length élevée dans l’API fetch.
• Correction de la méthode items() pour un dictionnaire partagé.

Pour obtenir la liste complète des fonctionnalités, modifications et corrections de bugs, consultez le journal des modifications de njs.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R31 dès que possible. Outre toutes les nouvelles fonctionnalités remarquables, vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires. En restant à jour, vous permettrez à NGINX de mieux vous aider si vous devez ouvrir un ticket d’assistance.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le découvrir. Vous pouvez l’utiliser pour la sécurité, l’équilibrage de charge et les passerelles d’API, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Commencez dès aujourd’hui avec un essai gratuit de 30 jours.

À propos de l’auteur

Prabhat Dixit

Autres articles de Prabhat Dixit