NGINXaaS pour Azure permet aux entreprises de fournir en toute sécurité des applications hautes performances dans le cloud. Propulsé par NGINX Plus, il s'agit d'un service entièrement géré qui est devenu généralement disponible en janvier 2023. Depuis sa sortie et dans le futur, nous continuons d’améliorer NGINXaaS pour Azure en ajoutant de nouvelles fonctionnalités .
Dans ce blog, nous mettons en évidence certaines des dernières fonctionnalités de performances et de sécurité qui vous permettent de profiter davantage des avantages de NGINX Plus sans avoir à déployer, maintenir et mettre à jour vos propres instances NGINX Plus. Pour obtenir des informations générales sur NGINXaaS pour Azure et ses fonctionnalités globales, lisez Simplifier et accélérer les migrations vers le cloud avec F5 NGINXaaS pour Azure .
Figure 1 : Présentation de NGINXaaS pour Azure
Alors que les proxys inverses nécessitent SSL/TLS pour crypter le trafic côté client sur l'Internet public, le TLS mutuel (mTLS) devient essentiel pour authentifier et garantir la confidentialité côté serveur. Avec le passage au Zero Trust , il est également nécessaire de vérifier que le trafic du serveur en amont n'a pas été modifié ou intercepté.
Figure 2 : mTLS avec NGINXaaS
NGINXaaS pour Azure prend désormais en charge les directives NGINX pour sécuriser le trafic en amont avec des certificats SSL/TLS. Grâce à ces directives, vous pouvez non seulement conserver le trafic en amont chiffré via mTLS, mais vous pouvez également vérifier que les serveurs en amont présentent un certificat valide provenant d'une autorité de certification de confiance.
Un élément clé (jeu de mots intentionnel) de l’utilisation de certificats TLS avec NGINXaaS pour Azure consiste à gérer en toute sécurité ces certificats via l’utilisation d’ Azure Key Vault (AKV) . AKV conserve le matériel cryptographique sensible en toute sécurité et permet à NGINXaaS pour Azure d’utiliser ces certificats tout en empêchant la divulgation accidentelle ou intentionnelle du matériel clé via le portail Azure.
Figure 3 : Rotation des certificats avec Azure Key Vault
NGINXaaS pour Azure peut désormais effectuer automatiquement la rotation des certificats dans vos déploiements NGINX chaque fois qu'ils sont mis à jour dans AKV. Les nouvelles versions des certificats sont intégrées à vos déploiements dans un délai de quatre heures.
Fermez les yeux et repensez à l’année 1997. Nous étions en train de danser avec Chumbawamba, portant nos jeans JNCO (ou Modrobes pour nos compatriotes canadiens), et HTTP/1.1 était publié. À cette époque, la plupart des utilisateurs finaux accédaient à Internet via un modem commuté, les pages Web ne contenaient que quelques dizaines d’éléments et, en matière d’expérience utilisateur, la bande passante était une préoccupation bien plus importante que la latence.
Vingt-cinq ans plus tard, une grande partie des applications web utilise encore HTTP/1.1 pour diffuser du contenu. Cela pose problème. HTTP/1.1 fonctionne toujours, mais il ne permet de livrer qu’une ressource par connexion à la fois. Or, les applications web modernes envoient souvent des centaines de requêtes pour actualiser une interface utilisateur.
Même si la plupart des utilisateurs bénéficient d’une bande passante nettement plus large, la vitesse de transmission des données (limitée par la vitesse fondamentale de la lumière) n’a pas suivi le même rythme. Ainsi, la latence cumulée de toutes ces requêtes peut fortement affecter la performance perçue de votre application. Les navigateurs modernes ouvrent plusieurs connexions TCP vers un même serveur, mais chaque requête sur ces connexions reste séquentielle, ce qui fait qu’une ressource lente peut retarder toutes celles qui suivent.
Jetez un œil à la page d’accueil de F5 lorsqu’elle se charge en utilisant uniquement HTTP/1.1 :
Figure 4 : F5.com accessible via HTTP/1.1
Vous voyez toutes ces barres grises ? Le navigateur gaspille ce temps précieux à attendre l’établissement de la session, à bloquer une ressource lente ou à rechercher une connexion TCP disponible.
Activons HTTP/2 et essayons à nouveau :
Figure 5 : La même requête, mais en utilisant HTTP/2
Beaucoup mieux. Quelques ressources restent lentes, mais elles ne bloquent pas les autres requêtes et vous perdez nettement moins de temps à cause des délais liés au passage en file d’attente. HTTP/2 conserve les mêmes principes que HTTP/1.1, familiers aux navigateurs et serveurs, tout en ajoutant de nouvelles fonctionnalités pour améliorer la perception des performances des applications (par exemple, la priorisation des requêtes, la compression des en-têtes et le multiplexage des requêtes).
Compte tenu d’une différence aussi claire, NGINXaaS pour Azure prend désormais en charge le traitement des requêtes client via HTTP/2 . Les connexions côté client sont plus susceptibles d'être affectées par des temps d'aller-retour plus longs, vous pouvez donc distribuer ce trafic avec les avantages de réduction de latence de HTTP/2 tout en laissant vos serveurs en amont inchangés.
Malgré ce que certains acteurs du secteur des application Web voudraient croire, nous reconnaissons qu’il existe des options de protocole supplémentaires au-delà de HTTP à votre disposition. C'est pourquoi le module NGINX gRPC est désormais également disponible dans NGINXaaS pour Azure. Il fournit plusieurs directives de configuration pour travailler avec le trafic gRPC, notamment l'interception des erreurs, la manipulation des en-têtes, etc.
Pour le trafic non HTTP/gRPC, le module de flux est désormais disponible dans NGINXaaS pour Azure. Ce module prend en charge le proxy et l'équilibrage de charge du trafic TCP et UDP.
NGINXaaS pour Azure peut désormais fonctionner à la fois comme un équilibreur de charge cloud natif TCP/UDP de couche 4 et HTTP/HTTP de couche 7. Pourquoi est-ce important ? Au lieu de déployer deux services ou équilibreurs de charge différents, NGINXaaS pour Azure vous permet de déployer un seul équilibreur de charge et de le configurer pour fonctionner sur les deux couches en même temps, simplifiant ainsi votre architecture cloud et réduisant vos coûts.
Vous pouvez en apprendre davantage sur la configuration ici .
NGINXaaS pour Azure est un service basé sur la consommation qui est mesuré toutes les heures et facturé mensuellement en unités de capacité NGINX (NCU) . Nous avons récemment doublé cette capacité de déploiement, passant de 80 à 160 NCU. Les clients peuvent déployer un système plus petit de 20 NCU et, si la charge de travail augmente, peuvent évoluer jusqu'à 160 NCU. De plus, les clients ont également la possibilité de déployer jusqu’à 160 NCU au départ.
Pour offrir une expérience de configuration simple et rapide, passant d'une offre sur site à une offre cloud entièrement gérée, nous avons ajouté de nombreuses directives NGINX Plus. Veuillez vous référer à toutes les directives NGINX Plus que nous prenons en charge dans NGINXaaS pour Azure ici .
Nous améliorons et développons constamment les façons dont vous pouvez utiliser la technologie NGINX et F5 pour sécuriser, fournir et optimiser chaque application et API, partout. Grâce aux fonctionnalités susmentionnées et à d’autres nouvelles fonctionnalités ajoutées à NGINXaaS pour Azure, davantage d’utilisateurs Azure peuvent résoudre de nombreux problèmes d’applications et d’API avec la puissance de NGINX Plus, sans avoir à gérer une machine virtuelle ou une infrastructure de conteneur supplémentaire.
Si vous souhaitez en savoir plus sur NGINXaaS pour Azure, nous vous encourageons à consulter la documentation du produit . Si vous êtes prêt à essayer NGINXaaS pour Azure, visitez la place de marché Azure ou contactez-nous pour discuter de vos cas d’utilisation.
« 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."