‫Donc, ce petit peu de magie n'était pas vraiment magique. C'était le maillage de routage. Le maillage de routage
‫est un réseau entrant ou entrant qui distribue les paquets de notre service aux tâches de ce service,
‫car nous pouvons avoir plusieurs tâches.
‫Cela couvre en fait tous les nœuds et utilise des primitives du noyau qui existent depuis un certain temps et
‫qui s'appellent en réalité IPVS.
‫Nous ne parlons donc pas d'un nouveau service sophistiqué. En réalité, nous ne
‫parlons que des fonctionnalités principales du noyau Linux. Ce qui est réellement fait ici, c'est équilibrer la charge
‫sur tous les nœuds et écouter le trafic sur tous les nœuds.
‫Il y a deux façons de parler de la façon dont cela fonctionne.
‫Le premier exemple va d'un conteneur à un autre.
‫Si notre système backend, comme par exemple les bases de données, passait à deux réplicas, les frontends communiquant avec
‫les backends,
‫ne parleraient pas directement à leur adresse IP.
‫Ils parleraient en fait à quelque chose appelé un VIP ou une adresse IP virtuelle, que Swarm met en avant de
‫tous les services.
‫Il s’agit d’une adresse IP privée à l’intérieur du réseau virtuel de Swarm, qui garantit que la charge est répartie
‫entre toutes les tâches d’un service.
‫Donc, si vous pouvez imaginer si vous avez un rôle de travailleur dans votre application et 10 conteneurs différents, vous n'avez pas besoin de mettre
‫un équilibreur de charge devant cela.
‫Cela fait ça pour toi.
‫Lorsque vous parlez de trafic provenant d’un service de votre réseau virtuel, communiquez avec un autre service
‫de votre réseau virtuel.
‫Et le deuxième exemple de la façon dont fonctionne le maillage de routage est que le trafic externe entrant dans votre
‫essaim peut réellement choisir de frapper l’un des nœuds de votre essaim.
‫Ce port publié sera ouvert sur tous les nœuds de travail et le trafic de ce conteneur sera écouté,
‫puis le trafic sera redirigé vers le conteneur approprié en fonction de son équilibrage de charge.
‫Cela signifie que lorsque vous déployez des conteneurs dans un essaim, vous n'êtes pas censé avoir à vous soucier de savoir sur
‫quel serveur il se trouve car cela pourrait être déplacé, n'est-ce pas?
‫Si un conteneur échoue et que la tâche est recréée par l'essaim, il peut le placer sur un autre noeud. Et vous ne voudrez certainement pas modifier
‫votre pare-feu ou vos paramètres DNS pour que ce conteneur fonctionne à
‫nouveau.
‫Le maillage de routage résout beaucoup de ces problèmes en permettant à notre site Web Drupal sur le port 80 d’être
‫accessible à partir de n’importe quel nœud de l’essaim. Et en arrière-plan, il prend ces paquets de ce
‫serveur puis les achemine vers le conteneur. S'il se trouve sur un autre nœud, il le routera via
‫les réseaux virtuels.
‫S'il se trouve sur le même nœud, il suffit de le rediriger vers le port de ce conteneur.
‫Et nous n’avons rien à faire pour cela.
‫C'était tout hors de la boîte.
‫Voyons un diagramme illustrant comment cela pourrait fonctionner.
‫Si j'ai créé un service de formulaire de News, et je lui ai dit d'avoir trois répliques. Et il a créé trois
‫tâches, avec trois conteneurs, sur trois nœuds. À l'intérieur de ce réseau superposé, il crée en fait une adresse IP virtuelle
‫mappée sur le nom DNS du service, n'est-ce pas? Et le service, par défaut, le nom DNS, est le nom du
‫service.
‫Dans ce cas, j'ai créé un service appelé my-web, et tous les autres conteneurs de mes réseaux superposés devant communiquer
‫avec ce service à l'intérieur de l'essaim, ils n'ont plus qu'à
‫se soucier de l'utilisation du DNS de mon web. L'adresse IP virtuelle correctement chargée fait
‫rebondir le trafic entre toutes les tâches de ce service.
‫Ce n'est pas réellement DNS Round Robin. C'est en fait une configuration légèrement différente. Nous pourrions activer
‫cela si nous le voulions. Il existe en fait une option pour utiliser DNS Round Robin.
‫L'avantage des VIP par rapport aux Round Robin est que, très souvent, nos caches DNS dans nos applications nous empêchent
‫de répartir correctement la charge.
‫Plutôt que de nous battre avec nos clients DNS dans la configuration DNS, nous nous basons simplement sur le
‫VIP, un peu comme si vous aviez acheté un équilibreur de charge matérielle dédié.
‫Dans le deuxième exemple, cela montre ce que serait le trafic externe entrant.
‫Ceci est similaire à ce que nous venons de faire avec Drupal, où lorsque j'ai créé ces boîtes jaunes,
‫en créant un service, appelé mon site Web, il a créé deux tâches et les a appliquées à deux nœuds différents, chacun de ces nœuds
‫ayant une construction -en équilibreur de charge sur l'adresse IP externe. Pour moi, parce que j'utilise DigitalOcean, cette adresse
‫IP est celle que DigitalOcean m'a donnée. Lorsque j'utilise le -p et que je le publie
‫sur un port, dans cet exemple, il utilise le port 80:80, tout trafic entrant dans l'un de ces
‫trois nœuds atteint cet équilibreur de charge sur le port 80:80. L'équilibreur de charge décide quel conteneur doit recevoir le trafic et si ce
‫trafic se trouve ou non sur le nœud local ou s'il doit envoyer le trafic sur
‫le réseau à un autre nœud.
‫Encore une fois, tout se passe à l’arrière-plan sans aucun effort particulier de notre part.
‫D'accord. Voyons ce maillage de routage en action.
‫Nous avons déjà vu l'exemple avec Drupal et son écoute sur les trois nœuds.
‫Mais que se passe-t-il si nous avons plusieurs tâches pour lesquelles cet équilibreur de charge fonctionne?
‫Si nous créons un
‫service Docker, nous allons utiliser un conteneur Elasticsearch. Nous allons appeler cela la recherche et
‫lui donner trois répliques. Et voulez le publier sur le port 9200, qui est son port par défaut.
‫Dans ce cas, nous voulons absolument: 2: il s'agit de la version la plus facile à
‫déployer pour le moment. Cela dit, Elasticsearch
‫est en fait une base de données de recherche accessible via une API Web
‫JSON.
‫Il est donc très facile de jouer avec curl et de nous donner de bons exemples de la façon dont cela fonctionne.
‫Je fais une recherche ps service docker, nous pouvons voir qu'il est intelligemment créé chaque tâche sur un nœud différent.
‫Si je ne fais que courber sur mon hôte local, sur le nœud un sur le port 9200 parce que j'ai publié
‫ce port, je récupèrerai les informations de base Elasticsearch. Une partie de cela est qu'il va effectivement créer un nom
‫aléatoire.
‫Ce n'est qu'une fonctionnalité de Elasticsearch.
‫Si je me plie à plusieurs reprises, vous verrez sur celle-ci qu'il s'agit de Patch, le serveur
‫de correctifs,
‫puis une troisième fois, Jane Foster, puis le processus se répète comme tel.
‫Il s’agit en fait de l’adresse IP virtuelle faisant office d’équilibreur de charge et répartissant ma charge entre
‫les trois tâches.
‫Quelques notes supplémentaires sur le maillage de routage. Dans 17. 03, qui est la version sur laquelle je vous montre
‫cette information, le maillage de routage et l’équilibrage de la charge sont actuellement un équilibreur de charge sans état.
‫Si vous avez déjà traité avec State à l'intérieur de l'équilibreur de charge classique d'Amazon ou d'autres technologies d'équilibrage de charge, vous
‫savez de quoi il en retourne.
‫En gros, cela signifie que si vous devez utiliser des cookies de session sur votre application ou attendez qu'un conteneur
‫cohérent communique avec un client cohérent, vous devrez peut-être ajouter d'autres éléments pour vous aider à
‫résoudre ce problème.
‫En sortie de boîte, chaque fois que vous frappez un service avec plusieurs tâches, vous obtiendrez potentiellement un
‫résultat différent.
‫En outre, si vous entrez dans les détails, il s’agit en fait d’un équilibreur de charge de couche 3, qui fonctionne au
‫niveau de la couche IP et du port.
‫Il ne fonctionne pas réellement au niveau de la couche DNS.
‫Si vous avez déjà exécuté plusieurs sites Web sur le même port, sur le même serveur, cela ne se produira pas
‫encore.
‫Vous aurez encore besoin d'une autre pièce du puzzle
‫si vous souhaitez réellement exploiter plusieurs sites Web sur le même port, sur le même essaim.
‫Heureusement, c'est une demande assez courante et il y a plusieurs options que vous pouvez faire pour résoudre
‫ces deux problèmes.
‫L’un d’eux est d’utiliser Nginx ou HAProxy, il existe d’excellents exemples de conteneurs placés devant votre maillage de routage
‫et agissant comme un équilibreur de charge dynamique ou une couche pour l’équilibreur de charge, qui peut également mettre
‫en cache et plein d'autres choses. Si vous en avez besoin, vous pouvez
‫en vérifier certaines dans les ressources de cette section.
‫Je devrais également mentionner que si vous deviez payer pour un abonnement à Docker Enterprise Edition, ce dernier s'appelle
‫UCP ou Docker Data Center, qui est une interface Web. Mais je devrais mentionner que Docker Enterprise Edition, si
‫vous obtenez un abonnement à cela pour vos nœuds Swarm, elle vient en fait avec une
‫couche intégrée pour le proxy Web qui vous permet de simplement jeter des noms DNS dans la configuration Web de vos
‫services Swarm et tout fonctionne bien.