Aujourd'hui (24 juillet) marque la fin de nos trois derniers mois de développement et la sortie de NGINX Plus Release 4 (R4) .
NGINX Plus R4 rassemble les fonctionnalités récemment publiées dans notre branche open source avec un certain nombre de fonctionnalités exclusivement commerciales dans une version entièrement testée et prise en charge.
La validation des certificats et la prise en charge SNI pour les flux en amont améliorent la sécurité des appels d’API et du trafic équilibré dans les environnements non fiables. Un magasin de phrases de passe externe améliore la sécurité de vos précieuses clés privées SSL.
La sécurité de bout en bout est une préoccupation majeure, en particulier si vous créez une application qui s'étend sur plusieurs emplacements. Si votre trafic interne transite par l’Internet ouvert (ou même au sein d’un cloud public), le SSL de base seul n’est pas suffisant pour vous protéger contre les attaques de l’homme du milieu (MITM) triviales. Cette version (avec nos remerciements à CloudFlare ) ajoute la vérification des certificats pour les serveurs en amont , vous pouvez donc être sûr que NGINX Plus communique avec le serveur auquel il est destiné. Il ajoute également la prise en charge SNI pour les services en amont afin de faciliter la mise à l'échelle sécurisée de services complexes en amont.
La sécurité intérieure est tout aussi importante. De nombreux sites stockent leur configuration NGINX Plus de manière centralisée, mais cela soulève des inquiétudes quant à la préservation de la confidentialité de la clé privée SSL. Les phrases de passe pour décrypter la clé privée sont la bonne solution, mais jusqu'à présent elles se sont révélées très gênantes.
NGINX Plus vous permet d'utiliser un magasin de phrases de passe externe , local sur chaque serveur et distinct de la configuration. Cela garantit que les clés sont protégées lorsque la configuration est stockée ou en vol, et que seuls les serveurs autorisés peuvent les déchiffrer.
Les optimisations et les nouvelles disciplines pour l'équilibrage de charge et la mise en cache de NGINX Plus créent une interface très performante pour diffuser vos applications Web.
La version 4 ajoute un nouvel algorithme d'équilibrage de charge – Hash – aux algorithmes existants (Round Robin, IP Hash et Least Connections). L'équilibrage de charge basé sur le hachage vous permet de répartir le trafic de manière uniforme sur un groupe en amont en fonction d'une fonction de hachage de n'importe quelle combinaison de paramètres de demande : adresse IP source et port, URL, etc.
La méthode Hash devient très utile si vous activez le paramètre facultatif cohérent
de la directive hash
. Cela permet un équilibrage de charge de hachage cohérent (en utilisant la méthode d'équilibrage de charge ketama pour l'interopérabilité avec memcached), ce qui constitue un énorme avantage lors de l'équilibrage de charge des serveurs de cache et d'autres applications qui accumulent l'état.
Avec un hachage cohérent, les demandes sont partagées de manière uniforme entre les serveurs cibles en fonction de la valeur de hachage de la clé spécifiée par l'utilisateur. Si un serveur est ajouté ou supprimé (parce qu'il tombe en panne, par exemple), l'espace de hachage minimum possible est redistribué pour minimiser les échecs de cache. Pour une distribution uniforme, l'implémentation basée sur ketama de NGINX Plus utilise 160 points par serveur dans l'espace de hachage (l'illustration ci-dessus ne montre que 8 points).
La version 4 ajoute également un nouveau mécanisme d'affinité de session – sticky learn – aux mécanismes existants (sticky route et sticky cookie). Le mécanisme d’apprentissage est extrêmement flexible : NGINX Plus apprend dynamiquement quelles sessions sont initiées par chaque serveur et sait identifier la signature de session dans les requêtes des clients. Il existe de nombreuses possibilités d’utiliser cette fonctionnalité si vous avez besoin d’un contrôle précis de la manière dont les requêtes sont acheminées au sein des groupes en amont.
Enfin, la mise en cache est désormais encore plus efficace pour minimiser la charge sur vos serveurs en amont. La revalidation du cache peut utiliser les ETag
ainsi que l'horodatage de dernière modification
pour vérifier que le contenu n'a pas changé.
Concentrez-vous sur les informations dont vous avez besoin avec des techniques permettant de filtrer et d'explorer en profondeur les données de journalisation et de surveillance.
NGINX Plus génère une richesse de données, grâce à l'access_log et à sa fonction unique de surveillance des activités en direct . Parfois, le volume de données peut être écrasant : le coût de leur collecte, de leur stockage et de leur analyse peut être tout simplement trop élevé, en particulier pour les sites très fréquentés avec un grand nombre de services et d’utilisateurs.
La journalisation conditionnelle dans le journal d'accès vous permet de définir les demandes intéressantes qui sont enregistrées et d'ignorer celles qui le sont moins. C'est vraiment utile pour les décisions d'exécution ; peut-être souhaitez-vous simplement enregistrer les requêtes qui génèrent des erreurs de serveur 5xx ? Ou ignorer les demandes du réseau local ? Peut-être souhaitez-vous supprimer les données inutiles générées par un moniteur de santé externe ? Quelles que soient vos exigences, si vous souhaitez filtrer et limiter les entrées de journal au moment de l'exécution, la journalisation conditionnelle est la réponse.
Dans les versions précédentes de NGINX Plus, les demandes de données de surveillance d'activité en direct générées par le module d'état étendu renvoyaient une quantité massive de données internes décrivant l'activité et l'état actuels. Cependant, si tout ce que vous souhaitez faire est de surveiller un compteur (par exemple, le nombre de requêtes) ou si vous souhaitez simplement obtenir l'état de santé des nœuds de vos flux en amont, il est alors inefficace de récupérer l'ensemble des données d'état. Avec la version 4, vous pouvez utiliser une API RESTful pour explorer et récupérer des sous-ensembles de données, ou simplement une seule valeur, ce qui rend la surveillance plus efficace et plus légère.
NGINX Plus R4 hérite d'autres mises à jour, correctifs et nouvelles fonctionnalités récents de la version NGINX 1.7.3, et les modules tiers inclus dans les packages nginx-plus-lua et nginx-plus-extras ont été mis à jour pour utiliser Lua version 0.9.10 et Passenger Open Source version 4.0.45.
Conformément à notre politique de prise en charge des versions de distributions de systèmes d'exploitation prises en charge par leurs fournisseurs, nous avons ajouté la prise en charge de CentOS/RHEL 7 et mis fin à la prise en charge d'Ubuntu 12.10, 13.04 et 13.10.
Pour une liste complète des nouvelles fonctionnalités et modifications de la version 4, consultez la page des versions de NGINX Plus .
Si vous utilisez NGINX Plus, nous vous encourageons vivement à effectuer la mise à jour vers la version 4 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 NGINX Plus .
Si vous n'avez pas essayé NGINX Plus, démarrez votre essai gratuit de 30 jours dès aujourd'hui et découvrez comment NGINX Plus peut vous aider à développer et à diffuser vos applications.
« 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."