‫Das bisschen Magie war also eigentlich keine Magie. Es war das Routing Mesh. Das Routing Mesh ist ein
‫eingehendes oder eingehendes Netzwerk, das Pakete für unseren Dienst an die Aufgaben für diesen Dienst verteilt, da wir
‫mehr als eine Aufgabe haben können.
‫Dies erstreckt sich tatsächlich über alle Knoten und verwendet Kernel-Primitive, die seit einiger Zeit als
‫IPVS bezeichnet werden.
‫Es handelt sich also nicht um einen ausgefallenen neuen Service. Wir sprechen hier
‫nur über die Kernfunktionen des Linux-Kernels. Was hier wirklich getan wird, ist der Lastenausgleich
‫über alle Knoten und das Abhören aller Knoten auf Datenverkehr.
‫Wir können auf verschiedene Arten darüber sprechen, wie dies funktioniert.
‫Das erste Beispiel ist von einem Container zum anderen.
‫Wenn unser Backend-System, wie beispielsweise die Datenbanken, auf zwei Replikate erhöht würde, würden die Frontends, die mit
‫den Backends
‫kommunizieren, nicht direkt mit ihrer IP-Adresse kommunizieren.
‫Sie würden tatsächlich mit so etwas wie einem VIP oder einer virtuellen IP sprechen, die Swarm vor
‫alle Dienste stellt.
‫Dies ist eine private IP innerhalb des virtuellen Netzwerks von Swarm und stellt sicher, dass die Last auf alle
‫Aufgaben für einen Dienst verteilt wird.
‫Wenn Sie sich also vorstellen können, dass Ihre Anwendung eine Worker-Rolle und 10 verschiedene Container enthält, müssen Sie keinen
‫Load Balancer davor stellen.
‫Das macht das für dich.
‫Wenn Sie über Datenverkehr von einem Dienst in Ihrem virtuellen Netzwerk sprechen, sprechen Sie mit einem anderen Dienst
‫in Ihrem virtuellen Netzwerk.
‫Und das zweite Beispiel für die Funktionsweise des Routing-Netzes ist, dass der externe Verkehr, der in Ihren Schwarm
‫gelangt, tatsächlich einen der Knoten in Ihrem Schwarm treffen kann.
‫Auf jedem Worker-Knoten ist dieser veröffentlichte Port geöffnet und wartet auf den Datenverkehr dieses Containers. Anschließend
‫wird der Datenverkehr auf der Grundlage des Lastenausgleichs an den richtigen Container umgeleitet.
‫Dies bedeutet, dass Sie sich beim Bereitstellen von Containern in einem Schwarm nicht darum kümmern müssen, auf welchem
‫Server sie sich befinden, da sich diese möglicherweise verschieben, oder?
‫Wenn ein Container ausfällt und die Aufgabe vom Schwarm neu erstellt wird, wird sie möglicherweise auf einem anderen Knoten abgelegt. Und Sie möchten auf keinen Fall
‫Ihre Firewall oder Ihre DNS-Einstellungen ändern müssen, damit dieser Container wieder
‫funktioniert.
‫Das Routing-Netz löst viele dieser Probleme, indem unsere Drupal-Website auf Port 80 von jedem
‫Knoten im Schwarm aus zugänglich ist. Und im Hintergrund werden diese Pakete von diesem Server
‫genommen und dann an den Container weitergeleitet. Wenn es sich auf einem anderen Knoten befindet, wird es über
‫die virtuellen Netzwerke weitergeleitet.
‫Wenn es sich auf demselben Knoten befindet, wird es nur zum Port dieses Containers umgeleitet.
‫Und wir mussten nichts tun, um dies zu ermöglichen.
‫Das war alles out of the box.
‫Schauen wir uns ein Diagramm an, wie das funktionieren könnte.
‫Wenn ich einen Newsform-Service erstellt und ihm drei Replikate zugewiesen habe. Dabei wurden drei Aufgaben mit
‫drei Containern auf drei Knoten erstellt. In diesem Overlay-Netzwerk wird tatsächlich eine virtuelle IP erstellt, die
‫dem DNS-Namen des Dienstes zugeordnet ist, oder? Und der Dienst, standardmäßig der DNS-Name, ist der Name des
‫Dienstes.
‫In diesem Fall habe ich einen Dienst namens my-web erstellt, und alle anderen Container in meinen Overlay-Netzwerken,
‫die mit diesem Dienst im Schwarm kommunizieren müssen, müssen sich
‫nur um die Verwendung des my-web-DNS kümmern. Durch die ordnungsgemäße Auslastung der virtuellen IP
‫wird der Datenverkehr zwischen allen Aufgaben in diesem Dienst umgeleitet.
‫Dies ist nicht wirklich DNS Round Robin. Das ist eigentlich eine etwas andere Konfiguration. Wir könnten das
‫ermöglichen, wenn wir wollten. Es gibt tatsächlich eine Option zur Verwendung von DNS Round Robin.
‫Der Vorteil von VIPs gegenüber Round Robin besteht darin, dass unsere DNS-Caches in unseren Apps uns häufig daran hindern,
‫die Last richtig zu verteilen.
‫Anstatt mit unseren DNS-Clients in der DNS-Konfiguration zu kämpfen, verlassen wir uns nur auf den VIP. Das entspricht
‫in etwa dem, was Sie hätten, wenn Sie einen dedizierten Hardwarelastausgleich gekauft hätten.
‫Im zweiten Beispiel zeigt dies tatsächlich, wie es wäre, wenn externer Verkehr hereinkäme.
‫Dies ist vergleichbar mit dem, was wir gerade mit Drupal gemacht haben, als ich diese gelben Felder erstellt
‫habe, indem ich einen Dienst namens "Mein Web" erstellt und zwei Aufgaben erstellt und diese auf zwei verschiedene Knoten angewendet habe. Jeder dieser Knoten
‫hat einen eingebauten -in Load Balancer auf der externen IP-Adresse. Für mich ist diese IP-Adresse die, die mir
‫DigitalOcean gegeben hat, weil ich DigitalOcean verwende. Wenn ich das -p verwende und es auf
‫einem Port veröffentliche, in diesem Beispiel auf Port 80:80, trifft jeder Datenverkehr, der zu einem dieser
‫drei Knoten gelangt, den Load Balancer auf Port 80:80. Der Lastenausgleich entscheidet, welcher Container den Datenverkehr abrufen soll und ob sich dieser
‫Datenverkehr auf dem lokalen Knoten befindet oder nicht, oder er muss den Datenverkehr über das Netzwerk
‫an einen anderen Knoten senden.
‫Auch dies geschieht eigentlich alles im Hintergrund, ohne dass unsererseits besondere Anstrengungen erforderlich sind.
‫Gut. Lassen Sie uns dieses Routing-Netz in Aktion sehen.
‫Wir haben bereits das Beispiel mit Drupal gesehen und wie es auf allen drei Knoten lauscht.
‫Was wäre, wenn wir mehrere Aufgaben hätten, bei denen der Load Balancer funktioniert?
‫Wenn wir einen
‫Docker-Dienst erstellen, verwenden wir einen Elasticsearch-Container. Wir werden es Suche nennen und es
‫drei Repliken geben. Und möchten es auf Port 9200 veröffentlichen, der sein Standardport ist.
‫In diesem Fall möchten wir auf jeden Fall die: 2, da dies die derzeit am einfachsten
‫zu implementierende Version ist. Beim Erstellen erwähne
‫ich nur, dass Elasticsearch eine Suchdatenbank ist, auf die über eine JSON-Web-API zugegriffen werden
‫kann.
‫Es ist also wirklich einfach, mit Locken zu schlagen und uns gute Beispiele zu geben, wie dies funktioniert.
‫Wenn ich eine Docker-Dienst-PS-Suche durchführe, können wir feststellen, dass jede Aufgabe auf einem anderen Knoten erstellt wurde.
‫Wenn ich auf meinem Localhost auf Knoten 1 auf Port 9200 nur eine Locke mache, weil ich diesen Port
‫veröffentlicht habe, erhalte ich die grundlegenden Elasticsearch-Informationen zurück. Dazu gehört, dass tatsächlich ein zufälliger Name erstellt
‫wird.
‫Das ist nur eine Funktion von Elasticsearch.
‫Wenn ich das mehrmals mache, siehst du auf diesem einen Patch, den Patch-Server und dann
‫ein drittes
‫Mal Jane Foster, und dann beginnt es, sich so zu wiederholen.
‫Das ist eigentlich die virtuelle IP, die als Lastausgleich fungiert und meine Last auf die drei
‫Aufgaben verteilt.
‫Noch ein paar Anmerkungen zum Routing-Netz. In 17. 03, das ist die Version, auf der
‫ich Ihnen dies zeige. Das Routing-Netz und der Lastenausgleich sind derzeit ein zustandsloser Lastenausgleich.
‫Wenn Sie sich jemals mit dem Status von Amazon oder anderen Load-Balancer-Technologien befasst haben, wissen
‫Sie, worum es geht.
‫Dies bedeutet im Grunde, dass Sie möglicherweise einige andere Dinge hinzufügen müssen, um das Problem zu lösen, wenn Sie
‫Sitzungscookies für Ihre Anwendung verwenden müssen oder wenn erwartet wird, dass ein konsistenter Container mit einem
‫konsistenten Client kommuniziert.
‫Jedes Mal, wenn Sie einen Dienst mit mehreren Aufgaben ausführen, erhalten Sie automatisch ein
‫anderes Ergebnis.
‫Wenn Sie auf die Details eingehen, handelt es sich tatsächlich um einen Layer-3-Load-Balancer, der tatsächlich auf
‫der IP- und Port-Ebene ausgeführt wird.
‫Es funktioniert nicht wirklich auf der DNS-Ebene.
‫Wenn Sie jemals mehrere Websites auf demselben Port und auf demselben Server betrieben haben, ist dies noch nicht der
‫Fall.
‫Darüber hinaus benötigen Sie noch einen weiteren Teil
‫des Puzzles, wenn Sie tatsächlich mehrere Websites auf demselben Port und mit demselben Schwarm ausführen möchten.
‫Glücklicherweise ist dies eine recht häufige Anfrage, und Sie können verschiedene Möglichkeiten nutzen, um beide
‫Probleme zu lösen.
‫Eine davon ist die Verwendung von Nginx oder HAProxy. Es gibt einige gute Beispiele für Container, die sich vor
‫Ihrem Routing-Mesh befinden und tatsächlich als Stateful Load Balancer oder Layer für Load Balancer fungieren, der auch Caching
‫ausführen kann und viele andere Dinge. Wenn Sie das brauchen, können Sie
‫einige davon in den Ressourcen dieses Abschnitts nachlesen.
‫Ich sollte auch erwähnen, dass, wenn Sie für ein Abonnement der Docker Enterprise Edition bezahlen, ein Produkt namens
‫UCP oder Docker Data Center (eine Webschnittstelle) mitgeliefert wird. Aber ich sollte erwähnen, dass Docker Enterprise
‫Edition, wenn Sie ein Abonnement für Ihre Schwarmknoten erhalten, tatsächlich eine eingebaute
‫Schicht für Web-Proxy enthält, mit der Sie DNS-Namen einfach in die Web-Konfiguration Ihrer Schwarmdienste werfen können
‫und alles funktioniert einfach.