Annonce de NGINX Plus R13

Nous sommes heureux d'annoncer que NGINX Plus Release 13 (R13) est désormais disponible en tant que mise à niveau gratuite pour tous les abonnés NGINX Plus. NGINX Plus est un serveur Web combiné, un équilibreur de charge et un cache de contenu construit sur NGINX Open Source. NGINX Plus R13 inclut de nouvelles fonctionnalités axées sur les déploiements dynamiques, des capacités de débogage améliorées et une sécurité et des performances améliorées.

NGINX Plus R13 introduit la prise en charge de :

• Une nouvelle API NGINX Plus – Effectuez une configuration dynamique et obtenez des mesures d’état étendues sur un seul point de terminaison consolidé ; l’API ajoute également la prise en charge des magasins clé-valeur.
• Demande de mise en miroir – Envoyez une copie de tout le trafic entrant vers un serveur dédié, où vous pouvez surveiller, inspecter et enregistrer le trafic des applications sans affecter les performances des serveurs de production.
• Améliorations apportées au module JavaScript NGINX – Étendez NGINX Plus avec une configuration programmatique à l'aide du module JavaScript NGINX, notre implémentation personnalisée de JavaScript. [Le module s'appelait auparavant nginScript.] Le nouveau shell interactif njs fournit une console qui affiche tous les objets intégrés pour JavaScript. Ces objets peuvent être étudiés plus en détail pour exposer les méthodes et primitives disponibles pour chaque objet.
• Outil de création de modules dynamiques – Utilisez notre nouvel outil de création pour créer des packages installables pour les nombreux modules tiers disponibles pour NGINX et NGINX Plus.

D’autres améliorations incluent des améliorations de la méthode d’apprentissage persistant pour la persistance des sessions, la prise en charge des bandes-annonces HTTP et un nouveau module dynamique tiers pour les substitutions HTTP.

Changements de comportement

• Modules obsolètes – Les API précédentes pour l’état étendu et la configuration dynamique des groupes en amont (les modules Status et Upstream Conf ) sont obsolètes et remplacées par l’ API NGINX Plus unifiée. Les API obsolètes continueront d’être fournies avec NGINX Plus pendant au moins 6 mois, parallèlement à la nouvelle API NGINX Plus . Les API obsolètes seront supprimées dans une future version de NGINX Plus.
• Directive supprimée – La directive sticky_cookie_insert a été supprimée dans NGINX Plus R13, après avoir été obsolète dans NGINX Plus R2.
• Modules dynamiques tiers – Les modules dynamiques installés à partir du référentiel NGINX sont automatiquement mis à niveau vers R13. Tous les modules tiers, c’est-à-dire les modules non inclus dans le référentiel officiel NGINX , doivent être recompilés avec NGINX Open Source 1.13.4 pour continuer à fonctionner avec NGINX Plus R13. Pour plus d'informations, consultez le Guide d'administration NGINX Plus .

• La directive dans le module ModSecurity n'est plus prise en charge – La directive SecRequestBodyInMemoryLimit pour ModSecurity n'est plus prise en charge. Les clients peuvent supprimer cette directive en toute sécurité, car le module ModSecurity obéit à la gestion du corps de la requête définie par la configuration NGINX.

  [ Éditeur – Le module WAF NGINX ModSecurity pour NGINX Plus est officiellement en fin de commercialisation depuis le 1er avril 2022 et passe en fin de vie à compter du 31 mars 2024 . Pour plus de détails, voir F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]

• Suppression de la prise en charge des versions de système d’exploitation en fin de vie : NGINX Plus n’est plus pris en charge sur CentOS 5.10+, Red Hat Enterprise Linux 5.10+, Oracle Linux 5.10+, Ubuntu 12.04 LTS ou Ubuntu 16.10.

Fonctionnalités détaillées de NGINX R13

API NGINX Plus

NGINX Plus R13 inclut une nouvelle API REST unifiée sous un seul point de terminaison. Les versions précédentes de NGINX Plus incluaient des API Upstream Conf et Extended Status distinctes. La nouvelle API combine les fonctionnalités des deux et prend également en charge le nouveau module Key-Value Store dans divers cas d'utilisation pour la configuration dynamique (discutés dans la section Key-Value Store ci-dessous).

Pour activer l' API NGINX Plus , incluez la nouvelle directive api dans un bloc d'emplacement :

serveur { écouter 80 ;

emplacement /api {
api write=on ;
# directives qui autorisent l'accès uniquement aux utilisateurs autorisés
}
}

Par défaut, l’ API NGINX Plus fournit un accès en lecture seule aux données. Ajoutez le paramètre write=on à la directive api pour activer l’accès en lecture/écriture afin que des modifications puissent être apportées aux serveurs en amont et au nouveau module Key-Value Store . Nous vous recommandons fortement de restreindre l'accès à l'API aux seuls utilisateurs autorisés, en particulier lorsque le mode lecture/écriture est activé.

Pour voir tous les types d’informations disponibles à partir du point de terminaison de l’API, exécutez cette commande :

$ curl http://localhost:80/api/1/ ["nginx","processus","connexions","ssl","slabs","http","stream"]

Pour afficher les détails sur un type d'informations spécifique, ajoutez la chaîne appropriée à l'URI de la demande :

• connexions – Afficher les métriques pour le nombre total de connexions

• http – Afficher les métriques du trafic HTTP et modifier la configuration HTTP en amont

  Il existe également deux « sous-types » sous http :

  • http/server_zones – Affiche des informations sur les serveurs virtuels HTTP
  • http/upstreams – Affiche des informations sur les groupes de serveurs HTTP en amont et modifie leur configuration
• nginx – Afficher des informations générales sur NGINX
• processus – Afficher des informations sur les processus de travail NGINX
• dalles – Affiche des informations sur la mémoire partagée allouée par NGINX
• ssl – Afficher les métriques des clients SSL/TLS en temps réel
• stream – Afficher les métriques du trafic TCP/UDP et modifier la configuration des groupes de serveurs TCP/UDP en amont (sur stream/upstreams )

Surveillance étendue de l'état

NGINX Plus fournit plus de 40 mesures exclusives en plus de ce qui est disponible dans NGINX Open Source. Vous pouvez désormais accéder à ces métriques à l'aide de l' API NGINX Plus . Utilisez l'API pour accéder aux métriques qui vous intéressent.

À titre d’exemple, ajoutez des connexions à l’URI pour générer un instantané de l’état de la connexion, qui inclut le nombre de connexions client acceptées, actives, abandonnées et inactives.

$ curl http://localhost:80/api/1/connections {"accepté":3,"abandonné":0,"actif":1,"inactif":0}

Autre exemple : ajoutez ssl à l'URI pour générer un instantané des statistiques du client SSL en temps réel.

$ curl http://localhost:80/api/1/ssl {"poignées de main":0,"poignées de main échouées":0,"réutilisations de session":0}

Configuration dynamique des groupes de serveurs en amont

Dans NGINX Plus R12 et versions antérieures, vous pouvez utiliser la directive upstream_conf pour activer la configuration dynamique des groupes de serveurs en amont existants sans recharger NGINX Plus. Cette fonctionnalité est désormais intégrée à l' API NGINX Plus .

Cet extrait de configuration NGINX Plus définit deux serveurs dans le groupe en amont appelé backend et active l' API NGINX Plus dans /api :

backend en amont { zone backends 64k;
serveur 10.10.10.2; 
serveur 10.10.10.4;
}

serveur {
écoute 80;
nom_serveur www.exemple.org;

emplacement /api {
api write=on;
}
}

Pour ajouter un serveur au groupe backend , incluez l'option -d dans une requête curl à /api/1/http/upstreams/backend/servers , avec du texte JSON qui définit l'adresse IP du nouveau serveur (ici, 10.10.10.6). L'option -i signifie que les en-têtes HTTP sont inclus dans la réponse. (Vous pouvez omettre -X POST car c'est la méthode par défaut avec -d , mais nous l'incluons pour plus de cohérence avec d'autres méthodes.)

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/servers HTTP/1.1 201 Créé ...

Pour plus de détails sur toutes les options de configuration des groupes en amont, consultez la documentation de référence du module API NGINX Plus .

Magasin de valeurs clés

NGINX Plus R13 introduit un nouveau module Key-Value Store . Vous pouvez utiliser l' API NGINX Plus pour créer, modifier et supprimer des paires clé-valeur à la volée dans une ou plusieurs zones de mémoire partagée « keyval ». La valeur de chaque paire clé-valeur peut ensuite être évaluée comme une variable à utiliser par d’autres fonctionnalités NGINX Plus.

Pour ajouter, modifier, lire et supprimer des entrées dans le magasin clé-valeur, utilisez respectivement les méthodes HTTP POST , PATCH , GET et DELETE . Le magasin clé-valeur fournit une multitude de solutions de configuration dynamique pour permettre l'intégration en temps réel avec des systèmes externes.

Voici quelques exemples de cas d’utilisation :

