Ich lade Sie ein, sich mit der Transkription des Berichts von Alexander Sigachev über Service Discovery in verteilten Systemen am Beispiel von Consul vertraut zu machen.
Service Discovery wurde entwickelt, um ein neues Anwendung mit minimalen Kosten in unsere bestehende Umgebung einzufügen. Durch die Nutzung von Service Discovery können wir entweder einen Container in Form von Docker oder einen virtuellen Dienst maximal von der Umgebung trennen, in der er ausgeführt wird.
Ich grüße alle! Ich bin Alexander Sigachev, arbeite bei der Firma Inventos. Heute möchte ich Ihnen ein Konzept wie Service Discovery vorstellen. Wir betrachten Service Discovery am Beispiel von Consul.
Welche Probleme löst Service Discovery? Service Discovery wurde entwickelt, um ein neues Anwendung mit minimalen Kosten in unsere bestehende Umgebung einzufügen. Durch die Nutzung von Service Discovery können wir entweder einen Container in Form von Docker oder einen virtuellen Dienst maximal von der Umgebung trennen, in der er ausgeführt wird.
Wie sieht das aus? Am klassischen Beispiel im Web – es gibt ein Frontend, das die Benutzeranfrage entgegennimmt. Danach leitet es sie an das Backend weiter. In diesem Beispiel balanciert der Load-Balancer zwischen zwei Backends.
Hier sehen wir, dass wir eine dritte Instanz der Anwendung starten. Wenn die Anwendung gestartet wird, registriert sie sich bei Service Discovery. Service Discovery benachrichtigt den Load-Balancer. Der Load-Balancer ändert automatisch seine Konfiguration, und das neue Backend wird bereits in Betrieb genommen. Auf diese Weise können Backends hinzugefügt oder umgekehrt aus dem Betrieb ausgeschlossen werden.
Was kann man noch bequem mit Service Discovery tun? In Service Discovery können Konfigurationen für nginx, Zertifikate und eine Liste aktiver Backend-Server gespeichert werden.
Außerdem ermöglicht Service Discovery die Erkennung von Ausfällen und Störungen. Welche möglichen Schemen gibt es bei der Erkennung von Störungen?
- Diese Anwendung, die wir entwickelt haben, benachrichtigt Service Discovery selbst, dass sie weiterhin funktionsfähig ist.
- Service Discovery fragt seinerseits die Anwendung über die Verfügbarkeit ab.
- Oder es wird ein externes Skript oder eine Anwendung verwendet, die unsere Anwendung auf ihre Verfügbarkeit überprüft und Service Discovery benachrichtigt, dass alles in Ordnung ist und weiterarbeiten kann, oder umgekehrt, dass alles schlecht ist und diese Instanz der Anwendung aus der Lastverteilung ausgeschlossen werden muss.
Jedes der Schemas kann abhängig von der verwendeten Software angewendet werden. Wenn wir beispielsweise gerade ein neues Projekt entwickeln, können wir problemlos ein Schema implementieren, bei dem unsere Anwendung Service Discovery benachrichtigt. Alternativ können wir auch annehmen, dass Service Discovery die Überprüfung durchführt.
Wenn die Anwendung jedoch von uns übernommen wurde oder von einem Dritten entwickelt wurde, passt hier die dritte Option, bei der wir einen Handler schreiben, und dies automatisiert in unsere Arbeit eingefügt wird.
Das ist eines der Beispiele. Der Load Balancer in Form von nginx wird neu gestartet. Das ist ein zusätzliches Tool, das zusammen mit Consul bereitgestellt wird. Das nennt sich consul-template. Wir beschreiben eine Regel. Wir geben an, dass wir eine Vorlage verwenden (Template Engine von Golang). Bei Ereignissen, bei Benachrichtigungen über Änderungen, wird es neu generiert, und Service Discovery erhält den Befehl „reload“. Ein einfaches Beispiel ist, dass nginx bei einem Ereignis neu konfiguriert und neu gestartet wird.
Was ist Consul?
Zunächst einmal ist es Service Discovery.
Es verfügt über einen Verfügbarkeitsprüfungsmechanismus – Health Checking.
Außerdem verfügt es über einen KV Store.
Und es ist in der Lage, Multi-Datacenter zu unterstützen.
Wozu kann all dies verwendet werden? Im KV Store können wir Konfigurationsbeispiele speichern. Mit Health Checking können wir lokale Dienste überprüfen und Benachrichtigungen senden. Multi-Datacenter wird verwendet, um eine Karte von Diensten zu erstellen. Zum Beispiel hat Amazon mehrere Zonen und leitet den Verkehr optimal um, um überflüssige Anfragen zwischen den Rechenzentren zu vermeiden, die separat vom lokalen Verkehr abgerechnet werden und dementsprechend kürzere Verzögerungen aufweisen.
Lassen Sie uns ein wenig mit den Begriffen vertrautmachen, die in Consul verwendet werden.
- Consul ist ein Dienst, der in Go geschrieben wurde. Ein Vorteil von Programmen in Go ist die 1-Binary-Datei, die Sie einfach herunterladen. Sie können von jedem Ort starten, und es gibt keine Abhängigkeiten.
- Weiterhin können wir diesen Dienst mit Schlüsseln entweder im Client- oder im Servermodus starten.
- Außerdem erlaubt das Attribut „datacenter“ das Setzen eines Flags, zu welchem Rechenzentrum dieser Server gehört.
- Konsens basiert auf dem Raft-Protokoll. Wer Interesse hat, kann mehr darüber auf der Consul-Website nachlesen. Es handelt sich um ein Protokoll, das es ermöglicht, einen Führer zu bestimmen und festzustellen, welche Daten als gültig und verfügbar gelten.
- Gossip – ein Protokoll, das die Interaktion zwischen Knoten ermöglicht. Dieses System ist dezentralisiert. Innerhalb eines Rechenzentrums kommunizieren alle Knoten mit ihren Nachbarn. Entsprechend wird die jeweils aktuelle Information untereinander ausgetauscht. Man könnte sagen, es sind Klatschgeschichten zwischen Nachbarn.
- LAN Gossip – lokaler Datenaustausch zwischen Nachbarn innerhalb eines Rechenzentrums.
- WAN Gossip – wird verwendet, wenn wir Informationen zwischen zwei Rechenzentren synchronisieren müssen. Die Informationen werden zwischen Knoten ausgetauscht, die als Server markiert sind.
- RPC – ermöglicht es, Anfragen über den Client an den Server zu senden.
Beschreibung von RPC. Angenommen, auf einer virtuellen Maschine oder einem physischen Server läuft Consul als Client. Wir greifen lokal darauf zu. Der lokale Client fragt dann Informationen vom Server an und synchronisiert sich. Je nach Einstellung können die Informationen entweder aus dem lokalen Cache bereitgestellt oder mit dem Führenden, dem Master-Server, synchronisiert werden.
Diese beiden Ansätze haben sowohl Vor- als auch Nachteile. Wenn wir mit dem lokalen Cache arbeiten, geht es schnell. Arbeiten wir jedoch mit Daten, die auf dem Server gespeichert sind, dauert es länger, dafür erhalten wir aktuellere Informationen.
Grafisch dargestellt zeigt sich folgendes Bild der Seite. Wir sehen, dass drei Master aktiv sind. Einer ist mit einem Stern als Führer gekennzeichnet. In diesem Beispiel gibt es drei Clients, die lokal Informationen über UDP/TCP austauschen. Die Informationen zwischen den Rechenzentren werden zwischen den Servern übertragen. Hier interagieren die Clients lokal miteinander.
Welche API bietet Consul? Um Informationen zu erhalten, gibt es zwei Arten von APIs bei Consul.
Das DNS API. Standardmäßig wird Consul auf Port 8600 gestartet. Wir können die Anfrage-Proxys einrichten und über lokales DNS zugänglich machen. Wir können eine Anfrage über die Domain starten und erhalten als Antwort die Informationen zur IP-Adresse.
HTTP API – alternativ können wir lokal auf Port 8500 Informationen über einen bestimmten Dienst anfordern und erhalten eine JSON-Antwort, welche IP der Server hat, welcher Host genutzt wird und welcher Port registriert ist. Zusätzliche Informationen können über ein Token übermittelt werden.
Was benötigt man, um Consul zu starten?
Im ersten Modus geben wir im Entwicklermodus das Flag an, dass dies der Entwicklermodus ist. Der Agent startet als Server und führt die gesamte Funktionalität bereits selbstständig auf einer Maschine aus. Praktisch, schnell und ohne dass für den ersten Start zusätzliche Einstellungen erforderlich sind.
Der zweite Modus ist der Start im Produktionsmodus. Hier wird der Start etwas komplizierter. Wenn wir keine Version des Konsuls haben, müssen wir die erste Maschine über das Bootstrap einrichten, d. h. diese Maschine übernimmt die Aufgaben des Leaders. Wir heben sie an, dann heben wir eine zweite Serverinstanz an und übermitteln ihr die Informationen, wo sich unser Master befindet. Dann starten wir die dritte. Nachdem wir drei Maschinen hochgefahren haben, starten wir die erste Maschine aus dem gestarteten Bootstrap im normalen Modus neu. Die Daten werden synchronisiert, und der anfängliche Cluster ist bereits bereit.
Es wird empfohlen, zwischen drei und sieben Instanzen im Servermodus zu betreiben. Das liegt daran, dass die Zeit für die Synchronisation von Informationen zwischen den Servern steigt, wenn deren Anzahl wächst. Die Anzahl der Knoten sollte ungerade sein, um ein Quorum zu gewährleisten.
Wie werden die Health Checks sichergestellt? Im Konfigurationsverzeichnis für Consul schreiben wir eine Überprüfungsregel im JSON-Format. Die erste Variante ist die Verfügbarkeit der Domain google.com in diesem Beispiel. Wir geben an, dass alle 30 Sekunden diese Überprüfung durchgeführt werden soll. Auf diese Weise überprüfen wir, ob unser Knoten Zugang zum externen Netzwerk hat.
Die zweite Variante ist die Selbstprüfung. Wir verwenden curl, um localhost über den angegebenen Port alle 10 Sekunden anzusprechen.
Diese Überprüfungen werden summiert und gehen in die Service Discovery ein. Basierend auf der Verfügbarkeit werden diese Knoten entweder ausgeschlossen oder erscheinen in der Liste der verfügbaren und korrekt funktionierenden Maschinen.
Außerdem bietet Consul eine Benutzeroberfläche, die mit einem zusätzlichen Flag gestartet wird und auf der Maschine verfügbar ist. Dies ermöglicht es, Informationen einzusehen und einige Änderungen vorzunehmen.
In diesem Beispiel ist der Tab "Service" geöffnet. Es wird angezeigt, dass drei Dienste laufen, einer davon ist Consul. Die Anzahl der durchgeführten Prüfungen wird angezeigt. Außerdem gibt es drei Rechenzentren, in denen sich die Maschinen befinden.
Dies ist ein Beispiel für die Registerkarte „Nodes“. Wir sehen, dass sie zusammengesetzte Namen mit den Rechenzentren enthalten. Hier wird auch angezeigt, welche Dienste gestartet sind, d. h. wir sehen, dass keine Tags zugewiesen sind. In diesen zusätzlichen Tags können Sie Informationen angeben, die der Entwickler zur Angabe zusätzlicher Parameter verwenden kann.
Es ist auch möglich, Informationen über den Status der Festplatten und die durchschnittliche Auslastung an Consul zu übermitteln.
Fragen
Frage: Wir haben einen Docker-Container, wie können wir ihn mit Consul verwenden?
Antwort: Für den Docker-Container gibt es mehrere Ansätze. Einer der gängigsten besteht darin, einen externen Docker-Container zu verwenden, der für die Registrierung verantwortlich ist. Beim Start wird ihm der Docker-Socket übergeben. Alle Ereignisse der Registrierung und Deregistrierung des Containers werden in Consul aufgezeichnet.
Frage: Das heißt, Consul startet selbst den Docker-Container?
Antwort: Nein. Wir starten den Docker-Container. Und bei der Konfiguration geben wir an – höre auf diesen Socket. Das ist ungefähr so, wie es bei einem Zertifikat funktioniert, wenn wir Informationen übergeben, wo und was wir haben.
Frage: Das bedeutet, dass innerhalb des Docker-Containers, den wir mit Service Discovery verbinden möchten, eine Logik vorhanden sein sollte, die in der Lage ist, Daten an Consul zu übermitteln?
Antwort: Nicht ganz. Wenn er startet, übergeben wir über die Umgebungsvariablen die Variablen. Zum Beispiel den Dienstnamen, den Dienstport. Der Registrierungsdienst hört auf diese Informationen und trägt sie in Consul ein.
Frage: Ich habe noch eine Frage zur Benutzeroberfläche. Wir haben die Benutzeroberfläche beispielsweise auf einem Produktionsserver bereitgestellt. Wie steht es um die Sicherheit? Wo werden die Daten gespeichert? Kann man Daten irgendwie sammeln?
Antwort: In der Benutzeroberfläche stammen die Daten aus der Datenbank und aus der Service Discovery. Die Passwörter setzen wir in den Einstellungen selbst.
Frage: Kann man das im Internet veröffentlichen?
Antwort: Standardmäßig startet Consul auf localhost. Um es im Internet zu veröffentlichen, muss ein Proxy eingerichtet werden. Für die Sicherheitsregeln sind wir selbst verantwortlich.
Frage: Liefert es historische Daten standardmäßig? Es wäre interessant, Statistiken zu den Health Checks zu sehen. Man könnte Probleme diagnostizieren, wenn der Server häufig ausfällt.
Antwort: Ich bin mir nicht sicher, ob dort Einzelheiten zu den Prüfvorgängen vorhanden sind.
Frage: Es ist nicht so wichtig, wie der aktuelle Zustand ist, sondern wie die Dynamik ist.
Antwort: Für die Analyse – ja.
Frage: Sollte man Service Discovery für Docker nicht besser mit Consul verwenden?
Antwort: Ich würde nicht empfehlen, es zu verwenden. Ziel des Berichts ist es, das Konzept vorzustellen. Historisch gesehen hat es, meiner Meinung nach, seinen Weg bis zur ersten Version zurückgelegt. Jetzt gibt es bereits vollständigere Lösungen, wie Kubernetes, das all dies unter der Haube hat. Im Bereich der Kubernetes-Service-Discovery steht es hinter Etcd zurück. Aber ich bin nicht so vertraut damit wie mit Consul. Daher habe ich mich entschieden, die Service Discovery am Beispiel von Consul zu erläutern.
Frage: Verzögert das Schema mit dem Leader-Server den gesamten Start des Anwendungsprogramms? Und wie bestimmt Consul einen neuen Leader, wenn dieser ausfällt?
Antwort: Sie haben ein ganzes Protokoll beschrieben. Wenn es interessant ist, kann man es nachlesen.
Frage: Agiert Consul als vollwertiger Server und fliegen alle Anfragen über ihn?
Antwort: Er fungiert nicht als vollwertiger Server, sondern übernimmt einen bestimmten Bereich. Dieser endet in der Regel mit service.consul. Und weiter gehen wir schon nach Logik. Wir verwenden in der Produktion keine Domainnamen, sondern nutzen die interne Infrastruktur, die normalerweise hinter dem Cache des Servers versteckt ist, wenn wir über DNS arbeiten.
Frage: D. h., wenn wir auf die Datenbank zugreifen wollen, müssen wir auf jeden Fall Consul anfragen, um zuerst diese Datenbank zu finden, richtig?
Antwort: Ja. Wenn wir über DNS arbeiten, funktioniert das wie ohne Consul, wenn wir DNS-Namen verwenden. Moderne Anwendungen fragen normalerweise nicht bei jedem Aufruf den Domainnamen an, weil wir die Verbindung hergestellt haben; alles funktioniert und in naher Zukunft nutzen wir das praktisch nicht mehr. Wenn die Verbindung unterbrochen wird, dann – ja, fragen wir wieder, wo sich unsere Datenbank befindet und gehen zu ihr.
— Benutzer-Chat für Hashicorp: Consul, Nomad, Terraform
P.S. Zum Thema Health Checks. In Consul wie auch in Kubernetes wird dasselbe System zur Überprüfung des Status der Serviceverfügbarkeit auf Grundlage des Statuscodes verwendet.
200 OK für gesund
503 Dienst nicht verfügbar für ungesundQuellen:
Quelle: habr.com
