Équilibrage de charge de Docker Swarm avec NGINX et NGINX Plus

En septembre dernier, lors de la conférence nginx.conf 2016 à Austin, j’ai donné une présentation sur l’utilisation de NGINX et NGINX Plus dans un cluster Docker Swarm. Dans cet article, j’explique comment utiliser NGINX et NGINX Plus pour l’équilibrage de charge de Docker Swarm, conjointement avec les fonctionnalités introduites dans Docker 1.12. Tous les fichiers utilisés lors de ma démonstration à nginx.conf (et bien plus encore) sont disponibles sur GitHub pour vous permettre de les tester.

Vue d’ensemble

Docker version 1.12, publié fin juillet 2016, intègre Docker Engine et Swarm et ajoute de nouvelles fonctionnalités d’orchestration afin de créer une plateforme similaire à d’autres plateformes de conteneurs telles que Kubernetes. Dans Docker 1.12, le mode Swarm permet de regrouper un ensemble d’hôtes Docker au sein d’un swarm, offrant ainsi une architecture décentralisée, tolérante aux pannes et autoréparatrice. La nouvelle plateforme facilite également la configuration d’un cluster Swarm, sécurise tous les nœuds à l’aide d’une clé et chiffre toutes les communications entre les nœuds avec TLS.

Parallèlement, l’API Docker a été étendue pour prendre en charge les « services », qui sont des ensembles de conteneurs utilisant la même image (semblables aux services de Docker Compose, mais avec davantage de fonctionnalités). Vous pouvez créer et mettre à l’échelle des services, effectuer des mises à jour progressives, créer des contrôles d’intégrité, et bien plus encore. La découverte de services DNS et l’équilibrage de charge sont intégrés, et vous pouvez également configurer des réseaux overlay à l’échelle du cluster.

Topologie de l’équilibrage de charge dans Docker Swarm

Pour cette présentation et cette démonstration, je dispose de trois nœuds Swarm : un manager et deux workers. Les commandes Swarm sont exécutées sur le nœud manager. Swarm gère l’ordonnancement, la découverte de services DNS, la mise à l’échelle et la répartition de charge entre les conteneurs (représentés dans la figure par les petits rectangles) sur tous les nœuds.

Figure 1. Un cluster Docker Swarm avec un nœud manager et deux nœuds workers

Pour permettre des communications réseau privées entre les conteneurs d’un cluster, ceux-ci peuvent être connectés à plusieurs réseaux overlay internes couvrant tous les nœuds du cluster. Les conteneurs peuvent être rendus accessibles depuis l’extérieur du cluster via l’équilibreur de charge Swarm.

Figure 2. Connectivité réseau interne et externe dans un cluster Docker Swarm

L’équilibreur de charge Docker Swarm s’exécute sur chaque nœud et peut répartir les requêtes entre tous les conteneurs de tous les hôtes du cluster. Dans un déploiement Swarm sans NGINX ni NGINX Plus, l’équilibreur de charge Swarm traite aussi bien les requêtes clientes entrantes (représentées par les flèches vertes dans la Figure 3) que les requêtes internes entre services (représentées par les flèches rouges).

Figure 3. Équilibrage de charge des requêtes client et interservices dans un cluster Swarm sans NGINX ni NGINX Plus

Maintenant que Swarm intègre l’équilibrage de charge, pourquoi auriez-vous besoin d’un autre équilibreur de charge ? L’une des raisons est que l’équilibreur de charge de Swarm est un équilibreur de charge basique de couche 4 (TCP). De nombreuses applications nécessitent des fonctionnalités supplémentaires, dont voici quelques exemples :

• Terminaison SSL/TLS
• Routage basé sur le contenu (par exemple, en fonction de l’URL ou d’un en-tête)
• Contrôle d’accès et autorisation
• Réécritures et redirections

De plus, vous avez peut-être déjà de l’expérience avec un équilibreur de charge. Pouvoir l’utiliser avec Swarm vous permet de tirer parti des outils et des connaissances dont vous disposez déjà.

Utilisation de NGINX Open Source et de NGINX Plus

NGINX Open Source et NGINX Plus sont deux équilibreurs de charge qui offrent des fonctionnalités essentielles aux applications, absentes de l’équilibreur de charge natif de Swarm.

Utilisation de NGINX Open Source

NGINX Open Source fournit les fonctionnalités mentionnées précédemment (terminaison SSL/TLS, etc.), ainsi que d’autres, notamment :

• Un choix d’algorithmes de répartition de charge
• Davantage de protocoles, par exemple HTTP/2 et WebSocket
• Journalisation configurable
• Limites de trafic, notamment le débit de requêtes, la bande passante et le nombre de connexions
• Création de scripts pour les cas d’utilisation avancés à l’aide de Lua, Perl et JavaScript (avec le module dynamique nginScript [Note de l’éditeur – Désormais appelé module dynamique NGINX JavaScript])
• Fonctionnalités de sécurité telles que les listes d’autorisation et de refus

La façon la plus simple d’utiliser NGINX Open Source consiste à le déployer en tant que service, avec un ou plusieurs conteneurs. Les ports nécessaires au service NGINX sont exposés sur le cluster, et les répartiteurs de charge Swarm distribuent les requêtes reçues sur ces ports aux conteneurs NGINX.

Figure 4. Les répartiteurs de charge Swarm distribuent les requêtes destinées aux services NGINX entre les différentes instances

Dans le cadre de cet exemple, le service fourni par NGINX assure la terminaison SSL/TLS. Pour illustrer son fonctionnement, nous déployons un service backend A dans le cluster et le mettons à l’échelle afin qu’il comporte trois conteneurs (deux instances sur un nœud et une instance sur un autre, comme illustré à la Figure 5). Swarm attribue une adresse IP virtuelle (VIP) au service A pour son utilisation au sein du cluster. Nous utilisons cette VIP dans la configuration NGINX du groupe en amont associé au service A, au lieu de répertorier les adresses IP individuelles des conteneurs. Nous pouvons ainsi mettre le service A à l’échelle sans avoir à modifier la configuration NGINX.

Comme illustré à la figure 5, lorsqu’un client envoie une requête destinée au service A au premier nœud Swarm, l’équilibreur de charge Swarm de ce nœud achemine la requête vers NGINX. NGINX traite la requête, en effectuant dans cet exemple le déchiffrement SSL/TLS, puis l’achemine vers l’adresse IP virtuelle (VIP) du service A. L’équilibreur de charge Swarm achemine alors la requête (désormais non chiffrée) vers l’un des conteneurs du service A, sur n’importe lequel des nœuds Swarm.

Figure 5. NGINX assure la terminaison SSL/TLS des requêtes des clients externes

Il est possible de configurer NGINX pour qu’il répartisse la charge des requêtes directement entre les conteneurs backend et qu’il gère également les requêtes internes entre services, mais uniquement au moyen d’une solution plus complexe qui nécessite de modifier et de recharger la configuration de NGINX chaque fois que le service A est mis à l’échelle. J’expliquerai plus loin comment réaliser facilement cette opération avec NGINX Plus.

Utilisation de NGINX Plus

Voici quelques-unes des fonctionnalités supplémentaires offertes par NGINX Plus :

• Contrôles actifs de l’état des applications – NGINX Plus vérifie en permanence les nœuds backend afin de s’assurer qu’ils sont opérationnels et répondent correctement, et retire les nœuds défaillants de la rotation de l’équilibrage de charge.
• Persistance de session – Également appelée « sessions persistantes », elle est nécessaire pour les applications qui exigent que les requêtes des clients continuent d’être envoyées au même serveur backend. NGINX Plus permet de mettre fin progressivement aux sessions lorsque vous devez mettre des serveurs backend hors ligne sans perturber les clients ayant des sessions ouvertes.
• Reconfiguration dynamique – Cette fonctionnalité permet d’augmenter ou de réduire le nombre de serveurs backend sans avoir à modifier ni à recharger la configuration de NGINX. Elle est particulièrement utile pour la découverte de services avec une plateforme de microservices telle que Swarm, et constitue l’une des principales fonctionnalités permettant l’intégration complète de NGINX Plus à ces plateformes. Il existe deux méthodes de reconfiguration dynamique : une API permettant d’envoyer des modifications à NGINX Plus, et le DNS, que NGINX Plus interroge en permanence afin de détecter les changements du nombre de nœuds associés à un nom de domaine. C’est cette dernière méthode qui est utilisée dans cette démonstration de NGINX Plus pour assurer l’intégration avec la découverte de services intégrée à Swarm.
• Surveillance de l’activité en temps réel – Fournit une API permettant d’obtenir des métriques détaillées de NGINX Plus, ainsi qu’un tableau de bord web basé sur cette API, depuis lequel vous pouvez consulter les métriques et ajouter, supprimer ou modifier des serveurs backend.

Dans la configuration NGINX Open Source décrite ci-dessus, l’équilibreur de charge Swarm distribue les requêtes externes aux conteneurs backend et gère également les requêtes interservices entre ceux-ci. Le rôle de NGINX consiste à assurer la terminaison SSL/TLS.

Lors de l’utilisation de NGINX Plus, les requêtes des clients externes atteignent d’abord l’équilibreur de charge Swarm, mais c’est NGINX Plus qui assure l’équilibrage de charge proprement dit vers les conteneurs backend (figure 6). Le fait que les requêtes des clients atteignent d’abord l’équilibreur de charge Swarm permet de garantir facilement la haute disponibilité de NGINX Plus.

Figure 6. L’équilibreur de charge Docker Swarm transmet les requêtes des clients à NGINX Plus, qui les répartit entre les instances de service

De même, l’équilibreur de charge Swarm reçoit les requêtes interservices, mais c’est NGINX Plus qui les répartit effectivement entre les services (figure 7).

Figure 7. L’équilibreur de charge Docker Swarm transmet les requêtes interservices à NGINX Plus, qui les répartit entre les instances de service

Démonstrations

Afin de fournir quelques exemples d’utilisation de Swarm pour la répartition de charge Docker avec et sans NGINX, j’ai créé trois démonstrations. Tous les fichiers associés à ces démonstrations sont disponibles sur GitHub, accompagnés d’instructions détaillées. Les trois démonstrations sont les suivantes :

• Répartition de charge avec Docker Swarm
• Équilibrage de charge Docker Swarm avec NGINX Open Source
• Équilibrage de charge de Docker Swarm avec NGINX Plus

Répartition de charge avec Docker Swarm

Cet exemple illustre la répartition de charge des requêtes par Docker Swarm vers le backend d’une application web simple, sans NGINX ni NGINX Plus.

Équilibrage de charge Docker Swarm avec NGINX Open Source

Cette démonstration ajoute NGINX Open Source afin d’assurer la terminaison SSL/TLS des requêtes externes. L’équilibreur de charge Swarm distribue les requêtes vers le même backend d’application web simple que dans la démonstration précédente et gère les requêtes internes entre services.

Équilibrage de charge Docker Swarm avec NGINX Plus

Cette démonstration comporte deux parties. La première utilise NGINX Plus qui, en plus d’assurer la terminaison SSL/TLS, répartit les requêtes directement entre les conteneurs backend et gère également les requêtes internes entre services. NGINX Plus est intégré à la découverte de services de Swarm et utilise le DNS dynamique pour résoudre à nouveau, à intervalles fréquents, le nom de domaine associé aux backends. NGINX Plus répartit la charge entre deux services backend, Service1 et Service2. Elle illustre les requêtes internes entre services en faisant en sorte que Service1 envoie une requête à Service2.

Figure 8. NGINX Plus utilise le mécanisme de découverte de services DNS dynamique de Swarm pour répartir la charge entre les services backend

La deuxième partie montre comment combiner l’API Status de NGINX avec l’API Service de Docker afin d’adapter automatiquement le nombre de conteneurs backend. Un programme Python utilise l’API Status de NGINX Plus pour surveiller la charge de Service1 et de Service2, ainsi que l’API Service de Docker Swarm pour augmenter ou réduire le nombre de conteneurs backend.

Figure 9. Docker Swarm utilise la surveillance de l’activité en temps réel de NGINX Plus pour suivre la charge des services à des fins de mise à l’échelle automatique

Résumé

Les nouvelles fonctionnalités introduites dans Docker 1.12 font de Swarm une plateforme plus puissante, mais il est possible d’en accroître encore les capacités en tirant parti de NGINX Open Source, et davantage encore en utilisant NGINX Plus. La capacité de NGINX Plus à reconfigurer dynamiquement les conteneurs backend afin de répartir la charge à l’aide du DNS, ainsi que la visibilité offerte par l’API Status, en font une solution de conteneurs très performante.

Pour essayer NGINX Plus, commencez votre essai gratuit de 30 jours dès aujourd’hui ou contactez-nous pour discuter de vos cas d’utilisation.

Et essayez les démonstrations disponibles dans notre dépôt GitHub.

---