2017-08-11 3 views
2

Wir verwenden Spring-Boot mit dem eingebetteten Launcher-Skript im service Modus, um dämonisiertes/init.d Verhalten zu haben.Spring-Boot-Start-Skript: Wie Pid_folder Identity-Unterverzeichnis zu vermeiden?

Wir haben jedoch keinen /etc/init.d Symlink zum Spring-Boot-Glas, als würde die Verwendung sudo erfordern. wir vermeiden sudo ein Profil-Umwelt wie -Dspring.profiles.active=$APP_PROFILE im JAVA_OPTS (dies funktioniert, wenn sie über sudo aber definiert in /home/appuser/.bashrc (?) gestartet wird nicht)

Wir haben dieses Verzeichnis-Layout mit einigen Umwegen zu übergeben. im Grunde app.jar => current/app.jar => build-xx/app.jar

[email protected]:~/apps/services$ ls 
app.jar -> /home/appuser/apps/services/current/services-1.0-SNAPSHOT.jar 
current -> /home/appuser/apps/services/services-1298 
services-1298 

Beim Starten die Anwendung mit app.jar start der Start-Skript ein zusätzliches pid-Unterverzeichnis im pid-Ordner auf der Grundlage der „Identität“ des Programms erzeugt. Für uns kann dies wie folgt aussehen:

/home/appuser/apps/services/run/services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298/services.pid 

Anders als wenn sie mit einem Symlink /etc/init.d verwendet, die eine besondere Behandlung und die pid-subdir bekommt services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298 weggelassen wird/bleibt stabil.

Dieses dynamische PID-Unterverzeichnis macht es sehr schwierig für uns, den Status des Daemons zu überprüfen oder während der Bereitstellung zu starten/stoppen, weil Sie immer die Reihenfolge einhalten müssen und niemand Sie daran hindert, einen Prozess zweimal zu starten (die alte Instanz und jetzt eine neue Instanz mit einem neuen Identity-Unterverzeichnis).

Also, weiß jemand, warum diese PID-Subdir-Identität Zeug existieren muss und was wäre unser bester Weg, damit umzugehen? Haben wir ein schlechtes Setup?

Jeder Ratschlag geschätzt.

Antwort

1

Sie können die Identität mithilfe der Umgebungsvariablen APP_NAME steuern.

Ich würde empfehlen, die Umgebungsvariablen Ihres Dienstes mit einer .conf Datei neben der JAR-Datei zu konfigurieren. Wenn Ihre App z. B. app.jar heißt, sollte die Datei conf den Namen app.conf haben und im selben Verzeichnis wie das jar gespeichert sein. Sie können dann APP_NAME und JAVA_OPTS usw. für Ihre Anwendung konfigurieren. Dies sollte Ihnen ermöglichen, init.d zu verwenden, wenn Sie dies wünschen.

+0

Wir benutzen '.conf' und versuchten mit' APP_NAME' zu arbeiten, aber es ist nur möglich, 'APP_NAME' als Umgebung zu setzen und wir haben verschiedene Apps von'/home/appuser/apps/... ' Backend, Frontend, API usw. - das funktioniert nur mit einer App pro User, oder? – hotzen

+0

Nein. Wenn Sie eine .conf-Datei verwenden, wie in meiner Antwort empfohlen, können Sie die Umgebung pro Anwendung konfigurieren, unabhängig davon, wie viele Benutzer beteiligt sind. –

+0

dies funktioniert nicht. APP_NAME kann nicht über einen conf-Dateieintrag konfiguriert werden aber nur über eine Umgebungsvariable. Es wird sogar verwendet, bevor die Datei conf stammt – hotzen