Annonce de NGINX Plus R13

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que NGINX Plus Release 13 (R13) est désormais disponible sous forme de mise à niveau gratuite pour tous les abonnés à NGINX Plus. NGINX Plus combine un serveur web, un équilibreur de charge et un cache de contenu, le tout basé 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, ainsi qu’une sécurité et des performances accrues.

NGINX Plus R13 prend désormais en charge :

• Une nouvelle API NGINX Plus – Effectuez une configuration dynamique et obtenez des métriques d’état étendues à partir d’un point de terminaison unique et centralisé ; l’API prend également en charge les magasins clé-valeur.
• Mise en miroir des requêtes – Envoyez une copie de tout le trafic entrant vers un serveur dédié, où vous pouvez surveiller, inspecter et journaliser le trafic applicatif sans affecter les performances des serveurs de production.
• Améliorations apportées au module JavaScript NGINX – Étendez NGINX Plus grâce à une configuration programmatique utilisant le 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 JavaScript intégrés. Vous pouvez explorer ces objets plus en détail afin de découvrir les méthodes et les primitives disponibles pour chacun d’eux.
• Outil de compilation pour les modules dynamiques – Utilisez notre nouvel outil de compilation pour créer des paquets installables pour les nombreux modules tiers disponibles pour NGINX et NGINX Plus.

Parmi les autres améliorations figurent des optimisations de la méthode sticky learn pour la persistance des sessions, la prise en charge des en-têtes de fin HTTP et un nouveau module dynamique tiers pour les substitutions HTTP.

Changements de comportement

• Modules obsolètes – Les anciennes API de statut étendu et de configuration dynamique des groupes de serveurs en amont (les modules Status et Upstream Conf) sont obsolètes et remplacées par l’API unifiée NGINX Plus API. Les API obsolètes continueront d’être fournies avec NGINX Plus pendant au moins 6 mois, parallèlement à la nouvelle NGINX Plus API. Elles seront supprimées dans une prochaine version de NGINX Plus.
• Directive supprimée – La directive sticky_cookie_insert a été supprimée dans NGINX Plus R13, après avoir été déclarée obsolète dans NGINX Plus R2.
• Modules dynamiques tiers – Les modules dynamiques installés depuis le dépôt NGINX sont automatiquement mis à niveau vers la version R13. Tous les modules tiers, c’est-à-dire les modules qui ne sont pas inclus dans le dépôt officiel de 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 de NGINX Plus.
• Directive du module ModSecurity désormais non prise en charge – La directive SecRequestBodyInMemoryLimit de ModSecurity n’est plus prise en charge. Les clients peuvent la supprimer sans risque, car le module ModSecurity respecte la gestion du corps des requêtes définie par la configuration NGINX.[Note de la rédaction – Le module NGINX ModSecurity WAF pour NGINX Plus a officiellement cessé d’être commercialisé le 1er avril 2022 et arrivera en fin de vie le 31 mars 2024. Pour plus de détails, consultez l’article F5 NGINX ModSecurity WAF Is Transitioning to End-of-Life<.htmla> sur notre blog.]
• Fin de la prise en charge des versions de systèmes d’exploitation arrivées 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 de NGINX R13 en détail

API NGINX Plus

NGINX Plus R13 inclut une nouvelle API REST unifiée sous un point de terminaison unique. Les versions précédentes de NGINX Plus incluaient des API distinctes pour Upstream Conf et Extended Status. 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 de configuration dynamique (abordés dans la section Key‑Value Store ci-dessous).

Pour activer l’API NGINX Plus, incluez la nouvelle directive « api » dans un bloc « location » :

server {    listen 80;

    location /api {
        api write=on;
        # directives that allow access only by authorized users
    }
}

Par défaut, l’API NGINX Plus fournit un accès aux données en lecture seule. Ajoutez le paramètre « write=on » à la directive « api » pour activer l’accès en lecture/écriture afin de pouvoir apporter des modifications aux serveurs en amont et au nouveau module « magasin clé-valeur ». Nous vous recommandons vivement de réserver l’accès à l’API aux seuls utilisateurs autorisés, en particulier lorsque le mode lecture/écriture est activé.

Pour afficher 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","processes","connections","ssl","slabs","http","stream"]

Pour afficher des informations détaillées sur un type d’informations spécifique, ajoutez la chaîne appropriée à l’URI de la requête :

• connections – Afficher les métriques du nombre total de connexions
• http – Afficher les métriques du trafic HTTP et modifier la configuration des serveurs HTTP en amont. Il existe également deux « sous-types » sous http :
  • http/server_zones – Afficher des informations sur les serveurs virtuels HTTP
  • http/upstreams – Afficher des informations sur les groupes de serveurs en amont HTTP et modifier leur configuration
• nginx – Afficher des informations générales sur NGINX
• processes – Affiche des informations sur les processus de travail NGINX
• slabs – Afficher des informations sur la mémoire partagée allouée par NGINX
• ssl – Afficher en temps réel les métriques des clients SSL/TLS
• stream – Afficher les métriques du trafic TCP/UDP et modifier la configuration des groupes de serveurs en amont TCP/UDP (dans stream/upstreams)

