Consul: Service Discovery ist einfach, oder verabschieden Sie sich von Konfigurationsdateien

  • Tutorial
Was ist hier interessant:

Bild

Ein Übersichtsartikel über Consul ( http://consul.io ), ein System zur Unterstützung der Serviceerkennung und der verteilten Speicherung von Schlüsselwerten. Berücksichtigen Sie neben Consul selbst auch Consul-Template - ein Tool zum Verwalten von Dienstkonfigurationen, das Änderungen in der Topologie automatisch widerspiegelt. Der Artikel ist für DevOps-Ingenieure, Systemarchitekten, Projektleiter und andere an Microservice-Architekturen interessierte Personen interessant.

Natürlich kann ich nicht alle Aspekte der Funktionsweise und des Gebrauchs von Consul behandeln, aber der Artikel wird genug beschreiben, um den neugierigen Leser zu interessieren und weiter zu vertiefen.

Konsul: "Was für ein Vogel - womit fressen sie?"

Lyrischer Exkurs, aber zum Thema.
In der heutigen Welt der riesigen Datenmengen, in der verteilte Systeme für ihre Verarbeitung nicht zu etwas aus der Welt der unerreichbaren Fiktion werden, sondern zu gewöhnlichen Dingen, werden die Fragen nach ihrer korrekten Gestaltung und Implementierung zu einem sehr wichtigen Punkt bei der nachfolgenden Entwicklung dieser Systeme. Jeder, der mindestens einmal an der Entwicklung von Architekturen für automatisch skalierbare, verteilte Systeme teilgenommen hat, weiß, dass dieser Prozess sehr zeitaufwendig ist und einen ziemlich großen Wissensstapel über Systeme erfordert, aus denen solche Architekturlösungen erstellt werden können. Angesichts der rasanten Entwicklung des Cloud-Computing und der Einführung von IaaS-Plattformen ist die Bereitstellung skalierbarer Systeme recht einfach geworden. Das Zusammenspiel der Komponenten solcher Systeme (Integration neuer Komponenten, Entfernen nicht verwendeter Teile usw.) bereitet den Architekten jedoch immer Kopfzerbrechen. Entwickler und Programmierer. Zu diesem Zweck können Sie Ihr Fahrrad erfinden (Konfigurationsdateivorlagen, Unterstützung für die Selbstregistrierung von der Anwendungsseite usw.), Sie können lokale oder verteilte Schlüsselwertspeichersysteme (Redis, Zoowärter usw.) verwenden oder Sie können verwenden Service Discovery-Systeme (Service Discovery).

Häufig bezieht sich der Begriff Service Discovery (in Zukunft werde ich die Abkürzung SD verwenden) auf Netzwerkerkennungssysteme ( z. B. SDP- Protokoll ), in letzter Zeit wird SD jedoch auch im Softwareteil von Architekturen zur gegenseitigen Erkennung verwandter Systemkomponenten verwendet. Dies gilt insbesondere für den Microservice-Ansatz zur Entwicklung von Softwaresystemen. MSA (Micro Services Architecture), einer der Pioniere und Popularisierer von Netflix, entwickelt sich zunehmend zum Standard für die Entwicklung verteilter, automatisch skalierbarer Systeme mit hoher Auslastung. Und Consul wurde häufig eingesetzt, um SD in solchen Systemen bereitzustellen. Cisco verwendet es beispielsweise in seiner Engine für MSA - Cisco MI .

Tatsächlich ist Consul eine erfolgreiche Kombination aus K / V-Speicher- und SD-Funktionalität. Nun, jetzt mehr.

Konsul: Was ist es besser?

Eine einigermaßen vernünftige Frage lautet: „Warum brauchen wir Consul, wenn wir Zookeeper haben, und er leistet bei der SD-Aufgabe hervorragende Arbeit?“ Die Antwort auf der Oberfläche ist Zookeeper, und ähnliche Systeme (etcd, doozerd, redis, etc) bieten keine SD-Funktionalität - ihre Aufgabe besteht nur darin, Daten in dem einen oder anderen Format zu speichern und ihre Verfügbarkeit und Konsistenz zu einem bestimmten Zeitpunkt zu gewährleisten (sofern dies korrekt ist) Einstellungen und Verwendung natürlich). Natürlich ist ein solches Modell ausreichend, um SD bereitzustellen, aber die Benutzerfreundlichkeit (Einstellungen, Wartung usw.) lässt oft zu wünschen übrig.

