Annonce de NGINX Plus R15

Liam CrillyDirecteur senior de la gestion des produits

Nous avons le plaisir d’annoncer que la quinzième version de NGINX Plus, notre produit phare, est désormais disponible. Depuis notre lancement initial en 2013, NGINX Plus a connu une croissance considérable, tant sur le plan de ses fonctionnalités que de son succès commercial. NGINX Plus compte désormais plus de [ngx_snippet name=’nginx-plus-customers’] clients et [ngx_snippet name=’number-sites’] utilisateurs de NGINX Open Source.

Basé sur NGINX Open Source, NGINX Plus est la seule solution tout-en-un combinant équilibreur de charge, cache de contenu, serveur web et passerelle d’API. NGINX Plus inclut des fonctionnalités avancées exclusives conçues pour simplifier l’architecture des applications modernes, ainsi qu’un support primé.

NGINX Plus R15 introduit la prise en charge de gRPC, le push serveur HTTP/2, une meilleure prise en charge de la mise en cluster, des fonctionnalités de passerelle API améliorées, et bien plus encore :

• Prise en charge native de gRPC – gRPC est la nouvelle norme d’appel de procédure à distance (RPC) développée par Google. Elle permet aux clients et aux serveurs de communiquer de manière légère et efficace. Grâce à cette nouvelle fonctionnalité, NGINX Plus peut assurer la terminaison SSL, le routage et l’équilibrage de charge du trafic gRPC vers vos serveurs backend.
• Push serveur HTTP/2 – Grâce au push serveur HTTP/2, NGINX Plus peut envoyer des ressources avant même que les clients ne les demandent, ce qui améliore les performances et réduit le nombre d’allers-retours.
• Partage d’état au sein d’un cluster – Avec cette version, les données de mémoire partagée utilisées pour la persistance des sessions Sticky Learn peuvent être partagées entre toutes les instances NGINX Plus d’un cluster. Les prochaines versions de NGINX Plus s’appuieront sur nos fonctionnalités de clustering et introduiront de nouvelles fonctionnalités adaptées aux clusters.
• Intégration d’OpenID Connect – Vous pouvez désormais fournir une authentification unique (SSO) à n’importe quelle application web avec NGINX Plus, en utilisant le flux de code d’autorisation OpenID Connect et en émettant des jetons web JSON (JWT) pour les clients. NGINX Plus s’intègre à CA Single Sign‑On (anciennement SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity et à d’autres fournisseurs d’identité populaires.
• Améliorations du module JavaScript NGINX (njs) – Les modules njs (anciennement nginScript) permettent d’exécuter du code JavaScript lors du traitement des requêtes par NGINX Plus. Le module njs pour HTTP prend désormais en charge l’émission de sous-requêtes HTTP indépendantes de la requête du client et exécutées de manière asynchrone par rapport à celle-ci. Cette fonctionnalité est utile dans les cas d’utilisation de passerelle API, car elle permet de modifier et de regrouper les appels d’API à l’aide de JavaScript. Les modules njs pour HTTP et TCP/UDP incluent également désormais des bibliothèques cryptographiques permettant d’implémenter des fonctions de hachage courantes.

Cette version est complétée par d’autres nouvelles fonctionnalités, notamment une nouvelle variable ALPN, des mises à jour de plusieurs modules dynamiques, et bien plus encore.

Changements de comportement

• NGINX Plus R13 a marqué l’introduction de la toute nouvelle API NGINX Plus, qui offre des fonctionnalités auparavant mises en œuvre dans des API distinctes, notamment la configuration dynamique des groupes en amont et des métriques étendues. Les anciennes API, configurées à l’aide des directives « upstream_conf » et « status », sont obsolètes. Nous vous recommandons de vérifier si ces directives figurent dans votre configuration et de passer à la nouvelle directive « api » dès que possible (pour plus de détails, consultez l’article « Présentation de NGINX Plus R13 » sur notre blog). À compter de la prochaine version, NGINX Plus R16, les API obsolètes ne seront plus fournies.
• L’API NGINX Plus passe à la version 3 dans cette version. Les versions précédentes restent prises en charge. Si vous envisagez de mettre à jour vos clients API, consultez la documentation sur la compatibilité de l’API.
• Les paquets NGINX Plus disponibles dans le dépôt officiel utilisent désormais un nouveau système de numérotation. Le paquet NGINX Plus et tous les modules dynamiques indiquent désormais le numéro de version de NGINX Plus. La version de chaque paquet correspond désormais à la version de NGINX Plus, afin d’identifier plus clairement la version installée et de simplifier les dépendances des modules. Ce changement est transparent, sauf si vous utilisez des systèmes automatisés qui référencent les paquets par leur numéro de version. Dans ce cas, veuillez d’abord tester votre processus de mise à niveau dans un environnement hors production.

Fonctionnalités de NGINX Plus R15 en détail

Prise en charge de gRPC

Avec cette version, NGINX Plus peut assurer le proxy et l’équilibrage de charge du trafic gRPC, que de nombreuses organisations utilisent déjà pour communiquer avec des microservices. gRPC est un framework open source et hautes performances d’appel de procédure à distance (RPC), conçu par Google pour permettre des communications de service à service extrêmement efficaces et à faible latence. gRPC impose HTTP/2, plutôt que HTTP 1.1, comme mécanisme de transport, car les fonctionnalités de HTTP/2 – contrôle de flux, multiplexage et diffusion bidirectionnelle du trafic à faible latence – sont parfaitement adaptées à l’interconnexion de microservices à grande échelle.

NGINX achemine le trafic gRPC et assure la terminaison SSL

La prise en charge de gRPC a été introduite dans NGINX Open Source 1.13.10 et est désormais incluse dans NGINX Plus R15. Vous pouvez maintenant inspecter et acheminer les appels de méthodes gRPC, ce qui vous permet de :

• Appliquez les fonctionnalités de NGINX Plus – notamment le chiffrement TLS HTTP/2, la limitation du débit, les listes de contrôle d’accès basées sur les adresses IP et la journalisation – aux services gRPC publiés.
• Publiez plusieurs services gRPC via un point de terminaison unique en inspectant les connexions gRPC et en les transmettant par proxy aux services internes.
• Faites évoluer vos services gRPC lorsque vous avez besoin de capacité supplémentaire en répartissant la charge des connexions gRPC entre les pools de serveurs backend en amont.
• Utilisez NGINX Plus comme passerelle d’API pour les points de terminaison gRPC et RESTful.

Pour en savoir plus, consultez l’article « Présentation de la prise en charge de gRPC avec NGINX 1.13.10 » sur notre blog.

Push serveur HTTP/2

La première impression est importante, et le temps de chargement des pages est un facteur déterminant pour inciter les utilisateurs à revenir sur votre site web. Le push serveur HTTP/2 permet notamment de leur fournir des réponses plus rapides en réduisant le nombre de RTT (temps d’aller-retour, c’est-à-dire le temps nécessaire à une requête et à sa réponse) qu’ils doivent attendre.

NGINX peut envoyer de manière proactive des ressources aux clients afin d’améliorer les performances

Le push serveur HTTP/2 était une fonctionnalité très demandée et très attendue par la communauté open source de NGINX. Elle a été introduite dans NGINX Open Source 1.13.9. Désormais incluse dans NGINX Plus R15, elle permet à un serveur d’envoyer de manière anticipée les données susceptibles d’être nécessaires pour répondre à une requête précédemment initiée par le client. Par exemple, un navigateur a besoin de tout un ensemble de ressources – feuilles de style, images, etc. – pour afficher une page Web. Il peut donc être judicieux d’envoyer ces ressources dès que le client accède pour la première fois à la page, plutôt que d’attendre que le navigateur les demande explicitement.

Dans l’exemple de configuration ci-dessous, nous utilisons la directive http2_push pour envoyer de manière anticipée au client les feuilles de style et les images dont il aura besoin pour afficher la page web demo :

Chargement de l’exemple de code…

Dans certains cas, cependant, il n’est pas possible de déterminer l’ensemble exact des ressources dont les clients ont besoin, ce qui rend peu pratique l’énumération de fichiers spécifiques dans le fichier de configuration NGINX. Dans ces cas, NGINX peut intercepter les en-têtes HTTP « Link » et envoyer les ressources qui y sont marquées « preload ». Pour activer l’interception des en-têtes « Link », définissez la directive « http2_push_preload » sur « on ».

Chargement de l’exemple de code…

Pour en savoir plus, consultez l’article « Présentation du push serveur HTTP/2 avec NGINX 1.13.9 » sur notre blog.

Partage d’état au sein d’un cluster

La configuration de plusieurs serveurs NGINX Plus en cluster haute disponibilité renforce la résilience de vos applications et élimine les points de défaillance uniques dans votre pile applicative. La mise en cluster de NGINX Plus est conçue pour les déploiements de production critiques, où la résilience et la haute disponibilité sont primordiales. Il existe de nombreuses solutions pour déployer un cluster haute disponibilité avec NGINX Plus.

La prise en charge de la mise en cluster a été introduite dans les versions précédentes de NGINX Plus, avec deux niveaux de clustering :

• Résilience réseau à l’aide du paquet keepalived – Assure le basculement en cas de panne d’un serveur NGINX Plus.
• Synchronisation de la configuration à l’aide du paquet nginx-sync package – Garantit la synchronisation de la configuration sur tous les serveurs NGINX Plus.

NGINX Plus R15 introduit un troisième niveau de mise en cluster : le partage d’état pendant l’exécution, qui permet de synchroniser les données des zones de mémoire partagée entre les nœuds du cluster. Plus précisément, les données stockées dans les zones de mémoire partagée pour la persistance de session Sticky Learn peuvent désormais être synchronisées sur tous les nœuds du cluster à l’aide du nouveau module zone_sync pour le trafic TCP/UDP.

Nouveau module zone_sync Module

Avec le partage d’état, il n’y a pas de nœud principal : tous les nœuds sont des pairs et échangent des données selon une topologie entièrement maillée. En outre, la solution de clustering avec partage d’état est indépendante de la solution de haute disponibilité assurant la résilience du réseau. Un cluster avec partage d’état peut donc s’étendre sur plusieurs sites physiques.

Un cluster NGINX Plus avec partage d’état doit répondre à trois exigences :

• Connectivité réseau entre tous les nœuds du cluster
• Horloges synchronisées
• La configuration de chaque nœud active le module zone_sync, comme dans l’exemple suivant :

  Chargement de l’exemple de code…

La directive « zone_sync » permet de synchroniser les zones de mémoire partagée au sein d'un cluster. La directive « zone_sync_server » identifie les autres instances NGINX Plus du cluster. NGINX Plus prend en charge la découverte de services DNS, ce qui permet d'identifier les membres du cluster par leur nom d'hôte et d'utiliser ainsi une configuration identique pour chacun d'eux.

La configuration minimale ci-dessus ne dispose pas des contrôles de sécurité nécessaires pour protéger les données de synchronisation dans un environnement de production. L’extrait de configuration suivant met en œuvre plusieurs de ces mesures de protection :

• Chiffrement SSL/TLS des données de synchronisation
• Authentification par certificat client, afin que chaque nœud du cluster s’identifie auprès des autres (TLS mutuel)
• Listes de contrôle d’accès (ACL) basées sur les adresses IP, afin que seuls les nœuds NGINX Plus situés sur le même réseau physique puissent se connecter pour la synchronisation

Chargement de l’exemple de code…

Partage d’état pour la persistance des sessions avec apprentissage de l’affinité

La première fonctionnalité prise en charge par NGINX Plus qui utilise des données d’état partagées au sein d’un cluster est la persistance de session Sticky Learn. La persistance de session signifie que les requêtes d’un client sont toujours transmises au serveur qui a traité sa première requête, ce qui est utile lorsque l’état de la session est stocké dans le backend.

Dans la configuration suivante, la directive sticky learn définit une zone de mémoire partagée appelée sessions. Le paramètre sync active le partage de l’état à l’échelle du cluster en demandant à NGINX Plus de publier des messages sur le contenu de sa zone de mémoire partagée auprès des autres nœuds du cluster.

Notez que, pour que la synchronisation des données d’état fonctionne correctement, la configuration de chaque nœud NGINX Plus du cluster doit inclure le même bloc « upstream » avec la directive « sticky » « learn », ainsi que les directives qui activent le module « zone_sync » (décrit ci-dessus).

Chargement de l’exemple de code…

Remarque: la prise en charge de la mise en cluster et la persistance de session Sticky Learn sont exclusivement disponibles dans NGINX Plus.

Intégration d’OpenID Connect

De nombreuses entreprises utilisent des solutions de gestion des identités et des accès (IAM) pour gérer les comptes utilisateurs et fournir un environnement d’authentification unique (SSO) pour plusieurs applications. Elles cherchent souvent à étendre le SSO aux applications nouvelles et existantes afin de réduire au minimum la complexité et les coûts.

« L’utilisation d’OpenID Connect avec NGINX Plus nous a permis d’intégrer rapidement et facilement notre fournisseur d’identité, tout en simplifiant l’architecture de notre application. » – Scott Macleod, ingénieur logiciel, NHS Digital

NGINX Plus R10 a introduit la prise en charge de la validation des jetons OpenID Connect. Dans cette version, nous étendons cette fonctionnalité afin que NGINX Plus puisse également contrôler le flux de code d’autorisation pour l’authentification avec OpenID Connect 1.0, en communiquant avec le fournisseur d’identité et en délivrant le jeton d’accès au client. Cela permet l’intégration avec la plupart des principaux fournisseurs d’identité, notamment CA Single Sign-On (anciennement SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin et Ping Identity. Cette fonctionnalité étendue vous permet également de :

• Étendre l’authentification unique (SSO) aux applications existantes sans avoir à les modifier ni à les moderniser
• Intégrer le SSO aux nouvelles applications sans implémenter le SSO ni l’authentification dans le code de l’application
• Éliminez la dépendance vis-à-vis d’un fournisseur : vous bénéficiez d’une authentification unique (SSO) basée sur des normes, sans avoir à déployer avec l’application un logiciel agent propriétaire d’un fournisseur de solutions IAM.

L’intégration d’OpenID Connect à NGINX Plus est disponible sous forme d’implémentation de référence sur GitHub. Le dépôt GitHub comprend un exemple de configuration ainsi que des instructions pour l’installation, la configuration et l’optimisation en fonction de cas d’utilisation spécifiques.

Améliorations apportées au module JavaScript de NGINX

[Note de la rédaction – Les exemples suivants ne représentent que quelques-uns des nombreux cas d’utilisation du module JavaScript NGINX. Pour obtenir la liste complète, consultez Cas d’utilisation du module JavaScript NGINX.

Le code de cette section a été mis à jour comme suit afin de tenir compte des modifications apportées à l’implémentation de NGINX JavaScript depuis la publication initiale de l’article :

• Pour utiliser l’objet session (s) remanié pour le module Stream, introduit dans NGINX JavaScript 0.2.4.
• Pour utiliser la directive js_import, qui remplace la directive js_include dans NGINX Plus R23 et les versions ultérieures. Pour plus d’informations, consultez la documentation de référence du module JavaScript NGINX : la section « Exemple de configuration » présente la syntaxe correcte pour les fichiers de configuration NGINX et les fichiers JavaScript.

]

Avec le module JavaScript de NGINX, njs (anciennement nginScript), vous pouvez intégrer du code JavaScript à votre configuration NGINX afin qu’il soit évalué lors de l’exécution, à mesure que les requêtes HTTP ou TCP/UDP sont traitées. Cela ouvre la voie à de nombreux cas d’utilisation, notamment un contrôle plus précis du trafic, la mutualisation des fonctions JavaScript entre les applications et la protection contre les menaces de sécurité.

NGINX Plus R15 inclut deux mises à jour importantes de njs : les sous-requêtes et les fonctions de hachage.

Sous-requêtes

Vous pouvez désormais émettre simultanément des requêtes HTTP indépendantes de la requête du client et exécutées de manière asynchrone par rapport à celle-ci. Cela ouvre la voie à une multitude de cas d’usage avancés.

L’exemple de code JavaScript suivant envoie simultanément une requête HTTP à deux backends différents. La première réponse est transmise à NGINX Plus afin d’être envoyée au client, tandis que la seconde est ignorée.

Chargement de l’exemple de code…

La directive js_import de la configuration NGINX Plus correspondante charge le code JavaScript depuis fastest_wins.js. Toutes les requêtes correspondant à l’emplacement racine (/) sont transmises à la fonction sendFastest(), qui génère des sous-requêtes vers les emplacements /server_one et /server_two. L’URI d’origine, avec ses paramètres de requête, est transmise aux serveurs backend correspondants. Les deux sous-requêtes exécutent la fonction de rappel done. Toutefois, comme cette fonction contient r.return(), seule la sous-requête qui se termine en premier envoie sa réponse au client.

Chargement de l’exemple de code…

Fonctions de hachage

Les modules njs pour le trafic HTTP et TCP/UDP incluent désormais une bibliothèque cryptographique proposant des implémentations des éléments suivants :

• Fonctions de hachage : MD5, SHA‑1, SHA‑256
• HMAC utilisant : MD5, SHA‑1, SHA‑256
• Formats de condensé : Base64, Base64URL, hexadécimal

Un exemple de cas d’utilisation des fonctions de hachage consiste à garantir l’intégrité des données des cookies d’une application. L’exemple de code njs suivant comprend une fonction signCookie() permettant d’ajouter une signature numérique à un cookie et une fonction validateCookieSignature() permettant de valider les cookies signés.

Chargement de l’exemple de code…

La configuration NGINX Plus suivante utilise le code njs pour valider les signatures des cookies dans les requêtes HTTP entrantes et renvoyer un message d’erreur au client en cas d’échec de la validation. NGINX Plus transmet la requête au serveur mandataire si la validation réussit ou si aucun cookie n’est présent.

Chargement de l’exemple de code…

Nouvelles fonctionnalités supplémentaires de NGINX Plus R15

Variable ALPN pour les modules Stream

La négociation de protocole de couche applicative (ALPN) est une extension de TLS qui permet à un client et à un serveur de déterminer, lors de l’établissement de la liaison TLS, le protocole à utiliser pour la connexion en cours d’établissement. Elle évite ainsi des allers-retours supplémentaires susceptibles d’accroître la latence et de dégrader l’expérience utilisateur. Le cas d’usage le plus courant d’ALPN consiste à faire passer automatiquement les connexions de HTTP à HTTP/2 lorsque le client et le serveur prennent tous deux en charge HTTP/2.

La nouvelle variable NGINX $ssl_preread_alpn_protocols, introduite pour la première fois dans NGINX Open Source 1.13.10, récupère la liste des protocoles annoncés par le client dans son message ClientHello lors de la phase de prélecture ALPN. Avec la configuration ci-dessous, un client XMPP peut s’identifier via ALPN afin que NGINX Plus achemine le trafic XMPP vers le groupe en amont xmpp_backend, le trafic gRPC vers grpc_backend et tout autre trafic vers http_backend, le tout via un point de terminaison unique.

Pour permettre à NGINX Plus d’extraire des informations du message ClientHello et de renseigner la variable $ssl_preread_alpn_protocols, vous devez également inclure la directive ssl_preread on.

Chargement de l’exemple de code…

Pour en savoir plus, consultez la documentation du module « ngx_stream_ssl_preread ».

Variable de temps d’attente

NGINX Plus prend en charge la mise en file d’attente en amont afin que les requêtes des clients ne soient pas immédiatement rejetées lorsque tous les serveurs du groupe en amont sont indisponibles pour accepter de nouvelles requêtes.

Un cas d’utilisation courant de la mise en file d’attente en amont consiste à protéger les serveurs backend contre la surcharge sans avoir à rejeter immédiatement les requêtes lorsque tous les serveurs sont occupés. Vous pouvez définir le nombre maximal de connexions simultanées pour chaque serveur en amont à l’aide du paramètre max_conns de la directive server. La directive queue place alors les requêtes dans une file d’attente lorsqu’aucun backend n’est disponible, soit parce qu’ils ont atteint leur limite de connexions, soit parce qu’ils ont échoué à un contrôle d’intégrité.

Dans cette version, la nouvelle variable NGINX $upstream_queue_time, introduite pour la première fois dans NGINX Open Source 1.13.9, mesure le temps qu’une requête passe dans la file d’attente. La configuration ci-dessous comprend un format de journal personnalisé qui enregistre différentes métriques temporelles pour chaque requête ; ces métriques peuvent ensuite être analysées hors ligne dans le cadre de l’optimisation des performances. Nous limitons à 20 le nombre de requêtes placées en file d’attente pour le groupe en amont my_backend. Le paramètre timeout définit la durée pendant laquelle les requêtes sont conservées dans la file d’attente avant qu’un message d’erreur ne soit renvoyé au client (503 par défaut). Ici, nous la fixons à 5 secondes (la valeur par défaut est de 60 secondes).

Chargement de l’exemple de code…

Pour en savoir plus, consultez la documentation relative à la directive « queue ».

Journaux d’accès sans échappement

Vous pouvez désormais désactiver l’échappement dans le journal d’accès de NGINX Plus. Le nouveau paramètre « escape=none » de la directive « log_format », introduit pour la première fois dans NGINX Open Source 1.13.10, indique qu’aucun échappement n’est appliqué aux caractères spéciaux dans les variables.

Mise à jour de l’implémentation de référence de l’authentification LDAP

Notre implémentation de référence pour l’authentification des utilisateurs à l’aide d’un système d’authentification LDAP a été mise à jour afin de résoudre certains problèmes et de corriger des bugs. Découvrez-la sur GitHub.

Proxy transparent sans privilèges root

Vous pouvez utiliser NGINX Plus comme proxy transparent en ajoutant le paramètre « transparent » à la directive « proxy_bind ». Les processus de travail peuvent désormais hériter de la capacité Linux « CAP_NET_RAW » du processus maître, de sorte que NGINX Plus ne nécessite plus de privilèges spéciaux pour fonctionner comme proxy transparent.

Remarque: cette fonctionnalité s’applique uniquement aux plateformes Linux.

Délai de grâce du JWT

Si un JWT inclut une revendication temporelle – nbf (date de début de validité), exp (date d’expiration), ou les deux –, la validation du JWT par NGINX Plus vérifie que l’heure actuelle se situe dans l’intervalle spécifié. Toutefois, si l’horloge du fournisseur d’identité n’est pas synchronisée avec celle de l’instance NGINX Plus, les jetons peuvent expirer de manière inattendue ou sembler prendre effet à une date ultérieure. Pour définir le décalage maximal acceptable entre les deux horloges, utilisez la directive auth_jwt_leeway.

Module dynamique Cookie Flag

Le module tiers permettant de définir les attributs des cookies est désormais disponible sous la forme du module dynamique Cookie-Flag dans le dépôt NGINX et est couvert par votre contrat de support NGINX Plus. Vous pouvez l’installer à l’aide de votre gestionnaire de paquets :

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

Mise à jour du module WAF NGINX ModSecurity

NGINX ModSecurity WAF, un module dynamique pour NGINX Plus basé sur ModSecurity 3.0, a été mis à jour avec les améliorations suivantes :

• Améliorations des performances de libmodsecurity
• Corrections de fuites de mémoire dans ModSecurity-nginx

[Note de la rédaction – La fin de commercialisation de NGINX ModSecurity WAF est officiellement intervenue le 1er avril 2022, et sa fin de vie prendra effet 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.]

Mettez à niveau ou essayez NGINX Plus

NGINX Plus R15 offre des fonctionnalités d’authentification améliorées pour vos applications clientes, des fonctionnalités de clustering supplémentaires, des améliorations de njs et des corrections de bugs notables.

Si vous utilisez NGINX Plus, nous vous recommandons vivement de passer à la version 15 dès que possible. Vous bénéficierez ainsi de plusieurs correctifs et améliorations, et cette mise à niveau nous permettra de mieux vous aider si vous devez ouvrir un ticket d’assistance. Les instructions d’installation et de mise à niveau de NGINX Plus R15 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 jamais utilisé NGINX Plus, nous vous invitons à l’essayer 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. Commencez gratuitement dès aujourd’hui avec une évaluation gratuite de 30 jours. Découvrez 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