Surveillance étendue de l’état

NGINX Plus fournit plus de 40 métriques exclusives en complément de celles disponibles 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.

Par exemple, ajoutez connections à l’URI pour obtenir un instantané de l’état des connexions, notamment le nombre de connexions clientes acceptées, actives, abandonnées et inactives.

$ curl http://localhost:80/api/1/connections{"accepted":3,"dropped":0,"active":1,"idle":0}

Autre exemple : ajoutez ssl à l’URI pour afficher un instantané des statistiques des clients SSL en temps réel.

$ curl http://localhost:80/api/1/ssl {"handshakes":0,"handshakes_failed":0,"session_reuses":0}

Configuration dynamique des groupes de serveurs en amont

Dans NGINX Plus R12 et les versions antérieures, vous pouviez 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 nommé « backend » et active l’API NGINX Plus à l’emplacement « /api » :

upstream backend {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
}

server {
    listen 80;
    server_name www.example.org;

    location /api {
        api write=on;
    }
}

Pour ajouter un serveur au groupe backend, incluez l’option -d dans une requête curl adressée à /api/1/http/upstreams/backend/servers, avec du texte JSON définissant l’adresse IP du nouveau serveur (ici, 10.10.10.6). L’option -i indique que les en-têtes HTTP sont inclus dans la réponse. (Vous pouvez omettre -X POST, car il s’agit de la méthode utilisée par défaut avec -d, mais nous l’incluons par souci de cohérence avec les autres méthodes.)

$ curl -iX POST -d '{"server":"10.10.10.6"}' http://localhost/api/1/http/upstreams/backend/serversHTTP/1.1 201 Created
...

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

Magasin clé-valeur

NGINX Plus R13 introduit un nouveau module de stockage clé-valeur. Vous pouvez utiliser l’API NGINX Plus pour créer, modifier et supprimer à la volée des paires clé-valeur dans une ou plusieurs zones de mémoire partagée « keyval ». La valeur de chaque paire clé-valeur peut ensuite être évaluée en tant que variable afin d’être utilisée par d’autres fonctionnalités de 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 offre de nombreuses solutions de configuration dynamique permettant une intégration en temps réel avec des systèmes externes.

Voici quelques exemples de cas d’utilisation :

• Ajout dynamique d’adresses IP à la liste de refus (voir le Guide de l’administrateur NGINX Plus)
• Routage des URI vers les serveurs backend
• Gestion des listes d’URI autorisées pour chaque 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=redirects:1M state=state/redirects.json;  # Save key-val pairs to filekeyval $uri $target zone=redirects;                        # $uri is the key, $target is the value

