Annonce de NGINX Plus R18

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer la disponibilité de NGINX Plus Release 18 (R18). NGINX Plus est la seule solution tout-en-un faisant office d’équilibreur de charge, de cache de contenu, de serveur web et de passerelle API. Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités avancées exclusives et une assistance primée. R18 simplifie les processus de configuration pour les équipes DevOps et améliore la sécurité et la fiabilité de vos applications à grande échelle.

Plus de 87 % des sites web utilisent désormais SSL/TLS pour chiffrer les communications sur Internet, contre 66 % il y a seulement trois ans. Le chiffrement de bout en bout est désormais le modèle de déploiement par défaut pour les sites web et les applications, et la multiplication des certificats SSL/TLS oblige certaines entreprises à gérer plusieurs milliers de certificats dans leurs environnements de production. Cette situation nécessite une approche plus souple du déploiement et de la configuration des certificats.

Cette version prend désormais en charge le chargement dynamique des certificats. Avec des milliers de certificats, il n’est pas viable de définir manuellement chacun d’eux dans la configuration afin de les charger depuis le disque : non seulement ce processus est fastidieux, mais la configuration devient excessivement volumineuse et le démarrage de NGINX Plus, beaucoup trop lent. Avec NGINX Plus R18, les certificats SSL/TLS peuvent désormais être chargés à la demande sans être répertoriés individuellement dans la configuration. Pour simplifier encore davantage les déploiements automatisés, les certificats peuvent être provisionnés à l’aide de l’API NGINX Plus, sans même avoir à être stockés sur disque.

Parmi les autres nouveautés de NGINX Plus R18 figurent :

• Améliorations d’OpenID Connect – Nous continuons d’améliorer notre implémentation de référence prise en charge pour OpenID Connect, initialement publiée dans NGINX Plus R15. Dans cette version, nous avons ajouté la prise en charge des jetons de session opaques, des jetons d’actualisation et d’une URL de déconnexion.
• Plages de ports pour les serveurs virtuels – Les serveurs virtuels NGINX Plus peuvent désormais être configurés pour écouter sur une plage de ports, par exemple 80‑90. Cela permet à NGINX Plus de prendre en charge un plus large éventail d’applications, telles que le FTP passif, qui nécessitent la réservation de plages de ports.
• Définition de paires clé-valeur dans la configuration – Le magasin clé-valeur de NGINX Plus permet de mettre en œuvre des solutions pour un large éventail de cas d’utilisation, notamment la mise sur liste de blocage dynamique d’adresses IP et l’atténuation dynamique des attaques DDoS. Vous pouvez désormais créer des paires clé-valeur directement à l’aide de variables dans la configuration de NGINX Plus, ouvrant ainsi la voie à encore plus de cas d’utilisation.
• Une plus grande flexibilité pour les contrôles d’intégrité actifs – Les contrôles d’intégrité actifs de NGINX Plus constituent un outil puissant pour surveiller l’état des systèmes backend. Avec NGINX Plus R18, vous pouvez désormais tester la valeur de n’importe quelle variable NGINX et fermer automatiquement les connexions TCP existantes vers les serveurs défaillants.

Pour compléter cette version figurent une configuration simplifiée pour les environnements en cluster, ainsi que des modules dynamiques nouveaux et mis à jour (notamment Brotli). Les mises à jour de l’écosystème NGINX Plus comprennent une organisation modulaire du code avec le module JavaScript de NGINX et l’installation directe via Helm du contrôleur Ingress NGINX officiel pour Kubernetes.

Modifications importantes du comportement

