|
如需获取最新稳定版本，请使用 Spring Boot 4.0.4！ |
安装 Spring Boot 应用程序
除了直接使用 java -jar 运行 Spring Boot 应用程序外，还可以将它们作为 systemd、init.d 或 Windows 服务运行。
安装为 systemd 服务
systemd 是 System V init 系统的继任者，目前正被许多现代 Linux 发行版使用。
Spring Boot 应用程序可以通过使用 systemd ‘service’ 脚本来启动。
假设您有一个打包为 uber jar 的 Spring Boot 应用程序，位于 /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 字段。 |
ExecStart 字段未声明脚本操作命令，这意味着默认使用 run 命令。 |
运行应用程序的用户、PID文件和控制台日志文件由systemd本身管理，因此必须通过“service”脚本中的适当字段进行配置。
有关更多详细信息，请参阅service unit 配置手册页。
要将应用程序标记为在系统启动时自动启动，请使用以下命令：
$ systemctl enable myapp.service运行 man systemctl 以获取更多详细信息。
作为 init.d 服务安装（System V）
要将您的应用程序用作 init.d 服务，请将其构建配置为生成完全可执行的 JAR。
完全可执行的 JAR 文件通过在文件开头嵌入一个额外的脚本来工作。
目前，某些工具不接受这种格式，因此您可能无法始终使用此技术。
例如，jar -xf 可能在提取已制成完全可执行的 jar 或 war 文件时静默失败。
建议您仅在打算直接执行 jar 或 war 文件，而不是使用 java -jar 运行它或将其部署到 Servlet 容器时，才将其制成完全可执行文件。 |
无法使 zip64 格式的 jar 文件完全可执行。
尝试这样做将导致生成的 jar 文件在直接执行或使用 java -jar 执行时被报告为已损坏。
包含一个或多个 zip64 格式嵌套 jar 的标准格式 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跟踪应用程序的 PID -
将控制台日志写入
/var/log/<appname>.log
假设您已在 /var/myapp 中安装了一个 Spring Boot 应用程序，若要将该 Spring Boot 应用程序作为 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 服务的情况），默认的可执行脚本会以 RUN_AS_USER 环境变量中指定的用户身份运行应用程序。
如果未设置该环境变量，则使用拥有 jar 文件的用户。
切勿以 root 身份运行 Spring Boot 应用程序，因此 RUN_AS_USER 绝不应为 root，且应用程序的 jar 文件绝不应由 root 拥有。
相反，应创建一个专用用户来运行您的应用程序，并设置 RUN_AS_USER 环境变量，或使用 chown 将该用户设置为 jar 文件的所有者，如下例所示：
$ 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文件来自定义其启动过程，则该.conf文件将由 root 用户读取并执行。
应相应地确保其安全性。
使用chmod命令使文件仅能被所有者读取，并使用chown命令将所有者设为 root，如下例所示：
$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf自定义启动脚本
Maven 或 Gradle 插件生成的默认嵌入式启动脚本可以通过多种方式进行自定义。
对大多数人来说，使用默认脚本并进行少量自定义通常就足够了。
如果您发现无法自定义某些需要的内容，请使用 embeddedLaunchScript 选项来完全编写您自己的文件。
自定义启动脚本的编写方式
通常，在将启动脚本写入 jar 文件时，自定义其中的某些元素是合理的。 例如，init.d 脚本可以提供一个“描述”。 由于你事先知道该描述（并且它不需要更改），因此在生成 jar 文件时一并提供该描述是合适的。
要自定义生成的元素，请使用 Spring Boot Maven 插件的 embeddedLaunchScriptProperties 选项，或 Spring Boot Gradle 插件的 properties 属性中的 launchScript。
默认脚本支持以下属性替换：
| 名称 | 描述 | Gradle 默认 | Maven 默认 |
|---|---|---|---|
|
脚本模式。 |
|
|
|
“INIT INFO”的 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
包含 jar 文件的文件夹 |
包含 jar 文件的文件夹 |
|
对应在默认启动脚本中内联的文件脚本的引用。
这可用于在加载任何外部配置文件之前设置环境变量，例如 |
||
|
|
||
|
|
||
|
|
||
|
|
||
|
当 |
|
|
|
|
60 |
60 |
自定义脚本运行时的行为
对于在 JAR 文件生成后需要自定义的脚本项，您可以使用环境变量或配置文件。
默认脚本支持以下环境属性：
| 变量 | 描述 |
|---|---|
|
操作“模式”。
默认值取决于 jar 的构建方式，但通常为 |
|
用于运行应用程序的用户。 未设置时，将使用拥有 jar 文件的用户。 |
|
当 |
|
pid 文件夹的根名称（默认为 |
|
用于存放日志文件的文件夹名称（默认为 |
|
读取 .conf 文件的文件夹名称（默认与 jar 文件位于同一文件夹）。 |
|
|
|
应用的名称。 如果 jar 是通过符号链接运行的，脚本会猜测应用名称。 如果不是符号链接，或者你希望显式设置应用名称，则此选项非常有用。 |
|
传递给程序（Spring Boot 应用）的参数。 |
|
默认情况下， |
|
启动 JVM 时传递给它的选项。 |
|
jar 文件的显式位置，以防该脚本用于启动一个并未实际嵌入其中的 jar 文件。 |
|
如果不为空，则在 shell 进程上设置 |
|
停止应用程序时，在强制关闭之前等待的时间（以秒为单位）（默认为 |
PID_FOLDER、LOG_FOLDER 和 LOG_FILENAME 变量仅对 init.d 服务有效。
对于 systemd，需使用“service”脚本进行相应的自定义。
有关更多详细信息，请参见service 单元配置手册页。 |
使用配置文件
除了 JARFILE 和 APP_NAME 之外，上一节中列出的设置可以通过使用 .conf 文件进行配置。
该文件应位于 jar 文件旁边，并具有相同的名称，但后缀为 .conf 而不是 .jar。
例如，名为 /var/myapp/myapp.jar 的 jar 使用名为 /var/myapp/myapp.conf 的配置文件，如下例所示：
JAVA_OPTS=-Xmx1024M
LOG_FOLDER=/custom/log/folder如果您不喜欢将配置文件放在 jar 文件旁边，可以设置 CONF_FOLDER 环境变量来自定义配置文件的位置。 |
要了解如何适当地保护此文件，请参阅保护 init.d 服务的指南。