Ich schlage vor, dass Sie sich mit dem Transkript von Alexander Sigachevs Bericht Service Discovery in verteilten Systemen am Beispiel von Consul vertraut machen.
Service Discovery wurde entwickelt, damit Sie mit minimalen Kosten eine neue Anwendung an unsere bestehende Umgebung anschließen können. Mithilfe von Service Discovery können wir entweder einen Container in Form eines Dockers oder einen virtuellen Dienst maximal von der Umgebung trennen, in der er ausgeführt wird.
Ich heiße alle herzlich willkommen! Ich bin Alexander Sigachev, ich arbeite für Inventos. Und heute werde 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, damit Sie mit minimalen Kosten eine neue Anwendung an unsere bestehende Umgebung anschließen können. Mithilfe von Service Discovery können wir entweder einen Container in Form eines Dockers oder einen virtuellen Dienst maximal von der Umgebung trennen, in der er ausgeführt wird.
Wie sieht es aus? In einem klassischen Beispiel im Web ist dies ein Frontend, das eine Benutzeranfrage empfängt. Anschließend wird es an das Backend weitergeleitet. In diesem Beispiel gleicht dieser Load-Balancer zwei Backends aus.
Hier sehen wir, dass wir die dritte Instanz der Anwendung starten. Dementsprechend wird die Anwendung beim Start bei Service Discovery registriert. Service Discovery benachrichtigt den Load-Balancer. Der Load-Balancer ändert seine Konfiguration automatisch und das neue Backend ist bereits mit der Arbeit verbunden. Somit können Backends hinzugefügt oder umgekehrt von der Arbeit ausgeschlossen werden.
Was kann man sonst noch bequem mit Service Discovery machen? Service Discovery kann Nginx-Konfigurationen, Zertifikate und eine Liste aktiver Backend-Server speichern.
Mit Service Discovery können Sie auch einen Fehler erkennen und Fehler erkennen. Welche möglichen Vorgehensweisen gibt es, wenn Fehler erkannt werden?
- Diese von uns entwickelte Anwendung benachrichtigt Service Discovery selbst darüber, dass sie noch betriebsbereit ist.
- Service Discovery wiederum fragt die Anwendung nach Verfügbarkeit ab.
- Oder es wird ein Skript oder eine Anwendung eines Drittanbieters verwendet, die unsere Anwendung auf Verfügbarkeit prüft und Service Discovery benachrichtigt, dass alles in Ordnung ist und funktionieren kann, oder umgekehrt, dass alles schlecht ist und diese Instanz der Anwendung vom Balancing ausgeschlossen werden muss.
Jedes der Schemata kann abhängig von der von uns verwendeten Software angewendet werden. Wenn wir beispielsweise gerade mit der Entwicklung eines neuen Projekts begonnen haben, können wir ganz einfach ein Schema dafür bereitstellen, wann unsere Anwendung Service Discovery benachrichtigt. Oder wir können eine Verbindung herstellen, die von Service Discovery überprüft wird.
Wenn die Anwendung von uns geerbt oder von jemand anderem entwickelt wurde, dann eignet sich hier die dritte Option, wenn wir einen Handler schreiben und das alles automatisch in unsere Arbeit einfließt.
Dies ist ein Beispiel. Load-Balancer in Form von Nginx wird neu geladen. Dies ist ein optionales Dienstprogramm, das mit Consul geliefert wird. Dies ist eine Konsul-Vorlage. Wir beschreiben die Regel. Wir sagen, dass wir eine Vorlage (Golang Template Engine) verwenden. Wenn Ereignisse auftreten, wenn Benachrichtigungen über Änderungen vorliegen, wird diese neu generiert und der Befehl „Neu laden“ wird an Service Discovery gesendet. Das einfachste Beispiel ist, wenn Nginx bei einem Ereignis neu konfiguriert und neu gestartet wird.
Was ist Konsul?
-
Zunächst einmal handelt es sich um Service Discovery.
-
Es verfügt über einen Mechanismus zur Verfügbarkeitsprüfung – Health Checking.
-
Er hat auch einen KV Store.
-
Und es basiert auf der Fähigkeit, Multi Datacenter zu nutzen.
Wofür kann das alles genutzt werden? Im KV Store können wir Konfigurationsbeispiele speichern. Mit der Gesundheitsprüfung können wir den lokalen Service überprüfen und benachrichtigen. Multi Datacenter wird verwendet, um eine Karte von Diensten erstellen zu können. Amazon verfügt beispielsweise über mehrere Zonen und leitet den Verkehr optimal weiter, sodass keine unnötigen Anfragen zwischen Rechenzentren entstehen, die separat vom lokalen Verkehr abgerechnet werden und dementsprechend eine geringere Verzögerung aufweisen.
Schauen wir uns ein wenig die Begriffe an, die in Consul verwendet werden.
- Consul ist ein in Go geschriebener Dienst. Einer der Vorteile eines Go-Programms ist 1 Binärdatei, die Sie gerade heruntergeladen haben. Von überall aus gestartet und Sie haben keine Abhängigkeiten.
- Darüber hinaus können wir diesen Dienst mithilfe der Schlüssel entweder im Client-Modus oder im Server-Modus starten.
- Außerdem können Sie mit dem Attribut „Datacenter“ ein Flag setzen, zu welchem Rechenzentrum dieser Server gehört.
- Konsens – basierend auf dem Floßprotokoll. Wenn jemand Interesse hat, kann er mehr darüber auf der Consul-Website lesen. Hierbei handelt es sich um ein Protokoll, mit dem Sie den Anführer bestimmen und feststellen können, welche Daten als gültig und verfügbar gelten.
- Gossip ist ein Protokoll, das die Kommunikation zwischen Knoten ermöglicht. Darüber hinaus ist dieses System dezentralisiert. Innerhalb eines Rechenzentrums kommunizieren alle Knoten mit ihren Nachbarn. Und dementsprechend werden Informationen über den aktuellen Zustand untereinander übermittelt. Wir können sagen, dass es sich um Klatsch zwischen Nachbarn handelt.
- LAN-Klatsch – lokaler Datenaustausch zwischen Nachbarn innerhalb desselben Rechenzentrums.
- WAN-Klatsch – wird verwendet, wenn wir Informationen zwischen zwei Rechenzentren synchronisieren müssen. Informationen werden zwischen Knoten übertragen, die als Server gekennzeichnet sind.
- RPC – ermöglicht es Ihnen, Anfragen über den Client an den Server zu stellen.
Beschreibung von RPC. Nehmen wir an, Consul wird als Client auf einer virtuellen Maschine oder einem physischen Server ausgeführt. Wir kümmern uns vor Ort darum. Und dann fordert der lokale Client Informationen vom Server an und synchronisiert. Informationen können je nach Einstellung aus dem lokalen Cache ausgegeben oder mit dem Leader, mit dem Server-Master, synchronisiert werden.
Diese beiden Systeme haben sowohl Vor- als auch Nachteile. Wenn wir mit einem lokalen Cache arbeiten, dann geht das schnell. Wenn wir mit Daten arbeiten, die auf dem Server gespeichert sind, dann dauert es länger, wir erhalten aber aktuellere Informationen.
Wenn dies grafisch dargestellt ist, finden Sie hier ein Bild der Website. Wir sehen, dass wir drei Meister am Laufen haben. Einer ist als Anführer mit einem Sternchen gekennzeichnet. In diesem Beispiel gibt es drei Clients, die lokal über UDP/TCP miteinander kommunizieren. Und Informationen zwischen Rechenzentren werden zwischen Servern übertragen. Dabei interagieren die Kunden vor Ort miteinander.
Welche API stellt Consul bereit? Um Informationen zu erhalten, verfügt Consul über zwei Arten von APIs.
Dies ist die DNS-API. Standardmäßig läuft Consul auf Port 8600. Wir können das Anforderungs-Proxying konfigurieren und den Zugriff über lokale Auflösung und lokales DNS bereitstellen. Wir können nach Domänen abfragen und als Antwort Informationen über die IP-Adresse erhalten.
HTTP-API – oder wir können Informationen zu einem bestimmten Dienst lokal auf Port 8500 anfordern und eine JSON-Antwort erhalten, welche IP der Server hat, welcher Host, welcher Port registriert ist. Und per Token können weitere Informationen weitergegeben werden.
Was benötigen Sie, um Consul zu leiten?
In der ersten Option geben wir im Entwicklermodus das Flag an, dass es sich um den Entwicklermodus handelt. Der Agent startet als Server. Und es führt die gesamte Funktion selbstständig auf einer Maschine aus. Bequem, schnell und praktisch ohne zusätzliche Einstellungen für den ersten Start.
Der zweite Modus läuft in der Produktion. Hier wird der Start etwas knifflig. Wenn wir keine Version des Konsuls haben, müssen wir die erste Maschine in den Bootstrap bringen, d. h. diese Maschine, die die Aufgaben des Anführers übernimmt. Wir rufen es auf, dann rufen wir die zweite Instanz des Servers auf und übergeben ihr Informationen darüber, wo wir den Master haben. Erhöhen Sie den dritten. Nachdem wir drei Maschinen hochgefahren haben, starten wir auf der ersten Maschine Bootstrap und starten sie im normalen Modus neu. Die Daten werden synchronisiert und der erste Cluster ist bereits aktiv.
Es wird empfohlen, drei bis sieben Instanzen im Servermodus auszuführen. Dies liegt daran, dass mit zunehmender Anzahl von Servern auch die Zeit zum Synchronisieren von Informationen zwischen ihnen zunimmt. Um ein Quorum bereitzustellen, muss die Anzahl der Knoten ungerade sein.
Wie werden Gesundheitschecks durchgeführt? Im Consul-Konfigurationsverzeichnis schreiben wir eine Validierungsregel in Form von Json. Die erste Option ist in diesem Beispiel die Verfügbarkeit der Domain google.com. Und wir sagen, dass Sie diese Prüfung nach einem Intervall von 30 Sekunden durchführen müssen. Somit überprüfen wir, ob unser Knoten Zugriff auf das externe Netzwerk hat.
Die zweite Möglichkeit besteht darin, sich selbst zu testen. Wir verwenden den üblichen Curl, um localhost im Abstand von 10 Sekunden auf den angegebenen Port zu ziehen.
Diese Prüfungen werden zusammengefasst und in Service Discovery eingespeist. Je nach Verfügbarkeit werden diese Knoten entweder ausgeschlossen oder erscheinen in der Liste der verfügbaren und ordnungsgemäß funktionierenden Maschinen.
Consul bietet außerdem eine Benutzeroberfläche, die mit einem separaten Flag gestartet wird und auf dem Computer verfügbar ist. Auf diese Weise können Sie Informationen anzeigen und auch einige Änderungen vornehmen.
In diesem Beispiel ist die Registerkarte „Extras“ geöffnet. Es werden drei Dienste angezeigt, einer davon ist Consul. Die Anzahl der durchgeführten Prüfungen. Und es gibt drei Rechenzentren, in denen die Maschinen stehen.
Dies ist ein Beispiel für die Registerkarte „Knoten“. Wir sehen, dass sie unter Beteiligung von Rechenzentren zusammengesetzte Namen haben. Außerdem wird angezeigt, welche Dienste ausgeführt werden, d. h. wir sehen, dass keine Tags gesetzt sind. In diesen zusätzlichen Tags können Sie einige Informationen festlegen, die der Entwickler zur Angabe zusätzlicher Parameter verwenden kann.
Sie können Consul auch Informationen über den Status der Festplatten und die durchschnittliche Auslastung senden.
Fragen
Frage: Wir haben einen Docker-Container. Wie verwende ich ihn mit Consul?
Antwort: Für einen Docker-Container gibt es mehrere Ansätze. Am häufigsten wird für die Registrierung ein Docker-Container eines Drittanbieters verwendet. Beim Start wird ein Docker-Socket dorthin geworfen. Alle Ereignisse zum Registrieren und Depublizieren eines Containers werden in Consul protokolliert.
F: Läuft Consul selbst den Docker-Container?
Antwort: Nein. Wir betreiben einen Docker-Container. Und bei der Konfiguration legen wir fest: Hören Sie sich den einen oder anderen Socket an. Das ist ungefähr so, als würden wir mit einem Zertifikat arbeiten, wenn wir Informationen darüber weitergeben, wo und was wir haben.
Frage: Es stellt sich heraus, dass es im Docker-Container, den wir mit Service Discovery zu verbinden versuchen, eine Art Logik geben muss, die Daten an Consul weitergeben kann?
Antwort: Nicht ganz. Wenn es startet, übergeben wir Variablen durch die Variablenumgebung. Sagen wir Dienstname, Dienstport. Es hört sich diese Informationen im Register an und trägt sie in Consul ein.
Frage: Ich habe eine weitere Frage zur Benutzeroberfläche. Wir haben die Benutzeroberfläche beispielsweise auf einem Produktionsserver bereitgestellt. Wie sieht es mit der Sicherheit aus? Wo werden die Daten gespeichert? Gibt es eine Möglichkeit, Daten zu sammeln?
Antwort: In der Benutzeroberfläche nur Daten aus der Datenbank und von Service Discovery. Wir legen Passwörter in den Einstellungen selbst fest.
Frage: Kann dies im Internet veröffentlicht werden?
Antwort: Consul startet standardmäßig auf localhost. Um in diesem Internet zu veröffentlichen, müssen Sie eine Art Proxy einsetzen. Für die Sicherheitsregeln sind wir selbst verantwortlich.
Frage: Gibt es sofort historische Daten? Es ist interessant, die Statistiken zu Health Checks zu sehen. Sie können auch Probleme diagnostizieren, wenn der Server häufig abstürzt.
Antwort: Ich bin mir nicht sicher, ob es Einzelheiten zu den Kontrollen gibt.
Frage: Der aktuelle Zustand ist nicht so wichtig, sondern die Dynamik.
Antwort: Zur Analyse, ja.
Frage: Ist es besser, Service Discovery für Consul Docker nicht zu verwenden?
Antwort: Ich würde die Verwendung nicht empfehlen. Der Zweck des Berichts besteht darin, ein solches Konzept vorzustellen. Historisch gesehen hat er meiner Meinung nach einen langen Weg bis zur 1. Version zurückgelegt. Mittlerweile gibt es bereits umfassendere Lösungen, zum Beispiel Kubernetes, das all das unter der Haube hat. Als Teil von Kubernetes ist Service Discovery Etcd unterlegen. Aber ich kenne ihn nicht so gut wie Consul. Aus diesem Grund habe ich beschlossen, Service Discovery am Beispiel von Consul durchzuführen.
Frage: Verlangsamt das Schema mit dem Serverführer den Start der gesamten Anwendung? Und wie bestimmt der Konsul einen neuen Anführer, wenn dieser lügt?
Antwort: Sie haben ein ganzes Protokoll beschrieben. Wenn Sie interessiert sind, können Sie lesen.
Frage: Consul fungiert als vollwertiger Server und alle Anfragen laufen über ihn?
Antwort: Er fungiert nicht als vollwertiger Server, sondern belegt eine bestimmte Zone. Es endet normalerweise mit service.consul. Und dann gehen wir logisch vor. Wir verwenden in der Produktion keine Domainnamen, sondern die interne Infrastruktur, die sich bei der Arbeit über DNS meist hinter dem Server-Caching verbirgt.
Frage: Das heißt, wenn wir auf die Datenbank zugreifen möchten, ziehen wir auf jeden Fall zuerst Consul, um diese Datenbank zu finden, oder?
Antwort: Ja. Wenn wir mit DNS arbeiten, dann funktioniert es wie ohne Consul, wenn wir DNS-Namen verwenden. Normalerweise rufen moderne Anwendungen den Domänennamen nicht bei jeder Anfrage ab, da wir connect installiert haben, alles funktioniert und wir es in naher Zukunft praktisch nicht mehr verwenden. Wenn die Verbindung unterbrochen ist, dann - ja, wir fragen erneut, wo unsere Basis ist und gehen dorthin.
— Chat der Hashicorp-Benutzer: Consul, Nomad, Terraform
PS Bezüglich Gesundheitskontrollen. Consul verwendet wie Kubernetes dasselbe System zur Überprüfung des Gesundheitszustands eines Dienstes basierend auf dem Codestatus.
200 OK for healthy
503 Service Unavailable for unhealthyQuellen:
Source: habr.com