© Liashko/Shutterstock.com
Entwickler Magazin
Consul: Service Discovery für den Microservices-Stack

Wo bist du?

HashiCorp hat mit Consul eine inzwischen fest etablierte Service-Discovery-Lösung geschaffen. Ein Konsul ist ein entsandter Beamter, der in einem fremden Staat die Interessen der eigenen Bevölkerung wahrt und den Handel fördert. Betrachtet man eine Microservices-Landschaft als fremdes Land und die Einwohner als einzelne Services, die sich austauschen, kann man mit etwas Wohlwollen die Namensgebung nachvollziehen. Einen Überblick über Einsatzzweck, Features und Aufbau bietet dieser Artikel.

Simon Kölsch


In einer verteilten Systemlandschaft gilt es irgendwann, das Problem zu lösen, wie Services sich gegenseitig im Netz finden. Der einfachste Ansatz ist es, in den betreffenden Services eine feste Konfiguration zu hinterlegen. Meist finden sich dann hinter einem Servicenamen eine IP-Adresse und der dazugehörige Port wieder. Eine etwas dynamischere Lösung ist es, anstatt IP-Adressen einen DNS-Eintrag zu verwenden. Dabei können Adresse und Port z. B. in einem DNS SRV Record hinterlegt werden. Auch ist es möglich, mehrere Instanzen der gleichen Services zur Verfügung zu stellen, indem man ein Round-Robin-Verfahren nutzt. Vereinfacht ausgedrückt wird bei jeder Anfrage die IP-Adresse einer anderen Instanz zurückgegeben.

Welche Probleme löst dann eigentlich noch Consul? Zum reinen Auflösen von Namen und Ports kommen in einem moderneren verteilten System schnell weitere Anforderungen dazu: Services sollen sich oft an einem zentralen API registrieren können. Bereits registrierte Dienste müssen per Health Check auf ihre Erreichbarkeit geprüft werden, um sie im Fehlerfall automatisiert aus der Registry zu entfernen. Außerdem ist die Discovery ein fester Teil der Infrastruktur und muss daher natürlich auch eine entsprechende Robustheit und Ausfallsicherheit bieten. Kann mein Service die anderen Systeme nicht finden, ist das oft mit einem Netzwerkausfall gleichzusetzen. Außerdem benötigt man häufig eine zentrale Stelle, um systemweite Konfiguration wie „Feature Toggles“ ablegen zu können, die bestimmte Features an- oder abschalten. Traditionelle DNS-Server sind mit anderen Zielen entwickelt worden, und eine selbstgebaute Lösung entspricht vom Aufwand eher einem eigenen Projekt. Aus diesem Grund lohnt sich ein Blick auf Consul.

Die Servicedefinition ist der erste Schritt

Um einen Service registrieren und abfragen zu können, ist es wichtig, wie die Discovery einen Service definiert und welche Informationen verfügbar sind und gespeichert werden. Bei Consul besteht eine Servicedefinition grundlegend aus ID, Name, IP-Adresse und Port. Optional können noch das Rechenzentrum, beliebige Tags und Health Checks angegeben werden. Das Rechenzentrum ist dabei nicht nur eine reine Zusatzinformation, sondern dient zur Strukturierung und Aufbau des Clusters. Der Name muss nicht eindeutig sein. Damit können mehrere Instanzen der gleichen Services unterstützt werden. Die Unterscheidung nach Instanzen ist bewusst gewählt und ermöglicht so z. B. die Konfiguration von unterschiedlichen Heal...

Entwickler Magazin
Consul: Service Discovery für den Microservices-Stack

Wo bist du?

HashiCorp hat mit Consul eine inzwischen fest etablierte Service-Discovery-Lösung geschaffen. Ein Konsul ist ein entsandter Beamter, der in einem fremden Staat die Interessen der eigenen Bevölkerung wahrt und den Handel fördert. Betrachtet man eine Microservices-Landschaft als fremdes Land und die Einwohner als einzelne Services, die sich austauschen, kann man mit etwas Wohlwollen die Namensgebung nachvollziehen. Einen Überblick über Einsatzzweck, Features und Aufbau bietet dieser Artikel.

Simon Kölsch


In einer verteilten Systemlandschaft gilt es irgendwann, das Problem zu lösen, wie Services sich gegenseitig im Netz finden. Der einfachste Ansatz ist es, in den betreffenden Services eine feste Konfiguration zu hinterlegen. Meist finden sich dann hinter einem Servicenamen eine IP-Adresse und der dazugehörige Port wieder. Eine etwas dynamischere Lösung ist es, anstatt IP-Adressen einen DNS-Eintrag zu verwenden. Dabei können Adresse und Port z. B. in einem DNS SRV Record hinterlegt werden. Auch ist es möglich, mehrere Instanzen der gleichen Services zur Verfügung zu stellen, indem man ein Round-Robin-Verfahren nutzt. Vereinfacht ausgedrückt wird bei jeder Anfrage die IP-Adresse einer anderen Instanz zurückgegeben.

Welche Probleme löst dann eigentlich noch Consul? Zum reinen Auflösen von Namen und Ports kommen in einem moderneren verteilten System schnell weitere Anforderungen dazu: Services sollen sich oft an einem zentralen API registrieren können. Bereits registrierte Dienste müssen per Health Check auf ihre Erreichbarkeit geprüft werden, um sie im Fehlerfall automatisiert aus der Registry zu entfernen. Außerdem ist die Discovery ein fester Teil der Infrastruktur und muss daher natürlich auch eine entsprechende Robustheit und Ausfallsicherheit bieten. Kann mein Service die anderen Systeme nicht finden, ist das oft mit einem Netzwerkausfall gleichzusetzen. Außerdem benötigt man häufig eine zentrale Stelle, um systemweite Konfiguration wie „Feature Toggles“ ablegen zu können, die bestimmte Features an- oder abschalten. Traditionelle DNS-Server sind mit anderen Zielen entwickelt worden, und eine selbstgebaute Lösung entspricht vom Aufwand eher einem eigenen Projekt. Aus diesem Grund lohnt sich ein Blick auf Consul.

Die Servicedefinition ist der erste Schritt

Um einen Service registrieren und abfragen zu können, ist es wichtig, wie die Discovery einen Service definiert und welche Informationen verfügbar sind und gespeichert werden. Bei Consul besteht eine Servicedefinition grundlegend aus ID, Name, IP-Adresse und Port. Optional können noch das Rechenzentrum, beliebige Tags und Health Checks angegeben werden. Das Rechenzentrum ist dabei nicht nur eine reine Zusatzinformation, sondern dient zur Strukturierung und Aufbau des Clusters. Der Name muss nicht eindeutig sein. Damit können mehrere Instanzen der gleichen Services unterstützt werden. Die Unterscheidung nach Instanzen ist bewusst gewählt und ermöglicht so z. B. die Konfiguration von unterschiedlichen Heal...

Neugierig geworden?


    
Loading...

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang