Microservice Toolchain: Wohin die .tar Pakete von Kafka, Docker, Debezium etc. entpacken?

[von Spotz]

Hallo

die Frage ist vielleicht nicht unbedingt Java-Spezifisch. Wobei unter der toolchain auch einige Java-Frameworks dabei sind. Vielleicht müßte man das Thema auch bei "Administration" etc. veröffentlichen. Trotzdem scheint es ja so zu sein, daß die meisten dieser Projekte in Java geschrieben sind und dann ist die Frage, wo man diese installiert, ja doch schon Java-Spezifisch. Außerdem sind die meisten Microservice Projekte / Dienste größtenteils in Java geschrieben.



Ich versuche mich gerade an der Installation grundlegender Microservice Toolchain / Containerizing zu installieren.

Verschiedene Tutorials entpacken die .tar Pakete, die es auf den jeweiligen Seiten zum download gibt, in verschiedene Verzeichnisse.


Einige der Tutorials legen sogar für jeden Service einen eigenen Benutzer an. Das möchte ich jetzt nicht unbedingt tun, weil es sich denke ich nicht lohnt, wenn ich erst einmal nur lokal damit herumspielen möchte.


Dann gibt es verschiedene Verzeichnisse, in welche die Tutorials die .tar Pakete entpacken. Zum Beispiel das Kafka Paket hier https://kafka.apache.org/downloads


Manche installieren nach /opt/kafka, manche nach /usr/local/kafka. Oder bei einem eigenen Benutzerkonto ins home-directory.

Die Dokumentation hier https://kafka.apache.org/quickstart sagt nicht, wohin sie entpackt, aber ruft den dienst mit

$ bin/kafka-server-start.sh config/server.properties

auf.

Es gibt mehrere Möglichkeiten, zu den Möglichkeiten, dependencies aus der microservice toolchain bereitzustellen. Einmal eben Verzeichnisse, oder bei Maven über pom.xml einbinden (die andere... Manager? ... Gradle, Ant, etc., ... kenne ich noch nicht). Andere binden über das Dockerfile ein. Wie in dem Turorial https://medium.com/phi-skills/event-driven-data-collection-d662a7db52a5

version: '3.1'
services:
  publisher:
    build: ./publisher
    ...
  handler:
    build: ./handler
    ...
  inspector:
    build: ./inspector
    ...
  entity-store:
    image: mongo:4.2.5
    ...
  event-store:
    image: confluentinc/cp-kafka:5.4.1
    ...
  zookeeper:
    image: zookeeper:3.5

Außerdem kann man ja auch die PATH Variable setzen.


Richtig oder falsch gibt es hier wohl nicht. Aber welches sind denn "best-practice" Verzeichnisse, wenn ich keinen neuen Benutzer anlege, um ein ge-tar'tes Projekt dorthin zu entpacken ?

Alles Gute
von Spotz

 

[kneitzel]

Es gibt keine klare Vorgabe.

Das, was noch als klarste Regel anzusehen ist: Wenn es in einem speziellen User-Account läuft, dann kannst Du es im Home des Users laufen lassen. Dann sollte es aber eine reine User-Angelegenheit sein (Also nicht in automatische starts eingebunden und so). Hintergrund ist hier, dass es ggf. für das /home Verzeichnis spezifische Verfahren gibt, die dem zuwider laufen (z.B. über systemd-homed Aktionen bei einem Login...)

Ansonsten kann man sagen:
/bin /sbin /lib -> Das eigentliche System. Setzt aber voraus, dass es sowas wie ein Kernsystem gibt (FreeBSD z.B., Linux hat das so nicht wirklich weshalb erste Distributionen das nur noch als Links haben.
/usr/bin /usr/sbin, .... -> Das sind Elemente der Distribution selbst
/usr/local -> Das sind vom Admin global installierte Dinge. Dies sind manuelle Installationen die eben nicht zu der Distribution gehören. (Also typischer Ort für ./configure && make && make install Aktionen um ein Beispiel zu nennen.
/opt/ -> Das wird oft genommen, wenn man Systeme installiert, die umfangreich sind und man alles zusamen halten will. in /usr/local hat man halt alles aufgetrennt in etc, bin, lib, ... in /opt/<whatever>/ hat man dann alles so, wie es die Software verlangt.

Bei Unix Systemen (FreeBSD, Linux, ... kein Mac!) ist /opt der Ort, den ich immer wähle. Da kommt dann z.B. ein individueller tomcat rein oder so.

Mac habe ich explizit ausgenommen - Apple hat sich noch nie an irgendwas gehalten, das von außen kommt Apple ist ein Pippi Langstrumpf und die macht sich die ganze Welt, wie es ihr gefällt. Da sind so Regeln nicht existent sondern es gibt eigene Regeln mit eigener Aufteilung, die genommen werden sollte. Aber es gibt vieles, das dem entgegen läuft. HomeBrew kapert z.B. /usr/local für sich. Und das eigentlich nur für einen Anwender, der da dann Schreibrechte haben soll....

 

[mrBrown]

Grundsätzlich würde ich dabei immer erstmal auf Docker (oder gleichwertige Alternativen) setzen, grad für die „Stabdardsachen“ gibt es vernünftige fertige Images.

Einmal spart man sich damit den Installationsaufwand, und zusätzlich müllst du dir dein eigenes System nicht zu.

EDIT: und wenn du es doch selbst machen willst, würd ich das auch in nem Container machen. Dann ist es gleich reproduzierbar und du müllst wieder dein eigenes System zu. Falls man es dann doch irgendwann mal außerhalb braucht, kann man das nahezu 1-zu-1 auf ein normales Linux-System umsetzen

 

[von Spotz]

Ok, wieder einmal Danke an kneitzel für die freundliche Antwort. Ich lese mich einfach einmal in die üblichen "best practice" Linux-Verzeichnisse für nicht-system und nicht-paketmanager Programme an, die etwa nur als Pakete vorliegen und/oder zusätzlich noch mit configure/make/install zu binaries kompiliert werden müssen. Also entweder dann, wie von Dir empfohlen, /opt, oder /usr/local oder, falls es das gibt, noch Unterverzeichnisse. In /usr legt der System Paketmanager die Programme ab, oder?

Danke auch an mrBrown. Kannst Du mir vielleicht noch erklären was in dem Dockerfile

build: ./publisher

bedeutet? Oder wo ich sonst eine klare Antwort bekomme, die nicht so sehr verkürzt ist, daß sie nur für bereits erfahrenerere Benutzer verständlich ist? In https://docs.docker.com/engine/reference/commandline/build/ z.B. kann ich keinen usecase finden, der so aussieht, wie die o.g. Zeile.

Viele Grüße

 

[mrBrown]

Danke auch an mrBrown. Kannst Du mir vielleicht noch erklären was in dem Dockerfile

build: ./publisher

bedeutet? Oder wo ich sonst eine klare Antwort bekomme, die nicht so sehr verkürzt ist, daß sie nur für bereits erfahrenerere Benutzer verständlich ist? In https://docs.docker.com/engine/reference/commandline/build/ z.B. kann ich keinen usecase finden, der so aussieht, wie die o.g. Zeile.

Dein Beispiel ist kein Dockerfile, sondern nutzt docker-compose: https://docs.docker.com/compose/compose-file/compose-file-v3/#build