BLOG | NGINX

Annonce de NGINX Plus R12

NGINX-Partie-de-F5-horiz-black-type-RGB
Vignette d'Owen Garrett
Owen Garrett
Publié le 14 mars 2017

[Éditeur – Ce message a été mis à jour pour faire référence à l’ API NGINX Plus , qui remplace et déprécie les modules de configuration et d’état dynamiques distincts décrits dans la version originale du message.]

Aujourd'hui, nous sommes heureux d'annoncer que NGINX Plus R12 est disponible en tant que mise à niveau gratuite pour tous les abonnés NGINX Plus. NGINX Plus est une plate-forme de diffusion d'applications logicielles hautes performances qui comprend un équilibreur de charge, un cache de contenu et un serveur Web. NGINX Plus R12 est une version importante avec de nouvelles fonctionnalités axées sur le clustering, la personnalisation et la surveillance.

Pour en savoir plus sur NGINX Plus R12, regardez notre webinaire à la demande .

Les utilisateurs d’entreprise bénéficieront de la nouvelle fonctionnalité de clustering, qui simplifie le processus de gestion des clusters hautement disponibles des serveurs NGINX Plus. Tous les utilisateurs bénéficieront du support officiel de nginScript, un langage de script léger et hautes performances intégré directement dans la configuration NGINX. Les améliorations apportées à la surveillance et à l’instrumentation, à la mise en cache et aux contrôles de santé améliorent la fiabilité et les performances des applications.

D’autres améliorations fournissent l’authentification par certificat client pour les services TCP, la possibilité d’inspecter les champs personnalisés dans les JWT OAuth, la prise en charge du format WebP dans le module Image-Filter et un certain nombre d’améliorations des performances et de la stabilité.

Nous encourageons tous les abonnés à effectuer immédiatement la mise à jour vers NGINX Plus R12 pour profiter des améliorations de performances, de fonctionnalités et de fiabilité de cette version. Avant d’effectuer la mise à jour, assurez-vous de vérifier les modifications de comportement répertoriées dans la section suivante.

Changements de comportement

NGINX Plus R12 introduit quelques modifications au comportement par défaut et aux composants internes de NGINX Plus dont vous devez être conscient lors de la mise à niveau :

  • Format des métadonnées du cache – Le format de l’en-tête des métadonnées du cache interne a changé. Lorsque vous effectuez une mise à niveau vers NGINX Plus R12, le cache sur disque devient invalide et NGINX Plus actualise automatiquement le cache selon les besoins. Les anciennes entrées de cache sont automatiquement supprimées.
  • Variables SSL « DN » – Le format des variables $ssl_client_s_dn et $ssl_client_i_dn a changé. La virgule ( , ) sert désormais de séparateur de champ au lieu de la barre oblique ( / ) et est échappée conformément aux RFC2253 et4514 . Pour continuer à utiliser le format X509_NAME_oneline avec le séparateur de champ barre oblique, utilisez les variables $ssl_client_s_dn_legacy et $ssl_client_i_dn_legacy .
  • File d'attente de connexions maximales – La directive queue indique à NGINX Plus de mettre en file d'attente les connexions aux serveurs en amont s'ils sont surchargés . En raison des optimisations de mémoire et de performances dans R12, la directive queue doit désormais apparaître dans le bloc en amont sous la directive qui spécifie l'algorithme d'équilibrage de charge ( hash , ip_hash , least_conn ou least_time ).
  • Modules dynamiques tiers – Des modules dynamiques créés ou certifiés par NGINX, Inc. sont fournis dans notre référentiel. Tous les modules tiers doivent être recompilés avec la version 1.11.10 de NGINX Open Source pour continuer à fonctionner avec NGINX Plus R12. Veuillez vous référer au Guide d'administration NGINX Plus pour plus d'informations.
  • Version finale pour les versions de système d'exploitation en fin de vie – Ubuntu a annoncé la fin de vie d' Ubuntu 12.04 LTS et Red Hat a annoncé la fin de vie de la prise en charge de la phase de production de Red Hat Enterprise Linux 5.10+ , toutes deux effectives le 31 mars 2017. NGINX Plus R12 est la dernière version qui inclura des packages pour ces versions de système d'exploitation, ainsi que CentOS 5.10+ et Oracle Linux 5.10+, et prendra en charge ces versions. Pour continuer à recevoir des mises à jour et de l'assistance après NGINX Plus R12, effectuez une mise à jour vers une version du système d'exploitation prise en charge.

Caractéristiques détaillées de NGINX Plus R12

Partage de configuration

Les serveurs NGINX Plus sont souvent déployés dans un cluster de deux instances ou plus à des fins de haute disponibilité et d'évolutivité. Cela vous permet d'améliorer la fiabilité de vos services en les isolant de l'impact d'une panne de serveur, et également de les faire évoluer et de gérer de gros volumes de trafic.

NGINX Plus propose déjà un moyen pris en charge pour distribuer le trafic sur un cluster, de manière active-passive ou active-active . NGINX Plus R12 ajoute une autre méthode prise en charge pour synchroniser la configuration sur un cluster. Cette fonctionnalité de synchronisation de configuration permet à un administrateur de configurer un « cluster » de serveurs NGINX Plus à partir d’un seul emplacement. Ces serveurs partagent un sous-ensemble commun de leur configuration.

La configuration NGINX Plus est poussée du primaire vers les homologues

Voici comment synchroniser la configuration :

  1. Nommez un ou plusieurs nœuds « primaires » dans le cluster.
  2. Installez le nouveau package nginx-sync sur les nœuds principaux.
  3. Appliquer les modifications de configuration à un nœud principal.

  4. Appelez le processus de synchronisation de configuration, nginx-sync.sh , qui est inclus dans le package nginx-sync , pour mettre à jour chacun des autres serveurs du cluster (les homologues ). Le processus de synchronisation exécute ces étapes sur chaque homologue :

    1. Envoie la configuration mise à jour au pair via ssh ou rsync .
    2. Vérifie que la configuration est valide pour l'homologue et la restaure si ce n'est pas le cas.
    3. Applique la configuration si elle est valide et recharge les serveurs NGINX Plus sur le pair.

Cette capacité est particulièrement utile lorsque NGINX Plus est déployé dans une paire de serveurs tolérants aux pannes (ou un plus grand nombre). Vous pouvez utiliser cette méthode pour simplifier le déploiement fiable de la configuration au sein d'un cluster ou pour transférer la configuration d'un serveur intermédiaire vers un cluster de serveurs de production.

Pour des instructions détaillées, consultez le Guide d'administration NGINX Plus .

Disponibilité générale du module JavaScript NGINX

Avec NGINX Plus R12, nous sommes heureux d'annoncer que le module JavaScript NGINX est désormais disponible en tant que module stable pour NGINX Open Source et NGINX Plus. [Le module s'appelait auparavant nginScript et cet article utilise les noms de manière interchangeable.] nginScript est entièrement pris en charge pour les abonnés NGINX Plus.

nginScript est une implémentation JavaScript unique <.htmla> pour NGINX et NGINX Plus, conçue spécifiquement pour les cas d'utilisation côté serveur et le traitement par requête. Il vous permet d'étendre la syntaxe de configuration NGINX Plus avec du code JavaScript afin de mettre en œuvre des solutions de configuration sophistiquées.

Avec nginScript, vous pouvez enregistrer des variables personnalisées à l’aide d’une logique complexe, contrôler la sélection en amont, implémenter des algorithmes d’équilibrage de charge, personnaliser la persistance des sessions et même implémenter des services Web simples. Nous publierons des instructions complètes pour certaines de ces solutions sur notre blog dans les prochaines semaines, et nous ajouterons des liens vers elles ici dès qu'elles seront disponibles.

Plus précisément, NGINX Plus R12 inclut les améliorations suivantes :

  • Phase de prélecture dans le module Stream
  • Méthodes et constantes mathématiques ECMAScript 6
  • Méthodes de chaîne supplémentaires telles que endsWith , includes , repeat , startsWith et trim
  • Portées

Bien que nginScript soit stable, le travail continue pour prendre en charge encore plus de cas d'utilisation et de couverture du langage JavaScript. Pour en savoir plus, consultez Exploiter la puissance et la commodité de JavaScript pour chaque requête avec le module JavaScript NGINX<.htmla> sur notre blog.

Nouvelles statistiques

La surveillance et l’instrumentation dans NGINX Plus constituent une valeur ajoutée importante qui vous donne un aperçu approfondi des performances et du comportement de NGINX Plus et des applications en amont. Les statistiques sont fournies à la fois via notre tableau de bord graphique intégré et au format JSON qui peut être exporté vers votre outil de surveillance préféré.

Le tableau de bord de surveillance des activités en direct de NGINX Plus avec les mises à jour de la version 12
Le tableau de bord de surveillance des activités en direct est mis à jour pour NGINX Plus R12

NGINX Plus R12 ajoute un certain nombre d'améliorations : plus d'informations sur les performances (temps de réponse) des serveurs à charge équilibrée, des informations sur le fonctionnement des services TCP et UDP, et une gamme de données internes qui aident au dépannage pour identifier les problèmes et régler NGINX Plus pour optimiser les performances.

Les nouvelles statistiques de NGINX Plus R12 incluent :

  • Temps de réponse du serveur en amont – Dans NGINX Plus R11 et les versions antérieures, le temps de réponse des serveurs en amont était calculé uniquement lorsque l’algorithme d’équilibrage de charge Least Time était utilisé. À partir de NGINX Plus R12, le temps de réponse est mesuré pour tous les algorithmes et signalé à la fois dans les données JSON et sur le tableau de bord intégré.
  • Codes de réponse pour les connexions TCP/UDP en amont dans le tableau de bord graphique – Le module Stream pour l'équilibrage de charge TCP/UDP génère des pseudo-codes d'état pour identifier comment une connexion a été fermée (200 signifie « succès »,502 signifie « indisponible en amont », etc.), en les signalant dans la variable $status . NGINX Plus R12 ajoute une série de colonnes au tableau de bord pour afficher le nombre de codes de réponse pour les serveurs virtuels TCP et UDP, comme ceux déjà fournis pour les serveurs virtuels HTTP. Les pseudo-codes d’état peuvent également être enregistrés pour être intégrés aux outils d’analyse de journaux existants.
  • Informations sur la version de NGINX Plus – Pour faciliter le dépannage, les données JSON indiquent désormais le numéro de version de NGINX Plus sous la forme nginx_build (par exemple, nginx-plus-r12 ) ainsi que le numéro de version NGINX Open Source sous la forme nginx_version (par exemple,1.11.10 ). Le tableau de bord affiche les deux valeurs dans la case supérieure gauche de l’onglet principal.

  • Nom d’hôte en amont – Dans les données JSON, le champ serveur identifie un serveur dans un groupe en amont par adresse IP et port. Le nouveau champ de nom signale le premier paramètre à la directive serveur dans le bloc de configuration en amont , qui peut être un nom de domaine ou un chemin de socket de domaine UNIX ainsi qu'une adresse IP et un port. Sur le tableau de bord, la colonne Nom la plus à gauche des onglets Upstreams et TCP/UDP Upstreams indique désormais la valeur du champ nom au lieu du champ serveur (qui était signalé dans NGINX Plus R11 et versions antérieures).

    La nouvelle métrique facilite la corrélation des données JSON et du tableau de bord avec vos serveurs en amont si vous les définissez à l'aide de noms DNS, en particulier des noms qui se résolvent en plusieurs adresses IP.

  • Utilisation de la zone de mémoire partagée dans les données d'état étendues – Les zones de mémoire partagée sont configurées avec une taille fixe et il peut être difficile de sélectionner une taille qui n'est ni trop grande (la mémoire est allouée mais jamais utilisée) ni trop petite (la mémoire est épuisée et les éléments mis en cache sont supprimés).

    La nouvelle instrumentation dans les métriques fournit un rapport interne détaillé de l'utilisation de la mémoire de chaque zone partagée, vous permettant de surveiller l'utilisation de la mémoire et le support technique NGINX pour fournir des conseils plus éclairés sur l'optimisation de la configuration NGINX.

  • Échappement conforme à JSON dans le journal d’accès NGINX Plus – Certains outils d’analyse de journaux modernes peuvent ingérer efficacement des fichiers journaux au format JSON et sont capables d’extraire des informations plus facilement qu’à partir de fichiers journaux non formatés. Vous pouvez définir un modèle JSON dans la directive standard NGINX Plus log_format , et le nouveau paramètre d'échappement facultatif de la directive applique l'échappement conforme à JSON afin que les lignes de journal soient correctement formatées.

Pour plus d'informations, voir Surveillance des activités en direct .

Mise en cache améliorée

NGINX Plus R12 améliore considérablement le moteur de mise en cache NGINX Plus.

Proposer du contenu obsolète lors de la mise à jour

NGINX Plus R12 ajoute la prise en charge des extensions Cache-Control définies dans la RFC 5861 , stale-while-revalidate et stale-if-error . Vous pouvez désormais configurer NGINX Plus pour respecter ces extensions Cache-Control et continuer à servir les ressources expirées à partir du cache tout en les actualisant en arrière-plan, sans ajouter de latence à la demande du client. De même, NGINX Plus peut servir des ressources expirées à partir du cache si le serveur en amont n’est pas disponible – une technique permettant d’implémenter des modèles de disjoncteur dans les applications de microservices.

À moins qu'il ne soit configuré pour ignorer l'en-tête Cache-Control , NGINX Plus respecte les temporisateurs obsolètes des serveurs d'origine qui renvoient des en-têtes Cache-Control conformes à la RFC 5861, comme dans cet exemple :

Contrôle du cache : max-age=3600 stale-while-revalidate=120 stale-if-error=900

Pour activer la prise en charge des extensions Cache-Control avec actualisation en arrière-plan, incluez les directives en surbrillance :

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { # ... location / { proxy_cache my_cache; # Diffuser du contenu obsolète lors de la mise à jour proxy_cache_use_stale editing ; # De plus, ne bloquez pas la première requête qui déclenche la mise à jour # et effectuez la mise à jour en arrière-plan proxy_cache_background_update on ; proxy_pass http://my_upstream; } }

La directive de mise à jour proxy_cache_use_stale indique à NGINX Plus de diffuser la version obsolète du contenu pendant sa mise à jour. Si vous incluez uniquement cette directive, le premier utilisateur à demander du contenu obsolète paie la pénalité « cache miss » – c'est-à-dire qu'il ne reçoit pas le contenu tant que NGINX Plus ne l'a pas récupéré auprès du serveur d'origine et ne l'a pas mis en cache. Les utilisateurs qui demandent ultérieurement le contenu obsolète pendant qu'il est en cours de mise à jour l'obtiennent immédiatement à partir du cache, tandis que le premier utilisateur n'obtient rien jusqu'à ce que le contenu mis à jour soit récupéré et mis en cache.

Avec la nouvelle directive proxy_cache_background_update , tous les utilisateurs, y compris le premier utilisateur, reçoivent le contenu obsolète pendant que NGINX Plus l'actualise en arrière-plan.

La nouvelle fonctionnalité est également disponible dans les modules FastCGI , SCGI et uwsgi .

Demandes de plage d'octets

Une amélioration supplémentaire du moteur de mise en cache permet à NGINX Plus de contourner le cache pour les demandes de plage d’octets qui démarrent plus d’un nombre configuré d’octets après le début d’un fichier non mis en cache. Cela signifie que pour les fichiers volumineux tels que le contenu vidéo, les demandes d'une plage d'octets profondément dans le fichier n'ajoutent pas de latence à la demande du client. Dans les versions antérieures de NGINX Plus, le client ne recevait pas la plage d’octets demandée tant que NGINX Plus n’avait pas récupéré tout le contenu du début du fichier jusqu’à la plage d’octets demandée et l’avait écrit dans le cache.

La nouvelle directive proxy_cache_max_range_offset spécifie le décalage à partir du début du fichier au-delà duquel NGINX Plus transmet une demande de plage d'octets directement au serveur d'origine et ne met pas en cache la réponse. (La nouvelle fonctionnalité est également disponible dans les modules FastCGI , SCGI et uwsgi .)

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off; server { location / { proxy_cache my_cache; # Contourner le cache pour les requêtes de plage d'octets au-delà de 10 mégaoctets proxy_cache_max_range_offset 10m ; proxy_pass http://my_upstream; } }

Ces améliorations renforcent encore davantage la position de NGINX Plus en tant que moteur de mise en cache hautes performances et conforme aux normes, adapté à n’importe quel environnement, de l’accélération de la diffusion d’applications à la création de réseaux de diffusion de contenu (CDN) à part entière.

Contrôles de santé améliorés

NGINX Plus R12 améliore encore les capacités de contrôle de santé actif de NGINX Plus.

Vérification de l'état de santé des serveurs nouvellement ajoutés

Avec l’adoption croissante des environnements conteneurisés et des groupes d’applications mis à l’échelle automatiquement, il est essentiel que l’équilibreur de charge implémente des contrôles de santé proactifs au niveau de l’application et laisse aux nouveaux serveurs le temps d’initialiser les ressources internes avant d’être opérationnels.

Avant NGINX Plus R12, lorsque vous ajoutiez un nouveau serveur au pool d’équilibrage de charge (à l’aide de l’ API NGINX Plus ou du DNS), NGINX Plus le considérait immédiatement comme sain et lui envoyait immédiatement du trafic. Lorsque vous incluez le nouveau paramètre obligatoire dans la directive health_check ( HTTP ou TCP/UDP ), le nouveau serveur doit réussir le contrôle de santé configuré avant que NGINX Plus ne lui envoie du trafic. Associé à la fonctionnalité de démarrage lent , le nouveau paramètre donne aux nouveaux serveurs encore plus de temps pour se connecter aux bases de données et « se réchauffer » avant d’être invités à gérer l’intégralité de leur part de trafic.

en amont mon_en_amont { zone mon_en_amont 64k; serveur backend1.exemple.com slow_start=30s ; } serveur { emplacement / { proxy_pass http://mon_en_amont; # Exiger que le nouveau serveur réussisse le contrôle d'intégrité avant de recevoir du trafic contrôle_d'intégrité obligatoire ; } }

Ici, le paramètre obligatoire de la directive health_check et le paramètre slow_start de la directive serveur ( HTTP ou TCP/UDP ) sont tous deux inclus. Les serveurs ajoutés au groupe en amont à l'aide des interfaces API ou DNS sont marqués comme non sains et ne reçoivent aucun trafic jusqu'à ce qu'ils passent le contrôle de santé ; à ce stade, ils commencent à recevoir une quantité de trafic progressivement croissante sur une période de 30 secondes.

Vérification de l'état UDP sans configuration

Il est tout aussi important d’implémenter des contrôles de santé au niveau de l’application pour les serveurs UDP que pour les serveurs HTTP et TCP, afin que le trafic de production ne soit pas envoyé vers des serveurs qui ne sont pas entièrement fonctionnels. NGINX Plus prend en charge les contrôles de santé actifs pour UDP, mais avant NGINX Plus R12, vous deviez créer un bloc de correspondance qui définissait les données à envoyer et la réponse à attendre . Il peut être difficile de déterminer les valeurs appropriées lors de l’utilisation de protocoles binaires ou de protocoles comportant des poignées de main complexes. Pour de telles applications, NGINX Plus R12 prend désormais en charge un contrôle de santé « zéro configuration » pour UDP qui teste la disponibilité de l'application sans vous obliger à définir des chaînes d'envoi et d'attente. Ajoutez le paramètre udp à la directive health_check pour une vérification de l’état UDP de base.

upstream udp_app { server backend1.example.com:1234; server backend2.example.com:1234; } server { listen 1234 udp; proxy_pass udp_app; # Vérification de l'état de santé UDP de base health_check udp ; }

Mises à jour SSL – Certificats clients pour les services TCP, variables mises à jour

Les certificats clients SSL sont couramment utilisés pour authentifier les utilisateurs sur des sites Web protégés. NGINX Plus R12 ajoute la prise en charge de l’authentification pour les services TCP protégés par SSL à la prise en charge HTTP existante. Ceci est généralement utilisé pour l’authentification de machine à machine, par opposition à la connexion de l’utilisateur final, et vous permet d’utiliser NGINX Plus pour la terminaison SSL et l’authentification client lors de l’équilibrage de charge des protocoles de couche 4. Les exemples incluent l’authentification des appareils IoT pour la communication avec le protocole MQTT.

La variable $ssl_client_verify inclut désormais des informations supplémentaires pour les événements d’authentification client ayant échoué. Cela inclut des raisons telles que les certificats « révoqués » et « expirés ».

Le format des variables $ssl_client_i_dn et $ssl_client_s_dn a été modifié pour se conformer aux RFC2253 et4514 . Pour plus de détails, voir Changements de comportement .

Validation JWT améliorée

NGINX Plus R10 a introduit la prise en charge native du jeton Web JSON (JWT) pour les cas d'utilisation OAuth 2.0 et OpenID Connect . L’un des principaux cas d’utilisation est que NGINX Plus valide un JWT, inspecte les champs qu’il contient et les transmet à l’application backend sous forme d’en-têtes HTTP. Cela permet aux applications de participer facilement à un environnement d’authentification unique (SSO) OAuth 2.0 en déchargeant la validation du jeton sur NGINX Plus et en consommant l’identité de l’utilisateur en lisant les en-têtes HTTP.

NGINX Plus R10 et versions ultérieures peuvent inspecter les champs définis dans la spécification JWT. NGINX Plus R12 étend la prise en charge de JWT afin que n'importe quel champ d'un JWT (y compris les champs personnalisés) puisse être accessible en tant que variable NGINX et donc proxy, enregistré ou utilisé pour prendre des décisions d'autorisation.

Mettre à niveau ou essayer NGINX Plus

Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à niveau vers la version 12 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 vous référer aux changements de comportement décrits ci-dessus 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 une API pour une surveillance et une gestion de configuration 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.

Lire plus d'articles de blog sur F5 NGINX ›

« Cet article de blog peut faire référence à des produits qui ne sont plus disponibles et/ou qui ne sont plus pris en charge. Pour obtenir les informations les plus récentes sur les produits et solutions F5 NGINX disponibles, explorez notre famille de produits NGINX . NGINX fait désormais partie de F5. Tous les liens NGINX.com précédents redirigeront vers un contenu NGINX similaire sur F5.com."