Aujourd’hui (24 juillet) marque l’achèvement de nos trois derniers mois de développement et la sortie de NGINX Plus Release 4 (R4).
NGINX Plus R4 réunit les fonctionnalités récemment publiées dans notre branche open source et plusieurs fonctionnalités exclusivement commerciales au sein d’une version entièrement testée et prise en charge.
Sécurité de bout en bout
La validation des certificats et la prise en charge de SNI pour les serveurs en amont renforcent la sécurité des appels d’API et du trafic avec équilibrage de charge dans les environnements non fiables. Un magasin externe de phrases secrètes améliore la protection de vos précieuses clés privées SSL.
La sécurité de bout en bout est une préoccupation majeure, en particulier si vous développez une application répartie sur plusieurs sites. Si votre trafic interne transite par l’Internet public (ou même au sein d’un cloud public), le protocole SSL de base ne suffit pas à vous protéger contre de simples attaques de l’homme du milieu (MITM). Cette version (avec nos remerciements à CloudFlare) ajoute la vérification des certificats des serveurs en amont, afin que vous puissiez avoir la certitude que NGINX Plus communique bien avec le serveur prévu. Elle ajoute également la prise en charge de SNI pour les serveurs en amont afin de permettre une mise à l’échelle sécurisée des services en amont complexes.
La sécurité interne est tout aussi importante. De nombreux sites stockent leur configuration NGINX Plus de manière centralisée, mais cela soulève des inquiétudes quant à la confidentialité de la clé privée SSL. Les phrases secrètes permettant de déchiffrer la clé privée constituent la bonne solution, mais jusqu’à présent, leur utilisation était très peu pratique.
NGINX Plus vous permet d’utiliser un stockage externe de phrases secrètes, propre à chaque serveur et distinct de la configuration. Ainsi, les clés sont protégées lorsque la configuration est stockée ou en transit, et seuls les serveurs autorisés peuvent les déchiffrer.
Amélioration de l’équilibrage de charge et de la mise en cache
Les optimisations et les nouvelles méthodes de répartition de charge et de mise en cache font de NGINX Plus une interface frontale très performante pour diffuser vos applications web.
La version 4 ajoute un nouvel algorithme d’équilibrage de charge – Hachage – aux algorithmes existants (Round Robin, IP Hash et Least Connections). L’équilibrage de charge basé sur le hachage permet de répartir uniformément le trafic au sein d’un groupe de serveurs en amont à l’aide d’une fonction de hachage appliquée à n’importe quelle combinaison de paramètres de requête : adresse IP et port sources, URL, etc.
La méthode Hash devient très utile si vous activez le paramètre facultatif consistent de la directive hash. Cela permet d’utiliser un équilibrage de charge par hachage cohérent (avec la méthode d’équilibrage de charge ketama pour assurer l’interopérabilité avec memcached), ce qui constitue un avantage considérable pour l’équilibrage de charge des serveurs de cache et d’autres applications qui accumulent un état.
Avec le hachage cohérent les requêtes sont réparties uniformément entre les serveurs cibles en fonction de la valeur de hachage de la clé spécifiée par l’utilisateur. Si un serveur est ajouté ou supprimé (en raison d’une défaillance, par exemple), la plus petite partie possible de l’espace de hachage est redistribuée afin de limiter les défauts de cache. Pour assurer une répartition uniforme, l’implémentation de NGINX Plus basée sur ketama utilise 160 points par serveur dans l’espace de hachage (l’illustration ci-dessus ne montre que 8 points).
La version 4 ajoute également un nouveau mécanisme d’affinité de session – sticky learn – aux mécanismes existants (sticky route et sticky cookie). Le mécanisme d’apprentissage est extrêmement flexible : NGINX Plus apprend dynamiquement quelles sessions sont initiées par chaque serveur et sait identifier la signature de session dans les requêtes des clients. Cette fonctionnalité offre de nombreuses possibilités si vous avez besoin de contrôler précisément l’acheminement des requêtes au sein des groupes de serveurs en amont.
Enfin, la mise en cache permet désormais de réduire encore plus efficacement la charge sur vos serveurs en amont. La revalidation du cache peut utiliser les ETag ainsi que l’horodatage Last-Modified pour vérifier que le contenu n’a pas été modifié.
Une surveillance simplifiée – explorez en détail les données dont vous avez besoin
Concentrez-vous sur les informations dont vous avez besoin grâce à des techniques permettant de filtrer et d’explorer en détail les données de journalisation et de surveillance.
NGINX Plus génère une multitude de données grâce à access_log et à sa fonctionnalité unique de surveillance de l’activité en temps réel. Le volume considérable de données peut parfois être difficile à gérer : le coût de leur collecte, de leur stockage et de leur analyse peut tout simplement être trop élevé, en particulier pour les sites très fréquentés comptant un grand nombre de services et d’utilisateurs.
La journalisation conditionnelle dans le journal d’accès vous permet de définir les requêtes pertinentes à consigner et d’ignorer celles qui le sont moins. Elle est particulièrement utile pour prendre des décisions lors de l’exécution : peut-être souhaitez-vous uniquement consigner les requêtes qui génèrent des erreurs serveur 5xx ? Ou ignorer les requêtes provenant du réseau local ? Peut-être voulez-vous éliminer les données inutiles générées par un outil externe de surveillance de l’état de santé ? Quels que soient vos besoins, si vous souhaitez filtrer et limiter les entrées de journal lors de l’exécution, la journalisation conditionnelle est la solution.
Dans les versions précédentes de NGINX Plus, les requêtes portant sur les données de surveillance de l’activité en temps réel générées par le module d’état étendu renvoyaient une quantité considérable de données internes décrivant l’activité et l’état actuels. Toutefois, si vous souhaitez uniquement surveiller un compteur (par exemple, le nombre de requêtes) ou simplement connaître l’état de santé des nœuds de vos groupes en amont, il est inefficace de récupérer l’intégralité des données d’état. Avec la version 4, vous pouvez utiliser une API RESTful pour explorer les données et en récupérer des sous-ensembles, voire une seule valeur, ce qui rend la surveillance plus efficace et plus légère.
Autres nouveautés de NGINX Plus R4
NGINX Plus R4 bénéficie également des dernières mises à jour, corrections et nouvelles fonctionnalités de la version 1.7.3 de NGINX, et les modules tiers inclus dans les paquets nginx-plus-lua et nginx-plus-extras ont été mis à jour pour utiliser Lua version 0.9.10 et Passenger Open Source version 4.0.45.
Conformément à notre politique consistant à prendre en charge les versions des distributions de systèmes d’exploitation maintenues par leurs éditeurs, nous avons ajouté la prise en charge de CentOS/RHEL 7 et mis fin à celle d’Ubuntu 12.10, 13.04 et 13.10.
Pour obtenir la liste complète des nouvelles fonctionnalités et des modifications de la version 4, consultez la page « Versions de NGINX Plus ».
Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 4 dès que possible. Vous bénéficierez ainsi de plusieurs correctifs et améliorations, et cela nous permettra de mieux vous aider si vous devez ouvrir un ticket d’assistance. Les instructions d’installation et de mise à niveau sont disponibles sur le portail client NGINX Plus.
Si vous n’avez pas encore essayé NGINX Plus, commencez dès aujourd’hui votre essai gratuit de 30 jours et découvrez comment NGINX Plus peut vous aider à faire évoluer votre infrastructure et à diffuser vos applications.
À propos de l’auteur
Articles de blog associés
Tendances actuelles des technologies cloud natives, de l’ingénierie de plateforme et de l’IA
Découvrez les principaux enseignements tirés des réponses à l’enquête annuelle F5 NGINX sur les dernières tendances en matière de technologies cloud natives, de sécurité, d’ingénierie de plateforme et d’IA.
Quels contrôleurs Ingress NGINX sont affectés par les vulnérabilités CVE-2022-4886, CVE-2023-5043 et CVE-2023-5044 ?
Lorsque de nouvelles CVE sont signalées, il est facile de ne plus savoir si elles concernent un outil de contrôleur Ingress NGINX particulier, car il existe plusieurs projets. Cet article présente les CVE et explique comment distinguer les différents projets de contrôleurs Ingress afin de dissiper toute confusion.
Votre API est-elle en temps réel ? Testez sa latence avec l’outil rtapi de NGINX
Votre API répond-elle aux requêtes en moins de 30 ms ? Si ce n’est pas le cas, il ne s’agit pas d’une API en temps réel offrant la faible latence exigée par la grande majorité des organisations. Mesurez la latence de votre API avec l’outil rtapi de NGINX et découvrez comment NGINX peut l’aider à offrir une réactivité en temps réel.
Un testeur d’expressions régulières pour NGINX et NGINX Plus
Le testeur d’expressions régulières (regex) pour NGINX et NGINX Plus vous évite de tâtonner en vous indiquant si une expression régulière utilisée dans un bloc location ou map correspond aux valeurs comme prévu. Il génère la configuration appropriée et affiche les valeurs des groupes de capture.
Caches partagés avec les clusters de cache NGINX Plus, partie 1
Optimisez la capacité de votre cache web en le répartissant entre plusieurs serveurs de cache web NGINX ou NGINX Plus. Découvrez comment procéder dans cet article.
Introduction aux microservices
Les microservices suscitent actuellement beaucoup d’intérêt. Cet article de blog est le premier d’une série de sept consacrée à la conception, au développement et au déploiement de microservices.