Ich lade Sie ein, die Auswertung des Berichts von Alexander Sigachev über Service Discovery in verteilten Systemen am Beispiel von Consul zu lesen.
Service Discovery wurde entwickelt, um neue Anwendungen mit minimalem Aufwand in unsere bestehende Umgebung zu integrieren. Mit Service Discovery können wir entweder einen Container in Form von Docker oder einen virtuellen Dienst vom Umfeld, in dem er betrieben wird, maximal isolieren.
Ich begrüße alle! Ich bin Alexander Sigachev und arbeite bei Inventos. Heute möchte ich Ihnen das Konzept des Service Discovery näherbringen. Wir werden Service Discovery am Beispiel von Consul betrachten.
Welche Probleme löst Service Discovery? Service Discovery wurde entwickelt, um neue Anwendungen mit minimalem Aufwand in unsere bestehende Umgebung zu integrieren. Mit Service Discovery können wir entweder einen Container in Form von Docker oder einen virtuellen Dienst vom Umfeld, in dem er betrieben wird, maximal isolieren.
Wie sieht das aus? Ein klassisches Beispiel im Web – das Frontend, das die Anfragen des Nutzers entgegennimmt. Danach wird die Anfrage an das Backend weitergeleitet. In diesem Beispiel balanciert ein 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 informiert den Load-Balancer. Der Load-Balancer ändert seine Konfiguration automatisch, und die neue Backend ist damit in Betrieb. So können Backend-Instanzen hinzugefügt oder umgekehrt aus dem Betrieb genommen werden.
Was kann man noch bequem mit Service Discovery tun? In Service Discovery können Konfigurationen von nginx, Zertifikate und die Liste aktiver Backend-Server gespeichert werden.
Service Discovery ermöglicht es auch, Fehler zu erkennen und Ausfälle festzustellen. Welche möglichen Strategien gibt es zur Fehlererkennung?
- Diese Anwendung, die wir entwickelt haben, informiert selbst Service Discovery darüber, dass sie weiterhin funktionsfähig ist.
- Service Discovery überprüft seinerseits, ob die Anwendung verfügbar ist.
- Alternativ kann ein externes Skript oder eine Anwendung verwendet werden, die unsere Anwendung auf Erreichbarkeit überprüft und Service Discovery mitteilt, dass alles in Ordnung ist und gearbeitet werden kann, oder umgekehrt, dass alles schlecht ist und diese Instanz der Anwendung aus dem Load-Balancing ausgeschlossen werden muss.
Jedes dieser Modelle kann je nach verwendeter Software angewendet werden. Wenn wir beispielsweise mit einem neuen Projekt beginnen, können wir problemlos ein Modell implementieren, bei dem unsere Anwendung Service Discovery benotet. Alternativ können wir auch Service Discovery dafür nutzen, um Prüfungen durchzuführen.
Handelt es sich jedoch um eine Anwendung, die wir geerbt haben oder die von einem Drittanbieter entwickelt wurde, ist die dritte Option relevant. In diesem Fall schreiben wir einen Handler, und alles wird automatisch in unsere Arbeitsabläufe integriert.
Ein Beispiel dafür ist der Load-Balancer, der als nginx fungiert und neu gestartet werden kann. Dies ist ein zusätzliches Tool, das zusammen mit Consul bereitgestellt wird: consul-template. Wir definieren eine Regel und nutzen eine Vorlage (Golang-Template). Wenn Ereignisse eintreten und Benachrichtigungen über Änderungen erfolgen, wird es neu generiert, und Service Discovery erhält den Befehl „reload“. Ein einfaches Beispiel, bei dem 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üfmechanismus – Health Checking.
Außerdem gibt es einen KV Store.
Seine Grundlage ist die Möglichkeit, Multi-Datacenter zu verwenden.
Wofür kann das alles genutzt werden? Im KV Store können wir Konfigurationsbeispiele speichern. Mit Health Checking können wir den lokalen Dienst überprüfen und Benachrichtigungen senden. Multi Datacenter wird verwendet, um eine Karte der Dienste zu erstellen. Zum Beispiel hat Amazon mehrere Zonen und leitet den Verkehr optimiert, damit es keine zusätzlichen Anfragen zwischen den Rechenzentren gibt, die separat von lokalem Traffic abgerechnet werden und daher eine geringere Latenz aufweisen.
Lass uns ein wenig mit den Begriffen vertraut machen, die in Consul verwendet werden.
- Consul ist ein Dienst, der in Go geschrieben wurde. Ein Vorteil von Programmen in Go ist die Existenz einer einzigen Binärdatei, die du einfach herunterlädst. Du kannst sie überall ausführen, ohne Abhängigkeiten.
- Anschließend können wir diesen Dienst mithilfe von Schlüsseln entweder im Client-Modus oder im Server-Modus starten.
- Das Attribut „datacenter“ erlaubt es auch, ein Flag zu setzen, zu welchem Rechenzentrum dieser Server gehört.
- Consensus – basiert auf dem Raft-Protokoll. Interessierte können auf der Website von Consul mehr darüber lesen. Dieses Protokoll ermöglicht es, einen Leader zu bestimmen und festzulegen, welche Daten als gültig und verfügbar gelten.
- Gossip – ist ein Protokoll, das die Interaktion zwischen den Knoten gewährleistet. Dabei handelt es sich um ein dezentrales System. Innerhalb eines Rechenzentrums kommunizieren alle Knoten mit ihren Nachbarn. Dadurch wird Informationen über den aktuellen Status ausgetauscht. Man könnte sagen, es handelt sich um Klatsch zwischen den 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 den als Server markierten Knoten übertragen.
- RPC – ermöglicht das Ausführen von Anfragen über einen Client an den Server.
RPC-Beschreibung. 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 Einstellungen kann die Information aus dem lokalen Cache ausgegeben werden oder sie wird mit dem Leader, dem Master-Server, synchronisiert.
Diese beiden Modelle haben sowohl Vorteile als auch Nachteile. Wenn wir mit dem lokalen Cache arbeiten, ist das schnell. Wenn wir jedoch mit Daten arbeiten, die auf dem Server gespeichert sind, dauert es länger, bietet aber genauere Informationen.
Grafisch dargestellt sieht die Seite so aus. Wir sehen, dass drei Master laufen. Einer ist mit einem Stern als Leader gekennzeichnet. In diesem Beispiel gibt es drei Clients, die lokal über UDP/TCP Informationen austauschen. Die Informationen zwischen den Rechenzentren werden zwischen den Servern übertragen. Hier interagieren die Clients lokal miteinander.
Welche APIs bietet Consul an? Um Informationen zu erhalten, gibt es zwei Arten von APIs bei Consul.
Das ist die DNS API. Standardmäßig läuft Consul auf Port 8600. Wir können die Anfrageproxies konfigurieren und den Zugriff über lokale Auflösung ermöglichen, also über den lokalen DNS. Wir können eine Abfrage über die Domain durchführen und erhalten als Antwort Informationen zur IP-Adresse.
Die HTTP API – wir können lokal über Port 8500 Informationen zu einem bestimmten Dienst anfordern und erhalten eine JSON-Antwort, die die IP-Adresse des Servers, den Host und den registrierten Port enthält. Zusätzlich können weitere Informationen über ein Token übermittelt werden.
Was benötigen wir, um Consul zu starten?
Im ersten Fall starten wir im Entwicklermodus und setzen ein Flag, dass es sich um den Entwicklermodus handelt. Der Agent läuft als Server. Und alle Funktionen werden bereits eigenständig auf einer Maschine ausgeführt. Praktisch, schnell und es sind kaum zusätzliche Einstellungen für den ersten Start erforderlich.
Der zweite Modus ist der Produktionsstart. Hier wird der Start etwas komplizierter. Wenn wir keine Version des Konsuls haben, müssen wir die erste Maschine im Bootstrap hochfahren, also diese Maschine, die die Rolle des Leaders übernimmt. Wir starten sie, dann starten wir die zweite Serverinstanz und übergeben ihr die Informationen, wo sich der Master befindet. Die dritte wird dann hochgefahren. Nachdem wir drei Maschinen aktiviert haben, starten wir die erste Maschine aus dem gestarteten Bootstrap neu im normalen Modus. Die Daten werden synchronisiert und das initiale Cluster ist bereits hochgefahren.
Es wird empfohlen, zwischen drei und sieben Instanzen im Servermodus zu starten. Dies liegt daran, dass bei einer Erhöhung der Anzahl der Server die Zeit für die Synchronisierung der Informationen zwischen diesen steigt. 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 in Form von JSON eine Prüfvorschrift. Die erste Variante ist die Erreichbarkeit, in diesem Beispiel der Domain google.com. Wir geben an, dass alle 30 Sekunden diese Prüfung durchgeführt werden soll. So überprüfen wir, dass unser Knoten Zugang zum externen Netzwerk hat.
Die zweite Option besteht darin, sich selbst zu überprüfen. Wir verwenden ein einfaches curl, um localhost alle 10 Sekunden am angegebenen Port abzufragen.
Diese Überprüfungen werden summiert und an die Service Discovery weitergeleitet. Basierend auf der Verfügbarkeit werden diese Knoten entweder ausgeschlossen oder erscheinen in der Liste der verfügbaren und ordnungsgemäß funktionierenden Maschinen.
Zusätzlich bietet Consul eine UI-Oberfläche, die mit einem speziellen Start-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 ausgeführt werden, einer davon ist Consul. Die Anzahl der durchgeführten Prüfungen und es sind drei Rechenzentren vorhanden, in denen sich die Maschinen befinden.
Dies ist ein Beispiel für den Tab "Nodes". Wir sehen, dass sie zusammengesetzte Namen mit Bezug auf die Rechenzentren haben. Hier wird auch angezeigt, welche Dienste running sind, d.h. wir sehen, dass keine Tags festgelegt sind. In diesen zusätzlichen Tags können Informationen angegeben werden, die der Entwickler nutzen kann, um zusätzliche Parameter festzulegen.
Es ist auch möglich, Informationen an Consul über den Zustand der Festplatten und die durchschnittliche Auslastung zu übermitteln.
Fragen
Frage: Wir haben einen Docker-Container. Wie verwenden wir ihn mit Consul?
Antwort: Für den Docker-Container gibt es mehrere Ansätze. Einer der gängigsten ist die Verwendung eines externen Docker-Containers, der für die Registrierung verantwortlich ist. Beim Start wird ihm der Socket des Docker-Containers übergeben. Alle Ereignisse zur Registrierung und Deregistrierung des Containers werden in Consul eingetragen.
Frage: Heißt das, Consul startet selbst den Docker-Container?
Antwort: Nein. Wir starten den Docker-Container. Bei der Konfiguration geben wir an, dass er einen bestimmten Socket überwachen soll. Das funktioniert ähnlich wie bei einem Zertifikat, wenn wir Informationen übermitteln, wo und was wir gespeichert haben.
Frage: Bedeutet das, dass im Docker-Container, den wir mit Service Discovery verbinden möchten, eine Logik vorhanden sein muss, die Daten an Consul übergeben kann?
Antwort: Nicht ganz. Wenn er startet, übergeben wir über Umgebungsvariablen Variablen. Zum Beispiel den Servicenamen, den Serviceport. Das Register hört auf diese Informationen und trägt sie in Consul ein.
Frage: Ich habe noch eine Frage zur Benutzeroberfläche. Wir haben die UI auf einem Produktionsserver bereitgestellt. Wie steht es um die Sicherheit? Wo werden die Daten gespeichert? Gibt es eine Möglichkeit, die Daten zu akkumulieren?
Antwort: Im UI kommen die Daten direkt aus der Datenbank und aus dem Service Discovery. Die Passwörter legen wir selbst in den Einstellungen fest.
Frage: Kann man das im Internet veröffentlichen?
Antwort: Standardmäßig startet Consul auf localhost. Um es im Internet zu veröffentlichen, benötigen wir einen Proxy. Für die Sicherheitsregeln sind wir selbst verantwortlich.
Frage: Liefert es von Haus aus historische Daten? Es wäre interessant, Statistiken zu den Health Checks zu sehen. Man könnte Probleme diagnostizieren, wenn der Server oft ausfällt.
Antwort: Ich bin mir nicht sicher, ob dort Details zu den Checks vorhanden sind.
Frage: Es ist nicht so wichtig, wie der aktuelle Zustand ist, sondern vielmehr die Dynamik.
Antwort: Für die Analyse – ja.
Frage: Sollte man Service Discovery für Docker Consul besser nicht verwenden?
Antwort: Ich würde nicht empfehlen, es zu verwenden. Ziel des Vortrags ist es, das Konzept vorzustellen. Historisch hat es meines Wissens bis zur Version 1 einen Weg zurückgelegt. Heute gibt es bereits umfassendere Lösungen, wie Kubernetes, das all das im Hintergrund hat. Im Rahmen von Kubernetes steht Service Discovery hinter Etcd zurück. Aber ich bin nicht so vertraut mit Etcd wie mit Consul. Daher habe ich mich entschieden, Service Discovery am Beispiel von Consul zu erklären.
Frage: Verzögert das Leader-Server-Schema den Start der Anwendung insgesamt? Und wie bestimmt Consul einen neuen Leader, wenn dieser ausgefallen ist?
Antwort: Es gibt ein ausformulierter Protokoll dafür. Falls es interessant ist, kann man darüber lesen.
Frage: Agiert Consul bei uns als vollständiger Server, und laufen alle Anfragen über ihn?
Antwort: Er funktioniert nicht als vollständiger Server, sondern deckt einen bestimmten Bereich ab. Dieser endet in der Regel mit service.consul. Und danach folgen wir der Logik. In der Produktion verwenden wir keine Domainnamen, sondern die interne Infrastruktur, die normalerweise hinter dem Server-Caching verborgen ist, wenn wir über DNS arbeiten.
Frage: Das bedeutet also, dass wir, wenn wir auf die Datenbank zugreifen wollen, immer zuerst Consul abfragen müssen, richtig?
Antwort: Ja. Wenn wir über DNS arbeiten, funktioniert das auch ohne Consul, wenn wir DNS-Namen verwenden. Moderne Anwendungen greifen nicht bei jeder Anfrage auf den Domainnamen zu, da wir die Verbindung hergestellt haben, und es funktioniert. In naher Zukunft verwenden wir es kaum. Wenn die Verbindung jedoch abbricht, fragen wir erneut, wo sich unsere Datenbank befindet und gehen zu ihr.
— Hashicorp-Benutzer-Chat: Consul, Nomad, Terraform
P.S. Zum Thema Health Checks: In Consul, wie auch in Kubernetes, wird ein ähnliches System zur Überprüfung der Verfügbarkeit von Diensten auf Basis des Statuscodes verwendet.
200 OK für verfügbar
503 Dienst nicht verfügbar für nicht verfügbarQuellen:
Quelle: habr.com
