Mise à jour produit hebdomadaire : conseils pour configurer la terminaison SSL sur les Cloud Load Balancers

Nous aimons vous tenir au courant de l’actualité de Mailgun chaque semaine, mais les projets sur lesquels nous travaillons sont parfois en phase de Recherche et Développement, et nous n’avons pas grand-chose à partager. C’est ce qui s’est passé cette semaine, nous n’avons donc rien de majeur à signaler. Cela ne veut pas dire que nous sommes restés inactifs. Comme les clients de Mailgun sont des développeurs comme nous, nous avons pensé partager ce que nous avons appris lors d’une tâche de maintenance courante : l’ajout d’une terminaison SSL à nos Cloud Load Balancers, qui gèrent le trafic du panneau de configuration et du site Web. Nous avons découvert des choses intéressantes, notamment en matière de performances, qui pourraient vous être utiles dans votre propre application. Si ce n’est pas votre domaine, ne vous inquiétez pas, revenez la semaine prochaine pour découvrir de nouvelles fonctionnalités et améliorations.

L’une des exigences courantes pour les fournisseurs SaaS (comme Mailgun et beaucoup de nos clients) est le suivi des sessions par adresse IP. Lors du passage du trafic par un répartiteur de charge, il existe différentes manières de s’assurer que l’adresse IP d’origine est conservée. Autrefois, nous utilisions un répartiteur de charge F5 qui transmettait une variable $remoteaddr que nous utilisions dans notre configuration nginx. Cette variable était l’adresse d’un client extraite des options de socket. Lorsque nous sommes récemment passés aux Rackspace Cloud Load Balancers pour gérer le trafic de notre site Web et de notre panneau de configuration, nous avons remarqué que les Cloud Load Balancers fournissent l’adresse IP du répartiteur de charge pour $remoteaddr, au lieu de l’adresse IP du client. Nous avions donc besoin d’un autre moyen de conserver ces informations.

Les Cloud Load Balancers peuvent ajouter un en-tête X-Forwarded-For contenant la valeur de l’adresse IP du client. Cependant, cette option ne fonctionne pas avec le protocole SSL que nous utilisons pour notre panneau de configuration. Pourquoi cela ne fonctionnerait-il pas ? C’est simple. Afin d’ajouter un en-tête au fichier envoyé via SSL, le répartiteur de charge doit d’abord déchiffrer le fichier. Par défaut, un répartiteur de charge n’est pas équipé pour cela et l’en-tête n’est pas ajouté. Heureusement, les Cloud Load Balancers proposent une option de terminaison SSL qui vous permet de déchiffrer le trafic SSL avant de le transmettre aux serveurs de destination. Cela présente certains avantages pour réduire la charge sur les serveurs d’application. Pour que cela fonctionne, il vous suffit d’activer la terminaison SSL pour votre répartiteur de charge et de lui fournir une clé privée et un certificat SSL.

Il s’agit en fait d’un excellent exemple de séparation des préoccupations. Au lieu de conserver tous les éléments liés au SSL dans les fichiers de configuration de votre serveur, vous les placez dans le répartiteur de charge et tout fonctionne.

Un point important à garder à l’esprit est qu’après l’activation de la terminaison SSL, tout le trafic HTTPS passant par le répartiteur de charge deviendra du HTTP. Cela semble évident, et pourtant il est très courant d’oublier ce petit détail. Nous avons d’ailleurs rencontré ce problème lors de nos tests sur notre environnement de pré-production. La solution consiste à utiliser l’en-tête X-Forwarded-Proto que le répartiteur de charge définit sur « https » pour le trafic HTTPS. Voici un bon exemple de la façon de procéder dans nginx.

Avant de mettre en œuvre ce changement, nous voulions nous assurer que les performances ne pâtiraient pas de l’utilisation de la terminaison SSL. Pour le vérifier, nous avons effectué des tests de performance sur notre environnement de pré-production et avons obtenu des résultats inattendus : les répartiteurs de charge avec terminaison SSL ont en réalité obtenu de meilleures performances en moyenne que ceux qui n’en étaient pas équipés.

Pour exécuter le test, nous avons réalisé une requête GET sur trois URL différentes :

• GET /cp
• GET /cp/log
• GET /cp/domains[/list]

Chaque GET a récupéré des pages HTML avec et sans toutes les ressources intégrées, c’est-à-dire l’analyse du fichier HTML et l’envoi de requêtes HTTP/HTTPS pour l’ensemble des images, applets Java, fichiers JavaScript, CSS, etc., référencés dans le fichier.

Bien qu’il y ait eu un cas où les performances avec SSL ont été plus lentes, la performance moyenne a été étonnamment meilleure : le temps de chargement moyen est passé de 3 957 millisecondes à 3 811 millisecondes, soit une baisse de 3,7 %. Ce n’est pas si mal si l’on considère que la terminaison SSL ajoute des étapes au processus de transfert d’un fichier du client vers le serveur et inversement.

C’est tout pour cette semaine. Nous espérons que la prochaine fois que vous devrez ajouter une terminaison SSL à vos répartiteurs de charge, vous trouverez ces informations utiles. À la semaine prochaine.

Bons envois d’emails,

L’équipe Mailgun

Auteur·trice: The Sinch Mailgun team The Sinch Mailgun team shares news, best practices, and strategies to take your products and apps to the next level using email. Subscribe to our newsletter to get all the articles in your inbox!