• API obsolètes – NGINX Plus R13 (août 2017) a introduit la toute nouvelle API NGINX Plus pour la collecte de métriques et la reconfiguration dynamique des groupes de serveurs en amont, remplaçant les API Status et Upstream Conf qui assuraient auparavant ces fonctions. Comme annoncé à l’époque, les API obsolètes sont restées disponibles et prises en charge pendant une période prolongée, qui a pris fin avec NGINX Plus R16. Si votre configuration comprend les directives status et/ou upstream_conf, vous devez les remplacer par la directive api dans le cadre de la mise à niveau vers R18. Pour obtenir des conseils et de l’aide concernant la migration vers la nouvelle API NGINX Plus, consultez le guide de transition sur notre blog ou contactez notre équipe d’assistance.
• Mise à jour de la directive listen directive – Auparavant, lorsque la directive listen spécifiait un nom d’hôte correspondant à plusieurs adresses IP, seule la première adresse IP était utilisée. Désormais, un socket d’écoute est créé pour chaque adresse IP renvoyée.
• Modifications apportées au module JavaScript NGINX (njs) – L’objet obsolète req.response a été supprimé du module JavaScript NGINX. Les fonctions déclarées à l’aide de la syntaxe function(req,res) qui font également référence aux propriétés de l’objet res génèrent des erreurs d’exécution, renvoient le code d’état HTTP 500 et ajoutent une entrée correspondante dans le journal des erreurs :

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of undefined

• Comme le code JavaScript est interprété au moment de l’exécution, la commande de validation syntaxique nginx -t ne détecte pas la présence d’objets et de propriétés non valides. Vous devez vérifier soigneusement votre code JavaScript et supprimer ces objets avant de procéder à la mise à niveau vers NGINX Plus R18. En outre, les objets JavaScript qui représentent l’état de NGINX (par exemple, r.headersIn) renvoient désormais undefined au lieu d’une chaîne vide lorsqu’aucune valeur n’est définie pour une propriété donnée. Grâce à cette modification, les objets JavaScript propres à NGINX se comportent désormais comme les objets JavaScript intégrés.
• Anciens systèmes d’exploitation supprimés ou qui seront supprimés :
  • Amazon Linux 2017.09 n’est plus pris en charge ; la version la plus ancienne encore prise en charge est désormais la 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 n’est plus pris en charge ; la version la plus ancienne désormais prise en charge est la 7.4
  • Debian 8.0 sera supprimé dans NGINX Plus R19
  • Ubuntu 14.04 ne sera plus pris en charge dans NGINX Plus R19

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

Chargement dynamique des certificats SSL/TLS

Dans les versions précédentes de NGINX Plus, l’approche habituelle pour gérer les certificats SSL/TLS des sites et applications sécurisés consistait à créer un bloc server distinct pour chaque nom d’hôte, en spécifiant de manière statique le certificat et la clé privée associée sous forme de fichiers sur disque. (Pour faciliter la lecture, nous utiliserons désormais le terme certificat pour désigner l’ensemble formé par le certificat et la clé.) Les certificats étaient ensuite chargés au démarrage de NGINX Plus. Avec NGINX Plus R18, les certificats peuvent être chargés dynamiquement et, éventuellement, stockés dans le magasin clé-valeur en mémoire de NGINX Plus plutôt que sur disque.

Le chargement dynamique des certificats répond à deux cas d’usage principaux :

• « Chargement différé » des certificats depuis le disque
• Stockage des certificats en mémoire

Dans les deux cas, NGINX Plus peut charger dynamiquement les certificats en fonction du nom d’hôte fourni par l’indication du nom du serveur (SNI) lors de la négociation TLS. NGINX Plus peut ainsi héberger plusieurs sites web sécurisés avec une seule configuration de serveur et sélectionner à la demande le certificat approprié pour chaque requête entrante.

Chargement différé des certificats SSL/TLS depuis le disque

Avec le « chargement différé », les certificats SSL/TLS ne sont chargés en mémoire qu’à l’arrivée des requêtes indiquant le nom d’hôte correspondant. Cela simplifie la configuration (en supprimant la liste des certificats propres à chaque nom d’hôte) et réduit l’utilisation des ressources de l’hôte. Lorsqu’il existe un grand nombre de certificats (plusieurs milliers), leur lecture depuis le disque et leur chargement en mémoire peuvent prendre plusieurs secondes. En outre, le rechargement de la configuration NGINX mobilise une quantité importante de mémoire, car le nouvel ensemble de processus de travail charge en mémoire une nouvelle copie des certificats, en plus de ceux déjà chargés par l’ensemble précédent. Les certificats précédents restent en mémoire jusqu’à ce que la dernière connexion établie sous l’ancienne configuration soit terminée et que les processus de travail précédents soient arrêtés. Si la configuration est fréquemment mise à jour et que les connexions clientes sont de longue durée, plusieurs copies des certificats peuvent se trouver simultanément en mémoire, ce qui risque d’entraîner un épuisement de la mémoire.

