Annonce de NGINX Plus R18

Nous sommes heureux d'annoncer que NGINX Plus Release 18 (R18) est désormais disponible. NGINX Plus est le seul équilibreur de charge, cache de contenu, serveur Web et passerelle API tout-en-un . Basé sur NGINX Open Source, NGINX Plus inclut des fonctionnalités améliorées exclusives et un support primé. R18 simplifie les flux de travail de configuration pour 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 crypter les communications sur Internet, contre 66 % il y a seulement trois ans. De bout en bout Le cryptage est désormais le modèle de déploiement par défaut pour les sites Web et les applications, et l’explosion des certificats SSL/TLS signifie que certaines entreprises gèrent plusieurs milliers de certificats dans des environnements de production. Cela nécessite une approche plus flexible pour le déploiement et la configuration des certificats.

La nouveauté de cette version est la prise en charge du chargement dynamique des certificats . Avec des milliers de certificats, il n'est pas possible de définir manuellement chacun d'eux dans la configuration pour le chargement à partir du disque. Non seulement ce processus est fastidieux, mais la configuration devient ingérable et le démarrage de NGINX Plus est inacceptablement 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 avec l' API NGINX Plus et ils n'ont même pas besoin de rester sur le disque.

Les nouvelles fonctionnalités supplémentaires de NGINX Plus R18 incluent :

• Améliorations d’OpenID Connect – Nous continuons d’améliorer notre implémentation de référence OpenID Connect prise en charge, 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 une gamme plus large d'applications, telles que le FTP passif, qui nécessitent la réservation de plages de ports.
• Définition de clé-valeur dans la configuration – Le magasin de clés-valeurs NGINX Plus permet des solutions pour un large éventail de cas d'utilisation, notamment la mise sur liste noire dynamique des adresses IP et l'atténuation dynamique des attaques DDoS. Vous pouvez désormais créer des paires clé-valeur directement avec des variables dans la configuration NGINX Plus, ouvrant ainsi encore plus de cas d’utilisation.
• Une plus grande flexibilité pour les contrôles de santé actifs – Les contrôles de santé actifs de NGINX Plus sont un outil puissant pour surveiller la santé des systèmes back-end. Avec NGINX Plus R18 , vous pouvez désormais tester la valeur de n'importe quelle variable NGINX et fermer automatiquement les connexions TCP existantes aux serveurs défaillants.

Cette version est complétée par une configuration simplifiée pour les environnements en cluster et des modules dynamiques nouveaux et mis à jour (y compris Brotli). Les mises à jour de l'écosystème NGINX Plus incluent une organisation de code modulaire avec le module JavaScript NGINX et l'installation directe de Helm du contrôleur d'entrée officiel NGINX pour Kubernetes.

Changements importants dans le 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 en amont, remplaçant les API Status et Upstream Conf qui implémentaient auparavant ces fonctions. Comme annoncé à l'époque, les API obsolètes ont continué à être disponibles et prises en charge pendant une période significative, qui a pris fin avec NGINX Plus R16 . Si votre configuration inclut 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 sur la migration vers la nouvelle API NGINX Plus , veuillez consulter le guide de transition sur notre blog ou contacter notre équipe d'assistance.

• Directive d’écoute mise à jour – Auparavant, lorsque la directive d’écoute spécifiait un nom d’hôte qui résolvait 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 du module JavaScript NGINX (njs) – L’objet req.response obsolète a été supprimé du module JavaScript NGINX . Les fonctions déclarées à l'aide de la syntaxe function(req,res) qui référencent également les propriétés de l'objet res génèrent des erreurs d'exécution, renvoyant un code d'état HTTP500 et une entrée correspondante dans le journal des erreurs :

  AAAA / MM / JJ hh : mm : ss [erreur] 34#34 : exception js : TypeError : impossible d'obtenir la propriété « return » de undefined

  Étant donné que 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 .

  De plus, les objets JavaScript qui représentent l’état NGINX (par exemple, r.headersIn ) renvoient désormais undefined au lieu de la chaîne vide lorsqu’il n’y a aucune valeur pour une propriété donnée. Cette modification signifie que les objets JavaScript spécifiques à NGINX se comportent désormais de la même manière que les objets JavaScript intégrés.

• Systèmes d'exploitation plus anciens supprimés ou à supprimer :

  • Amazon Linux 2017.09 n'est plus pris en charge ; la version la plus ancienne prise en charge est désormais 2018.03
  • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3 n'est plus pris en charge ; la version la plus ancienne prise en charge est désormais 7.4
  • Debian 8.0 sera supprimé dans NGINX Plus R19
  • Ubuntu 14.04 sera supprimé de NGINX Plus R19

Nouvelles fonctionnalités en détail

Chargement de certificats SSL/TLS dynamiques

Avec les versions précédentes de NGINX Plus, l’approche typique de gestion des certificats SSL/TLS pour les sites et applications sécurisés consistait à créer un bloc de serveur 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 le disque. (Pour faciliter la lecture, nous utiliserons désormais le terme certificat pour désigner le certificat et la clé associés.) Les certificats ont ensuite été chargés au démarrage de NGINX Plus. Avec NGINX Plus R18 , les certificats peuvent être chargés de manière dynamique et éventuellement stockés dans le magasin de clés-valeurs NGINX Plus en mémoire plutôt que sur le disque.

Il existe deux principaux cas d’utilisation pour le chargement dynamique de certificats :

• « Chargement paresseux » de certificats à partir du disque
• Stockage des certificats en mémoire

Dans les deux cas, NGINX Plus peut effectuer un chargement de certificat dynamique en fonction du nom d'hôte fourni par Server Name Indication (SNI) dans le cadre de la négociation TLS. Cela permet à NGINX Plus d'héberger plusieurs sites Web sécurisés sous une seule configuration de serveur et de sélectionner le certificat approprié à la demande pour chaque demande entrante.

Chargement différé des certificats SSL/TLS à partir du disque

Avec le « chargement paresseux », les certificats SSL/TLS sont chargés en mémoire uniquement lorsque les requêtes arrivent et spécifient le nom d'hôte correspondant. Cela simplifie à la fois la configuration (en éliminant la liste des certificats par nom d’hôte) et réduit l’utilisation des ressources sur l’hôte. Avec un grand nombre (plusieurs milliers) de certificats, il peut falloir plusieurs secondes pour les lire tous à partir du disque et les charger en mémoire. De plus, une grande quantité de mémoire est utilisée lorsque la configuration NGINX est rechargée, car le nouvel ensemble de processus de travail charge une nouvelle copie des certificats en mémoire, aux côtés des certificats chargés par l'ensemble de processus de travail précédent. Les certificats précédents restent en mémoire jusqu'à ce que la connexion finale établie sous l'ancienne configuration soit terminée et que les travailleurs précédents soient terminés. Si la configuration est mise à jour fréquemment et que les connexions client durent longtemps, il peut y avoir plusieurs copies des certificats en mémoire, ce qui peut entraîner un épuisement de la mémoire.

Le chargement différé des certificats à partir du disque est idéal pour les déploiements avec 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 difficile 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é élimine le besoin de modifications de configuration ; déployez simplement les certificats sur chaque instance et vous avez terminé.

Pour prendre en charge le chargement paresseux, les directives ssl_certificate et ssl_certificate_key acceptent désormais des paramètres variables. La variable doit être disponible pendant le traitement SNI, qui se produit avant la lecture de la ligne de demande 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 à partir du disque pendant la négociation TLS au début de chaque session client et mis en cache dans la mémoire du cache du système de fichiers, réduisant ainsi encore l'utilisation de la mémoire.

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

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

1. Il élimine le bloc de serveur séparé pour chaque nom d'hôte, ce qui rend la configuration beaucoup plus petite et donc plus facile à lire et à gérer.
2. Cela élimine le besoin de recharger la configuration chaque fois que vous ajoutez un nouveau nom d’hôte. Lorsque vous devez recharger la configuration, c'est beaucoup plus rapide car NGINX Plus ne charge pas tous les certificats.

Notez que le chargement différé allonge la durée de la négociation TLS de 20 à 30 %, selon l'environnement, en raison des appels au système de fichiers requis pour récupérer le certificat à partir du disque. Cependant, la latence supplémentaire affecte uniquement la négociation – une fois la session TLS établie, le traitement des demandes prend le temps habituel.

Stockage de certificats SSL/TLS en mémoire

Vous pouvez désormais stocker les données de certificat SSL/TLS en mémoire, dans le magasin de clés-valeurs NGINX Plus, ainsi que dans des fichiers sur le 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 dans le magasin clé-valeur où résident réellement les données).

