此版本仍在开发中,尚未被视为稳定版本。对于最新的稳定版本,请使用 Spring Boot 3.4.0! |
安装 Spring Boot 应用程序
除了直接使用 Spring Boot 应用程序外,还可以将它们作为 或 Windows 服务运行。java -jar
systemd
init.d
作为 systemd 服务安装
systemd
是 System V init 系统的后继者,现在被许多现代 Linux 发行版使用。
Spring Boot 应用程序可以使用 'service' 脚本启动。systemd
假设您在 中将 Spring Boot 应用程序打包为 uber jar,要将其安装为服务,请创建一个名为 的脚本并将其放在目录中。
以下脚本提供了一个示例:/var/myapp
systemd
myapp.service
/etc/systemd/system
[Unit]
Description=myapp
After=syslog.target network.target
[Service]
User=myapp
Group=myapp
Type=exec
ExecStart=/path/to/java/home/bin/java -jar /var/myapp/myapp.jar
WorkingDirectory=/var/myapp
SuccessExitStatus=143
[Install]
WantedBy=multi-user.target
请记住更改应用程序的 、 、 和 字段。Description User Group ExecStart WorkingDirectory |
该字段不声明 script action 命令,这意味着默认情况下使用该命令。ExecStart run |
运行应用程序的用户、PID 文件和控制台日志文件由其自身管理,因此必须使用 'service' 脚本中的相应字段进行配置。
有关更多详细信息,请参阅 Service Unit configuration 手册页。systemd
要将应用程序标记为在系统引导时自动启动,请使用以下命令:
$ systemctl enable myapp.service
运行 了解更多详情。man systemctl
作为 init.d 服务 (System V) 安装
要将应用程序用作服务,请配置其构建以生成完全可执行的 jar。init.d
完全可执行的 jar 通过在文件前面嵌入额外的脚本来工作。
目前,某些工具不接受此格式,因此您可能并不总是能够使用此技术。
例如,可能会以静默方式无法提取已完全可执行的 jar 或 war。
建议仅在打算直接执行 jar 或 war 时才使 jar 或 war 完全可执行,而不是使用 servlet 容器运行它或将其部署到 servlet 容器。jar -xf java -jar |
无法使 zip64 格式的 jar 文件完全可执行。
尝试执行此操作将导致 jar 文件在直接执行或使用 .
包含一个或多个 zip64 格式嵌套 jar 的标准格式 jar 文件可以完全执行。java -jar |
要使用 Maven 创建“完全可执行”的 jar,请使用以下插件配置:
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<configuration>
<executable>true</executable>
</configuration>
</plugin>
以下示例显示了等效的 Gradle 配置:
tasks.named('bootJar') {
launchScript()
}
然后可以对其进行符号链接以支持标准的 、 、 和 命令。init.d
start
stop
restart
status
添加到完全可执行 jar 的默认启动脚本支持大多数 Linux 发行版,并在 CentOS 和 Ubuntu 上进行了测试。 其他平台(如 OS X 和 FreeBSD)需要使用自定义脚本。 默认脚本支持以下功能:
-
以拥有 jar 文件的用户身份启动服务
-
使用
/var/run/<appname>/<appname>.pid
-
将控制台日志写入
/var/log/<appname>.log
假设您在 中安装了 Spring Boot 应用程序,要将 Spring Boot 应用程序安装为服务,请创建一个符号链接,如下所示:/var/myapp
init.d
$ sudo ln -s /var/myapp/myapp.jar /etc/init.d/myapp
安装后,您可以按照通常的方式启动和停止服务。 例如,在基于 Debian 的系统上,您可以使用以下命令启动它:
$ service myapp start
如果您的应用程序无法启动,请检查写入的日志文件是否有错误。/var/log/<appname>.log |
您还可以使用标准操作系统工具将应用程序标记为自动启动。 例如,在 Debian 上,您可以使用以下命令:
$ update-rc.d myapp defaults <priority>
保护 init.d 服务
以下是有关如何保护作为 init.d 服务运行的 Spring Boot 应用程序的一组准则。 它并不是为强化应用程序及其运行环境而应执行的所有操作的详尽列表。 |
当以 root 身份执行时,就像使用 root 启动 init.d 服务时一样,默认可执行脚本以环境变量中指定的用户身份运行应用程序。
如果未设置环境变量,则使用拥有 jar 文件的用户。
您永远不应该以 root 身份运行 Spring Boot 应用程序,因此永远不应该是 root,并且应用程序的 jar 文件永远不应该归 root 所有。
相反,请创建一个特定用户来运行您的应用程序并设置环境变量或使用使其成为 jar 文件的所有者,如以下示例所示:RUN_AS_USER
root
RUN_AS_USER
RUN_AS_USER
chown
$ chown bootapp:bootapp your-app.jar
在这种情况下,默认可执行脚本以用户身份运行应用程序。bootapp
为了减少应用程序用户帐户被盗用的几率,您应该考虑阻止它使用登录 shell。
例如,您可以将账户的 shell 设置为 ./usr/sbin/nologin |
您还应该采取措施来防止修改应用程序的 jar 文件。 首先,配置其权限,使其无法写入,只能由其所有者读取或执行,如下例所示:
$ chmod 500 your-app.jar
其次,您还应该采取措施来限制您的应用程序或运行它的账户被盗用时的损害。
如果攻击者确实获得了访问权限,他们可以使 jar 文件可写并更改其内容。
防止这种情况的一种方法是使用 使其不可变,如以下示例所示:chattr
$ sudo chattr +i your-app.jar
这将阻止任何用户(包括 root)修改 jar。
如果使用 root 来控制应用程序的服务,并且您使用 .conf
文件自定义其启动,则 root 用户将读取和评估该文件。
它应该得到相应的保护。
使用,以便文件只能由所有者读取,并用于使 root 成为所有者,如以下示例所示:.conf
chmod
chown
$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf
自定义启动脚本
可以通过多种方式自定义 Maven 或 Gradle 插件编写的默认嵌入式启动脚本。
对于大多数人来说,使用默认脚本和一些自定义通常就足够了。
如果您发现无法自定义所需的内容,请使用该选项完全编写您自己的文件。embeddedLaunchScript
在编写 start 脚本时对其进行自定义
在将启动脚本写入 jar 文件时,自定义启动脚本的元素通常是有意义的。 例如,init.d 脚本可以提供 “description”。 由于您预先知道描述(并且不需要更改),因此您也可以在生成 jar 时提供它。
要自定义编写的元素,请使用 Spring Boot Maven 插件的选项或 Spring Boot Gradle 插件的 launchScript
的 properties
属性。embeddedLaunchScriptProperties
默认脚本支持以下属性替换:
名字 | 描述 | Gradle 默认 | Maven 默认 |
---|---|---|---|
|
脚本模式。 |
|
|
|
“INIT INFO” 部分 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
的单行版本(回退到 |
|
|
|
|
|
|
|
|
|
|
的默认值 |
包含 jar 的文件夹 |
包含 jar 的文件夹 |
|
对应在默认启动脚本中内联的文件脚本的引用。
这可用于设置环境变量,例如在加载任何外部配置文件之前 |
||
|
的默认值。
仅对服务 |
||
|
的默认值。
仅对服务 |
||
|
的默认值。
仅对服务 |
||
|
中 PID 文件名称的默认值。
仅对服务 |
||
|
是否应使用命令(如果可用)来控制进程 |
|
|
|
默认值(以秒为单位)。
仅对服务 |
60 |
60 |
在脚本运行时自定义脚本
对于在编写 jar 后需要自定义的脚本项,您可以使用环境变量或配置文件。
默认脚本支持以下环境属性:
变量 | 描述 |
---|---|
|
操作的 “模式”。
默认值取决于 jar 的构建方式,但通常是(这意味着它试图通过检查它是否是名为 的目录中的符号链接来猜测它是否是 init 脚本)。
您可以将其显式设置为 to 以便命令正常工作,或者 to 如果您想在前台运行脚本。 |
|
将用于运行应用程序的用户。 如果未设置,则将使用拥有 jar 文件的用户。 |
|
是否应使用命令(如果可用)来控制进程。
默认为 。 |
|
pid 文件夹的根名称(默认)。 |
|
放置日志文件的文件夹的名称(默认为)。 |
|
要从中读取 .conf 文件的文件夹的名称(默认情况下与 jar-file 相同)。 |
|
( 默认为) 中的日志文件的名称。 |
|
应用程序的名称。 如果 jar 是从符号链接运行的,则脚本会猜测应用程序名称。 如果它不是符号链接,或者你想显式设置应用程序名称,这可能很有用。 |
|
要传递给程序(Spring Boot 应用程序)的参数。 |
|
默认情况下,可执行文件的位置是使用 发现的,但如果 中存在可执行文件,则可以显式设置它。 |
|
启动 JVM 时传递给 JVM 的选项。 |
|
jar 文件的显式位置,以防脚本用于启动实际上并未嵌入的 jar。 |
|
如果不为空,则在 shell 进程上设置标志,以便您查看脚本中的逻辑。 |
|
在强制关闭之前停止应用程序时等待的时间(以秒为单位)(默认情况下)。 |
、 和 变量仅对服务有效。
对于 ,等效的自定义是使用 'service' 脚本进行的。
有关更多详细信息,请参阅 Service Unit configuration 手册页。PID_FOLDER LOG_FOLDER LOG_FILENAME init.d systemd |
使用 Conf 文件
除 和 外,上一节中列出的设置可以使用文件进行配置。
该文件应位于 jar 文件旁边,并且具有相同的名称,但后缀为 而不是 .
例如,名为 的 jar 使用名为 的配置文件,如以下示例所示:JARFILE
APP_NAME
.conf
.conf
.jar
/var/myapp/myapp.jar
/var/myapp/myapp.conf
JAVA_OPTS=-Xmx1024M
LOG_FOLDER=/custom/log/folder
如果您不喜欢将配置文件放在 jar 文件旁边,则可以设置环境变量来自定义配置文件的位置。CONF_FOLDER |
要了解如何适当地保护此文件,请参阅保护 init.d 服务的准则。