我們在service
模式下使用帶有嵌入式啓動腳本的彈簧引導,以實現daemonized/init.d行爲。spring-boot launch-script:如何避免pid_folder identity-subdirectory?
但是,我們沒有/etc/init.d
符號鏈接到彈簧引導罐,因爲這需要使用sudo
。我們避免sudo
通過一個配置文件,環境像-Dspring.profiles.active=$APP_PROFILE
在JAVA_OPTS
(當通過sudo
開始,但在/home/appuser/.bashrc
(?)定義,這將不起作用)
我們有這個目錄佈局一些間接引用。基本上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
當開始與app.jar start
啓動腳本生成在PID-夾基於該程序的「同一性」的附加的PID子目錄中的應用。對我們來說,這可能是這樣的:
/home/appuser/apps/services/run/services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298/services.pid
與符號鏈接/etc/init.d
它得到特殊待遇和PID-子目錄省略services-1.0-SNAPSHOT_homeappuserappsservicesservices-1298
使用時不像/保持穩定。
這個動態的pid-subdir使得我們很難在部署過程中檢查守護進程的狀態或啓動/停止,因爲您必須始終順序正確,沒有人阻止您啓動一個進程兩次(舊實例和現在是具有新標識 - 子目錄的新實例)。
那麼,有沒有人知道爲什麼這個pid-subdir-identity必須存在,我們最好的辦法是什麼? 我們有一個不好的設置?
任何意見讚賞。
我們使用'.conf'並嘗試使用'APP_NAME',但只能將'APP_NAME'設置爲環境並且我們有幾個不同的應用程序unser'/ home/appuser/apps/...'後端,前端,api等 - 這隻適用於每個用戶的一個應用程序,不是嗎? – hotzen
不可以。如果您在我的回答中建議使用.conf文件,則可以根據每個應用程序配置環境,而不考慮涉及多少用戶 –
這不起作用,APP_NAME無法通過conf文件條目進行配置但只能通過一個環境變量。它甚至在conf文件來源之前使用 – hotzen