Un avantage supplémentaire du stockage dans le magasin clé-valeur plutôt que sur le disque est que les images de déploiement et les sauvegardes n’incluent plus de copies de la clé privée, qu’un attaquant peut utiliser pour déchiffrer tout le trafic envoyé vers et depuis le serveur. Les entreprises disposant de pipelines de déploiement hautement automatisés bénéficient de la flexibilité de pouvoir utiliser l’ API NGINX Plus pour insérer par programmation des certificats dans le magasin clé-valeur. De plus, les entreprises qui migrent des applications vers un environnement de cloud public où il n’existe pas de véritable module de sécurité matériel (HSM) pour la protection des clés privées bénéficient de la sécurité supplémentaire de ne pas stocker les clés privées sur le disque.

Voici un exemple de configuration pour le chargement de certificats à partir du magasin de clés-valeurs :

Une façon de télécharger des certificats et des clés privées dans le magasin de clés-valeurs avec l’ API NGINX Plus consiste à exécuter la commande curl suivante (seul le tout début des données de clé est affiché). Si vous utilisez la commande curl , n'oubliez pas de faire une copie des données PEM et de 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 vous téléchargez le certificat une seule fois pour une propagation automatique sur le cluster. Pour protéger les données du certificat elles-mêmes, utilisez la directive zone_sync_ssl pour chiffrer TLS les connexions entre les membres du cluster. L'utilisation du magasin clé-valeur est également idéale pour les certificats de courte durée ou pour automatiser les intégrations avec des émetteurs de certificats tels que Let's Encrypt et Hashicorp Vault .

Comme avec le chargement paresseux à partir du disque, le chargement des certificats à partir du magasin clé-valeur se produit lors de chaque négociation TLS, ce qui entraîne une baisse des performances. Pour les connexions TLS les plus rapides, utilisez les directives ssl_certificate et ssl_certificate_key avec un paramètre codé en dur dans un fichier sur le disque. De plus, les certificats ECC sont plus rapides que les certificats RSA.

Notez que même si le magasin clé-valeur rend plus difficile pour un attaquant l’obtention de fichiers de clés privées qu’à partir du stockage sur disque, un attaquant disposant d’un accès shell à l’hôte NGINX Plus peut toujours être en mesure d’accéder aux clés chargées en mémoire. Le magasin clé-valeur ne protège pas les clés privées dans la même mesure qu'un module de sécurité matériel (HSM) ; pour que NGINX Plus récupère les clés d'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 back-end via notre implémentation de référence . Cela a été à la fois simplifié et amélioré maintenant que le magasin clé-valeur peut être modifié directement à partir du module JavaScript à l'aide de variables ( voir ci-dessous ).

L'implémentation de référence d'OpenID Connect délivre désormais aux clients des jetons de session opaques sous la forme d'un cookie de navigateur. Les jetons opaques ne contiennent aucune information personnellement identifiable sur l'utilisateur, donc aucune information sensible n'est stockée sur le client. NGINX Plus stocke le jeton d’identification réel dans le magasin clé-valeur et le remplace par le jeton opaque présenté par le client. La validation JWT est effectuée pour chaque demande afin que les jetons expirés ou non valides soient rejetés.

L'implémentation de référence OpenID Connect prend désormais également en charge les jetons d'actualisation afin que les jetons d'identification expirés soient actualisés de manière transparente sans nécessiter d'interaction de l'utilisateur. NGINX Plus stocke le jeton d’actualisation envoyé par un serveur d’autorisation dans le magasin clé-valeur et l’associe au jeton de session opaque. Lorsque le jeton d'identification 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’identification, qui est mis à jour de manière transparente dans le magasin clé-valeur. Les jetons d’actualisation permettent d’utiliser des jetons d’identification à courte durée de vie, ce qui offre une meilleure sécurité sans gêner les utilisateurs.

L'implémentation de référence OpenID Connect fournit désormais une URL de déconnexion. Lorsque les utilisateurs connectés visitent l’URI /logout , leur ID et leurs jetons d’actualisation sont supprimés du magasin de clés-valeurs et ils doivent s’authentifier à nouveau lors d’une future demande.

Plages de ports pour serveurs virtuels

Un bloc de serveur possède généralement une directive d'écoute spécifiant le port unique sur lequel NGINX Plus écoute ; si plusieurs ports doivent être configurés, il existe une directive d'écoute supplémentaire 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 n'est pas pratique de spécifier un grand nombre de directives d'écoute individuelles.

Les plages de ports peuvent être spécifiées pour la directive d'écoute HTTP et la directive d'écoute TCP/UDP (Stream). La configuration suivante permet à NGINX Plus d'agir comme proxy pour un serveur FTP en mode passif, où le port de données est choisi parmi une large gamme de ports TCP.

Cette configuration configure un serveur virtuel pour proxy les connexions au serveur FTP sur le même port sur lequel la connexion est arrivée.

Mise à jour du magasin de clés-valeurs via des variables

Lorsque le magasin clé-valeur est activé, NGINX Plus fournit une variable pour les valeurs qui y sont stockées en fonction d'une clé d'entrée (généralement une partie des métadonnées de la demande). Auparavant, le seul moyen de créer, de modifier ou de supprimer des valeurs dans le magasin de clés-valeurs était d'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 la valeur.

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

La directive set (ligne 7) attribue une valeur ( $last_uri ) pour chaque adresse IP client ( $remote_addr ), créant une nouvelle entrée si elle est absente, ou modifiant la valeur pour refléter le $uri de la requête en cours. Ainsi, la liste actuelle des clients récents et leurs URI demandés est disponible avec 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'utilisation plus puissants peuvent être obtenus avec des extensions de script telles que le module JavaScript NGINX (njs) et le module Lua. Toute configuration qui utilise njs a accès à toutes les variables, y compris celles sauvegardées par le magasin clé-valeur, par exemple r.variables.last_uri .

Une plus grande flexibilité pour les bilans de santé actifs

Les contrôles de santé actifs de NGINX Plus testent régulièrement les systèmes back-end, afin que le trafic ne soit pas dirigé vers des systèmes connus pour être en mauvais état. NGINX Plus R18 étend cette fonctionnalité importante avec deux capacités supplémentaires.

• Prise en charge des tests de variables arbitraires dans les contrôles de santé
• Possibilité de mettre fin aux sessions TCP en cas d'échec du contrôle de santé

Tester des variables arbitraires dans les contrôles de santé

Lors de la définition d'un contrôle d'intégrité pour une application back-end, vous pouvez utiliser un bloc de correspondance pour spécifier la valeur attendue pour plusieurs aspects de la réponse, y compris le code d'état HTTP et les chaînes de caractères dans les en-têtes et/ou le corps de la réponse. Lorsque la réponse inclut toutes les valeurs attendues, le backend est considéré comme sain.

Pour des vérifications encore plus complexes, NGINX Plus R18 fournit désormais la directive require pour tester la valeur de n'importe quelle variable, à la fois les variables NGINX standard et les variables que vous déclarez. Cela vous donne plus de flexibilité lors de la définition des contrôles de santé, car les variables peuvent être évaluées avec des blocs de carte , des expressions régulières et même des extensions de script.

La directive require à l’intérieur d’un bloc de correspondance spécifie une ou plusieurs variables, qui doivent toutes avoir une valeur différente de zéro pour que le test réussisse. L'exemple de configuration suivant définit un serveur en amont sain comme un serveur 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 différente de zéro, soit un en-tête Cache-Control .

L’utilisation de blocs de cartes de cette manière est un moyen courant d’intégrer la logique OR dans la configuration NGINX Plus. La directive require vous permet de profiter de cette technique dans les contrôles de santé, ainsi que d'effectuer des contrôles de santé avancés. Des contrôles de santé avancés peuvent également être définis en utilisant le module JavaScript (njs) pour analyser des attributs supplémentaires des réponses de chaque serveur en amont, tels que le temps de réponse .

Terminer les connexions de couche 4 lorsque les contrôles d'intégrité échouent

Lorsque NGINX Plus agit comme un é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 principal. Les contrôles de santé actifs sont une partie importante d'une telle configuration, mais par défaut, l'état de santé d'un serveur back-end n'est pris en compte que lorsqu'un nouveau client tente d'établir une connexion. Si un serveur principal est hors ligne, les clients établis peuvent rencontrer un délai d'attente lorsqu'ils envoient des données au serveur.

Avec la directive proxy_session_drop , nouvelle dans NGINX Plus R18 , vous pouvez immédiatement fermer la connexion lorsque le prochain paquet est reçu ou envoyé vers le serveur hors ligne. Le client est obligé de se reconnecter, auquel cas NGINX Plus transmet ses requêtes à un serveur backend sain.