• Liste de refus d'adresses IP dynamiques (voir le guide d'administration NGINX Plus )
• Routage des URI vers les serveurs backend
• Gestion des listes d'URI autorisées par utilisateur
• Gestion des règles de redirection (voir l'exemple suivant)

L'extrait de configuration suivant utilise le module Key-Value Store pour gérer les URL personnalisées d'un site Web.

keyval_zone zone=redirections:1M state=state/redirections.json; # Enregistrer les paires clé-valeur dans le fichierkeyval $uri $target zone=redirections; # $uri est la clé, $target est la valeur

server {
listen 80;

location /api {
api write=on; # Activer l'API NGINX Plus (sécuriser cet emplacement dans les environnements de production)
}

if ($target) { # Vrai lorsque $uri existe dans la zone keyval 'redirects'
return 301 $target; # Rediriger le client vers la valeur correspondante pour $uri
}

location / {
proxy_pass http://backend;
}
}

Dans la directive keyval , la clé est définie sur l'URI de la machine distante émettant la requête HTTP. Si $uri est une clé dans le magasin clé-valeur, la valeur associée à la clé est affectée à une nouvelle variable appelée $target . Ensuite, si $target existe, NGINX Plus redirige le client vers la valeur correspondante de $uri .

Pour remplir le magasin clé-valeur avec une URL de vanité initiale, nous envoyons les données, codées au format JSON, à l'URI de l' API NGINX Plus .

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirects HTTP/1.1 201 Créé ...

Désormais, les clients qui demandent /conf sont redirigés vers /conf2017 .

$ curl -i http://localhost/conf HTTP/1.1 301 Déplacé temporairement Emplacement : http://localhost/conf2017

Vous pouvez utiliser la méthode PATCH pour ajouter davantage de redirections d’URL personnalisées au magasin clé-valeur et modifier les entrées existantes de manière dynamique.

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirects HTTP/1.1 204 Aucun contenu ...

Vous pouvez configurer plusieurs magasins de clés-valeurs distincts en utilisant la directive keyval pour définir une zone de mémoire partagée différente pour chacun. Pour plus d'informations, consultez la documentation de référence du module Key-Value Store .

Documentation de Swagger

La nouvelle API NGINX Plus est livrée avec une spécification Swagger qui peut être utilisée pour explorer l'API et comprendre les capacités de chaque ressource. La documentation Swagger est fournie avec NGINX Plus et est accessible à l'adresse http:// nginx-host /swagger-ui/ .

La partie interactive de l'interface utilisateur Swagger nécessite l'activation de l' API NGINX Plus , ce qui peut être réalisé en supprimant le commentaire du bloc d'emplacement /api/ dans le fichier conf.d/default.conf .

# activer l'emplacement /api/ avec un contrôle d'accès approprié afin# d'utiliser l'API NGINX Plus
#
#location /api/ {
# api write=on;
# allow 127.0.0.1;
# deny all;
#}

Vous pouvez également explorer la documentation de l'API NGINX Plus sur https://demo.nginx.com/swagger-ui/ .

Note: L'ensemble de l'API NGINX Plus , y compris les mesures d'état étendues, la configuration en amont et le nouveau module Key-Value Store, est exclusif à NGINX Plus.

Demande de mise en miroir

Avec NGINX Plus R13, vous pouvez activer la mise en miroir des requêtes HTTP. Avec cette fonctionnalité, les requêtes HTTP transmises par proxy à un groupe en amont sont clonées et également envoyées vers une destination différente. La demande d’origine est traitée comme d’habitude, mais toutes les réponses de la demande clonée sont ignorées. Il existe de nombreux cas d'utilisation pour la mise en miroir des requêtes, notamment :

• Intégration avec les pare-feu d'application Web (WAF) lorsqu'ils sont déployés en mode d'apprentissage, afin que les modèles de requête typiques puissent être analysés sans impacter le trafic de production
• Réglage des performances sans risque grâce au trafic de production en direct
• Duplication des téléchargements de fichiers sur un serveur de sauvegarde pour éviter la réplication du système de fichiers entre les serveurs Web

L’activation de la mise en miroir des demandes a un impact négligeable sur le débit et les performances globales du système. L'extrait de configuration suivant montre comment utiliser la nouvelle directive mirror pour cloner des requêtes et les transmettre à un serveur en amont distinct.

emplacement / { miroir /miroir;
proxy_pass http://backend;
}

emplacement /miroir {
interne;
proxy_pass http://test_backend$request_uri;
}

Les demandes sont transmises par proxy au groupe backend en amont pour un traitement régulier. Ils sont également clonés et envoyés par proxy à un groupe en amont distinct nommé test_backend , conservant l'URI de la demande d'origine.

Note: La mise en miroir des requêtes a été initialement publiée dans NGINX Open Source 1.13.4.

Améliorations apportées au module JavaScript NGINX

Depuis qu'il est disponible dans NGINX Plus R12 , le module JavaScript NGINX (anciennement appelé nginScript) continue d'être étendu avec la prise en charge du langage JavaScript de base. Avec cette version, nous introduisons la prise en charge des nombres hexadécimaux (tels que 0x7b) et de la notation scientifique (telle que 512e10). Des méthodes primitives pour la classe Object ont également été implémentées.

NGINX JavaScript propose désormais également un shell interactif, invoqué avec la commande njs , pour aider au développement du code NGINX JavaScript.

L'extrait de shell suivant montre comment entrer dans le shell interactif JavaScript NGINX, définir une expression qui produit une date aléatoire jusqu'à 30 secondes dans le futur et calculer la somme de deux nombres.

$ njs interactive njscript >> Date.now() + Math.round(Math.random()*30*1000); 1500976350968 >> 0x7b + 512e10; 5120000000123 >>

Pour en savoir plus, consultez l' introduction à NGINX JavaScript<.htmla> sur notre blog.

Note: NGINX JavaScript est disponible pour NGINX Open Source et NGINX Plus.

Outil de création de modules dynamiques

NGINX 1.11.5 et NGINX Plus R11 ont introduit la prise en charge de la compilation de modules dynamiques indépendamment de NGINX lui-même. Cela permet aux utilisateurs de NGINX et NGINX Plus d'utiliser les versions officielles des référentiels NGINX, Inc. et de charger uniquement les modules dynamiques dont ils ont besoin.

Avec NGINX Plus R13, nous fournissons un outil de création permettant de compiler et d'empaqueter un module dynamique en tant que module installable qui préserve et respecte la dépendance entre celui-ci et la version NGINX de base à laquelle il est lié.

Pour plus de détails sur l'outil de création, consultez Création de packages installables pour les modules dynamiques sur notre blog.

Note: L'outil de création est disponible pour NGINX Open Source et NGINX Plus.

Persistance de session Sticky-Learn plus rapide

La persistance de session est une fonctionnalité très utile de l'équilibrage de charge NGINX Plus qui vous permet d'envoyer toutes les requêtes d'un client particulier à un serveur. Il existe plusieurs façons d'établir la persistance d'une session ; avec la méthode « sticky learn », NGINX Plus recherche la présence d'un cookie spécifique et épingle le client sur le même serveur chaque fois que ce cookie est inclus dans une demande.

Avec NGINX Plus R13, vous pouvez désormais établir une session collante dès que le serveur en amont a envoyé les en-têtes de sa réponse, au lieu d'attendre que la charge utile de la réponse complète soit arrivée. NGINX Plus peut ainsi envoyer la session collante au client dans les plus brefs délais. Incluez le nouveau paramètre d'en-tête dans la directive sticky learn :

backends en amont { zone backends 64k;
serveur 10.10.10.2; 
serveur 10.10.10.4;

sticky learn create=$upstream_cookie_sessionid
lookup=$cookie_sessionid
zone=client_sessions:1m
header;
}

Le paramètre d'en-tête est particulièrement utile si une application est sujette aux erreurs et que vous souhaitez que le client renvoie les requêtes ayant échoué au même serveur en amont.

Note: La persistance des sessions Sticky-learn est une exclusivité NGINX Plus.

Fonctionnalités supplémentaires

NGINX Plus R13 introduit les fonctionnalités supplémentaires suivantes :

• Bandes-annonces HTTP – La directive add_trailer permet d’ajouter des bandes-annonces arbitraires à la fin des réponses HTTP. L'en-tête de réponse de la bande-annonce permet à l'expéditeur d'inclure des champs supplémentaires à la fin des messages fragmentés pour fournir des métadonnées qui peuvent être générées dynamiquement lors de l'envoi du corps du message, comme une vérification de l'intégrité du message ou une signature numérique.
• Module dynamique de filtre de substitutions – Le module dynamique communautaire HTTP Substitutions Filter est désormais pris en charge et inclus dans nos distributions NGINX Plus. Le module peut appliquer des substitutions d’expressions régulières et de chaînes fixes aux corps de réponse. Il analyse le tampon des chaînes de sortie et fait correspondre la chaîne ligne par ligne. Vous pouvez également accéder au module sur la page Modules dynamiques .
• Arrêt gracieux des processus de travail – Utilisez la directive worker_shutdown_timeout pour définir un délai d’expiration qui permet l’arrêt gracieux des processus de travail pour qu’il se termine plus rapidement. Lorsque le délai d'expiration expire après la réception d'un signal d'arrêt ou de redémarrage, NGINX Plus tente de fermer toutes les connexions client ouvertes.

Passez à R13 ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à niveau vers la version 13 dès que possible. Vous bénéficierez d'un certain nombre de correctifs et d'améliorations, et cela nous aidera à vous aider si vous devez ouvrir un ticket d'assistance. Les instructions d'installation et de mise à niveau sont disponibles sur le portail client .

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 l'accélération Web, l'équilibrage de charge et la distribution d'applications, 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 gratuitement dès aujourd’hui avec une évaluation de 30 jours et voir par vous-même comment NGINX Plus peut vous aider à fournir et à faire évoluer vos applications.