Annonce de NGINX Plus R9

Owen GarrettDirecteur senior de la gestion des produits

NGINX, Inc. est fière d’annoncer la disponibilité de NGINX Plus Release 9 (R9), la dernière version de notre plateforme de mise à disposition d’applications. Cette mise à jour apporte deux nouvelles fonctionnalités majeures : la possibilité de charger dynamiquement des extensions riches dans NGINX Plus sans avoir recours à des fichiers binaires personnalisés, ainsi qu’un équilibrage de charge UDP bénéficiant d’un support commercial qui vient compléter nos fonctionnalités existantes d’équilibrage de charge TCP et HTTP.

Outre les nouvelles fonctionnalités prometteuses de NGINX Plus R9, nous lançons de nouvelles options de tarification et d’assistance. NGINX Plus est désormais proposé selon un modèle tarifaire « à volonté », qui vous permet de l’utiliser sans limites dans l’ensemble de vos applications ou de votre entreprise, pour un prix fixe. NGINX Plus peut désormais également être acheté avec trois niveaux d’assistance différents : l’assistance Basic 9×5 pour les applications hors production, l’assistance Professional 24×7 par téléphone ou par e-mail, et l’assistance Enterprise 24×7 avec un délai de réponse garanti de 30 minutes.

Note de la rédaction – Pour en savoir plus sur les principales nouveautés de NGINX Plus R9, consultez les ressources connexes suivantes.

• Équilibrage de charge du trafic DNS avec NGINX et NGINX Plus
• Utiliser le DNS pour la découverte de services avec NGINX et NGINX Plus
• Découverte de services pour NGINX Plus à l’aide d’enregistrements DNS SRV de Consul
• Nouveautés de NGINX Plus R9 (webinaire à la demande)

Les principales nouveautés de NGINX Plus R9 sont les suivantes :

• Modules dynamiques – NGINX Plus peut désormais être étendu à l’exécution grâce à des modules chargeables dynamiquement. Vous pouvez ainsi sélectionner uniquement les extensions dont vous avez besoin et les installer directement depuis le dépôt NGINX Plus, accessible à l’aide des commandes standard apt et yum. Au fil du temps, nous proposerons un nombre croissant d’extensions testées et entièrement certifiées pour notre logiciel. Les modules les plus populaires développés par NGINX et par des tiers, notamment ceux prenant en charge le langage de programmation Lua, ont déjà été convertis au nouveau format chargeable dynamiquement. Nous avons également publié des instructions à l’intention des propriétaires de modules tiers afin qu’ils convertissent leurs modules au nouveau format, une étape indispensable avant que ces modules puissent être ajoutés à notre dépôt.
• Répartition de charge UDP – Grâce à l’ajout de la répartition de charge UDP à ses fonctionnalités existantes de répartition de charge TCP et HTTP, NGINX Plus peut désormais répartir la charge de presque toutes les applications. Le mois dernier, nous avons ajouté la répartition de charge UDP dans NGINX Open Source et, avec cette version, nous étendons sa prise en charge à NGINX Plus en y ajoutant des fonctionnalités avancées. NGINX Plus surveille les services UDP à l’aide de contrôles d’intégrité actifs, offre une visibilité essentielle grâce à une multitude de statistiques et vous permet d’ajouter et supprimer des serveurs de manière dynamique. UDP est couramment utilisé pour les protocoles légers qui ne sont pas de nature transactionnelle, tels que DNS (résolution des noms de domaine en adresses), syslog (journalisation légère) et RADIUS (protocole d’authentification). UDP s’impose également comme l’un des protocoles privilégiés pour les applications IoT en raison de ses faibles besoins en bande passante. NGINX Plus peut facilement assurer la distribution et la répartition de charge de ces applications existantes et nouvelles.
• Découverte de services à l’aide d’enregistrements DNS SRV records – Les applications basées sur des microservices sont dynamiques : les services peuvent être redimensionnés à la hausse ou à la baisse, et déplacés à la demande. Pour connaître à tout moment l’état actuel de vos services, une bonne solution consiste à utiliser la découverte de services. De nombreuses plateformes de découverte de services, telles que Consul et etcd (SkyDNS), proposent une interface DNS permettant aux clients (comme NGINX Plus) de demander des informations sur les services découverts. Le numéro de port utilisé par les services est souvent attribué dynamiquement. Par conséquent, les plateformes de découverte de services utilisent des enregistrements DNS SRV records qui incluent les informations relatives au numéro de port. NGINX Plus prend désormais en charge les enregistrements DNS SRV et peut utiliser des requêtes DNS pour interroger le registre de services afin de localiser vos services, y compris les informations sur les ports attribués dynamiquement.
• Tarification de NGINX Plus par application – Pour garantir des performances et une disponibilité maximales en période de forte croissance, de variations saisonnières ou de trafic fluctuant, de nombreuses applications nécessitent une infrastructure dynamique. Ces applications reposent aussi généralement sur des microservices ou des architectures distribuées et utilisent des conteneurs ou des machines virtuelles pour leur exécution. La facturation des logiciels par instance ou par heure-machine n’offre ni la flexibilité ni la rentabilité dont ces applications modernes ont besoin. Pour ces cas d’usage, nous lançons la tarification de NGINX Plus par application. Celle-ci permet une utilisation illimitée des fonctionnalités avancées de NGINX Plus et de ses fichiers binaires bénéficiant d’un support commercial, moyennant un tarif forfaitaire annuel par application. Quel que soit le nombre de machines virtuelles, de conteneurs, de nœuds, de connexions simultanées ou d’utilisateurs, vous payez un tarif unique avantageux pour toute l’année. Déployez NGINX Plus quand, où et comme vous le souhaitez au sein de votre infrastructure applicative, dans vos environnements de développement, de test, de préproduction, de reprise après sinistre et de production : plus besoin de vous soucier de factures imprévisibles basées sur la consommation ni d’attendre l’obtention de clés de licence lorsque vous devez augmenter soudainement vos capacités.

Fonctionnalités de NGINX Plus R9 en détail

Cette section présente en détail l’ensemble des nouvelles fonctionnalités de NGINX Plus R9.

Modules dynamiques

NGINX et NGINX Plus reposent tous deux sur une architecture modulaire. Leurs fonctionnalités de base peuvent être étendues grâce à des modules développés aussi bien par des développeurs tiers que par l’équipe d’ingénierie principale de NGINX. Ces modules ajoutent des fonctionnalités essentielles, telles que l’intégration de scripts Lua et la géolocalisation des utilisateurs à partir de leur adresse IP. Il existe plus de 100 modules tiers et plus de 60 modules NGINX officiels. Nous en incluons 56 dans le package de base nginx‑plus et 10 supplémentaires dans le package nginx‑plus‑extras (la liste complète est disponible dans les Spécifications techniques de NGINX Plus).

Avec cette version, les modules supplémentaires du paquet nginx‑plus‑extras (qu’ils soient tiers ou officiels NGINX) peuvent également être chargés dynamiquement dans le paquet NGINX Plus de base, nginx‑plus. Vous pouvez ainsi charger uniquement les modules supplémentaires dont vous avez réellement besoin.

Ces modules sont disponibles dans le dépôt NGINX Plus, auquel nous prévoyons d’ajouter d’autres modules dans les mois à venir. Nous encourageons toutes les personnes qui utilisent actuellement le paquet nginx‑plus‑extras à migrer vers le paquet principal nginx‑plus, car le paquet nginx‑plus‑extras sera abandonné dans une prochaine version.

Nous testons chaque module dynamique en le chargeant dans le cœur de NGINX Plus avant d’exécuter notre vaste gamme de tests de version. Nous pouvons ainsi nous assurer que, lorsqu’il n’est pas configuré, le module n’entrave pas le bon fonctionnement de NGINX Plus. Nous suivrons les mises à jour des modules et publierons de nouvelles versions à chaque nouvelle version de NGINX Plus, ainsi qu’en cas de signalement d’un problème de sécurité critique entre deux versions.

Grâce aux modules dynamiques, nous pouvons distribuer un seul binaire NGINX Plus intégrant les fonctionnalités utilisées par tous. Les administrateurs peuvent ensuite sélectionner les modules supplémentaires qu’ils souhaitent utiliser.

Comment charger des modules dynamiques dans NGINX Plus

Pour installer et charger dynamiquement des modules, procédez comme suit. Ces étapes supposent que vous avez configuré votre gestionnaire de paquets pour récupérer les fichiers auprès de NGINX, Inc. plutôt que depuis la distribution du fournisseur du système d’exploitation.

1. Utilisez l’outil de gestion de paquets standard de votre système d’exploitation (apt ou yum, par exemple) pour installer l’image de base nginx‑plus ainsi que les modules que vous souhaitez charger dynamiquement (répétez la commande d’installation pour chaque module). Les commandes suivantes conviennent aux systèmes basés sur Debian.

# apt-get update# apt-get install nginx-plus
# apt-get install module-name

1. Les noms que vous pouvez utiliser à la place de module‑name dans cette version sont les suivants : Le répertoire /etc/nginx/modules est créé automatiquement avec des liens symboliques vers les emplacements d’installation des fichiers .so des modules sélectionnés. Remarques :
   • nginx-plus-module-geoip
   • nginx-plus-module-headers-more
   • nginx-plus-module-image-filter
   • nginx-plus-module-lua
   • nginx-plus-module-passenger
   • nginx-plus-module-perl
   • nginx-plus-module-rtmp
   • nginx-plus-module-set-misc
   • nginx-plus-module-xslt
   • Si vous utilisez le paquet nginx‑plus‑extras avec une version antérieure de NGINX Plus, vous devez le supprimer avant d’installer le paquet nginx‑plus R9. Pour les systèmes basés sur Debian, utilisez les commandes suivantes :

# apt-get update# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name

• Certains modules ne sont pas disponibles pour certaines versions de systèmes d’exploitation en raison des limitations de ces derniers. Pour plus de détails et pour consulter la description des modules, reportez-vous aux spécifications techniques de NGINX Plus.

1. Dans le contexte principal (de niveau supérieur) de /etc/nginx/nginx.conf, ajoutez une directive load_module pour chaque module pouvant être chargé dynamiquement :

load_module modules/module-name.so;

1. Vérifiez la validité syntaxique de la nouvelle configuration et rechargez NGINX Plus.

# nginx -t && nginx -s reload

1. Les modules répertoriés dans nginx.conf sont chargés dynamiquement dans NGINX Plus.

Répartition de charge UDP

Le mois dernier, nous avons lancé l’équilibrage de charge UDP dans NGINX Open Source, et NGINX Plus R9 étend cette fonctionnalité avec des contrôles d’intégrité, une surveillance avancée de l’état et une reconfiguration à la volée.

Comme pour l’équilibrage de charge TCP, la configuration de l’équilibrage de charge UDP s’effectue dans le contexte stream. À l’instar de l’équilibrage de charge HTTP et TCP, l’équilibrage de charge UDP utilise un groupe upstream pour définir l’ensemble des serveurs d’origine qui fournissent le service basé sur UDP, ainsi que l’algorithme à utiliser pour répartir le trafic entre les serveurs.

La configuration définit également un serveur virtuel pour chaque port UDP, avec une directive « proxy_pass » qui indique le groupe en amont fournissant le service associé :

stream {    upstream dns_upstreams {
        least_time;
        server dns-server-1-ip:53;
        server dns-server-2-ip:53;
    }
 
    server {
        listen 53 udp;
        listen 53; #tcp
        proxy_pass dns_upstreams;
        proxy_timeout 1s;
        proxy_responses 1;
        error_log logs/dns.log;
    }
}

Cet exemple de configuration concerne l’équilibrage de charge des services DNS. Dans le bloc upstream, nous configurons l’algorithme Least Time afin que NGINX Plus envoie chaque requête au serveur qui compte actuellement le moins de « connexions » et répond le plus rapidement. Dans le bloc server, nous écoutons le trafic UDP et TCP, car le DNS peut utiliser ces deux protocoles. La directive proxy_responses détermine le nombre de réponses que NGINX Plus reçoit du serveur en amont avant de libérer les ressources associées à la « connexion » UDP. Le DNS étant un protocole simple de type requête-réponse, une seule réponse suffit généralement.

NGINX Open Source inclut des contrôles d’intégrité de base pour UDP. Si un serveur UDP en amont ne répond pas à une requête dans le délai défini ou renvoie une erreur ICMP, NGINX et NGINX Plus cessent de lui envoyer du trafic pendant une durée définie.

NGINX Plus R9 ajoute des contrôles d’intégrité actifs pour les services UDP, similaires à ceux utilisés pour le trafic HTTP et TCP. Vous pouvez configurer NGINX Plus pour envoyer des requêtes UDP spécifiques aux serveurs en amont et définir le type de réponse que les serveurs doivent renvoyer pour être considérés comme opérationnels. Comme UDP ne dispose pas des mécanismes de livraison fiable que TCP fournit à HTTP, les contrôles d’intégrité actifs sont encore plus essentiels pour les applications UDP que pour les applications TCP et HTTP.

Avec NGINX Plus, vous pouvez également ajouter ou supprimer à la volée des serveurs en amont. Vous pouvez ainsi facilement, par exemple, mettre des serveurs hors ligne à des fins de maintenance, puis les réintégrer au pool avec équilibrage de charge. Les nouvelles statistiques relatives à UDP dans le module Status de NGINX Plus et le tableau de bord de surveillance de l’activité en temps réel vous offrent une visibilité essentielle sur les performances de vos serveurs.

NGINX Plus R9 répartit la charge des applications simples basées sur UDP les plus couramment utilisées : DNS, RADIUS, syslog et NTP. Les protocoles UDP à longue durée de vie, tels que la voix sur IP et les autres applications basées sur SIP, ne sont pas pris en charge pour le moment.

Découverte de services à l’aide d’enregistrements DNS « SRV »

Les applications web modernes se composent de plusieurs petits composants applicatifs : serveurs web, serveurs d’applications, bases de données, etc. Un équilibreur de charge frontal tel que NGINX Plus analyse le trafic entrant, puis achemine et répartit les requêtes entre les différents composants applicatifs.

Lorsque des composants d’application sont déployés sur des plateformes virtuelles ou basées sur des conteneurs, leurs adresses IP et leurs ports peuvent être imprévisibles. La découverte de services est le processus par lequel un client local (tel que l’équilibreur de charge frontal NGINX Plus) localise ces composants afin de pouvoir leur envoyer du trafic. La découverte de services s’appuie généralement sur une « base de données de services » telle que Consul, etcd ou ZooKeeper.

Dans NGINX Plus R8, nous avons annoncé une version persistante de notre API de reconfiguration à la volée et proposé des solutions de démonstration pour Consul, etcd et ZooKeeper qui interrogent la base de données des services et transmettent les modifications de configuration à NGINX Plus. Dans NGINX Plus R9, nous sommes heureux d’annoncer la prise en charge d’une autre méthode utilisant des requêtes DNS SRV. Les requêtes DNS SRV renvoient l’adresse IP, le port, la priorité et le poids des serveurs d’applications d’un type donné.

Consul et SkyDNS pour etcd fournissent tous deux des interfaces DNS que les clients peuvent utiliser pour récupérer des enregistrements SRV. NGINX Plus obtient la configuration de l’équilibrage de charge en interrogeant directement l’interface DNS d’un service. NGINX Plus vérifie régulièrement le service, de sorte que toute modification est propagée rapidement et automatiquement.

L’exemple suivant configure NGINX Plus pour obtenir la liste des serveurs en amont de my_service via DNS. Le paramètre service=http de la directive server active la prise en charge des enregistrements DNS SRV. Les instances d’application qui assurent le fonctionnement de my_service sont désormais découvertes automatiquement par NGINX Plus.

http {     resolver dns-server-ip;
 
    upstream my_service {
        zone backend 64k;
        server hostname-for-my_service service=http resolve;
    }
 
    server {
        # ...
 
        location /my_service {
            # ...
            proxy_pass http://my_service;
        }
    }
}

Tarification de l’application NGINX Plus

La tarification par instance est un excellent moyen de débuter avec NGINX Plus. Elle constitue une solution de remplacement très économique aux équilibreurs de charge matériels, mais les utilisations potentielles de NGINX Plus vont bien au-delà du simple remplacement de matériel. Grâce à son architecture logicielle légère, NGINX Plus est idéal pour assurer l’équilibrage de charge dédié de chaque application. De plus, comme NGINX Plus repose sur NGINX Open Source, il peut également remplacer les serveurs web et applicatifs de votre application. Ces cas d’usage entraînent un nombre croissant de déploiements de NGINX Plus pour lesquels la tarification par instance n’est ni assez économique ni assez flexible.

Avec NGINX Plus R9, nous lançons un nouveau modèle de tarification par application « à volonté », qui vous permet d’exécuter autant d’instances de NGINX Plus que vous le souhaitez pour une application donnée. Déployez NGINX Plus quand, où et comme vous le souhaitez au sein de votre infrastructure applicative, dans vos environnements de développement, de test, de préproduction, de reprise après sinistre et de production. Quel que soit le nombre de machines virtuelles, de conteneurs ou de nœuds, vous payez un tarif fixe unique pour toute l’année.

Chaque abonnement comprend toutes les fonctionnalités du logiciel NGINX Plus ainsi que notre primé service d’assistance et d’aide à la configuration. De plus, en optant pour le modèle de tarification par application, vous bénéficiez des avantages suivants :

• Une assistance à l’installation et/ou à l’optimisation, selon vos besoins, assurée par les services professionnels NGINX
• Formation de votre équipe aux fondamentaux de NGINX, aux sujets avancés, ou aux deux

L’utilisation est illimitée pour chaque application. Une application désigne les composants logiciels et l’équipe qui prennent en charge une application web unique ou une application de bureau ou mobile portant un nom distinct. Les architectures basées sur des microservices et autres architectures distribuées sont prévues et prises en charge dans le cadre de ce modèle.

Un abonnement sous licence de site est également disponible, permettant une utilisation illimitée de NGINX Plus dans l’ensemble d’une organisation.

Fonctionnalités supplémentaires

NGINX Plus R9 apporte plusieurs améliorations supplémentaires, notamment :

• Améliorations des performances du cache – L’année dernière, nous avons introduit un modèle de pool de threads afin d’améliorer les opérations de lecture du cache et d’éviter qu’elles ne bloquent potentiellement le cœur de NGINX. Cela a permis de multiplier potentiellement par 9 les performances pour certaines charges de travail du cache. Dans cette version, NGINX Plus peut également confier aux threads les écritures sur disque destinées au cache.
• Requêtes DNS via TCP – Par défaut, NGINX Plus utilise UDP pour les requêtes DNS. Toutefois, lorsque les réponses DNS sont volumineuses – par exemple, lorsqu’un nom correspond à un grand nombre de serveurs –, la réponse complète peut ne pas tenir dans un seul datagramme UDP (limité à 512 octets). Une réponse incomplète est signalée comme tronquée, et NGINX Plus relance désormais immédiatement la requête via TCP. NGINX Plus prend ainsi mieux en charge les déploiements de serveurs dynamiques de très grande envergure.
• Nouvelle tentative des requêtes non idempotentes – Lorsqu’une requête HTTP échoue en raison d’une erreur ou d’un dépassement de délai, NGINX Plus la réessaie automatiquement par défaut auprès d’un autre serveur du groupe en amont. Vous pouvez utiliser la directive proxy_next_upstream pour définir les types d’erreurs pour lesquels NGINX Plus réitère les requêtes, notamment certains codes de réponse 4xx ou 5xx. Par convention, les requêtes POST ne font généralement pas l’objet d’une nouvelle tentative, car les données du corps sont transmises en continu au serveur et ne peuvent pas être renvoyées en cas de défaillance de celui-ci. Toutefois, dans certaines circonstances de défaillance, les versions antérieures de NGINX Plus réessayaient les requêtes POST, ce qui était contraire au principe selon lequel elles ne doivent pas être réessayées puisqu’elles ne sont pas idempotentes. NGINX Plus ne réessaie désormais plus automatiquement les requêtes HTTP non idempotentes ayant échoué (POST, LOCK et PATCH). Pour rétablir le comportement précédent et permettre à NGINX Plus de réessayer, lorsque cela est possible, les requêtes non idempotentes ayant échoué, ajoutez le nouveau paramètre non_idempotent à la directive proxy_next_upstream.

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 9 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 auprès du support.

Si vous n’avez pas encore essayé NGINX Plus, nous vous invitons à le découvrir pour accélérer vos sites web, équilibrer la charge et assurer la mise à disposition de vos applications, ou pour l’utiliser comme serveur web entièrement pris en charge, doté d’une API permettant d’améliorer la surveillance et la reconfiguration dynamique. Commencez dès aujourd’hui avec un essai gratuit de 30 jours et constatez par vous-même comment NGINX Plus peut vous aider à déployer vos applications et à les faire évoluer.

Note de la rédaction – Pour en savoir plus sur les principales nouveautés de NGINX Plus R9, consultez les ressources connexes suivantes.

• Répartition de charge du trafic DNS avec NGINX et NGINX Plus
• Utiliser le DNS pour la découverte de services avec NGINX et NGINX Plus
• Découverte de services pour NGINX Plus à l’aide d’enregistrements DNS SRV de Consul
• Nouveautés de NGINX Plus R9 (webinaire à la demande)

À propos de l’auteur

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett