Gibt es einen "Standard" Folder für Spring deployment auf Linux Servern?

Thallius

Top Contributor
Hi,

vielleicht eine etwas komische Frage da es ja im Prinzip total egal ist wo ich die Spring App installiere aber vielleicht gibt es ja sowas wie einen quasi Standard oder eine Vorgabe in welchen Ordner man die .jar eigentlich kopieren soll auf einen Linux server?

Wo lieben die bei euch?

Gruß

Claus
 
K

kneitzel

Gast
Also bei Linux / Unix Systemen ist zusätzliche Software entweder in /usr/local (und verteilt sich da auf bin,etc,lib,....) oder in /opt (da dann in einem eigenständigen Verzeichnis, das die Software für sich hat, also /opt/meineSoftware/ oder so...
 

httpdigest

Top Contributor
was bringt mir denn Docker wenn auf dem Server nur eine Applikation benutzt wird?
Containerisierung hat viele Vorteile: Einfacheres Ausrollen der Anwendung und eventuelle Abhängigkeiten (in Form von Systemkomponenten), die die Anwendung benötigt (z.B. ein JRE). Du musst halt auf dem Server selber nicht apt install blabla machen und kannst schnell alles wieder aufräumen mit einem einzigen Befehl.
Das hat überhaupt nichts damit zu tun, wie viele Anwendungen auf dem Server laufen.
 

Thallius

Top Contributor
Containerisierung hat viele Vorteile: Einfacheres Ausrollen der Anwendung und eventuelle Abhängigkeiten (in Form von Systemkomponenten), die die Anwendung benötigt (z.B. ein JRE). Du musst halt auf dem Server selber nicht apt install blabla machen und kannst schnell alles wieder aufräumen mit einem einzigen Befehl.
Das hat überhaupt nichts damit zu tun, wie viele Anwendungen auf dem Server laufen.

hm also ich habe eine mit Maven erstellte .jar die sogar den Tomcat enthält. Mein deployment ist also das kopieren dieser einen Datei auf den Server. Deinstallieren wäre dann das löschen dieser Datei. Ich glaube das kann ein container Nicht wirklich vereinfachen...
 

httpdigest

Top Contributor
hm also ich habe eine mit Maven erstellte .jar die sogar den Tomcat enthält. Mein deployment ist also das kopieren dieser einen Datei auf den Server. Deinstallieren wäre dann das löschen dieser Datei. Ich glaube das kann ein container Nicht wirklich vereinfachen...
Und wer hat dir automatisch ein JRE auf dem Server installiert?

Heutzutage würde ich - egal, wie klein die Anwendung ist und wie wenig Anwendungen auf dem Server laufen sollen - eigentlich niemals mehr eine Anwendung "nackt" auf einen Server deployen/kopieren.
Ich will in der Lage sein, ohne manuelle Schritte flexibel morgen auf einen anderen Server bzw. eine andere Instanz zu deployen. Auch will ich in der Lage sein, die Anwendung per Continous Delivery auf meinen Server zu deployen, zu testen und wieder abreißen zu können. Ebenfalls ohne manuelle Schritte.
Natürlich schwinden die Vorteile von Containerisierung, wenn das alles im konkreten Fall keine Anforderungen sind.

EDIT: Ihr müsst mal in einer Firma gearbeitet haben, wo pro Pull Request eine ganze Infrastruktur per AWS automatisch hochgezogen wird (DNS Routing, CDN Distribution, Serverinstanzen, Firewall-Regeln, Load Balancing, NAT, ...), die Anwendung deployed wird, dann automatisiert getestet und dann das ganze Setup in wenigen Minuten wieder abgeräumt wird.
Da bekommt das Wort "DevOps" eine ganz andere Dimension. :)
 
Zuletzt bearbeitet:

sascha-sphw

Top Contributor
Containerisierung hat viele Vorteile: Einfacheres Ausrollen der Anwendung und eventuelle Abhängigkeiten (in Form von Systemkomponenten), die die Anwendung benötigt (z.B. ein JRE). Du musst halt auf dem Server selber nicht apt install blabla machen und kannst schnell alles wieder aufräumen mit einem einzigen Befehl.
Das hat überhaupt nichts damit zu tun, wie viele Anwendungen auf dem Server laufen.
Muss ich mir mal genauer anschauen. Wie sieht es mit einer DB aus, läuft die dann auch in diesem Container?
 

Thallius

Top Contributor
Und wer hat dir automatisch ein JRE auf dem Server installiert?

Heutzutage würde ich - egal, wie klein die Anwendung ist und wie wenig Anwendungen auf dem Server laufen sollen - eigentlich niemals mehr eine Anwendung "nackt" auf einen Server deployen/kopieren.
Ich will in der Lage sein, ohne manuelle Schritte flexibel morgen auf einen anderen Server bzw. eine andere Instanz zu deployen. Auch will ich in der Lage sein, die Anwendung per Continous Delivery auf meinen Server zu deployen, zu testen und wieder abreißen zu können. Ebenfalls ohne manuelle Schritte.
Natürlich schwinden die Vorteile von Containerisierung, wenn das alles im konkreten Fall keine Anforderungen sind.

EDIT: Ihr müsst mal in einer Firma gearbeitet haben, wo pro Pull Request eine ganze Infrastruktur per AWS automatisch hochgezogen wird (DNS Routing, CDN Distribution, Serverinstanzen, Firewall-Regeln, Load Balancing, NAT, ...), die Anwendung deployed wird, dann automatisiert getestet und dann das ganze Setup in wenigen Minuten wieder abgeräumt wird.
Da bekommt das Wort "DevOps" eine ganz andere Dimension. :)

das würde aber erfordern, dass auch das ganze Server Kernel mit allem drum und dran mit installiert wird. Da wird es dann aber recht kompliziert. Und wenn wie bei uns die Server fertig von Amazon konfiguriert werden, dann brauch ich nicht mehr viel machen

Ich habe die Nützlichkeit von Containern ja nicht generell in Frage gestellt aber ich Hasse es, dass heute so oft mit Kanonen auf Spatzen geschossen wird.
 

Neue Themen


Oben