Consul.io Teil 2

    Im ersten Teil haben wir detailliert untersucht, welche Probleme und Aufgaben die verteilte Anwendungsarchitektur für uns aufwirft. Wir stellten fest, mit welchen Tools wir diese Probleme lösen können, und stellten fest, wie wichtig die Entdeckung in der Anfangsphase des Projekts ist. Außerdem haben wir Consul als Hauptanwendung ausgewählt, auf deren Grundlage wir die Implementierung des Suchdienstes prüfen werden.



    Im letzten Teil werden wir uns ansehen, wie Consul mit dem DNS-Protokoll arbeitet, wir werden die grundlegenden Anforderungen für die HTTP-API analysieren, sehen, welche Arten von Integritätsprüfungen wir verwenden können, und natürlich werden wir verstehen, wofür K / V-Speicher gedacht ist. Und am wichtigsten ist, dass wir uns einige der Funktionen in der Praxis genauer ansehen.

    DNS-Schnittstelle


    Consul kann auf Anfragen mit dem DNS-Protokoll antworten, und jeder DNS-Client kann für Anfragen verwendet werden. Die DNS-Schnittstelle ist für Komponenten auf dem lokalen Host an Port 8600 verfügbar. Zusätzlich zu den direkten Anfragen an Consul können Sie sie als Resolver im System registrieren und transparent für die Namensauflösung verwenden, indem Sie alle externen Anfragen an den Upstream-DNS-Server weiterleiten und Anfragen an weiterleiten private zone .consul allein.
    Um einen primitiven DNS-Ausgleich für den Fall zu implementieren, dass mehrere Dienste mit demselben Namen und verschiedenen IP-Adressen im Verzeichnis vorhanden sind, mischt Consul die IP-Adressen in der Antwort nach dem Zufallsprinzip.
    Zusätzlich zu einer direkten Anforderung für die Auflösung von Domänennamen innerhalb des Clusters können Sie auch nachschlagen. Die Suche kann sowohl für den Dienst (Dienstsuche) als auch für den Knoten des Clusters (Knotensuche) durchgeführt werden.
    Das Format eines Domainnamens während einer DNS-Abfrage innerhalb eines Consul-Clusters ist streng definiert und kann nicht geändert werden.

    Clusterknoten


    Dies ist eine normale DNS-Abfrage, die die IP-Adresse eines Clusterknotens anhand seines Namens zurückgibt (der Knotenname wird festgelegt, wenn der Agent mit dem Parameter - node beginnt). Betrachten Sie das Hostnamenformat für eine DNS-Abfrage:
    [node].node[.datacenter].[domain]
    • [Knoten] - erforderliches Teil, Knotenname;
    • .node - ein Zeiger auf die Tatsache, dass wir eine Knotensuche durchführen;
    • [.datacenter] - ein optionaler Teil, der Name des Rechenzentrums (Consul „out of the box“) kann die Erkennung für mehrere Rechenzentren innerhalb desselben Clusters ermöglichen. Standardmäßig wird der Name dc1 verwendet. Wenn der Name des Rechenzentrums nicht angegeben ist, wird das aktuelle Rechenzentrum verwendet innerhalb dessen der Agent gestartet wird, zu dem die Anfrage läuft;
    • . [domain] - Erforderlicher Teil, Consul Private Domain der ersten Ebene. Es hat einen .consulStandardwert.

    Der Domänenname für den Knoten mit dem Namen, z. B. Nodeservice, sieht also folgendermaßen aus:
    nodeservice.node.consul.
    Wie wir sehen, fehlt der Name des Rechenzentrums, der Name kann jedoch auch folgendermaßen aufgebaut sein:
    nodeservice.node.dc1.consul.
    Mehrere Knoten mit demselben Namen innerhalb desselben Domänencontrollers sind nicht zulässig.

    Service


    Auf allen Knoten des Clusters wird eine Anforderung zur Suche nach einem Dienst nach Namen ausgeführt. Im Gegensatz zu einer Anforderung zum Auflösen eines Hostnamens bietet eine Anforderung zum Suchen nach einem Dienst mehr Optionen. Darüber hinaus können Sie mit der IP-Adresse des Dienstes (d. H. A-Datensätze) eine Anforderung für einen SRV-Datensatz erfüllen und die Ports ermitteln, auf denen der Dienst ausgeführt wird.
    So sieht eine normale Abfrage aus, um alle Knoten zu finden, auf denen der Dienst mit dem Namen ausgeführt wird rls:
    root@511cdc9dd19b:~# dig @127.0.0.1 -p 8600 rls.service.consul.
    ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 rls.service.consul.
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26143
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
    ;; WARNING: recursion requested but not available
    ;; QUESTION SECTION:
    ;rls.service.consul.		IN	A
    ;; ANSWER SECTION:
    rls.service.consul.	0	IN	A	172.17.0.2
    rls.service.consul.	0	IN	A	172.17.0.3
    ;; Query time: 4 msec
    ;; SERVER: 127.0.0.1#8600(127.0.0.1)
    ;; WHEN: Thu Feb 18 07:23:00 UTC 2016
    ;; MSG SIZE  rcvd: 104
    

    Anhand dieser Antwort können Sie erkennen, dass im Cluster zwei Knoten vorhanden sind, auf denen der Dienst mit dem Namen ausgeführt wird, rlsund dass die Consul-DNS-Schnittstelle die IP-Adressen aller Knoten zurückgegeben hat. Wenn wir die Anfrage mehrmals wiederholen, werden wir feststellen, dass die Datensätze regelmäßig die Orte wechseln, dh der erste Ort wird nicht dem ersten gefundenen Dienst zugewiesen. Dies ist ein Beispiel für einen einfachen DNS-Ausgleich, über den wir oben gesprochen haben.
    Wenn wir einen SRV-Datensatz anfordern, lautet die Antwort:

    root@511cdc9dd19b:/# dig @127.0.0.1 -p 8600 rls.service.consul. SRV
    ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 rls.service.consul. SRV
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8371
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
    ;; WARNING: recursion requested but not available
    ;; QUESTION SECTION:
    ;rls.service.consul.		IN	SRV
    ;; ANSWER SECTION:
    rls.service.consul.	0	IN	SRV	1 1 80 agent-two.node.dc1.consul.
    rls.service.consul.	0	IN	SRV	1 1 80 agent-one.node.dc1.consul.
    ;; ADDITIONAL SECTION:
    agent-two.node.dc1.consul. 0	IN	A	172.17.0.3
    agent-one.node.dc1.consul. 0	IN	A	172.17.0.2
    ;; Query time: 5 msec
    ;; SERVER: 127.0.0.1#8600(127.0.0.1)
    ;; WHEN: Thu Feb 18 07:39:22 UTC 2016
    ;; MSG SIZE  rcvd: 244
    

    Die ANSWER SECTIONDomänennamen der Knoten werden in dem von Consul gewünschten Format aufgelistet (beachten Sie die Knoten, aber nicht die Dienste!) Und die Ports, auf denen der angeforderte Dienst ausgeführt wird. Die IP-Adressen der Knoten (und entsprechend der Dienste) werden in der ADDITIONAL SECTIONAntwort aufgelistet .

    Das Format des Dienstnamens für die DNS-Abfrage sieht folgendermaßen aus:
    [tag.][service].service[.datacenter].[domain]
    • [tag.] ist ein optionaler Teil. Wird zum Filtern des Dienstes nach Tags verwendet. Wenn wir Services mit demselben Namen, aber unterschiedlichen Tags haben, hilft das Hinzufügen eines Tag-Namens, die Ergebnisse herauszufiltern.
    • [service] - erforderliches Teil, Servicename;
    • .service - ein Hinweis auf die Tatsache, dass wir eine Service-Suche durchführen;
    • [.datacenter] - optionaler Teil, Name des Rechenzentrums;
    • . [domain] - Erforderlicher Teil, Consul Private Domain der ersten Ebene.

    So kann ein Dienst namens nginx mit einem Tag namens web durch eine Domain dargestellt werden:
    web.nginx.service.consul

    SRV fordert die Suche nach Diensten gemäß RFC-2782 an

    Zusätzlich zur „üblichen“ Erstellung eines Domainnamens können wir ihn nach strengeren RFC-2782- Regeln erstellen , um eine Anforderung für einen SRV-Datensatz zu erfüllen. Das Namensformat lautet wie folgt:
    _service._tag.service[.datacenter].[domain]
    Der Servicename und das Tag haben einen Unterstrich (_) als Präfix. (Im ursprünglichen RFC sollte anstelle des Tags der Name des Protokolls verwendet werden, um Kollisionen während der Anforderung zu vermeiden.)
    Wenn Sie einen Namen im RFC-2782-Format verwenden, sieht ein Dienst namens nginx mit einem Tag namens web folgendermaßen aus: Die
    _web._nginx.service.consul

    Antwort ist genau die gleiche wie bei einer „einfachen“ Anfrage:
    root@511cdc9dd19b:/# dig @127.0.0.1 -p 8600 _rls._rails.service.consul. SRV
    ; <<>> DiG 9.9.5-3ubuntu0.7-Ubuntu <<>> @127.0.0.1 -p 8600 _rls._rails.service.consul. SRV
    ; (1 server found)
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26932
    ;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 2
    ;; WARNING: recursion requested but not available
    ;; QUESTION SECTION:
    ;_rls._rails.service.consul.	IN	SRV
    ;; ANSWER SECTION:
    _rls._rails.service.consul. 0	IN	SRV	1 1 80 agent-one.node.dc1.consul.
    _rls._rails.service.consul. 0	IN	SRV	1 1 80 agent-two.node.dc1.consul.
    ;; ADDITIONAL SECTION:
    agent-one.node.dc1.consul. 0	IN	A	172.17.0.2
    agent-two.node.dc1.consul. 0	IN	A	172.17.0.3
    ;; Query time: 6 msec
    ;; SERVER: 127.0.0.1#8600(127.0.0.1)
    ;; WHEN: Thu Feb 18 07:52:59 UTC 2016
    ;; MSG SIZE  rcvd: 268
    

    Standardmäßig haben alle Domainnamen in Consul TTL = 0, dh, sie werden überhaupt nicht zwischengespeichert. Sie müssen dies berücksichtigen.

    HTTP API


    Die HTTP-REST-API ist das primäre Consul-Cluster-Management-Tool und bietet eine Vielzahl von Funktionen. Im Rahmen der API werden 10 Endpunkte implementiert, von denen jeder Zugriff auf die Konfiguration eines bestimmten funktionalen Aspekts von Consul bietet. Eine detaillierte Beschreibung aller Edpoints finden Sie in der Consul-Dokumentation . Wir werden sie kurz beschreiben, um die Funktionen der API darzustellen:
    • acl - Zugangskontrolle;
    • Agent - Agent Management Consul;
    • Katalog - Verwaltung von Clusterknoten und -diensten;
    • Koordinate - Netzwerkkoordinaten;
    • Ereignis - Benutzerereignisse;
    • Gesundheit - Verfügbarkeitsprüfungen;
    • kv - Schlüssel- / Wertspeicher;
    • Abfrage - vorbereitete Abfragen;
    • Sitzung - Sitzungen;
    • status - Systemstatus.

    acl
    Wie der Name schon sagt, steuert acl die Zugriffssteuerung für Consul-Dienste. Wir können den Zugriff zum Empfangen und Ändern von Daten zu Diensten, Knoten und Benutzerereignissen sowie den Zugriff auf k / v-Speicher steuern.

    Agent
    Local Agent Management-Konsul. Alle an diesem Endpunkt verfügbaren Vorgänge wirken sich auf die lokalen Agentendaten aus. Sie können Informationen zum aktuellen Status des Agenten und seiner Rolle im Cluster abrufen sowie auf die Verwaltung lokaler Dienste zugreifen. Änderungen an lokalen Diensten werden mit allen Knoten im Cluster synchronisiert.

    Katalog
    Global Registry Management Consul. Hier konzentriert sich die Arbeit mit Knoten und Diensten. Auf diesem Endpunkt können Sie Dienste registrieren und deaktivieren. Wenn Sie mit Diensten arbeiten, ist die Verwendung dieses Abschnitts vorzuziehen agent. Das Durcharbeiten ist catalogeinfacher, klarer und trägt zur Antientropie bei .

    Der Koordinatenkonsul berechnet die Netzwerkkoordinaten
    mithilfe der Netzwerktomographie . Diese Koordinaten werden verwendet, um effektive Routen innerhalb des Clusters und viele nützliche Funktionen zu erstellen, z. B. den nächsten Knoten mit einem bestimmten Dienst zu finden oder im Falle eines Unfalls zum nächsten Rechenzentrum zu wechseln. Die API-Funktionen in diesem Abschnitt werden nur verwendet, um Informationen zum aktuellen Status der Netzwerkkoordinaten abzurufen.

    Ereignis
    Behandlung von benutzerdefinierten Ereignissen. Benutzerdefinierte Ereignisse werden verwendet, um Aktionen innerhalb des Clusters auszuführen: z. B. um Dienste automatisch bereitzustellen, neu zu starten, bestimmte Skripts oder andere Aktionen als Teil des Orchestrierungsprozesses auszuführen.

    Gesundheit
    überprüft den aktuellen Status der Knoten und Dienstleistungen. Dieser Endpunkt ist schreibgeschützt und gibt den aktuellen Status von Knoten und Diensten sowie Listen der durchgeführten Überprüfungen zurück.

    kv
    Dieser Endpunkt verfügt nur über eine Methode und wird zum Verwalten von Daten im von Consul bereitgestellten verteilten Schlüssel- / Wertspeicher verwendet. Die einzige Methode in diesem Endpunkt sieht folgendermaßen aus:
    /v1/kv/[key]
    Der Unterschied in der Verarbeitung ist die Anforderungsmethode. GET gibt den Wert mit der Taste zurück, PUT speichert den neuen Wert oder überschreibt den alten und DELETE löscht den Datensatz.

    Abfrage
    Verwaltung vorbereiteter Abfragen. Mit solchen Anforderungen können Sie komplexe Änderungen an der Konfiguration von Consul vornehmen und diese später speichern und ausführen. Gespeicherte Abfragen erhalten eine eindeutige ID. Mit seiner Hilfe kann die Anfrage jederzeit erfüllt werden, ohne dass eine wiederholte Vorbereitung erforderlich ist.

    Sitzung
    Die Consul-Sitzungs-Engine wird zum Erstellen verteilter Sperren verwendet. Sitzungen sind die Verbindungsebene zwischen den überprüften Knoten und dem k / v-Speicher. Jede Sitzung hat einen Namen und kann im Repository gespeichert werden. Der Name wird verwendet, um Sperren als Teil von sequentiellen Aktionen mit Knoten und Diensten in einem Wettbewerbsmodus zu implementieren. Der Mechanismus der Sitzungen ist in der Dokumentation von Consul beschrieben .

    status
    Dieser Endpunkt wird zum Abrufen von Clusterstatusinformationen verwendet. Hier können Sie den aktuellen Leader herausfinden und sich über alle Clustermitglieder informieren.

    Gesundheitschecks


    Früher haben wir über einen einheitlichen Lastenausgleich mithilfe von DNS gesprochen, und jetzt werden wir einen Mechanismus zum Überprüfen des Status von Knoten und Diensten in Betracht ziehen. Die Integritätsprüfung wird in regelmäßigen Abständen durchgeführt. Die Ergebnisse können den Status des zu prüfenden Systems bestimmen. Tatsächlich handelt es sich hierbei um eine automatische Überwachung, die den Zustand des Clusters in einem fehlerfreien Zustand hält, inaktive Knoten und Dienste bereinigt und zur Wiederherstellung des Zustands zurücksendet. Consul unterstützt verschiedene Arten von Schecks:
    • Skriptprüfung - Führen Sie ein bestimmtes Skript auf einem bestimmten Knoten mit einer bestimmten Häufigkeit aus. Abhängig vom Exit-Code (ein Code ungleich Null bedeutet, dass die Prüfung nicht bestanden wurde) wird der Knoten oder Dienst ein- oder ausgeschaltet.
    • HTTP-Prüfung - eine Prüfung, die versucht, die angegebene URL zu laden, und die das geprüfte Objekt abhängig vom Antwortcode ein- oder ausschaltet (jede 2xx - alles in Ordnung, zu viele Anfragen Code 429 erzeugt eine Warnung, andere Codes weisen auf einen Fehler hin).
    • TCP-Prüfung - Eine Prüfung, die versucht, eine TCP-Verbindung mit einem bestimmten Intervall zu der angegebenen Adresse und dem angegebenen Port herzustellen. Wenn keine Verbindung hergestellt wird, ist der Test fehlgeschlagen.
    • Die TTL-Prüfung ist eine Prüfung, die regelmäßig über die HTTP-API aktualisiert werden sollte. Wenn ein bestimmter Dienst diese Prüfung nicht innerhalb eines bestimmten Intervalls aktualisiert hat, wird sie als inaktiv markiert. Hierbei handelt es sich um eine passive Prüfung, dh der Dienst selbst muss regelmäßig die Funktionsfähigkeit melden. Wenn ein Bericht für ein bestimmtes Intervall nicht empfangen wurde, gilt die Prüfung als nicht bestanden.
    • Docker Check - Überprüfen Sie, ob Dienste in Docker-Containern ausgeführt werden. Consul kann mithilfe der Docker Exec-API ein Skript in einem Container ausführen. Das Ergebnis der Prüfung hängt vom Exit-Code ab, alle Fehler ungleich Null.

    K / V-Speicher


    Der von Consul bereitgestellte Speicher ist eine verteilte Schlüsselwertdatenbank und kann zum Speichern aller Daten verwendet werden, die jedem Mitglied des Clusters zur Verfügung stehen (natürlich in Übereinstimmung mit den ACL-Regeln). Dienste können Daten speichern, die für andere Clustermitglieder in diesem Speicher erforderlich sind. Dies können die Werte von Konfigurationsoptionen, die Ergebnisse einiger Berechnungen oder, wie oben angegeben, der k / v-Speicher sein, um mithilfe des Sitzungsmechanismus verteilte Sperren zu implementieren. Durch die Verwendung von k / v-Speicher können wir den Cluster effizienter gestalten und den Prozentsatz manueller Eingriffe reduzieren. Services können ihren Status abhängig von den Informationen im Speicher anpassen, die vom Cluster garantiert werden. Bitte beachten Sie: Sie sollten keine Daten in diesem Speicher speichern, in Bezug auf die Geschäftslogik Ihrer Dienste. Der von Consul bereitgestellte Speicher dient zum Speichern und Verteilen von Metainformationen zum Status von Clustermitgliedern und nicht zu den von ihnen verarbeiteten Daten.

    Fazit


    Es ist schwierig, die Rolle des Discovery-Service beim Aufbau einer verteilten Architektur für große Projekte zu überschätzen. Consul ist großartig für diese Rolle. Das Produkt entwickelt sich und steht nicht still, es sind viele nützliche Funktionen implementiert, die für eine reibungslose Wartung eines Systems mit einer großen Anzahl von Komponenten erforderlich sind. Darüber hinaus ist Consul in Go geschrieben und wird als einzelne ausführbare Datei verteilt, was das Aktualisieren und Unterstützen sehr komfortabel macht.

    Jetzt auch beliebt: