Microservices orchestrieren mit Docker und Consul

Wie Docker und Consul Entwicklungsprozesse revolutionieren
Kommentare

Microservices sind Anwendungsbausteine, die jeweils für sich genommen funktionieren und entsprechend einzeln angesprochen und deployed werden können. Um die Vielzahl der Microservices orchestrieren zu können, erfreut sich das Service-Discovery-Tool „Consul“ wachsender Beliebtheit.

Im folgenden Beitrag beschreibe ich anhand eines Praxisbeispiels, wie unter Einsatz von Consul und Docker die Entwicklungsprozesse deutlich verschlankt werden und Projekte schneller live gehen können.

Klassischer Deployment-Prozess: fehleranfällig und zeitaufwendig

Software-Releases durchlaufen in der Regel mehrere Zyklen und Schleifen, bevor Sie „Live“ gehen. Zwar ist diese klassische Vorgehensweise der sicherste Weg zur Implementierung der Software, jedoch ist der Prozess fehleranfällig und zeitaufwendig. So können beispielsweise mehrere Dienste in einer lokalen Umgebung gestartet werden, jedoch müssen die IP-Adressen geändert werden, damit sich die Services gegenseitig „sehen“ können. Mit jeder neuen Umgebung muss dieser Vorgang wiederholt und die IPs angepasst werden. Wenn dutzende miteinander verbundene Services bereitgestellt werden sollen, wird dieser Prozess unkontrollierbar und übermäßig fehleranfällig.

Bei großen Kundenprojekten der Neofonie durchläuft das Deployment in der Regel mehrere Phasen. Hierbei ist für jede Phase eine eigene Property-Datei mit dedizierten IP-Adressen definiert. Beispielsweise erfordert die Entwicklungsphase die manuelle Anbindung an eine MySQL-Instanz auf dem localhost. Prelive und Produktion erfordern die Anbindung der Anwendung an eine Remote-MySQL-Instanz. Dazu müssen mehrere IPs umkonfiguriert werden. So trivial das erscheinen mag, schleichen sich in solche Prozesse – wenn auch selten – Fehler ein. Infolge dessen kommt es zu Verbindungsproblemen.

Im vorliegenden Szenario verpacken wir die Anwendungen in Docker-Container, wodurch die Anwendungen separiert und vom Betriebssystem isoliert werden. Jedoch ist Docker nicht in der Lage, die IP-Adressen interdependenter Dienste selbständig aufzulösen und zu aktualisieren. Aber genau das wäre nötig, wenn ein Service ausfällt oder neu gestartet wird. Unser Ziel sind Container, die bei jedem Start und im laufenden Betrieb die IPs aller abhängigen Anwendungen und Dienste automatisiert aktualisieren. Hierfür setzen wir Consul ein.

Containerdienste mit Consul als Service Registry

Die Verwendung von Consul als DNS-Server in Kombination mit dem Consul Service Registry bedeutet, dass wir die gesamte Sammlung von Docker-Images überall ausführen können, ohne Properties anzupassen. Die Service-Topologie wird von den darunterliegenden Maschinen entkoppelt. Ganz gleich, ob Entwicklung, Test oder Produktion, das Vorgehen, wie wir Dienste anfragen, bleibt unverändert.

Alle verfügbaren Dienste in einer bestimmten Umgebung werden von der Consul Service Registry verwaltet, die selbst ebenfalls in einen Container gepackt ist und sich problemlos in jeder Umgebung starten lässt. Die übrigen Container in der Umgebung enthalten jeweils einen sog. „Consul Agent“, die sich beim Start mit der Consul Registry verbinden. Dieser Prozess wird durch die Link-Mechanik ermöglicht, die Docker mitbringt, um Umgebungsvariablen zwischen den Containern zu übertragen.

Durch Abfrage des Consul-APIs können sich unsere Dienste nun gegenseitig finden. In einigen Bereichen unserer Systems hatten wir jedoch keine vollständige Kontrolle über die Auflösung vereinzelter Dienste, weshalb wir eine erweiterte Lösung benötigt haben: Wenn sich ein bestimmter Dienst über JDBC oder ähnliche Technik mit einer Database verbinden soll, ist es nicht immer möglich, die richtige IP oder die korrekten Failover-Informationen zu ermitteln. Zur Lösung haben wir Consul als voll funktionsfähigen DNS-Server eingesetzt und in den Containern als primären DNS-Dienst eingetragen. Dadurch können wir mit dem einfachen Linux-Befehl dig die IP eines gewünschten Dienstes erhalten. Der Dienstname bleibt dabei stets unverändert; Consul löst die IP-Adressen in einem Round-Robin-Modus auf bzw. ordnet in Abhängigkeit der Dienstumgebung mehr oder weniger Adressen zu.

Neben der Service Registry und der DNS-Funktionalität bietet Consul noch weitere interessante Features: So bietet Consul nicht nur einen Key/Value-Store an, sondern führt auch Health- und Heartbeat-Checks aus. Diese Checks verwenden wir, um zu prüfen, ob ein Dienst intakt und „gesund“ ist. Dienste, die keinen Heartbeat senden, werden im Consul-Cluster mit „failed“ markiert. Consul entfernt die entsprechende IP aus der Liste der gesunden Services und damit auch aus allen anderen Konfigurationen. Auf diese Weise wird der Load-Balancer in unsere Infrastruktur sofort aktualisiert und die fehlerhafte IP nicht mehr verwendet.

Fazit

Durch die Verwendung von Consul und Docker konnten wir unseren Entwicklungs- und Bereitstellungsprozess deutlich vereinfachen. Ein Entwickler kann jetzt ganz einfach ein Projekt auf seiner lokalen Maschine auschecken und mit Docker Compose ein Teil der Produktionsumgebung auf dem lokalen Rechner starten. Consul verwaltet die Service-Topologie und sorgt dafür, dass alles korrekt verbunden wird. Das bedeutet auch, dass es keinen Unterschied mehr zwischen der Testumgebung und Produktion gibt. Dieser Ansatz reduziert die Fehlerquote, erhöht die Effizienz und verkürzt die Deploymentzeiten. Davon profitieren der Entwickler und der Kunde gleichermaßen.

Aufmacherbild: Viva La Revolucion Graffiti on Gray Cement Street Wall, Revolution Concept. von Shutterstock / Urheberrecht: igor.stevanovic

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -