‫Dus dat beetje magie was eigenlijk geen magie. Het was de Routing Mesh. De Routing Mesh is een
‫inkomend of binnenkomend netwerk dat pakketten voor onze service distribueert naar de taken voor die service, omdat we
‫meer dan één taak kunnen hebben.
‫Dit omvat eigenlijk alle knooppunten, en het gebruikt Kernel-primitieven die al een tijdje bestaan en die
‫eigenlijk IPVS worden genoemd.
‫We hebben het dus niet over een of andere mooie nieuwe dienst. We hebben het eigenlijk
‫alleen over de kernfuncties van de Linux-kernel. Wat het hier echt doet, is de taakverdeling
‫over alle knooppunten en luisteren op alle knooppunten voor verkeer.
‫Er zijn een aantal manieren waarop we kunnen praten over hoe dit werkt.
‫Het eerste voorbeeld is van de ene container naar de andere.
‫Als ons backend-systeem, zoals de databases, zou worden uitgebreid tot twee replica's, zouden de frontends die met
‫de backends
‫praten, niet rechtstreeks met hun IP-adres praten.
‫Ze zouden eigenlijk praten met iets dat een VIP wordt genoemd, of een virtueel IP-adres, dat Swarm voor
‫alle services plaatst.
‫Dit is een privé-IP binnen het virtuele netwerk van Swarm en het zorgt ervoor dat de belasting wordt verdeeld
‫over alle taken voor een service.
‫Dus als u zich kunt voorstellen dat u een werkrol in uw toepassing had en 10 verschillende containers had, hoeft u daar
‫geen load balancer voor te plaatsen.
‫Dit doet dat voor je.
‫Wanneer u het hebt over verkeer van de ene service binnen uw virtuele netwerk die praat met een andere service
‫binnen uw virtuele netwerk.
‫En het tweede voorbeeld van hoe het routeringsnet werkt, is dat extern verkeer dat in je zwerm komt, er daadwerkelijk voor
‫kan kiezen om een van de knooppunten in je zwerm te raken.
‫Elk van de werkknooppunten zal die gepubliceerde poort open hebben en luisteren naar het verkeer van die container, en
‫dan zal het dat verkeer omleiden naar de juiste container op basis van de taakverdeling.
‫Wat dit betekent is dat wanneer je containers in een zwerm inzet, je je niet hoeft te bekommeren om op
‫welke server het staat, want dat zou kunnen verhuizen, toch?
‫Als een container faalt en de taak opnieuw wordt gemaakt door de zwerm, kan deze op een ander knooppunt worden geplaatst. En je wilt zeker niet je firewall
‫of je DNS-instellingen moeten veranderen om die container weer te laten
‫werken.
‫De routing mesh lost veel van die problemen op door onze Drupal-website op poort 80 toegankelijk te
‫maken vanaf elk knooppunt in de zwerm. En op de achtergrond haalt het die pakketten van die
‫server en leidt ze naar de container. Als het zich op een ander knooppunt bevindt, wordt het via
‫de virtuele netwerken gerouteerd.
‫Als het zich op hetzelfde knooppunt bevindt, wordt het gewoon omgeleid naar de poort van die container.
‫En we hoefden niets te doen om dit mogelijk te maken.
‫Dit was allemaal uit de doos.
‫Laten we een diagram bekijken van hoe dit zou kunnen werken.
‫Als ik een nieuwsformulierservice heb gemaakt en ik heb gezegd dat deze drie replica's moet hebben. En het creëerde drie taken,
‫met drie containers, op drie knooppunten. Binnen dat overlay-netwerk creëert het eigenlijk een virtueel IP-adres dat is
‫toegewezen aan de DNS-naam van de service, toch? En de service, standaard de DNS-naam, is de naam van de
‫service.
‫In dit geval heb ik een service gemaakt met de naam my-web, en alle andere containers die ik in mijn overlay-netwerken heb
‫die met die service binnen de zwerm moeten praten, hoeven zich alleen maar
‫zorgen te maken over het gebruik van de my web-DNS. Het virtuele IP-adres wordt correct geladen
‫en stuitert het verkeer tussen alle taken in die service.
‫Dit is niet echt DNS Round Robin. Dat is eigenlijk een iets andere configuratie. We zouden dat kunnen
‫inschakelen als we dat zouden willen. Er is eigenlijk een optie om DNS Round Robin te gebruiken.
‫De voordelen van VIP's ten opzichte van Round Robin zijn dat onze DNS-caches in onze apps vaak voorkomen dat
‫we de belasting goed verdelen.
‫In plaats van te vechten met onze DNS-clients in DNS-configuratie, vertrouwen we gewoon op de VIP, wat een beetje
‫lijkt op wat je zou hebben als je een speciale hardware-load balancer zou kopen.
‫In het tweede voorbeeld laat dit zien hoe het zou zijn als er extern verkeer
‫binnenkomt.
‫Dit is vergelijkbaar met wat we net met Drupal hebben gedaan, toen ik die gele vakken maakte, door
‫één service te maken, mijn web genaamd, en het creëerde twee taken en paste ze toe op twee verschillende knooppunten, elk van die knooppunten
‫heeft een ingebouwde -in load balancer op het externe IP-adres. Voor mij, omdat ik DigitalOcean gebruik, is dat IP-adres
‫het adres dat DigitalOcean me heeft gegeven. Wanneer ik de -p gebruik en deze op een
‫poort publiceer, in dit voorbeeld gebruikt het poort 80:80, al het verkeer dat binnenkomt op een van
‫deze drie knooppunten raakt die load balancer op poort 80:80. De load balancer bepaalt welke container het verkeer moet krijgen en of dat
‫verkeer zich op het lokale knooppunt bevindt, of dat het verkeer via het netwerk naar een
‫ander knooppunt moet worden gestuurd.
‫Nogmaals, dit gebeurt eigenlijk allemaal op de achtergrond zonder enige speciale inspanning van onze kant.
‫Oke. Laten we dit Routing Mesh eens in actie zien.
‫We zagen het voorbeeld al met Drupal en hoe het luistert op alle drie de nodes.
‫Maar wat als we meerdere taken hadden die ervoor zorgen dat die load balancer werkt.
‫Als we een
‫docker-service maken, gaan we een Elasticsearch-container gebruiken. We noemen het zoeken en geven
‫het drie replica's. En wil het publiceren op poort 9200, wat de standaardpoort is.
‫In dit geval willen we zeker de :2 daar hebben, omdat dit de gemakkelijkste versie is
‫om nu te implementeren. Terwijl dat aan het
‫creëren is, zal ik alleen vermelden dat Elasticsearch eigenlijk een zoekdatabase is die toegankelijk is via een
‫JSON-web-API.
‫Het is dus heel gemakkelijk om met curl te slaan en geef ons goede voorbeelden van hoe dit werkt.
‫Ik doe een docker-service ps-zoekopdracht, we kunnen zien dat het elke taak slim op een ander knooppunt heeft gemaakt.
‫Als ik gewoon een curl doe op mijn localhost, op knooppunt één op poort 9200 omdat ik die poort heb
‫gepubliceerd, krijg ik de basisinformatie van Elasticsearch terug. Een deel daarvan is dat het een willekeurige naam zal
‫creëren.
‫Dat is slechts een functie van Elasticsearch.
‫Als ik dit meerdere keren omkrul, zie je hier dat het Patch is, de Patch-server, en
‫dan een
‫derde keer, Jane Foster, en dan begint het zichzelf zo te herhalen.
‫Dat is eigenlijk het virtuele IP-adres dat fungeert als een load balancer en mijn belasting verdeelt over
‫de drie taken.
‫Nog een paar opmerkingen over het routeringsnet. Op 17. 03, de release waarop ik je dit laat
‫zien, zijn de routing mesh en de load balancing momenteel een stateless load balancer.
‫Als je ooit met State te maken hebt gehad in misschien de klassieke load balancer van Amazon of andere load balancer-technologieën,
‫weet je waar dit over gaat.
‫Dit wil eigenlijk zeggen dat als je sessiecookies voor je applicatie moet gebruiken, of als het verwacht dat een consistente
‫container met een consistente client praat, je misschien wat andere dingen moet toevoegen om dat probleem
‫op te lossen.
‫Out of the box, elke keer dat u een service met meerdere taken raakt, krijgt u mogelijk een
‫ander resultaat.
‫Als je hier dieper op ingaat, is het eigenlijk een layer-3 load balancer, en die werkt
‫eigenlijk op de IP- en poortlaag.
‫Het werkt niet echt op de DNS-laag.
‫Als je ooit meerdere websites op dezelfde poort, op dezelfde server hebt gedraaid, zal dit dat nog niet
‫doen.
‫Je hebt daarbovenop nog een stukje van de
‫puzzel nodig als je meerdere websites op dezelfde poort en op dezelfde zwerm wilt draaien.
‫Gelukkig is dat een vrij algemeen verzoek, en er zijn verschillende opties die je kunt doen om beide problemen
‫op te lossen.
‫Een daarvan is om Nginx of HAProxy te gebruiken, waarvan er behoorlijk goede voorbeelden zijn van containers die vooraan met je
‫routeringsmesh zullen zitten, en feitelijk fungeren als een stateful load balancer of een laag voor load balancer, die ook caching
‫kan doen en tal van andere dingen. Als je dat nodig hebt, kun je
‫er een paar bekijken in de bronnen van deze sectie.
‫Ik moet ook vermelden dat als je zou betalen voor een abonnement op de Docker Enterprise-editie, er iets komt dat
‫UCP of Docker Data Center wordt genoemd, wat een webinterface is. Maar ik moet die Docker Enterprise-editie vermelden, als
‫je daar een abonnement op krijgt voor je zwermknooppunten, het komt eigenlijk met
‫een ingebouwde laag voor webproxy waarmee je gewoon DNS-namen in de webconfiguratie van je zwermservices kunt gooien
‫en alles werkt gewoon.