Zum Beispiel Zookeeper: Dies ist ein ständiger Streit mit seinem Cluster - beginnend mit der Ersteinrichtung (die automatisierte Installation eines zk-Clusters mit Ansible oder SaltStack kann selbst für fortgeschrittene Spezialisten ein Problem sein) und endend mit der Übertragung von Links zu einem Cluster der Form zk: // zu einer Software mit Zookeeper. 10.10.1.2:2181,10.10.1.1.3:2181,10.10.1.5:2181/app (Sie müssen zuerst wissen, wo sich der Cluster befindet, alle seine Knoten). Wenn der Zookeeper-Cluster aus irgendeinem Grund an andere Adressen verschoben wird (sehr wichtig in Cloud-Umgebungen, MSA-Architekturen), müssen Sie alle Anwendungen und Dienste, die diesen Cluster verwenden, neu starten.
Konsul macht es einfacher: HashiCorp- Leutemachte "alles für Menschen". Consul wird als 1 Binärdatei verteilt (es müssen keine Abhängigkeiten überwacht und keine Paketmanager verwendet werden), und jede Software, die Consul verwendet, stellt immer Anforderungen an localhost (es muss keine Verknüpfung zu einem Cluster oder einem Master-Dienstknoten gespeichert werden). - Consul kümmert sich um alles. Mit GossipAls Kommunikationsprotokoll macht Consul es schnell, fehlertolerant und benötigt keinen speziellen Assistenten für den normalen Betrieb. Der Master als solcher ist zwar formal verfügbar (selbst das Quorum der Master), dies ist jedoch zum größten Teil erforderlich, um einen vollständigen Stopp aller Clusterknoten zu überstehen (die Assistenten sichern die Betriebsdaten regelmäßig auf der Festplatte und gewährleisten so die Datenpersistenz). Infolgedessen beschränkt sich bei einer Anwendung (Mikrodienst), die Consul verwendet, die gesamte Arbeit mit SD auf die Kommunikation mit localhost: 8500 - wo immer die Anwendung sich bewegt - wird es immer einen Consul-Agenten geben. Für die Zusammenarbeit mit Consul benötigen Sie keine Client-Bibliotheken (wie im Fall von Zookeeper). Hierzu wird eine einfache und verständliche HTTP-REST-API verwendet (einfache Daten, nicht mehr als 20 verschiedene API-Funktionen).
Weitere Details finden Sie hier .

Konsul: Wie liefern und loslegen?

Ich muss sofort sagen, dass wir uns nicht mit der Installation und Konfiguration im Detail befassen werden - für diejenigen, die den Artikel lesen, ist dies meiner Meinung nach eine ziemlich einfache Übung. Ein einziges Problem, das Beachtung verdient, ist nicht die Transparenz bei der Suche nach Installationsdokumentationen auf der Site. Hier sind die Links: Erstinstallation (als Hausaufgabe - Entwickeln von Start / Stopp-Skripten für Ihr bevorzugtes init.d / upstart / systemd - Nichtzutreffendes streichen), Starten Agenten und Cluster-Initialisierung .

Ein paar Kommentare zur Auswahl einer Clustertopologie. Es ist nicht überflüssig zu bemerken, dass Consul keinen separaten Assistenten hat, der Servicekonfigurationen und Daten im Alleingang akzeptiert und zwischen den Knoten verteilt - absolut jeder Agent kann verwendet werden, um Services und Daten zu registrieren. Im Allgemeinen gibt es einen Master (genauer gesagt ein Quorum von Mast), dessen Hauptaufgabe darin besteht, die Persistenz von Daten während eines Neustarts des Clusters sicherzustellen.

Konsul: Registrieren Sie einen Dienst, verwenden Sie Anfragen

Wenn wir also einen fertigen Cluster (oder einen Knoten für Tests) haben, werden wir damit beginnen, Dienste zu registrieren. Zunächst erstellen wir ein hypothetisches Szenario, anhand dessen wir die Arbeit von Consul besser verstehen: Nehmen wir an, wir haben eine klassische Webanwendung, die aus mehreren Frontend-Services, mehreren Backend-Services und einem Data Warehouse besteht - sei es Mongodb. Wir werden gleich sagen, dass die Infrastruktur ein Test ist und Fragen wie: Warum ist MongoDB nicht geclustert? Warum ist HAProxy und nicht Nginx? usw. Ich lasse den neugierigen Leser als Hausaufgabe.
Bei der Arbeit mit Consul werden zwei Arten von Diensten unterschieden: aktiv (mit http rest api für die eigene Registrierung und Durchführung von Zugänglichkeitsprüfungen) und passiv (für Consul sind vorkonfigurierte Konfigurationsdateien erforderlich). Die erste umfasst lokal entwickelte Dienste (das Produkt des Unternehmens und seine Komponenten) und die zweite: Anwendungen von Drittanbietern (die die Arbeit mit Consul nicht unbedingt oder überhaupt nicht unterstützen, z. B. MongoDB).

Also werden wir die Registrierung für den MongoDB-Dienst einführen - erstelle die Datei /etc/consul.d/mongodb.json :

{
  "service": {
    "name": "mongo-db",
    "tags": ["mongo"],
    "address": "123.23.34.56",
    "port": 27017,
    "checks": [
      {
        "name": "Checking MongoDB"
        "script": "/usr/bin/check_mongo.py --host 123.23.34.56 --port 27017",
        "interval": "5s"
      }
    ]
  }
}

Das Wichtigste hier:
1. Adresse / Port - Dies sind die Daten, die Consul-Kunden als Antwort auf eine Anfrage nach Informationen über den Mongo-DB-Dienst erhalten. Die veröffentlichte Adresse muss zugänglich sein.
2. Abschnitt „Überprüfungen“ - Eine Liste von Überprüfungen, um festzustellen, ob der Dienst aktiv ist. Es kann sich um ein beliebiges Skript handeln (0 bei normaler Funktionsweise des Dienstes zurückgeben, 1 bei Warnungsstatus des Dienstes und einen anderen Wert bei Nichtverfügbarkeit des Dienstes), eine HTTP-Überprüfung (eine bestimmte URL wird angefordert und der Status des Dienstes wird basierend auf der Antwort generiert - HTTP / 2XX - der Dienst ist aktiv , HTTP / 4XX, HTTP / 5XX - der Dienst ist nicht verfügbar).

Weitere Details auf der Website: Beschreibung der Dienstleistung , Beschreibung der Schecks .

Ein anschließender Neustart des Agenten (unter Angabe von /etc/consul.d/ als Konfigurationsverzeichnis) akzeptiert diese Datei und registriert MongoDB als für SD verfügbaren Dienst. Das im Abschnitt checks angegebene Skript stellt eine Verbindung zu MongoDB auf dem angegebenen Host her (Testen der Verfügbarkeit des Dienstes) und fordert beispielsweise eine Sammlung auf, die Verfügbarkeit von Daten zu überprüfen.
Später können Sie die Registrierung mit curl überprüfen:

~/WORK/consul-tests #curl -XGET http://localhost:8500/v1/catalog/service/mongo-db
[{"Node":"mpb.local","Address":"192.168.59.3","ServiceID":"mongo-db","ServiceName":"mongo-db","ServiceTags":["mongo"],"ServiceAddress":"123.23.34.56","ServicePort":27017}]

Oder verwenden Sie den integrierten Consul DNS-Server:

~/WORK/consul-tests #dig @127.0.0.1 -p 8600 mongo-db.service.consul SRV
; <<>> DiG 9.8.3-P1 <<>> @127.0.0.1 -p 8600 mongo-db.service.consul SRV
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50711
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;mongo-db.service.consul.	IN	SRV
;; ANSWER SECTION:
mongo-db.service.consul. 0	IN	SRV	1 1 27017 mbp.local.node.dc1.consul.
;; ADDITIONAL SECTION:
NEST.local.node.dc1.consul. 0	IN	A	123.23.34.56
;; Query time: 1 msec
;; SERVER: 127.0.0.1#8600(127.0.0.1)
;; WHEN: Thu Sep 17 17:47:22 2015
;; MSG SIZE  rcvd: 152

Die Verwendung der einen oder anderen Methode zum Abrufen von Daten von Consul hängt von der Architektur der anfordernden Komponente ab (für Skripte ist die Verwendung der DNS-Schnittstelle für Komponenten, die in einer höheren Sprache geschrieben sind - REST-Anforderungen oder Spezialbibliotheken).

Alle Dienste, die die Selbstregistrierung unterstützen, sollten Bibliotheken für die erforderliche Sprache verwenden: Python , Java , Go , Ruby , PHP . Neben der eigentlichen Registrierung von Diensten ist es wichtig, Skripte zu entwickeln, mit denen die Verfügbarkeit eines bestimmten Dienstes überprüft werden kann, um ein System mit registrierten, aber nicht funktionierenden Diensten zu erhalten.

Consul: Auf Wiedersehen Konfigurationsdateien.

Wir sind der Geschichte auf den Grund gegangen - sie ist dem Lesen gewidmet. Zu einem bestimmten Zeitpunkt haben wir also die Umgebung, in der die Dienste registriert sind (z. B. Mongodb, Backend). Welchen Nutzen können wir daraus ziehen?
In herkömmlichen verteilten Systemen (ohne eingebettete SD) wird diese Technik hauptsächlich verwendet, um dem System eine neue Komponente hinzuzufügen (z. B. wenn die Auslastung zunimmt, müssen Sie ein anderes Backend erstellen):
1. Eine Backend-Service-Instanz wird erstellt (häufig unter Verwendung von SaltStack / Puppet / Ansible-Orchestrierungssystemen). / Handgefertigte Skripte / etc)
2. Das Template-Orchestrierungssystem generiert neue Konfigurationsdateien für Dienste, die das Backend verwenden (Load Balancer, Frontends usw.).
3. Das gleiche Orchestrierungssystem generiert eine Konfigurationsdatei für diesen neuen Back-End-Dienst, in der Kontaktinformationen zu Mongodb und anderen abhängigen Komponenten angegeben sind.
4. Alle abhängigen Dienste lesen die Konfiguration erneut (oder starten sie neu) und stellen die Verbindungen untereinander wieder her.
5. Das System wartet auf Konvergenz und wechselt zur Arbeit zustand.

Ein solcher Ansatz ist sehr kostspielig - Sie müssen die Dateikonfiguration generieren, verteilen, die Dienste neu starten usw. Für alle - das Orchestrierungssystem (eine Komponente außerhalb des Arbeitssystems) ist an dem Prozess beteiligt, dessen Verfügbarkeit ebenfalls überwacht werden muss.

SD ermöglicht es Ihnen, diesen Vorgang erheblich zu vereinfachen (ein neugieriger Leser hat es bereits erraten), erfordert jedoch eine Änderung des Verhaltens der im System enthaltenen Dienste. Dies ist nicht nur eine Unterstützung für SD (Dienstregistrierung und Diensterkennung), sondern auch für Fehlertoleranz (die Fähigkeit eines Dienstes, Änderungen in der Topologie untergeordneter Dienste problemlos zu überstehen), die aktive Verwendung von KV-Repositorys zum Austausch von Konfigurationsinformationen usw.
Die einzige externe Komponente, die in solchen Konfigurationen verwendet werden muss, ist das Consul-Template- Ein Tool zum Herstellen einer Verbindung zu Consul mit einer Vielzahl von Nicht-SD-unterstützenden Systemen, zum Beispiel: HAProxy. Die Aufgabe dieses Softwaretools besteht darin, die Registrierung / Deregistrierung von Diensten zu verfolgen und die Konfiguration von untergeordneten Diensten zu ändern, d.h. Wenn Sie ein neues Backend registrieren, wird die HAProxy-Konfiguration automatisch neu erstellt, um diese neue Instanz in den Lastausgleichsprozess einzubeziehen. Weitere Informationen dazu finden Sie lesen hier .
Tatsächlich kann die Verwendung von SD auf der Basis von Cunsul, Consul-Template, Consul-KV im Prinzip dazu beitragen, Konfigurationsdateien vollständig zu entfernen und alles der Gnade von Consul zu überlassen.

Als Fazit.

Aufgrund der Tatsache, dass sich Consul in der Phase der aktiven Entwicklung befindet, sind einige Probleme möglich (nach allem, was ich bemerkt habe - Probleme mit dem Clusterzusammenbruch beim Neustart aller Knoten mit Consul), aber die grundlegende SD-Funktionalität funktioniert einwandfrei und es gibt keine Beschwerden darüber. Ich möchte Sie daran erinnern, dass Consul viele Rechenzentren unterstützt, um die Verteilung zu gewährleisten.

Jetzt auch beliebt: