Hallo zusammen und willkommen zurück.
Im heutigen Video werden wir nun über die Zuhörer und Zielgruppen in den Lastverteilungen sprechen.
Nun, auf hoher Ebene ist ein Listener ein Prozess, der die Verbindungsanforderung mit dem von Ihnen
konfigurierten Protokoll und Port überprüft.
Dies lässt sich nun besser mit diesem Diagramm erklären, in dem Sie den Load Balancer haben und dieser Load
Balancer zwei Listener hat.
Der erste Listener hier ist dem Protokoll des HTTP-Ports 80 zugeordnet.
Der zweite Listener ist mit einem HTTPS-Protokoll und einem Port von vier, vier, drei verbunden.
Das würde also bedeuten, dass der Load Balancer, da er zwei Listener hat, sowohl die HTTP-basierte
Anfrage als auch die HTTPS-basierte Anfrage abhören kann.
Also lasst uns eine Sache tun.
Lassen Sie uns weitermachen und schnell einen Blick darauf werfen.
Jetzt habe ich derzeit einen Load Balancer für Beispielanwendungen, der verfügbar ist, und darin haben Sie eine Listener-Registerkarte,
und darin können Sie fortfahren und einen Listener hinzufügen.
Wenn Sie sich jetzt das Protokoll ansehen, haben Sie ein HTTP, Sie haben ein HTTP, senden Sie es, und so weiter.
Jetzt können Sie je nach Listener-Protokoll auch Ihren eigenen benutzerdefinierten Port definieren.
Nehmen wir zum Beispiel an, ich füge einen Listener auf Port 81 hinzu.
Das würde also bedeuten, dass unser Load Balancer fortfährt und Port 81 auf die empfangenen Client-Anforderungen
überwacht.
Nun, eine der Fragen, die gestellt werden, ist, nehmen wir an, dass diese Anfrage an den Load Balancer
gekommen ist, der http example dot com ist.
Jetzt ist dies eine HTTP-basierte Anfrage.
Das ging also an den Listener One, da Listener One dem Port 80 zugeordnet ist.
Da diese Anfrage nun dem ersten Listener zugeordnet ist, was ist der nächste Schritt?
Welche Aktion würde bei dieser speziellen Anfrage durchgeführt werden?
Wird diese Anfrage an den Backend-Server gesendet?
Wird diese Anfrage blockiert oder werden andere Aktionen durchgeführt, die für diese Anfrage durchgeführt werden?
Lassen Sie uns weitermachen und es untersuchen.
Der zweite wichtige Teil als Teil des Listeners ist also der Regelabschnitt.
Jetzt hat jeder Listener eine Regel, auf deren Grundlage eine Aktion bei einer bestimmten Anfrage ausgeführt wird.
Nun, wir haben bereits gesehen, dass diese HTTP-Anforderung ein Beispiel für dot com ist, das an die alb.
Dies wird einem Zuhörer zugeordnet.
Nun kann dieser Zuhörer einem bestimmten Satz von Regelsätzen zugeordnet werden.
Nun können diese Regelsätze vom Benutzer oder Administrator definiert werden, auf deren Grundlage die Aktion ausgeführt
wird.
In diesem Diagramm gibt es beispielsweise drei Regeln.
Diese Regeln prüfen also im Wesentlichen den Inhalt der Anfrage.
Hier wird also zuerst überprüft, ob der Benutzeragent Mozilla ist.
Ob es also beispielsweise von einem Firefox-Browser kommt, es prüft, ob ein Host-Header demo dot
com ist.
Es wird auch überprüft, ob es sich bei dem Pfad um Videos handelt.
Das sind also die drei Regelsätze, die dem Listener hinzugefügt werden.
Wenn nun diese Anforderung mit einer dieser Regeln übereinstimmt, ist es nicht erforderlich, dass sie mit allen diesen Regeln übereinstimmt,
selbst wenn sie mit einer der Regeln übereinstimmt.
Der nächste Schritt ist die Aktion, die für diese Anfrage ausgeführt wird.
Angenommen, diese Anfrage entspricht der ersten Regel, nämlich dass der Benutzeragent in dieser Anfrage
Firefox ist.
Was wird Ihre Elbe nun tun?
Hier kommen die Regelaktionen ins Bild.
Wenn beispielsweise eine Anforderung mit einer bestimmten Regel übereinstimmt, wird in der Regelaktion festgelegt, welche Aktionen Sie für
diese Anforderung ausführen möchten.
Angenommen, die Anfrage entspricht der ersten Regel, nämlich der Benutzeragent ist Mozilla.
Für diese Anfrage stehen also mehrere Regelaktionen zur Verfügung.
Sie können diese Anfragen an eine Reihe von Servern weiterleiten.
Je nachdem, was Sie beabsichtigen, können Sie diese Anfrage an eine bestimmte Domäne umleiten oder eine bestimmte
Antwort an den Client zurücksenden.
Schauen wir also schnell hinein.
Kehren wir zu unserem Load Balancer in unseren Listenern zurück.
Ich klicke schnell auf Regeln anzeigen und bearbeiten.
Gut.
Hier sehen Sie nun, dass insgesamt vier Regeln verfügbar sind.
Das sind also die vier Listener-Regeln, bei denen überprüft wird, ob der Benutzeragent angerufen wird, es wird überprüft,
ob der Benutzeragent Mozilla ist, es wird überprüft, ob der Benutzeragent W-Gate ist, und wenn die Anforderung nicht mit diesen
drei übereinstimmt, dann Sie eine weitere Regel haben, die festlegt, was mit den Anfragen passiert, die nicht mit den ersten drei
Regeln übereinstimmen.
Wenn Sie sich also die erste Regel ansehen, die besagt, ob die Anfrage den spezifischen User-Agent-Header
hat, dann sind das im Grunde die Regelaktionen, die wir bestimmt haben.
Hier in dieser Regelaktion geben wir also eine feste Antwort zurück, und die Antwort ist
höchste Alarmstufe.
Das ist also die Regelaktion hier drüben.
Sie haben auch eine weitere Bitte an Mozilla.
Wenn Sie sich die Regelaktion ansehen, gibt sie eine andere Antwort zurück.
Diese Return-Fix-Antwort ist also nichts anderes als die dritte.
Alles Aktionen, die wir hier gesehen haben.
Gut.
Probieren wir es jetzt noch einmal schnell praktisch aus.
Nur zum Überarbeiten.
Also kopiere ich den DNS-Namen unseres Load Balancers.
Also von meinem Terminal, wenn wir hier drüben telefonieren, bekommen wir eine Nachricht.
Anrufer Hallo, rufen Sie an, wenn wir ein W-Gate auf diesem speziellen Load Balancer durchführen.
Und wenn wir uns das Indexpunkt-HTML ansehen, erhalten Sie dieses Mal eine spezifische Antwort.
Hier kommen also unsere Regelaktionen ins Spiel, bei denen eine bestimmte Regel mit dem Load Balancer übereinstimmt, eine
Rückantwort mit fester Antwort ausführt und in der Rückantwort mit fester Antwort sofort eine Nachricht zurücksendet.
Der zweite wichtige Begriff ist die Zielgruppe.
Eine Zielgruppe wird also verwendet, um eine Anfrage an ein oder mehrere registrierte Ziele zu verwurzeln.
Und diese registrierten Ziele können einfach sein.
Zwei Instanzen, Lambda-Funktionen und so weiter.
In diesem Diagramm gibt es beispielsweise zwei Zielgruppen.
Zielgruppe eins ist einer 3c2-Instanz zugeordnet, Zielgruppe zwei ist einer Lambda-Funktion zugeordnet.
Und was wir können, ist, wir können auch eine Zielgruppe mit einem Zuhörer in Verbindung bringen.
Wenn Sie sich beispielsweise die Regelaktion ansehen, gibt es eine Regelaktion, die zwei weiterleitet, und diese für zwei
ermöglicht es uns, die Anfrage an eine bestimmte Zielgruppe weiterzuleiten.
Listener eins ist also mit Zielgruppe eins verbunden, wo es zwei C-Zwei-Instanzen gibt.
Listener zwei ist der Zielgruppe zwei zugeordnet, wo eine verfügbare Lambda-Funktion vorhanden ist.
Also schauen wir uns das auch schnell an.
Jetzt haben Sie im Load-Balancing-Bereich sowohl einen Load-Balancer als auch die Zielgruppe.
Jetzt haben Sie derzeit eine Zielgruppe, die für die heutige Demo verfügbar ist.
Wenn wir uns nun diese Zielgruppe ansehen und ich die Ziele hier drüben öffne, sehen Sie, dass zwei Ziele verfügbar
sind, und dies sind nichts anderes als die einfach zu instanziierenden Ziele, die mit der Zielgruppe und
vom Load Balancer verknüpft sind.
Schauen wir uns schnell die Listener-Regeln hier drüben an.
Hier können Sie fortfahren und eine Regel hinzufügen.
Nehmen wir an, wenn eine Bedingung zutrifft, sagen wir, wenn eine Anfrage zu dem Teil des Videos kommt, wenn Sie auf Weiterleiten
an innerhalb klicken, können Sie hier die Zielgruppe angeben und diese Anfrage wird an die zwei Instanzen von Lambda-Funktionen
weitergeleitet, die das sehen gehören zu dieser Zielgruppe.
Gut.
Ich hoffe also, dass Sie mit diesem Überblick auf hohem Niveau das Konzept der Hörer- und Zielgruppen verstanden haben.
Wenn Sie dieses Konzept nun klar verstanden haben, wird das Erstellen eines Load Balancers und der damit verbundenen
komplexen Konfiguration für Sie viel einfacher.
Damit wird das heutige Video abgeschlossen.