Annonce de NGINX Plus R12

Owen GarrettDirecteur senior de la gestion des produits

[Note de la rédaction – Cet article a été mis à jour pour faire référence à l’API NGINX Plus, qui remplace et rend obsolètes les modules distincts de configuration dynamique et d’état abordés dans la version originale de l’article.]

Nous avons le plaisir d’annoncer aujourd’hui que NGINX Plus R12 est disponible sous forme de mise à niveau gratuite pour tous les abonnés à NGINX Plus. NGINX Plus est une plateforme logicielle haute performance de mise à disposition d’applications qui comprend un équilibreur de charge, un cache de contenu et un serveur Web. NGINX Plus R12 est une version majeure qui propose de nouvelles fonctionnalités axées sur la mise en cluster, la personnalisation et la supervision.

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

Les utilisateurs en entreprise bénéficieront de la nouvelle fonctionnalité de clustering, qui simplifie la gestion des clusters de serveurs NGINX Plus à haute disponibilité. Tous les utilisateurs bénéficieront de la prise en charge officielle de nginScript, un langage de script léger et performant directement intégré à la configuration de NGINX. Les améliorations apportées à la surveillance et à l’instrumentation, à la mise en cache et aux contrôles d’intégrité renforcent la fiabilité et les performances des applications.

• Partage de configuration – Un script de partage de configuration pris en charge vous permet de déployer de manière fiable la configuration d’une instance NGINX Plus principale vers un ensemble d’instances homologues. Le processus effectue des sauvegardes et vérifie que la configuration est valide sur chaque instance distante avant de l’appliquer et de recharger le processus nginx.
• Disponibilité générale du module JavaScript NGINX – Le module JavaScript NGINX<.htmla> vous permet de créer des solutions sophistiquées de gestion du trafic avec NGINX Plus en utilisant la syntaxe JavaScript bien connue. [Le module s’appelait auparavant nginScript et cet article utilise les deux noms indifféremment.] Du code JavaScript peut être intégré à la configuration de NGINX Plus afin d’effectuer des actions personnalisées sur le trafic HTTP, TCP et UDP.
• Nouvelles statistiques – La visibilité est essentielle pour garantir le bon fonctionnement et les performances élevées des applications. NGINX Plus R12 offre une meilleure visibilité sur les performances des applications grâce à des métriques supplémentaires, notamment les temps de réponse des serveurs, l’utilisation des zones de mémoire partagée et les codes d’erreur des services TCP/UDP. Consultez les nouvelles statistiques dans le tableau de bord intégré de surveillance de l’activité en temps réel, ou exportez-les au format JSON vers votre outil de surveillance préféré.
• Mise en cache améliorée – Améliorez encore davantage les performances de votre cache. NGINX Plus R12 prend en charge les extensions de cache stale-while-revalidate et stale-if-error définies dans la RFC 5861. La revalidation du cache peut être effectuée en arrière-plan afin que les utilisateurs n’aient pas à attendre la fin de l’aller-retour vers le serveur d’origine.
• Améliorations des contrôles d’intégrité – Lorsque de nouveaux serveurs sont ajoutés à un pool d’équilibrage de charge via l’API NGINX Plus ou le DNS, NGINX Plus peut attendre qu’ils réussissent le contrôle d’intégrité périodique configuré avant de leur envoyer du trafic, puis appliquer la fonctionnalité de démarrage progressif afin d’augmenter graduellement le trafic qui leur est destiné. En outre, un nouveau contrôle d’intégrité simplifié pour UDP facilite le déploiement de services UDP fiables auprès de vos utilisateurs.

D’autres améliorations permettent l’authentification par certificat client pour les services TCP, l’inspection des champs personnalisés dans les JWT OAuth, la prise en charge du format WebP dans le module Image-Filter, ainsi que diverses améliorations des performances et de la stabilité.

Nous encourageons tous les abonnés à passer sans attendre à NGINX Plus R12 afin de bénéficier des améliorations apportées aux performances, aux fonctionnalités et à la fiabilité dans cette version. Avant d’effectuer la mise à jour, veillez à consulter les changements de comportement répertoriés dans la section suivante.

Modifications du comportement

NGINX Plus R12 apporte quelques modifications au comportement par défaut et au fonctionnement interne de NGINX Plus dont vous devez tenir compte lors de la mise à niveau :