server {
    listen 80;

    location /api {
        api write=on; # Enable the NGINX Plus API (secure this location in production environments)
    }

    if ($target) {          # True when $uri exists in the 'redirects' keyval zone
        return 301 $target; # Redirect client to the matching value for the $uri
    }

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

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

Pour alimenter le magasin clé-valeur avec une première URL personnalisée, nous envoyons les données, encodées au format JSON, à l’URI de l’API NGINX Plus.

$ curl -iX POST -d '{"/conf":"/conf2017"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 201 Created
...

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

$ curl -i http://localhost/confHTTP/1.1 301 Moved Temporarily
Location: http://localhost/conf2017

Vous pouvez utiliser la méthode « PATCH » pour ajouter d’autres redirections d’URL personnalisées au magasin clé-valeur et modifier dynamiquement les entrées existantes.

$ curl -iX PATCH -d '{"/conf":"/conf2018"}' http://localhost/api/1/http/keyvals/redirectsHTTP/1.1 204 No Content
...

Vous pouvez configurer plusieurs magasins clé-valeur distincts à l’aide de la directive keyval afin de définir une zone de mémoire partagée différente pour chacun d’eux. Pour plus d’informations, consultez la documentation de référence du module Key-Value Store.

Documentation Swagger

La nouvelle API NGINX Plus est fournie avec une spécification Swagger qui permet d’explorer l’API et de comprendre les fonctionnalités de chaque ressource. La documentation Swagger est incluse avec NGINX Plus et est accessible à l’adresse http://nginx-host/swagger-ui/.

La partie interactive de l’interface Swagger nécessite l’activation de l’API NGINX Plus. Pour ce faire, décommentez le bloc location /api/ dans le fichier conf.d/default.conf.

# enable /api/ location with appropriate access control in order# to make use of NGINX Plus API
#
#location /api/ {
#    api write=on;
#    allow 127.0.0.1;
#    deny all;
#}

Vous pouvez également consulter la documentation de l’API NGINX Plus à l’adresse https://demo.nginx.com/swagger-ui/.

Remarque : L’intégralité de l’API NGINX Plus, y compris les métriques d’état étendues, la configuration des serveurs en amont et le nouveau module de stockage clé-valeur, est exclusivement disponible dans NGINX Plus.

Mise en miroir des requêtes

Avec NGINX Plus R13, vous pouvez activer la mise en miroir des requêtes HTTP. Cette fonctionnalité permet de cloner les requêtes HTTP transmises par proxy à un groupe en amont et de les envoyer également vers une autre destination. La requête d’origine est traitée normalement, mais toutes les réponses à la requête clonée sont ignorées. La mise en miroir des requêtes peut être utilisée dans de nombreux cas, notamment :

• Intégration avec des pare-feu applicatifs web (WAF) déployés en mode apprentissage, afin de pouvoir analyser les schémas de requêtes habituels sans affecter le trafic de production
• Optimisation des performances sans risque à l’aide du trafic de production en temps réel
• Duplication des fichiers téléversés sur un serveur de sauvegarde afin d’éviter la réplication du système de fichiers entre les serveurs web

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

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

location /mirror {
    internal;
    proxy_pass http://test_backend$request_uri;
}

Les requêtes sont transmises par proxy au groupe de serveurs en amont « backend » pour un traitement normal. Elles sont également dupliquées et transmises par proxy à un groupe de serveurs en amont distinct nommé « test_backend », tout en conservant l’URI de la requête d’origine.

Remarque : La mise en miroir des requêtes a été introduite dans NGINX Open Source 1.13.4.

Améliorations apportées au module JavaScript de NGINX

Depuis sa mise à disposition générale dans NGINX Plus R12, le module JavaScript de NGINX (anciennement appelé nginScript) continue de s’enrichir avec la prise en charge des fonctionnalités fondamentales du langage JavaScript. Cette version introduit 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, lancé à l’aide de la commande « njs », afin de faciliter le développement de code NGINX JavaScript.

L’extrait de shell suivant montre comment accéder au shell interactif NGINX JavaScript, définir une expression qui génère une date aléatoire située au maximum 30 secondes dans le futur et calculer la somme de deux nombres.

$ njsinteractive 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.

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

Outil de compilation pour les 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. Les utilisateurs de NGINX et de NGINX Plus peuvent ainsi utiliser les versions officielles disponibles dans les dépôts de NGINX, Inc. et charger uniquement les modules dynamiques dont ils ont besoin.

Avec NGINX Plus R13, nous fournissons un outil de build permettant de compiler et de conditionner un module dynamique sous la forme d’un module installable qui préserve et respecte la dépendance entre celui-ci et la version de base de NGINX à laquelle il est lié.

Pour en savoir plus sur l’outil de compilation, consultez l’article « Création de paquets installables pour les modules dynamiques » sur notre blog.

Remarque : L’outil de compilation 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 la répartition de charge de NGINX Plus, qui permet d’envoyer toutes les requêtes d’un client donné vers un même serveur. Il existe plusieurs façons d’établir la persistance de session. Avec la méthode « sticky learn », NGINX Plus recherche la présence d’un cookie spécifique et associe le client au même serveur chaque fois que ce cookie est inclus dans une requête.

Avec NGINX Plus R13, vous pouvez désormais établir une session persistante dès que le serveur en amont a envoyé les en-têtes de sa réponse, au lieu d’attendre la réception de l’intégralité du contenu de la réponse. NGINX Plus peut ainsi transmettre la session persistante au client dans les meilleurs délais. Ajoutez le nouveau paramètre « header » à la directive « sticky learn » :

upstream backends {    zone backends 64k;
    server 10.10.10.2; 
    server 10.10.10.4;
   
    sticky learn create=$upstream_cookie_sessionid
                 lookup=$cookie_sessionid
                 zone=client_sessions:1m
                 header;
 }

Le paramètre header 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.

Remarque : la persistance de session Sticky‑learn est une fonctionnalité exclusive de NGINX Plus.

Fonctionnalités supplémentaires

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

• En-têtes de fin HTTP – La directive add_trailer permet d’ajouter des en-têtes de fin arbitraires à la fin des réponses HTTP. L’en-tête de réponse de fin permet à l’expéditeur d’inclure des champs supplémentaires à la fin des messages transmis par blocs afin de fournir des métadonnées susceptibles d’être générées dynamiquement pendant l’envoi du corps du message, telles qu’un contrôle d’intégrité du message ou une signature numérique.
• Module dynamique de filtre de substitution – Le module dynamique communautaire HTTP Substitutions Filter est désormais pris en charge et inclus dans nos distributions NGINX Plus. Ce module permet d’appliquer aux corps des réponses des substitutions basées sur des expressions régulières ou des chaînes fixes. Il analyse le tampon des chaînes de sortie et recherche les correspondances ligne par ligne. Vous pouvez également accéder au module sur la page Dynamic Modules.
• Arrêt progressif des processus de travail – Utilisez la directive worker_shutdown_timeout pour définir un délai d’expiration permettant d’accélérer l’arrêt progressif des processus de travail. Lorsque ce délai expire après la réception d’un signal d’arrêt ou de redémarrage, NGINX Plus tente de fermer toutes les connexions clientes ouvertes.

Passez à la version R13 ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 13 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.

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 tester pour accélérer vos sites web, équilibrer la charge et assurer la mise à disposition de vos applications, ou comme serveur web entièrement pris en charge, doté d’API avancées de surveillance et de gestion. Vous pouvez commencer gratuitement dès aujourd’hui avec une évaluation de 30 jours et constater 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