Lorsque cette directive est activée, deux autres conditions déclenchent également la fin des connexions existantes : l’échec d’un contrôle d’intégrité actif et la suppression du serveur d’un groupe en amont pour une raison quelconque. Cela inclut la suppression via la recherche DNS, où un serveur backend est défini par un nom d'hôte avec plusieurs adresses IP, telles que celles fournies par un registre de services .

Autres améliorations dans NGINX Plus R18

Configuration de clustering simplifiée

NGINX Plus prend en charge la synchronisation de l’état d’exécution à l’échelle du cluster depuis NGINX Plus R15 . Le module de synchronisation de zone prend actuellement en charge le partage des données d’état sur les sessions persistantes , la limitation du débit et le magasin clé-valeur dans un déploiement en cluster d’instances NGINX Plus.

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 signifie que chaque instance avait une configuration légèrement différente. Vous pouvez désormais demander au serveur zone_sync d'écouter toutes les interfaces locales en spécifiant une valeur générique pour le paramètre address : port de la directive listen . Cela 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 jusqu'au moment du déploiement.

L’utilisation de la même configuration sur chaque instance simplifie grandement le déploiement dans des environnements dynamiques (par exemple, avec des groupes de mise à l’échelle automatique ou des clusters conteneurisés).

Modules dynamiques nouveaux et mis à jour

Les modules dynamiques suivants sont 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 Huffman et la modélisation du contexte du second ordre.
• Nouveau module OpenTracing – Vous pouvez désormais instrumenter NGINX Plus avec des requêtes compatibles OpenTracing pour une gamme de services de traçage distribués, tels que Datadog, Jaeger et Zipkin.
• Module Lua mis à jour – 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 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 d’importation et d’exportation JavaScript, qui vous permettent d’organiser votre code JavaScript en plusieurs fichiers spécifiques aux fonctions. Auparavant, tout le code JavaScript devait résider dans un seul fichier.

L'exemple suivant montre comment les modules JavaScript peuvent être utilisés pour organiser et simplifier le code requis pour un cas d'utilisation relativement simple. Ici, nous utilisons JavaScript pour effectuer le masquage des données pour la confidentialité des utilisateurs afin qu'une version hachée (masquée) de l'adresse IP du client soit enregistrée au lieu 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 de cette section n’est qu’un des nombreux cas d’utilisation du module JavaScript NGINX. Pour une liste complète, voir Cas d'utilisation du module JavaScript NGINX .

Le code est mis à jour 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.

Dans NGINX Plus R22 et versions ultérieures, en plus des modules d’importation et d’exportation JavaScript , vous pouvez utiliser la directive njs js_import pour organiser votre code JavaScript en plusieurs fichiers spécifiques aux fonctions.

Nous avons placé les fonctions requises pour le masquage d'adresse 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 que dans le module et ne peuvent pas être appelées par un autre code JavaScript.

Ce module peut maintenant être importé dans le fichier JavaScript principal ( main.js ) et les fonctions exportées référencées.

En conséquence, main.js est très simple, contenant uniquement les fonctions référencées par la configuration NGINX. L'instruction d'importation spécifie 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 à rechercher.

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 qu'une grande quantité de code JavaScript est utilisée. 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 du contrôleur d'entrée NGINX pour Kubernetes

Vous pouvez désormais installer NGINX Ingress Controller pour Kubernetes directement depuis notre nouveau référentiel Helm, sans avoir à télécharger les fichiers sources des graphiques Helm (bien que cela soit également toujours pris 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 protocole PROXY TLV avec contrôle de santé fait planter 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 .

Équilibrage de charge le moins long ignoré en amont le plus lent

Auparavant, si un serveur en amont répondait suffisamment lentement pendant une longue période, il pouvait ne plus jamais être sélectionné car sa valeur pour la métrique de temps spécifiée était très élevée par rapport aux autres serveurs en amont. Désormais, un serveur en amont auparavant lent est finalement réintroduit dans le processus de sélection de l’équilibreur de charge lorsque de nouvelles mesures permettent de réduire la moyenne mobile.

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

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer une mise à niveau vers NGINX Plus R18 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, Inc. à 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 une évaluation gratuite de 30 jours . Découvrez par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.