2016-06-14 17 views
2

Ich habe ein Problem, Hexe Start Redis Server auf einer IP-Adresse in Mesos, Marathon.Run Redis in Marathon (Mesos) unter einer URL

Meine Schritte

  • eigene Dockerfile schaffen, die eigene redis.conf umfassen
  • ich mein eigenes Docker Bild erstellen und ziehen Sie sie in Docker Repo (Name arekmax/redis-instancje)
  • in Marathon I starte meine Docker Images - starte neu und arbeite richtig. screen from my redis instancje in marathon Failover-Redis-Server in Mesos funktionieren auch richtig - wenn ich heruntergefahren 192.168.18.21 Server - Marathon Redis in zweiter oder dritter Instanz starten.

Jetzt möchte ich meine Entwickler eine Adresse IP geben, wo sie redis Server verwenden können (ich will sie nicht geben jetzt 192.168.18.21:31822 und nach dem Failover zum Beispiel 192.168.18.22:23124). Ich brauche einige Proxy-Server, wie wird automatisch überprüfen Redis IP und Port.

Ich versuche, bamboo project verwenden, aber es funktioniert ordnungsgemäß Port 80 - ich weiß nicht, seine Möglichkeit, Bambus mit Redis-Server zu verwenden - ich kann keine Informationen finden, wie 31822 umleiten (in meiner Situation Redis-Port in Docker Container) zum Beispiel IP 192.168.18.10:6739 (Adresse IP 192.168.18.10 ist es für meinen Entwickler Redis-Server)

Kann mir jemand helfen? Was ist die beste Lösung des Problems? Welche Art von Proxy-Server/Instanz/Anwendung sollte ich verwenden?

Antwort

1

Sie können zum Beispiel marathon-lb verwenden, die die ip:port Suche abstrahieren wird. Sie können auch Mesos DNS verwenden, um Servicenamen in ip:port Zuordnungen aufzulösen.

7

Es gibt Dutzende Lösungen für die Durchführung von Discovery-Service in Mesos-Umgebung.

Wir können sie in drei Gruppen, die durch die Art und Weise teilen, wie Client-Diensten:

  1. Proxy basiert
    • Wenn zwischen Kunden und Service-Proxy zB Sitzt, HAProxy (marathon-lb basiert auf ihm), fabio, traefik, nixy), die sich um das Loadbalancing Ihrer Dienste kümmert, basierend auf HTTP - Pfad, Header, Domäne usw Diese Lösung ist einfach zu entwickeln und bietet die Möglichkeit, Loadbalancing auf Anfrage anzupassen. Auf der anderen Seite fügen wir zusätzlichen Hop hinzu und als Proxy haben wir MitM Situation.

proxy

  1. DNSlike (fragen Sie spezielle bekannten Endpunkt für die Lage von Service)
    • Software Defined Network - wir IP pro Behälter mit SDN können Jeder Container wird mit einer eindeutigen IP-Adresse versehen und stellt seine Dienste unter Verwendung der Standardports 80 für HTTP, 443 für HTTPS usw. bereit. Dies ist die am weitesten fortgeschrittene und relativ neue Technik, obwohl es einfaches altes DNS verwendet, um Dienst-IP zu finden. Es könnte schwieriger sein, den Proxy zu verwenden, aber er wird mit jeder Art von Datenverkehr funktionieren.
    • Service record - wobei jeder Container im globalen DNS registriert ist und der Client seine IP und PORT mit DNS SRV-Abfragen erhält. Consul Mesos DNS bietet diese Art von DNS-Server. Auch einige andere Protokolle basieren auf dieser Idee (siehe Bonjure). Es versucht, das Beste aus SDN und Proxy zu bekommen. Es ist relativ einfach einzurichten und es ist protokollunabhängig.

dns

  1. Andere
    • Alles, was in anderen Arten nicht zum Beispiel passen Inhouse entwickelte Lösung, etcd oder Eureka. Es könnte sehr eng mit Infrastruktur und Anwendung sein und einige Optimierungen bieten. Es ist erwähnenswert, dass es einige Versuche sind DHT basierte Discovery-Dienst zu verwenden - Meta Service Discovery

können Sie weitere Informationen zu Tools finden, die

für die Erstellung von Discovery Service here

verwendet werden könnten, können wir teilen Discovery Services durch die Art und Weise werden sie mit Diensteinträge bevölkert:

  1. Pooling
    • Mesos/Marathon wird regelmäßig über den Zustand abgefragt. So funktioniert Mesos DNS. Dies ist die einfachste Methode, führt jedoch zu einer großen Verzögerung zwischen Dienststart/-stopp und Änderungen, die in die Dienstsuche eintreten. Dies könnte minimiert werden, indem Healthchecking verwendet wird.
  2. Ereignis basiert
    • Marathon hat die Fähigkeit zu push events mit Informationen über Statusänderungen (Es initative ist zu Eventbus int Mesos aufzunehmen -.. design doc Auf diese Weise Marathon-lb arbeitet ähnlicher Job von getan wird marathon-consul aber Daten werden an Konsul übergeben.
  3. In app/Behälter
    • Above sollutions sind als ynchronus, so könnte es eine Zeitspanne geben, in der Ihr Dienstentdeckungszustand abgestanden ist, z. Dienst gestartet, aber nicht bereit, Anfragen zu bedienen, oder Dienst gerade gestorben. Selbst mit healtcheck konnten wir nicht davon ausgehen, dass alle Dinge mit 0 Ausfallzeiten passieren. Die Lösung zur Minimierung von Ausfallzeiten besteht darin, dass sich die Anwendung selbst registriert, wenn sie bereit ist, Anfragen zu bedienen, und sich vor dem Stoppen abmeldet (auch bekannt als "Herunterfahren").
+0

Sehr nette Antwort @janisz. Ich frage mich, was mit 2. passiert ist? Man könnte auch erwähnen, dass ein Nachteil (neben TTL) von DNS-basierten Ansätzen die fehlende Unterstützung für die Überprüfung der Integrität ist. –

+1

Falsche Nummerierung behoben, danke. Nach DNS-Nachteilen kommt es darauf an. Wenn Sie zum Beispiel Consul verwenden, unterstützt es die Überprüfung der Integrität und [vorbereitete Abfragen] (https://www.consul.io/docs/agent/http/query.html), so dass Sie fast dieselben Konfigurationsoptionen wie beim Proxy erhalten. – janisz

+1

Wir können Traefik nicht verwenden - diese Lösung unterstützt nur HTTP, aber das Redis-Protokoll ist TCP-basiert. Unterstützung für TCP in Traefik - wird in zukünftigen Versionen kommen - es ist auf offiziellen Traefick-Support bestätigt. Aber ich muss sagen, Traefik arbeiten sehr schön im HTTP-Protokoll. – Arek