Lors de nginx.conf 2016 à Austin en septembre, j'ai fait 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 Docker Swarm en conjonction avec les fonctionnalités introduites dans Docker 1.12. Tous les fichiers que j'ai utilisés lors de ma démonstration sur nginx.conf (et plus) sont disponibles sur GitHub pour que vous puissiez expérimenter.
La version 1.12 de Docker, publiée fin juillet 2016, intègre Docker Engine et Swarm et ajoute de nouvelles fonctionnalités d'orchestration, pour créer une plateforme similaire à d'autres plateformes de conteneurs telles que Kubernetes. Dans Docker 1.12, le mode Swarm vous permet de combiner un ensemble d'hôtes Docker dans un essaim , offrant ainsi une architecture décentralisée, tolérante aux pannes et auto-réparatrice. La nouvelle plateforme facilite également la configuration d'un cluster Swarm, sécurise tous les nœuds avec une clé et crypte toutes les communications entre les nœuds avec TLS.
Dans le même temps, l'API Docker a été étendue pour prendre en compte les services , qui sont des ensembles de conteneurs qui utilisent la même image (similaires aux services dans Docker Compose, mais avec plus de fonctionnalités). Vous pouvez créer et faire évoluer des services, effectuer des mises à jour continues, créer des contrôles de santé, et bien plus encore. La découverte du service DNS et l’équilibrage de charge sont intégrés et vous pouvez également configurer des réseaux superposés à l’échelle du cluster.
Pour cette discussion et démonstration, j’ai trois nœuds Swarm – un gestionnaire et deux travailleurs. Le nœud gestionnaire est l'endroit où les commandes Swarm sont exécutées. Swarm gère la planification, la découverte du service DNS, la mise à l'échelle et l'équilibrage de la charge des conteneurs (représentés dans la figure par les petites cases) sur tous les nœuds.
Pour fournir des communications réseau privées entre les conteneurs à l'intérieur d'un cluster, les conteneurs peuvent être connectés à plusieurs réseaux de superposition internes qui s'étendent sur tous les nœuds du cluster. Les conteneurs peuvent être exposés en dehors du cluster via l'équilibreur de charge Swarm.
L'équilibreur de charge Docker Swarm s'exécute sur chaque nœud et peut équilibrer la charge des demandes sur n'importe lequel des conteneurs sur n'importe lequel des hôtes du cluster. Dans un déploiement Swarm sans NGINX ou NGINX Plus, l'équilibreur de charge Swarm gère les demandes client entrantes (représentées par les flèches vertes dans la Figure 3) ainsi que les demandes internes de service à service (représentées par les flèches rouges).
Maintenant que Swarm inclut l’équilibrage de charge, pourquoi auriez-vous besoin d’un autre équilibreur de charge ? L’une des raisons est que l’équilibreur de charge Swarm est un équilibreur de charge de couche 4 (TCP) de base. De nombreuses applications nécessitent des fonctionnalités supplémentaires, comme celles-ci, pour n'en citer que quelques-unes :
De plus, vous avez peut-être déjà de l’expérience avec un équilibreur de charge, et le fait de pouvoir l’utiliser avec Swarm vous permet de profiter des outils et des connaissances que vous utilisez déjà.
NGINX Open Source et NGINX Plus sont deux équilibreurs de charge qui fournissent des fonctionnalités critiques pour les applications qui manquent à l'équilibreur de charge Swarm natif.
NGINX Open Source fournit les fonctionnalités mentionnées précédemment (terminaison SSL/TLS, etc.) et bien plus encore, notamment :
La manière la plus simple d'utiliser NGINX Open Source est de 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 équilibreurs de charge Swarm distribuent les requêtes sur ces ports aux conteneurs NGINX.
Pour les besoins de cet exemple, le service fourni par NGINX est la terminaison SSL/TLS. Pour illustrer son fonctionnement, nous déployons un service backend A dans le cluster et le mettons à l’échelle pour avoir trois conteneurs (deux instances sur un nœud et une instance sur un autre, comme illustré dans la Figure 5). Swarm attribue une adresse IP virtuelle (VIP) au service A pour une utilisation à l'intérieur du cluster. Nous utilisons ce VIP dans la configuration NGINX du groupe en amont pour le service A, plutôt que de répertorier les adresses IP individuelles des conteneurs. De cette façon, nous pouvons faire évoluer le service A sans avoir à modifier la configuration NGINX.
Comme illustré dans la Figure 5, lorsqu'un client envoie une demande de service A au premier nœud Swarm, l'équilibreur de charge Swarm de ce nœud achemine la demande vers NGINX. NGINX traite la demande, dans cet exemple en effectuant un déchiffrement SSL/TLS, et l'achemine vers le VIP du service A. L'équilibreur de charge Swarm achemine la demande (désormais non chiffrée) vers l'un des conteneurs du service A, sur l'un des nœuds Swarm.
Il est possible d'équilibrer la charge des requêtes NGINX directement vers les conteneurs principaux et de gérer également les requêtes internes de service à service, mais uniquement avec une solution plus complexe qui nécessite de modifier et de recharger la configuration NGINX à chaque fois que le service A est mis à l'échelle. Je discuterai plus tard de la manière dont cela est facilement accompli avec NGINX Plus.
Certaines des fonctionnalités supplémentaires fournies par NGINX Plus sont :
Reconfiguration dynamique : cela permet de faire évoluer les backends vers le haut ou vers le bas sans nécessiter que la configuration NGINX soit modifiée et rechargée. Cela est particulièrement utile lors de la découverte de services avec une plate-forme de microservices telle que Swarm, et c'est l'une des fonctionnalités les plus importantes qui permet à NGINX Plus d'être entièrement intégré à ces plates-formes.
Il existe deux méthodes de reconfiguration dynamique : une API qui vous permet d'appliquer des modifications à NGINX Plus, et DNS, que NGINX Plus vérifie en permanence pour détecter les modifications du nombre de nœuds attachés à un nom de domaine. Il s’agit de la méthode utilisée dans cette démonstration NGINX Plus pour s’intégrer à la découverte de services intégrée dans Swarm.
Dans la configuration NGINX Open Source décrite ci-dessus , l’équilibreur de charge Swarm distribue les requêtes externes aux conteneurs back-end et gère les requêtes de service à service entre eux. Le rôle de NGINX est le déchargement SSL/TLS.
Lors de l'utilisation de NGINX Plus, les demandes des clients externes atteignent d'abord l'équilibreur de charge Swarm, mais NGINX Plus effectue l'équilibrage de charge réel vers les conteneurs back-end (Figure 6). Le fait que les demandes des clients atteignent d'abord l'équilibreur de charge Swarm offre un moyen simple de rendre NGINX Plus hautement disponible.
De même, l’équilibreur de charge Swarm reçoit des demandes interservices, mais NGINX Plus les répartit en réalité entre les services (Figure 7).
Pour fournir quelques exemples d’utilisation de Swarm pour l’équilibrage de charge Docker avec et sans NGINX, j’ai créé trois démonstrations. Tous les fichiers de ces démonstrations sont disponibles sur GitHub , accompagnés d'instructions détaillées. Les trois manifestations sont :
Cela démontre l'équilibrage de charge Docker Swarm des requêtes vers un backend d'application Web simple, sans NGINX ou NGINX Plus.
Cette démo ajoute NGINX Open Source pour fournir un déchargement SSL/TLS pour les requêtes externes. L'équilibreur de charge Swarm distribue les requêtes au même backend d'application Web simple que dans la démo précédente et gère les requêtes internes de service à service.
Cette démo comporte deux parties. La première partie utilise NGINX Plus, qui, en plus d’effectuer le déchargement SSL/TLS, équilibre la charge des requêtes directement vers les conteneurs back-end et gère également les requêtes internes de service à service. Il est intégré à la découverte de services Swarm, utilisant un DNS dynamique pour résoudre fréquemment le nom de domaine associé aux backends. NGINX Plus équilibre la charge de deux services backend, Service1 et Service2 . Il démontre les demandes internes de service à service en demandant à Service1 d'adresser une demande à Service2 .
La deuxième partie montre comment vous pouvez combiner l’API NGINX Status avec l’API Docker Service pour mettre à l’échelle automatiquement les conteneurs backend. Un programme Python utilise l'API NGINX Plus Status pour surveiller la charge sur Service1 et Service2 , et l'API Docker Swarm Service pour augmenter ou diminuer les conteneurs backend.
Les nouvelles fonctionnalités introduites dans Docker 1.12 font de Swarm une plateforme plus puissante, mais elle peut être améliorée en tirant parti de NGINX Open Source et encore plus en utilisant NGINX Plus. La capacité de NGINX Plus à reconfigurer dynamiquement les conteneurs back-end pour équilibrer la charge à l'aide de DNS, ainsi que la visibilité fournie par l'API Status, constituent une solution de conteneur très puissante.
Pour essayer NGINX Plus, démarrez 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 sur notre dépôt GitHub .
« 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."