Konvertiere meine Knoten App in Docker/Kubernetes?

Question

Ich habe eine Knoten-App, die aus mehreren unabhängigen Modulen besteht, die über AMQP miteinander kommunizieren. Diese App wird von einer Datei index.js gestartet, die jede andere index.js in den verschiedenen Ordnern meines Projekts installiert, die wiederum die eigentlichen Module instanziieren.

Ich habe über Microservices gelesen und möchte meine Anwendung in Docker Container konvertieren. Ich habe Beispiele gefunden, wie man eine einfache Knoten-App in Docker konvertiert, aber ich möchte meine App so trennen, dass jedes Modul in einem unabhängigen Knoten-Container ist (weil jedes Modul unabhängig ist und nicht von anderen Modulen abhängt) Sie erhalten Arbeit von der Nachrichtenwarteschlange und stellen Ergebnisse in die Nachrichtenwarteschlange ein.

Was ich nicht finden kann, ist Informationen darüber, wie ich meinen Code organisieren und bereitstellen sollte. Soll ich für jedes meiner Module ein anderes Node-Projekt (mit separaten packages.json) haben? Oder sollte ich ein einzelnes Node-Projekt für alle meine Module haben und jedes einzeln bereitstellen?

Nachdem ich mein Projekt organisiert habe, gibt es ein Skript-Tool, das jedes meiner Module in einem eigenen Container generiert (build * und deploy)? Alle Beispiele, die ich bisher gefunden habe, sind "Hallo Welt" -Proben, die nur eine App packen.

Muss ich während der Entwicklung für jede Änderung, die ich testen möchte, neue Container bereitstellen?

*: Build, weil ich ES6 benutze und ich muss Babel verwenden.

Answer 1

Sollte ich eine separate packages.json für jede Dockerfile haben? Von dem, was ich gelesen habe, verstehe ich, dass die Dockerfile tatsächlich NPM ausführen und die tatsächlichen Pakete herunterladen wird. Wenn ich eine einzelne Paketdatei habe, würde ich in jedem meiner Bilder mit nicht benutzten Modulen viel aufgebläht haben.

Sicher haben Sie Bloat, das ist die Schönheit von Microservice, und That's the curse of Microservice.

Sollte ich eine separate packages.json haben?

Okay, lassen Sie mich versuchen, diese Frage speziell anzusprechen. Lassen Sie uns einfach sagen, Ihr Modul verwendet lodash.x.x.x. Und Sie möchten lodash.x + 1.x.x in moduleB verwenden. Sie sind sicher, dass lodash.x + 1.x.x nicht abwärtskompatibel zu lodash.x.x.x ist. Jetzt müssen Sie den Code von ModuleA mit lodash.x + 1.x.x kompatibel machen. Wenn das oben Gesagte wahr ist, nennen wir diese Anwendungen als Monolithen, nicht als Microservices. Um Ihre Frage zu beantworten, ja, Sie brauchen möglicherweise separate packages.json, es sei denn, Sie können ein Elternteil package.json mit gemeinsamen Abhängigkeiten und Submodule mit eigenen Paket.json (Ich bin nicht von Knoten-Land, so nicht sicher, ob Paket. json haben solche Fähigkeiten)

Was ich nicht finden können, sind Informationen darüber, wie ich organisieren sollte und meinen Code bereitstellen. Sollte ich für jedes meiner Module ein anderes Node-Projekt (mit separaten packages.json) haben? Oder sollte ich einen einzigen Knoten haben Projekt für alle meine Module und deploy jedes von ihnen einzeln?

Ich habe beide Muster (separate Projekte sowie Submodule in demselben Projekt) gesehen. Meine persönliche Meinung (für was es sich lohnt) ist ein separates Projekt und eine separate Code-Basis, da Ihre "Module" bereits über ein sprachunabhängiges Protokoll-AMQP sprechen. Morgen möchtest du vielleicht golang/kotlin für "ModuleB" verwenden (microserviceB, je nachdem wie du es siehst :)), wer weiß.

Nachdem ich mein Projekt organisiert haben, ist es ein Skript-Tool, das generieren (Build * und bereitstellen) jedes meiner Module zu einem eigenen Container?

Eine Sache, hier zu klären ist, Entwicklung und Implementierung eines Micro sollten Sie nicht andere Microservices zu ändern erzwingen/deploy solange der Vertrag zwischen ihnen intakt gehalten wird, sonst ist es ein verteiltes-Monolithen (whoa. . habe ich gerade einen neuen Begriff erfunden? Wenn es eine Vertragsänderung gibt, sollten Sie die Version stürzen und die Version für eine Weile laufen lassen, bis alle betroffenen Parteien (Ihre anderen Microservices) die Möglichkeit haben, ein Upgrade durchzuführen.

Answer 2

Es gibt mehrere Schichten, die Sie durchlaufen müssen.

Zuerst müssen Sie jeden Microservice in ein eigenes Containerbild containerisieren. Normalerweise verwenden Sie Docker dafür.

Jede App verfügt über eine separate Dockerdatei, die Sie zum Erstellen von Docker-Images verwenden, die Sie an Docker-Image-Registries senden, die von jedem, der Ihre App ausführen möchte, abgerufen werden.

Wie bei der Codebasenorganisation können Sie ein Repository mit all Ihren Microservices haben, aber Sie benötigen mehrere Dockerfiles, um Bilder für alle zu erstellen.

Dann müssen Sie Ihre aus Ihren Bildern erstellten Container orchestrieren (ausführen). Wenn Sie möchten, dass Ihre App auf einem Host ausgeführt wird, können Sie Docker Compose verwenden, mit dem Sie definieren können, welche Container in welcher Reihenfolge in einer einzelnen YAML-Manifestdatei ausgeführt werden. Docs sind hier: https://docs.docker.com/compose/

Wenn Sie Ihre App in einem kubernetes-Cluster ausführen möchten, sollten Sie eine k8s-Deployment (https://kubernetes.io/docs/concepts/workloads/controllers/deployment/) erstellen, die Ihre Container als Pods auf Ihren Clusterknoten ausführen wird.