• Format des métadonnées du cache – Le format de l’en-tête interne des métadonnées du cache a changé. Lors de la mise à niveau vers NGINX Plus R12, le cache sur disque devient non valide et NGINX Plus l’actualise automatiquement selon les besoins. Les anciennes entrées du cache sont automatiquement supprimées.
• Variables « DN » SSL – Le format des variables $ssl_client_s_dn et $ssl_client_i_dn a changé. La virgule ( , ) sert désormais de séparateur de champs à la place de la barre oblique ( / ) et est échappée conformément aux RFC 2253 et 4514. Pour continuer à utiliser le format X509_NAME_oneline avec la barre oblique comme séparateur de champs, utilisez les variables $ssl_client_s_dn_legacy et $ssl_client_i_dn_legacy.
• File d’attente des connexions maximales – La directive queue indique à NGINX Plus de mettre en file d’attente les connexions aux serveurs en amont lorsqu’ils sont surchargés. À la suite des optimisations de la mémoire et des performances apportées dans R12, la directive queue doit désormais figurer dans le bloc upstream après la directive qui spécifie l’algorithme d’équilibrage de charge (hash, ip_hash, least_conn ou least_time).
• Modules dynamiques tiers – Les modules dynamiques développés ou certifiés par NGINX, Inc. sont disponibles dans notre dépôt. Tous les modules tiers doivent être recompilés avec NGINX Open Source version 1.11.10 pour continuer à fonctionner avec NGINX Plus R12. Pour plus d’informations, consultez le Guide d’administration de NGINX Plus.
• Dernière version pour les systèmes 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 la phase de support en production de Red Hat Enterprise Linux 5.10+, toutes deux prenant effet le 31 mars 2017. NGINX Plus R12 est la dernière version à inclure des paquets pour ces versions de systèmes d’exploitation et à les prendre en charge, ainsi que CentOS 5.10+ et Oracle Linux 5.10+. Pour continuer à recevoir des mises à jour et une assistance après NGINX Plus R12, passez à une version de système d’exploitation prise en charge.

Fonctionnalités de NGINX Plus R12 en détail

Partage de configuration

Les serveurs NGINX Plus sont souvent déployés dans un cluster de deux instances ou plus afin d’assurer une haute disponibilité et une grande évolutivité. Cela vous permet d’améliorer la fiabilité de vos services en les protégeant des conséquences d’une défaillance de serveur, mais aussi d’effectuer une mise à l’échelle horizontale pour gérer d’importants volumes de trafic.

NGINX Plus propose déjà une méthode prise en charge pour répartir le trafic au sein d’un cluster selon un mode actif-passif ou actif-actif. NGINX Plus R12 ajoute une autre méthode prise en charge pour synchroniser la configuration au sein d’un cluster. Cette fonctionnalité de synchronisation de la configuration permet à un administrateur de configurer un « cluster » de serveurs NGINX Plus depuis un emplacement unique. Ces serveurs partagent un sous-ensemble commun de leur configuration.

La configuration de NGINX Plus est transmise du serveur principal aux serveurs homologues

Voici comment synchroniser la configuration :

1. Désignez un ou plusieurs nœuds « principaux » dans le cluster.
2. Installez le nouveau paquet nginx-sync sur les nœuds principaux.
3. Appliquez les modifications de configuration à un nœud principal.
4. Lancez le processus de synchronisation de la configuration, « nginx-sync.sh », inclus dans le paquet nginx-sync, afin de mettre à jour chacun des autres serveurs du cluster (les pairs). Le processus de synchronisation effectue les étapes suivantes sur chaque pair :
   1. Envoie la configuration mise à jour au pair via ssh ou rsync.
   2. Vérifie que la configuration est valide pour le pair et, dans le cas contraire, rétablit la configuration précédente.
   3. Applique la configuration si elle est valide, puis recharge les serveurs NGINX Plus sur le pair.

Cette fonctionnalité est particulièrement utile lorsque NGINX Plus est déployé sur une paire de serveurs tolérants aux pannes (ou sur un plus grand nombre de serveurs). 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 de préproduction vers un cluster de serveurs de production.

Pour obtenir des instructions détaillées, consultez le guide d’administration de NGINX Plus.

Disponibilité générale du module JavaScript NGINX

Avec NGINX Plus R12, nous avons le plaisir d’annoncer que le module JavaScript NGINX est désormais disponible pour tous en tant que module stable pour NGINX Open Source et NGINX Plus. [Le module s’appelait auparavant nginScript et cet article utilise les deux noms indifféremment.] nginScript bénéficie d’une prise en charge complète 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 de chaque requête. Elle vous permet d’étendre la syntaxe de configuration de NGINX Plus avec du code JavaScript afin de mettre en œuvre des solutions de configuration sophistiquées.

Avec nginScript, vous pouvez consigner des variables personnalisées à l’aide d’une logique complexe, contrôler la sélection des serveurs en amont, mettre en œuvre des algorithmes d’équilibrage de charge, personnaliser la persistance des sessions et même créer des services web simples. Au cours des prochaines semaines, nous publierons sur notre blog des instructions détaillées pour certaines de ces solutions et ajouterons ici les liens correspondants dès qu’ils seront disponibles.

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

• Phase de prélecture dans le module Stream
• Méthodes et constantes Math d’ECMAScript 6
• Méthodes supplémentaires de String telles que endsWith, includes, repeat, startsWith et trim
• Portées

Bien que nginScript soit stable, les travaux se poursuivent afin de prendre en charge encore davantage de cas d’usage et de fonctionnalités du langage JavaScript. Pour en savoir plus, consultez Exploiter la puissance et la simplicité de JavaScript pour chaque requête grâce au module JavaScript de NGINX<.htmla> sur notre blog.

Nouvelles statistiques

Les fonctionnalités de surveillance et d’instrumentation de NGINX Plus constituent une importante valeur ajoutée, car elles vous offrent une visibilité approfondie sur les performances et le comportement de NGINX Plus et des applications en amont. Les statistiques sont disponibles à la fois dans 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 de l’activité en temps réel est mis à jour pour NGINX Plus R12

NGINX Plus R12 apporte plusieurs améliorations : davantage d’informations sur les performances (temps de réponse) des serveurs à charge répartie, une meilleure visibilité sur le fonctionnement des services TCP et UDP, ainsi qu’un ensemble de données internes facilitant le dépannage, l’identification des problèmes et le réglage de NGINX Plus afin d’optimiser les performances.

Les nouvelles statistiques de NGINX Plus R12 comprennent :

• Temps de réponse des serveurs 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 indiqué à la fois dans les données JSON et sur le tableau de bord intégré.
• Codes de réponse des serveurs en amont TCP/UDP dans le tableau de bord graphique – Le module Stream d’équilibrage de charge TCP/UDP génère des pseudo-codes d’état permettant d’identifier la manière dont une connexion a été fermée (200 signifie « succès », 502 signifie « serveur en amont indisponible », etc.) et les transmet dans la variable $status. NGINX Plus R12 ajoute au tableau de bord une série de colonnes affichant le nombre de codes de réponse pour les serveurs virtuels TCP et UDP, à l’instar de celles déjà disponibles pour les serveurs virtuels HTTP. Les pseudo-codes d’état peuvent également être consignés dans les journaux afin de permettre leur intégration 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 de NGINX Open Source sous la forme nginx_version (par exemple, 1.11.10). Le tableau de bord affiche ces deux valeurs dans l’encadré situé en haut à gauche de l’onglet principal.
• Nom d’hôte du serveur en amont – Dans les données JSON, le champ server identifie un serveur d’un groupe en amont par son adresse IP et son port. Le nouveau champ name indique le premier paramètre de la directive server dans le bloc de configuration upstream, qui peut être un nom de domaine ou le chemin d’un socket de domaine UNIX, ainsi qu’une adresse IP et un port. Dans le tableau de bord, la colonne Nom située tout à gauche dans les onglets Serveurs en amont et Serveurs TCP/UDP en amont affiche désormais la valeur du champ name au lieu de celle du champ server (qui était affichée dans NGINX Plus R11 et les versions antérieures). La nouvelle métrique facilite la mise en correspondance des données JSON et du tableau de bord avec vos serveurs en amont lorsque vous les définissez à l’aide de noms DNS, en particulier lorsque ces noms correspondent à plusieurs adresses IP.
• Utilisation des zones 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 choisir une taille qui ne soit ni trop grande (de 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). De nouveaux instruments de mesure fournissent un rapport interne détaillé sur l’utilisation de la mémoire de chaque zone partagée, ce qui vous permet de surveiller cette utilisation et aide le support technique de NGINX à vous conseiller de manière plus éclairée sur l’optimisation de la configuration de NGINX.
• Échappement conforme à JSON dans le journal d’accès de NGINX Plus – Certains outils modernes d’analyse des journaux peuvent traiter efficacement les fichiers journaux au format JSON et en tirer plus facilement des informations qu’à partir de fichiers journaux non structurés. Vous pouvez définir un modèle JSON dans la directive standard log_format de NGINX Plus. Le nouveau paramètre facultatif escape de cette directive applique un échappement conforme à JSON afin que les lignes du journal soient correctement formatées.

Pour plus d’informations, consultez « Surveillance de l’activité en temps réel ».

Mise en cache améliorée

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

Servir du contenu obsolète pendant la mise à jour

NGINX Plus R12 prend désormais en charge les extensions Cache-Control définies dans la RFC 5861, à savoir stale-while-revalidate et stale-if-error. Vous pouvez désormais configurer NGINX Plus pour qu’il respecte ces extensions Cache-Control et continue à fournir des ressources expirées depuis le cache tout en les actualisant en arrière-plan, sans augmenter la latence de la requête du client. De même, NGINX Plus peut fournir des ressources expirées depuis le cache si le serveur en amont est indisponible – une technique permettant de mettre en œuvre des modèles de disjoncteur dans les applications de microservices.

Sauf s’il est configuré pour ignorer l’en-tête Cache-Control, NGINX Plus respecte les délais d’expiration stale des serveurs d’origine qui renvoient des en-têtes Cache-Control conformes à la RFC 5861, comme dans cet exemple :

Cache-Control: 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 mises en évidence :

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;

        # Serve stale content when updating
        proxy_cache_use_stale updating;
        
        # In addition, don’t block the first request that triggers the update
        # and do the update in the background
        proxy_cache_background_update on;

        proxy_pass http://my_upstream;
    }
}

La directive proxy_cache_use_stale updating demande à NGINX Plus de servir la version obsolète du contenu pendant sa mise à jour. Si vous incluez uniquement cette directive, le premier utilisateur qui demande le contenu obsolète subit la pénalité liée à l’« absence en cache » : il ne reçoit le contenu qu’une fois que NGINX Plus l’a récupéré auprès du serveur d’origine et mis en cache. Les utilisateurs qui demandent ensuite le contenu obsolète pendant sa mise à jour le reçoivent immédiatement depuis le cache, tandis que le premier utilisateur ne reçoit rien tant que le contenu mis à jour n’a pas été récupéré et mis en cache.

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

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

Requêtes de plages d’octets

Une autre amélioration du moteur de mise en cache permet à NGINX Plus de contourner le cache pour les requêtes de plages d’octets qui commencent au-delà d’un nombre configuré d’octets à partir du début d’un fichier non mis en cache. Ainsi, pour les fichiers volumineux tels que les contenus vidéo, les requêtes portant sur une plage d’octets située loin dans le fichier n’augmentent pas la latence de la requête du client. Dans les versions antérieures de NGINX Plus, le client ne recevait la plage d’octets demandée qu’après que NGINX Plus avait récupéré tout le contenu depuis le 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 » définit le décalage à partir du début du fichier au-delà duquel NGINX Plus transmet directement une requête de plage d’octets au serveur d’origine sans mettre la réponse en cache. (Cette 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;

        # Bypass cache for byte range requests beyond 10 megabytes
        proxy_cache_max_range_offset 10m;

        proxy_pass http://my_upstream;
    }
}

Ces améliorations confortent encore davantage NGINX Plus dans son rôle de moteur de mise en cache hautes performances, conforme aux normes et adapté à tous les environnements, de l’accélération de la diffusion des applications à la création de réseaux de diffusion de contenu (CDN) complets.

Contrôles d’intégrité améliorés

NGINX Plus R12 améliore encore les fonctionnalités de contrôle actif de l’état de NGINX Plus.

Contrôle de l’état des serveurs nouvellement ajoutés

Avec l’adoption croissante des environnements conteneurisés et des groupes d’applications à mise à l’échelle automatique, il est essentiel que l’équilibreur de charge effectue des contrôles d’intégrité proactifs au niveau applicatif et laisse aux nouveaux serveurs le temps d’initialiser leurs ressources internes avant d’atteindre leur pleine capacité.

Avant NGINX Plus R12, lorsque vous ajoutiez un nouveau serveur au pool d’équilibrage de charge (à l’aide de l’NGINX Plus API ou du DNS), NGINX Plus le considérait immédiatement comme sain et lui envoyait aussitôt du trafic. Lorsque vous ajoutez le nouveau paramètre mandatory à la directive health_check (HTTP ou TCP/UDP), le nouveau serveur doit réussir le contrôle d’intégrité configuré avant que NGINX Plus ne lui envoie du trafic. Associé à la fonctionnalité slow‑start, ce nouveau paramètre laisse aux nouveaux serveurs encore plus de temps pour se connecter aux bases de données et « monter en régime » avant de devoir prendre en charge la totalité de leur part de trafic.

upstream my_upstream {     zone my_upstream 64k;
     server backend1.example.com slow_start=30s;
}

server {
    location / {
        proxy_pass http://my_upstream;
  
        # Require new server to pass health check before receiving traffic
        health_check mandatory;
    }
}

Ici, le paramètre mandatory de la directive health_check et le paramètre slow_start de la directive server (HTTP ou TCP/UDP) sont tous deux inclus. Les serveurs ajoutés au groupe en amont via les interfaces API ou DNS sont marqués comme défaillants et ne reçoivent aucun trafic tant qu’ils n’ont pas réussi le contrôle d’intégrité. Ils commencent alors à recevoir un volume de trafic qui augmente progressivement sur une période de 30 secondes.

Vérification de l’état UDP sans configuration

Il est tout aussi important de mettre en œuvre des contrôles d’intégrité au niveau applicatif 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 pleinement opérationnels. NGINX Plus prend en charge les contrôles d’intégrité actifs pour UDP, mais avant NGINX Plus R12, vous deviez créer un bloc match définissant les données à send et la réponse à expect. Il peut être difficile de déterminer les valeurs appropriées lors de l’utilisation de protocoles binaires ou de protocoles comportant des négociations complexes. Pour ces applications, NGINX Plus R12 prend désormais en charge un contrôle d’intégrité « sans configuration » pour UDP, qui vérifie la disponibilité de l’application sans vous obliger à définir les chaînes send et expect. Ajoutez le paramètre udp à la directive health_check pour effectuer un contrôle d’intégrité UDP de base.

upstream udp_app {    server backend1.example.com:1234;
    server backend2.example.com:1234;
}

server {
    listen 1234 udp;
    proxy_pass udp_app;

    # Basic UDP health check
    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 qui accèdent à des sites web protégés. NGINX Plus R12 étend la prise en charge existante de l’authentification HTTP aux services TCP protégés par SSL. Cette fonctionnalité est généralement utilisée pour l’authentification de machine à machine, plutôt que pour la connexion des utilisateurs finaux. Elle permet d’utiliser NGINX Plus à la fois pour la terminaison SSL et l’authentification des clients lors de l’équilibrage de charge des protocoles de couche 4. Elle permet notamment d’authentifier les appareils IoT qui communiquent à l’aide du protocole MQTT.

La variable $ssl_client_verify inclut désormais des informations supplémentaires sur les échecs d’authentification des clients, notamment des motifs tels 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é afin d’être conforme aux RFC 2253 et 4514. Pour plus de détails, consultez la section « Modifications du comportement ».

Validation JWT améliorée

NGINX Plus R10 a introduit la prise en charge native des jetons Web JSON (JWT) pour les cas d’utilisation d’OAuth 2.0 et d’OpenID Connect. L’un des principaux cas d’utilisation consiste à permettre à NGINX Plus de valider un JWT, d’en examiner les champs et de les transmettre à l’application backend sous forme d’en-têtes HTTP. Les applications peuvent ainsi s’intégrer facilement à un environnement d’authentification unique (SSO) OAuth 2.0 en déléguant la validation des jetons à NGINX Plus et en récupérant l’identité de l’utilisateur à partir des en-têtes HTTP.

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

Mettez à niveau ou essayez NGINX Plus

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 12 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 consulter les changements de comportement décrits ci-dessus 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 diffusion de vos applications, ou à l’utiliser comme serveur web entièrement pris en charge, doté d’une API permettant d’améliorer la surveillance et la gestion de la configuration. 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

Owen GarrettDirecteur senior de la gestion des produits

Autres articles de Owen Garrett