Kommunikation zwischen Java und Container Orchestrator (Microservices)

[von Spotz]

Hallo,
kann ich nicht über Java neue Cluster und nodes von einem Service erstellen? Erfordert das dann nicht eine Kommunikation zwischen Java und Container Orchestrator? Zwischen dem containerisierten Java Paket und dem Container, welches dieses Paket enthält? Ist für Container wie Docker etwa ein Orchestrator verfügbar, der durch ein .jar gesteuert wird und nicht (nur) durch so etwas wie ein Dockerfile?

Bzw. was ist a) mit Zookeeper? Dieses kann doch mehrere Kafka-Nodes erstellen? (Ich weiß trotz Suche nicht genau, was Zookeeper ist. Die Beschreibung auf der Projektseite ist sehr schwammig. Hauptsache viel "distributed" ... Irgendwie scheint es "alles und nichts" zu können. Die Rolle nicht klar definierbar. Mir kommt es in bezug auf Kafka vor wie eine Art Container Manager / Container Orchestrator.

Und was ist b) mit Service Discovery Tools wie Netflix-Eureka ? Muss das nicht auch mit Containern arbeiten, obwohl es selbst containerisiert ist?

Tut mir Leid, daß meine Fragen so schwammig formuliert sind. Mir fehlt es etwas an Überblick. Mein Buch enthält wenige Beispiele aus der real world bzw. ist erst recht kein Kochbuch sondern vermittelt relativ abstrakt die Grundpattern von microservices. Kennt ihr vielleicht auch noch gute Bücher, welche eine Mischung aus soetwas und einem Kochbuch sind, oder welche nur Kochbuch sind, aber ohne sich zu sehr auf ein Framework festzunageln, etwa docker vs. kubernetes ? Für Bücherempfehlungen wäre ich dankbar.

Mit besten Grüßen
Maximilian

PS: Da domain services über Netzwerk kommunizieren und es ja kein eigenes Microservice Unterforum gibt, dachte ich mir, daß Microservice-Fragen hier evtl. aufgehoben sind?

 

[mrBrown]

PS: Da domain services über Netzwerk kommunizieren und es ja kein eigenes Microservice Unterforum gibt, dachte ich mir, daß Microservice-Fragen hier evtl. aufgehoben sind?

Hab das mal in das allgemeine Softwareentwicklungs-Forum verschoben, das passt es besser hin 🙂

 

[von Spotz]

Hab das mal in das allgemeine Softwareentwicklungs-Forum verschoben, das passt es besser hin 🙂

Gerne, solange meine Frage hoffentlich kein völliger semantischer Unsinn ist.

 

[Oneixee5]

zu b) Die Service Discovery ermöglicht es den Diensten, sich gegenseitig zu finden und miteinander zu kommunizieren, ohne Hostname und Port fest zu kodieren. Der einzige "Fixpunkt" in einer solchen Architektur besteht aus einer Service-Registry, bei der sich jeder Dienst registrieren muss. Hier spielt es also im Prinzip keine Rolle ob Container verwendet werden - es geht um Kommunikation. Die Anwendung muss über Containergrenzen hinaus im Netzwerk kommunizieren können.

 

[von Spotz]

Hallo Oneixee5,

danke für Deine Antwort.

und wie kommuniziere ich in meinem Java Projekt mit dem Container, in welchen mein Java-Projekt als domain-service containerisiert ist ?

Kannst Du vielleicht freundlicherweise ein Beispiel nennen?

Viele Grüße

 

[mrBrown]

Üblicherweise kann das im Container laufende Programm nicht direkt mit dem Container kommunizieren, abseits von der normalen Interaktion, die der Kernel so bietet.
Das geht nur, wenn man das selbst explizit bereitstellt, zB indem man den Docker-Socket in den Container mounted, und dann über diesen mit Docker kommuniziert.

 

[von Spotz]

Hallo mrBrown,

wie kann ich denn dann z.B. Cluster erstellen bzw. wie funktioniert Cluster Orchestration? Ist das etwas, auf das ich in Java keinen Einfluss habe? Wie kann ich mir das Wissen als Anfänger aneignen?

Mit besten Grüßen

 

[mrBrown]

z.B. https://www.redhat.com/de/topics/containers/what-is-container-orchestration

 

[Oneixee5]

Hallo Oneixee5,

danke für Deine Antwort.

und wie kommuniziere ich in meinem Java Projekt mit dem Container, in welchen mein Java-Projekt als domain-service containerisiert ist ?

Kannst Du vielleicht freundlicherweise ein Beispiel nennen?

Viele Grüße

Service Discovery wird einfach nur konfiguriert (z.B.: properties, yml), die Kommunikation selbst übernimmt das jeweilige Framework, z.B.: Netflix-Eureka. Ein Service ist ja kein Container. In einem Container könnten theoretisch 5 Services laufen, welche sich unabhängig voneinander bei der Service-Registry anmelden könnten. Ein Service benötigt auch nicht unbedingt einen Container, z.B.: könnte ein Service auf irgend einer VM im Netz laufen.

[CODE lang="java" title="application.yml"]eureka:
client:
registerWithEureka: true
fetchRegistry: true
serviceUrl:
defaultZone: ${EUREKA_URI:http://XYZ:8761/eureka}
instance:
appname: ${spring.application.name}:${random.value}
preferIpAddress: false[/CODE]

 

[von Spotz]

Service Discovery wird einfach nur konfiguriert (z.B.: properties, yml), die Kommunikation selbst übernimmt das jeweilige Framework, z.B.: Netflix-Eureka. Ein Service ist ja kein Container. In einem Container könnten theoretisch 5 Services laufen, welche sich unabhängig voneinander bei der Service-Registry anmelden könnten. Ein Service benötigt auch nicht unbedingt einen Container, z.B.: könnte ein Service auf irgend einer VM im Netz laufen.

[CODE lang="java" title="application.yml"]eureka:
client:
registerWithEureka: true
fetchRegistry: true
serviceUrl:
defaultZone: ${EUREKA_URI:http://XYZ:8761/eureka}
instance:
appname: ${spring.application.name}:${random.value}
preferIpAddress: false[/CODE]

Hallo Oneixee5,
allerdings ist es doch erstens relativ sinnlos, erst extra nach dem Architektur- (Entwurfsmuster?) "Microservice" voneinander unabhängig programmierte Services nicht zu containerisieren und dadurch also nicht die Möglichkeit zu geben, parallelisiert abzulaufen. Zweitens verlangen doch die Anbieter von Cloud Services, daß die Anwendungen die hochgeladen werden (als git repository vorliegen, ggf., und) daß sie containersiert sind. Oder nicht?<

Viele Grüße!
von Spotz (der Sportwagen, der echte Pferde unter der Haube hat)

 

[von Spotz]

Üblicherweise kann das im Container laufende Programm nicht direkt mit dem Container kommunizieren, abseits von der normalen Interaktion, die der Kernel so bietet.
Das geht nur, wenn man das selbst explizit bereitstellt, zB indem man den Docker-Socket in den Container mounted, und dann über diesen mit Docker kommuniziert.

Hallo BrBrown,
wie würde das gehen?
Oder kann ich stattdessen auch mit dem Service Orchestration Service kommunizieren? Das wäre nicht ganz so "meta", vor allem nicht, wenn es sich dabei tatsächlich um einen Service handelt, der so wie Eureka etwa nicht extern zu dem Microservice, den er containerisiert orchestriert, ist.

Viele Grüße!
von Spotz (das Duschgel, das Sie aus der Werbung kennen, mit den Frauen, die durchdrehen)

 

[mrBrown]

allerdings ist es doch erstens relativ sinnlos, erst extra nach dem Architektur- (Entwurfsmuster?) "Microservice" voneinander unabhängig programmierte Services nicht zu containerisieren und dadurch also nicht die Möglichkeit zu geben, parallelisiert abzulaufen. Zweitens verlangen doch die Anbieter von Cloud Services, daß die Anwendungen die hochgeladen werden (als git repository vorliegen, ggf., und) daß sie containersiert sind. Oder nicht?<

Anwendungen können auch ohne Container parallel laufen und bei den meisten Cloud-Anbietern kann man auch einfache VMs bekommen.
Container machen da nur vieles einfacher.

Oder kann ich stattdessen auch mit dem Service Orchestration Service kommunizieren? Das wäre nicht ganz so "meta", vor allem nicht, wenn es sich dabei tatsächlich um einen Service handelt, der so wie Eureka etwa nicht extern zu dem Microservice, den er containerisiert orchestriert, ist.

Die Anwendungen haben im Normalfall keine Ahnung davon, dass es überhaupt einen Service Orchestrator gibt, die laufen einfach nur in ihrem Container und sind glücklich, solange sie alles bekommen, was sie brauchen.

Deine Anwendung sollte höchstens irgendwie bekannt geben, was sie braucht – aber eben nicht dem konkreten Orchestrator, sondern besser abstrakt und deklarativ, und der Orchestrator, wenn es denn einen gibt, erfüllt das dann.