Le chargement différé des certificats depuis le disque est idéal pour les déploiements comportant un grand nombre de certificats et/ou lorsque les rechargements de configuration sont fréquents. Par exemple, les entreprises SaaS attribuent généralement un sous-domaine distinct à chaque client. L’intégration de nouveaux clients est complexe, car vous devez créer un nouveau serveur virtuel pour chacun d’eux, puis copier la nouvelle configuration et le certificat du client sur chaque instance NGINX Plus. Le chargement différé évite d’avoir à modifier la configuration : il suffit de déployer les certificats sur chaque instance, et le tour est joué.

Pour prendre en charge le chargement différé, les directives ssl_certificate et ssl_certificate_key acceptent désormais des paramètres variables. La variable doit être disponible lors du traitement SNI, qui intervient avant la lecture de la ligne de requête et des en-têtes. La variable la plus couramment utilisée est $ssl_server_name, qui contient le nom d’hôte extrait par NGINX Plus lors du traitement SNI. Le certificat et la clé sont lus sur le disque pendant la négociation TLS au début de chaque session client, puis mis en cache dans la mémoire via le cache du système de fichiers, ce qui réduit encore davantage l’utilisation de la mémoire.

La configuration d’un site sécurisé devient aussi simple que ceci :

Chargement de l’exemple de code…

Cette même configuration server peut être utilisée pour un nombre illimité de sites sécurisés. Cela présente deux avantages :

1. Cela évite d’avoir un bloc server distinct pour chaque nom d’hôte, ce qui allège considérablement la configuration et facilite ainsi sa lecture et sa gestion.
2. Cela évite d’avoir à recharger la configuration chaque fois que vous ajoutez un nouveau nom d’hôte. Lorsqu’un rechargement de la configuration est nécessaire, il est beaucoup plus rapide, car NGINX Plus ne charge pas tous les certificats.

Notez que le chargement différé allonge de 20 à 30 % la durée de la négociation TLS, selon l’environnement, en raison des appels au système de fichiers nécessaires pour récupérer le certificat sur le disque. Toutefois, cette latence supplémentaire n’affecte que la négociation : une fois la session TLS établie, le traitement des requêtes prend le temps habituel.

Stockage en mémoire des certificats SSL/TLS

Vous pouvez désormais stocker les données des certificats SSL/TLS en mémoire, dans le magasin clé-valeur de NGINX Plus, ainsi que dans des fichiers sur disque. Lorsque le paramètre de la directive ssl_certificate ou ssl_certificate_key commence par le préfixe data:, NGINX Plus interprète le paramètre comme des données PEM brutes (fournies sous la forme d’une variable qui identifie l’entrée du magasin clé-valeur où résident réellement les données).

Le stockage dans le magasin clé-valeur plutôt que sur disque présente un autre avantage : les images de déploiement et les sauvegardes ne contiennent plus de copies de la clé privée, qu’un attaquant pourrait utiliser pour déchiffrer l’ensemble du trafic envoyé au serveur et provenant de celui-ci. Les entreprises disposant de pipelines de déploiement hautement automatisés bénéficient de la souplesse offerte par l’API NGINX Plus, qui leur permet d’insérer des certificats dans le magasin clé-valeur par programmation. En outre, les entreprises qui migrent des applications vers un environnement de cloud public dépourvu de véritable module matériel de sécurité (HSM) pour protéger les clés privées bénéficient de la sécurité accrue qu’offre l’absence de stockage des clés privées sur disque.

Voici un exemple de configuration permettant de charger des certificats depuis le magasin clé-valeur :

Chargement de l’exemple de code…

Une façon de téléverser des certificats et des clés privées dans le magasin clé-valeur à l’aide de l’API NGINX Plus consiste à exécuter la commande curl suivante (seul le tout début des données de la clé est affiché). Si vous utilisez la commande curl, pensez à faire une copie des données PEM et à remplacer chaque saut de ligne par \n ; sinon, les sauts de ligne sont supprimés de la charge utile JSON.

$ curl -d '{"www.example.com":"-----BEGIN RSA PRIVATE KEY-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

L’utilisation du magasin clé-valeur pour les certificats est idéale pour les déploiements en cluster de NGINX Plus, car il suffit de téléverser le certificat une seule fois pour qu’il soit automatiquement propagé dans l’ensemble du cluster. Pour protéger les données du certificat, utilisez la directive zone_sync_ssl afin de chiffrer via TLS les connexions entre les membres du cluster. Le magasin clé-valeur est également idéal pour les certificats à courte durée de vie ou pour automatiser les intégrations avec des autorités de certification telles que Let’s Encrypt et Hashicorp Vault.

Comme pour le chargement différé depuis le disque, le chargement des certificats depuis le magasin clé-valeur s’effectue à chaque négociation TLS, ce qui entraîne une baisse des performances. Pour accélérer au maximum les négociations TLS, utilisez les directives « ssl_certificate » et « ssl_certificate_key » avec un paramètre codé en dur pointant vers un fichier sur le disque. En outre, les certificats ECC sont plus rapides que les certificats RSA.

Notez que, même si le magasin clé-valeur rend l’obtention des fichiers de clés privées plus difficile pour un attaquant que lorsqu’ils sont stockés sur disque, un attaquant disposant d’un accès shell à l’hôte NGINX Plus pourrait tout de même accéder aux clés chargées en mémoire. Le magasin clé-valeur ne protège pas les clés privées aussi efficacement qu’un module de sécurité matériel (HSM). Pour que NGINX Plus récupère les clés depuis un HSM, utilisez le paramètre engine:engine-name:key-id de la directive ssl_certificate_key.

Améliorations d’OpenID Connect

NGINX Plus prend en charge l’authentification OpenID Connect et l’authentification unique pour les applications backend grâce à notre implémentation de référence. Cette solution a été simplifiée et améliorée, car le magasin clé-valeur peut désormais être modifié directement depuis le module JavaScript à l’aide de variables (voir ci-dessous).

L’implémentation de référence d’OpenID Connect fournit désormais aux clients des jetons de session opaques sous la forme d’un cookie de navigateur. Les jetons opaques ne contiennent aucune information permettant d’identifier personnellement l’utilisateur. Ainsi, aucune information sensible n’est stockée sur le client. NGINX Plus stocke le véritable jeton d’ID dans le magasin clé-valeur et le substitue au jeton opaque présenté par le client. Une validation JWT est effectuée pour chaque requête afin de rejeter les jetons expirés ou non valides.

L’implémentation de référence d’OpenID Connect prend désormais également en charge les jetons d’actualisation, ce qui permet de renouveler automatiquement les jetons d’ID expirés sans intervention de l’utilisateur. NGINX Plus stocke dans le magasin clé-valeur le jeton d’actualisation envoyé par un serveur d’autorisation et l’associe au jeton de session opaque. Lorsque le jeton d’ID expire, NGINX Plus renvoie le jeton d’actualisation au serveur d’autorisation. Si la session est toujours valide, le serveur d’autorisation émet un nouveau jeton d’ID, qui est automatiquement mis à jour dans le magasin clé-valeur. Les jetons d’actualisation permettent d’utiliser des jetons d’ID à courte durée de vie, ce qui renforce la sécurité sans gêner les utilisateurs.

L’implémentation de référence d’OpenID Connect fournit désormais une URL de déconnexion. Lorsque les utilisateurs connectés accèdent à l’URI /logout, leurs jetons d’ID et d’actualisation sont supprimés du magasin clé-valeur, et ils doivent s’authentifier à nouveau lors d’une requête ultérieure.

Plages de ports pour les serveurs virtuels

Un bloc server comporte généralement une seule directive listen qui spécifie le port unique sur lequel NGINX Plus écoute. Si plusieurs ports doivent être configurés, une directive listen supplémentaire est nécessaire pour chacun d’eux. Avec NGINX Plus R18, vous pouvez désormais également spécifier des plages de ports, par exemple 80‑90, lorsqu’il est peu pratique de définir un grand nombre de directives listen individuelles.

Des plages de ports peuvent être spécifiées aussi bien pour la directive HTTP listen que pour la directive TCP/UDP (Stream) listen. La configuration suivante permet à NGINX Plus de servir de proxy pour un serveur FTP en mode passif, où le port de données est choisi parmi une large plage de ports TCP.

Chargement de l’exemple de code…

Cette configuration met en place un serveur virtuel qui transmet les connexions au serveur FTP sur le même port que celui par lequel elles sont arrivées.

Mise à jour du magasin clé-valeur à l’aide de variables

Lorsque le magasin clé-valeur est activé, NGINX Plus fournit une variable permettant d’accéder aux valeurs qui y sont stockées à partir d’une clé d’entrée (généralement une partie des métadonnées de la requête). Auparavant, le seul moyen de créer, de modifier ou de supprimer des valeurs dans le magasin clé-valeur consistait à utiliser l’API NGINX Plus. Avec NGINX Plus R18, vous pouvez modifier la valeur d’une clé directement dans la configuration en définissant la variable qui contient cette valeur.

L’exemple suivant utilise le magasin clé-valeur pour conserver une liste des adresses IP des clients ayant récemment accédé au site, ainsi que le dernier URI qu’ils ont demandé.

Chargement de l’exemple de code…

La directive « set » (ligne 7) attribue une valeur ($last_uri) à chaque adresse IP cliente ($remote_addr), en créant une entrée si elle n’existe pas ou en modifiant sa valeur pour refléter l’URI $uri de la requête actuelle. La liste à jour des clients récents et des URI qu’ils ont demandés est ainsi accessible au moyen d’un appel à l’API NGINX Plus :

$ curl http://localhost:8080/api/4/http/keyvals/recents{
  "10.19.245.68": "/blog/nginx-plus-r18-released/",
  "172.16.80.227": "/products/nginx/",
  "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available"
}

Des cas d’usage plus avancés peuvent être mis en œuvre grâce à des extensions de script telles que le module JavaScript NGINX (njs) et le module Lua. Toute configuration utilisant njs a accès à toutes les variables, y compris celles adossées au magasin clé-valeur, par exemple r.variables.last_uri.

Une plus grande flexibilité pour les contrôles d’intégrité actifs

Les contrôles d’intégrité actifs de NGINX Plus testent régulièrement les systèmes back-end afin que le trafic ne soit pas dirigé vers ceux dont on sait qu’ils sont défaillants. NGINX Plus R18 enrichit cette fonctionnalité importante de deux capacités supplémentaires.

• Prise en charge du test de variables arbitraires dans les contrôles d’intégrité
• Possibilité de mettre fin aux sessions TCP en cas d’échec du contrôle d’intégrité

Test de variables arbitraires dans les contrôles d’intégrité

Lorsque vous définissez un contrôle d’intégrité pour une application backend, vous pouvez utiliser un bloc match pour spécifier la valeur attendue de plusieurs éléments de la réponse, notamment le code d’état HTTP et les chaînes de caractères figurant dans les en-têtes et/ou le corps de la réponse. Lorsque la réponse contient toutes les valeurs attendues, le backend est considéré comme opérationnel.

Pour des vérifications encore plus complexes, NGINX Plus R18 propose désormais la directive require pour tester la valeur de n’importe quelle variable – qu’il s’agisse de variables NGINX standard ou de variables que vous déclarez. Vous bénéficiez ainsi d’une plus grande souplesse pour définir les contrôles d’intégrité, car les variables peuvent être évaluées à l’aide de blocs map, d’expressions régulières et même d’extensions de script.

La directive require au sein d’un bloc match spécifie une ou plusieurs variables, qui doivent toutes avoir une valeur non nulle pour que le test réussisse. L’exemple de configuration suivant considère comme sain un serveur en amont qui renvoie des en-têtes indiquant que la réponse peut être mise en cache : soit un en-tête Expires avec une valeur non nulle, soit un en-tête Cache-Control.

Chargement de l’exemple de code…

L’utilisation de blocs map de cette manière est une méthode courante pour intégrer une logique OU à la configuration de NGINX Plus. La directive require permet d’exploiter cette technique dans les contrôles d’intégrité, ainsi que d’effectuer des contrôles d’intégrité avancés. Ces derniers peuvent également être définis à l’aide du module JavaScript (njs), afin d’analyser des attributs supplémentaires des réponses de chaque serveur en amont, tels que le temps de réponse.

Interruption des connexions de couche 4 en cas d’échec des contrôles d’intégrité

Lorsque NGINX Plus fait office d’équilibreur de charge de couche 4 (L4) pour les applications TCP/UDP, il transmet les données dans les deux sens sur la connexion établie entre le client et le serveur backend. Les contrôles d’intégrité actifs constituent un élément important d’une telle configuration, mais, par défaut, l’état d’intégrité d’un serveur backend n’est pris en compte que lorsqu’un nouveau client tente d’établir une connexion. Si un serveur backend devient indisponible, les clients déjà connectés peuvent être confrontés à un délai d’expiration lorsqu’ils lui envoient des données.

Avec la directive proxy_session_drop introduite dans NGINX Plus R18, vous pouvez fermer immédiatement la connexion dès que le paquet suivant est reçu du serveur hors ligne ou lui est envoyé. Le client est alors contraint de se reconnecter, et NGINX Plus transmet ses requêtes à un serveur backend opérationnel.

Lorsque cette directive est activée, deux autres conditions entraînent également la fermeture des connexions existantes : l’échec d’un contrôle d’intégrité actif et le retrait du serveur d’un groupe en amont, quelle qu’en soit la raison. Cela inclut le retrait à la suite d’une résolution DNS, lorsqu’un serveur backend est défini par un nom d’hôte associé à plusieurs adresses IP, telles que celles fournies par un registre de services.

Autres améliorations de NGINX Plus R18

Configuration simplifiée du clustering

NGINX Plus prend en charge la synchronisation de l’état d’exécution à l’échelle du cluster depuis NGINX Plus R15. Le module Synchronisation de zones permet actuellement de partager les données d’état relatives aux sessions persistantes, à la limitation du débit et au magasin clé-valeur entre les instances NGINX Plus d’un déploiement en cluster.

Une seule configuration zone_sync peut désormais être utilisée pour toutes les instances d’un cluster. Auparavant, vous deviez configurer explicitement l’adresse IP ou le nom d’hôte de chaque membre, ce qui signifiait que chaque instance avait une configuration légèrement différente. Vous pouvez désormais faire en sorte que le serveur zone_sync écoute sur toutes les interfaces locales en spécifiant une valeur générique pour le paramètre adresse:port de la directive listen. Cette fonctionnalité est particulièrement utile lors du déploiement de NGINX Plus dans un cluster dynamique où l’adresse IP de l’instance n’est pas connue avant le déploiement.

L’utilisation de la même configuration sur chaque instance simplifie considérablement le déploiement dans les environnements dynamiques (par exemple, avec des groupes d’auto-scaling ou des clusters conteneurisés).

Modules dynamiques nouveaux et mis à jour

Les modules dynamiques suivants ont été ajoutés ou mis à jour dans cette version :

• Nouveau module de compression Brotli – Brotli est un algorithme de compression de données sans perte à usage général qui utilise une variante de l’algorithme LZ77, le codage de Huffman et la modélisation contextuelle de second ordre.
• Nouveau module OpenTracing – Vous pouvez désormais instrumenter NGINX Plus avec des requêtes compatibles avec OpenTracing pour différents services de traçage distribué, tels que Datadog, Jaeger et Zipkin.
• Mise à jour du module Lua – Lua est un langage de script pour NGINX Plus. Le module utilise désormais LuaJIT 2.1.

Mises à jour de l’écosystème NGINX Plus

Améliorations apportées au module JavaScript de NGINX

Le module JavaScript NGINX (njs) a été mis à jour vers la version 0.3.0. L’amélioration la plus notable est la prise en charge des modules JavaScript « import » et « export », qui vous permet d’organiser votre code JavaScript dans plusieurs fichiers dédiés à des fonctions spécifiques. Auparavant, tout le code JavaScript devait se trouver dans un seul fichier.

L’exemple suivant montre comment utiliser les modules JavaScript pour organiser et simplifier le code nécessaire à un cas d’utilisation relativement simple. Ici, nous utilisons JavaScript pour effectuer un masquage des données afin de protéger la vie privée des utilisateurs, de sorte qu’une version hachée (masquée) de l’adresse IP du client soit consignée dans le journal à la place de l’adresse réelle. Une adresse IP masquée donnée dans le journal représente toujours le même client, mais ne peut pas être reconvertie en adresse IP réelle.

[Éditeur – L’exemple présenté dans cette section n’est que l’un des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez Cas d’utilisation du module JavaScript NGINX.

Le code a été mis à jour pour utiliser la directive js_import, qui remplace la directive js_include dans NGINX Plus R23 et les versions ultérieures. 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.

Dans NGINX Plus R22 et les versions ultérieures, en plus des modules JavaScript import et export, vous pouvez utiliser la directive njs js_import pour organiser votre code JavaScript en plusieurs fichiers propres à chaque fonction.]

Nous plaçons les fonctions nécessaires au masquage des adresses IP dans un module JavaScript qui exporte une seule fonction, maskIp(). La fonction exportée dépend de fonctions privées qui ne sont disponibles qu’au sein du module et ne peuvent pas être appelées par un autre code JavaScript.

Chargement de l’exemple de code…

Ce module peut désormais être importé dans le fichier JavaScript principal (main.js), et les fonctions exportées peuvent être utilisées.

Chargement de l’exemple de code…

Par conséquent, main.js est très simple et contient uniquement les fonctions référencées par la configuration NGINX. L’instruction import indique un chemin relatif ou absolu vers le fichier du module. Lorsqu’un chemin relatif est fourni, vous pouvez utiliser la nouvelle directive js_path pour spécifier des chemins supplémentaires dans lesquels effectuer la recherche.

Chargement de l’exemple de code…

Les nouvelles fonctionnalités améliorent considérablement la lisibilité et la maintenance, en particulier lorsqu’un grand nombre de directives njs sont utilisées et/ou que le volume de code JavaScript est important. Des équipes distinctes peuvent désormais gérer leur propre code JavaScript sans avoir à effectuer une fusion complexe dans le fichier JavaScript principal.

Installation directe de NGINX Ingress Controller pour Kubernetes avec Helm

Vous pouvez désormais installer NGINX Ingress Controller pour Kubernetes directement depuis notre nouveau dépôt Helm, sans avoir à télécharger les fichiers sources du chart Helm (bien que cette méthode reste également prise en charge). Pour plus d’informations, consultez le dépôt GitHub.

Corrections de bugs notables

Limites de bande passante pour les applications UDP

Les directives « proxy_upload_rate » et « proxy_download_rate » fonctionnent désormais correctement pour les datagrammes UDP.

Le TLV du protocole PROXY avec vérification de l’état provoque le plantage de NGINX

Auparavant, NGINX Plus pouvait planter lorsque la directive health_check était incluse dans un emplacement faisant référence à la variable $proxy_protocol_tlv_0xEA, par exemple dans un environnement AWS PrivateLink.

L’équilibrage de charge « Least Time » ignorait le serveur en amont le plus lent

Auparavant, si un serveur en amont répondait très lentement pendant une période prolongée, il pouvait ne plus jamais être sélectionné, car sa valeur pour la métrique temporelle spécifiée était trop élevée par rapport à celle des autres serveurs en amont. Désormais, un serveur en amont précédemment lent est finalement réintégré au processus de sélection de l’équilibreur de charge, à mesure que de nouvelles mesures permettent à la moyenne mobile de diminuer.

Cela s’applique aux algorithmes d’équilibrage de charge qui utilisent le temps de réponse du serveur en amont comme critère de sélection, notamment least_time et random avec le paramètre least_time.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à NGINX Plus R18 dès que possible. Vous bénéficierez également de plusieurs correctifs et améliorations supplémentaires, et cela permettra à NGINX, Inc. 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 faire, que ce soit 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 une évaluation gratuite 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