部署 Spring Boot 应用程序
1. 部署到云
Spring Boot 的可执行 jar 对于大多数流行的云 PaaS(平台即服务)提供商来说是现成的。 这些提供商往往要求您 “自带容器”。 它们管理应用程序进程(而不是专门管理 Java 应用程序),因此它们需要一个中间层,使您的应用程序适应云中正在运行的进程的概念。
两个流行的云提供商 Heroku 和 Cloud Foundry 采用“buildpack”方法。
buildpack 将您部署的代码包装在启动应用程序所需的任何内容中。
它可能是 JDK 和对嵌入式 Web 服务器的调用,也可能是成熟的应用程序服务器。
buildpack 是可插拔的,但理想情况下,您应该能够通过尽可能少的自定义来获得它。
这减少了不受您控制的功能的占用空间。
它最大限度地减少了开发和生产环境之间的差异。java
理想情况下,你的应用程序(如 Spring Boot 可执行 jar)具有打包运行所需的一切。
在本节中,我们将了解如何在云中启动并运行我们在 “入门” 部分中开发的应用程序。
1.1. Cloud Foundry
Cloud Foundry 提供了默认的 buildpack,如果未指定其他 buildpack,则这些 buildpack 将发挥作用。
Cloud Foundry Java buildpack 对 Spring 应用程序(包括 Spring Boot)提供了出色的支持。
您可以部署独立的可执行 jar 应用程序以及传统的打包应用程序。.war
构建应用程序(例如,通过使用)并安装 cf
命令行工具后,使用命令部署应用程序,并将路径替换为已编译的 .
在推送应用程序之前,请确保已使用 cf
命令行客户端登录。
以下行显示了如何使用命令部署应用程序:mvn clean package
cf push
.jar
cf push
$ cf push acloudyspringtime -p target/demo-0.0.1-SNAPSHOT.jar
在前面的示例中,我们替换您作为应用程序名称提供的任何值。acloudyspringtime cf |
有关更多选项,请参阅 cf push
文档。
如果同一目录中存在 Cloud Foundry manifest.yml
文件,则考虑该文件。
此时,开始上传您的应用程序,生成类似于以下示例的输出:cf
Uploading acloudyspringtime... OK Preparing to start acloudyspringtime... OK -----> Downloaded app package (8.9M) -----> Java Buildpack Version: v3.12 (offline) | https://github.com/cloudfoundry/java-buildpack.git#6f25b7e -----> Downloading Open Jdk JRE Expanding Open Jdk JRE to .java-buildpack/open_jdk_jre (1.6s) -----> Downloading Open JDK Like Memory Calculator 2.0.2_RELEASE from https://java-buildpack.cloudfoundry.org/memory-calculator/trusty/x86_64/memory-calculator-2.0.2_RELEASE.tar.gz (found in cache) Memory Settings: -Xss349K -Xmx681574K -XX:MaxMetaspaceSize=104857K -Xms681574K -XX:MetaspaceSize=104857K -----> Downloading Container Certificate Trust Store 1.0.0_RELEASE from https://java-buildpack.cloudfoundry.org/container-certificate-trust-store/container-certificate-trust-store-1.0.0_RELEASE.jar (found in cache) Adding certificates to .java-buildpack/container_certificate_trust_store/truststore.jks (0.6s) -----> Downloading Spring Auto Reconfiguration 1.10.0_RELEASE from https://java-buildpack.cloudfoundry.org/auto-reconfiguration/auto-reconfiguration-1.10.0_RELEASE.jar (found in cache) Checking status of app 'acloudyspringtime'... 0 of 1 instances running (1 starting) ... 0 of 1 instances running (1 starting) ... 0 of 1 instances running (1 starting) ... 1 of 1 instances running (1 running) App started
祝贺!该应用程序现已上线!
应用程序上线后,您可以使用命令验证已部署应用程序的状态,如以下示例所示:cf apps
$ cf apps
Getting applications in ...
OK
name requested state instances memory disk urls
...
acloudyspringtime started 1/1 512M 1G acloudyspringtime.cfapps.io
...
一旦 Cloud Foundry 确认您的应用程序已部署,您应该能够在给定的 URI 中找到该应用程序。
在前面的示例中,您可以在 中找到它。https://acloudyspringtime.cfapps.io/
1.1.1. 绑定到服务
默认情况下,有关正在运行的应用程序的元数据以及服务连接信息作为环境变量(例如:)公开给应用程序。
这个架构决定是由于 Cloud Foundry 的多语言(任何语言和平台都可以作为 buildpack 支持)的性质。
进程范围的环境变量与语言无关。$VCAP_SERVICES
环境变量并不总是最简单的 API,因此 Spring Boot 会自动提取它们并将数据扁平化为可以通过 Spring 的抽象访问的属性,如以下示例所示:Environment
@Component
public class MyBean implements EnvironmentAware {
private String instanceId;
@Override
public void setEnvironment(Environment environment) {
this.instanceId = environment.getProperty("vcap.application.instance_id");
}
// ...
}
@Component
class MyBean : EnvironmentAware {
private var instanceId: String? = null
override fun setEnvironment(environment: Environment) {
instanceId = environment.getProperty("vcap.application.instance_id")
}
// ...
}
所有 Cloud Foundry 属性都以 为前缀。
您可以使用属性来访问应用程序信息 (如应用程序的公共 URL) 和服务信息 (如数据库凭据)。
有关完整详细信息,请参阅 CloudFoundryVcapEnvironmentPostProcessor
Javadoc。vcap
vcap
Java CFEnv 项目更适合于配置 DataSource 等任务。 |
1.2. Kubernetes
Spring Boot 通过检查环境变量的环境来自动检测 Kubernetes 部署环境。
您可以使用 configuration 属性覆盖此检测。"*_SERVICE_HOST"
"*_SERVICE_PORT"
spring.main.cloud-platform
Spring Boot 可帮助您管理应用程序的状态,并使用 Actuator 通过 HTTP Kubernetes 探针将其导出。
1.2.1. Kubernetes 容器生命周期
当 Kubernetes 删除应用程序实例时,关闭过程同时涉及多个子系统:关闭钩子、注销服务、从负载均衡器中删除实例...... 由于这种关闭处理是并行进行的(并且由于分布式系统的性质),因此有一个窗口可以将流量路由到也已开始其关闭处理的 Pod。
您可以在 preStop 处理程序中配置睡眠执行,以避免请求被路由到已经开始关闭的 Pod。 此休眠时间应足够长,以便新请求停止路由到 Pod,并且其持续时间因部署而异。 可以使用 Pod 配置文件中的 PodSpec 配置 preStop 处理程序,如下所示:
spec:
containers:
- name: "example-container"
image: "example-image"
lifecycle:
preStop:
exec:
command: ["sh", "-c", "sleep 10"]
一旦 pre-stop 钩子完成,SIGTERM 将被发送到容器并开始正常关闭,允许任何剩余的正在进行的请求完成。
当 Kubernetes 向 Pod 发送 SIGTERM 信号时,它会等待一个指定的时间,称为终止宽限期(默认为 30 秒)。
如果容器在宽限期后仍在运行,则会向它们发送 SIGKILL 信号并被强制删除。
如果 Pod 关闭时间超过 30 秒,这可能是因为您增加了 ,请确保通过在 Pod YAML 中设置选项来增加终止宽限期。spring.lifecycle.timeout-per-shutdown-phase terminationGracePeriodSeconds |
1.3. 赫洛库
Heroku 是另一个流行的 PaaS 平台。
要自定义 Heroku 构建,您需要提供一个 ,它提供部署应用程序所需的咒语。
Heroku 为 Java 应用程序分配一个要使用的 URL,然后确保路由到外部 URI 有效。Procfile
port
您必须将应用程序配置为侦听正确的端口。
以下示例显示了我们的入门 REST 应用程序:Procfile
web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar
Spring Boot 使参数可用作可从 Spring 实例访问的属性。
配置属性被馈送到嵌入式 Tomcat、Jetty 或 Undertow 实例,然后在启动时使用该端口。
环境变量由 Heroku PaaS 分配给我们。-D
Environment
server.port
$PORT
这应该是您所需要的一切。
Heroku 部署最常见的部署工作流是从代码到生产环境,如以下示例所示:git push
$ git push heroku main
这将导致以下内容:
Initializing repository, done. Counting objects: 95, done. Delta compression using up to 8 threads. Compressing objects: 100% (78/78), done. Writing objects: 100% (95/95), 8.66 MiB | 606.00 KiB/s, done. Total 95 (delta 31), reused 0 (delta 0) -----> Java app detected -----> Installing OpenJDK... done -----> Installing Maven... done -----> Installing settings.xml... done -----> Executing: mvn -B -DskipTests=true clean install [INFO] Scanning for projects... Downloading: https://repo.spring.io/... Downloaded: https://repo.spring.io/... (818 B at 1.8 KB/sec) .... Downloaded: https://s3pository.heroku.com/jvm/... (152 KB at 595.3 KB/sec) [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/target/... [INFO] Installing /tmp/build_0c35a5d2-a067-4abc-a232-14b1fb7a8229/pom.xml ... [INFO] ------------------------------------------------------------------------ [INFO] BUILD SUCCESS [INFO] ------------------------------------------------------------------------ [INFO] Total time: 59.358s [INFO] Finished at: Fri Mar 07 07:28:25 UTC 2014 [INFO] Final Memory: 20M/493M [INFO] ------------------------------------------------------------------------ -----> Discovering process types Procfile declares types -> web -----> Compressing... done, 70.4MB -----> Launching... done, v6 https://agile-sierra-1405.herokuapp.com/ deployed to Heroku To [email protected]:agile-sierra-1405.git * [new branch] main -> main
您的应用程序现在应该已在 Heroku 上启动并运行。 有关更多详细信息,请参阅将 Spring Boot 应用程序部署到 Heroku。
1.4. OpenShift
OpenShift 提供了许多描述如何部署 Spring Boot 应用程序的资源,包括:
1.5. 亚马逊网络服务 (AWS)
Amazon Web Services 提供了多种方法来安装基于 Spring Boot 的应用程序,既可以作为传统的 Web 应用程序 (WAR) 安装,也可以安装为带有嵌入式 Web 服务器的可执行 jar 文件。 选项包括:
-
AWS Elastic Beanstalk
-
AWS 代码部署
-
AWS OPS Works
-
AWS 云形成
-
AWS 容器注册表
每个都有不同的功能和定价模型。 在本文档中,我们介绍了使用 AWS Elastic Beanstalk 的方法。
1.5.1. AWS Elastic Beanstalk
如官方 Elastic Beanstalk Java 指南中所述,部署 Java 应用程序有两个主要选项。 您可以使用“Tomcat 平台”或“Java SE 平台”。
使用 Java SE 平台
此选项适用于生成 jar 文件并运行嵌入式 Web 容器的 Spring Boot 项目。
Elastic Beanstalk 环境在端口 80 上运行 nginx 实例,以代理在端口 5000 上运行的实际应用程序。
要对其进行配置,请将以下行添加到您的文件中:application.properties
server.port=5000
上传二进制文件而不是源
默认情况下,Elastic Beanstalk 会上传源并在 AWS 中编译它们。
但是,最好改为上传二进制文件。
为此,请将类似于以下内容的行添加到您的文件中:
|
通过设置环境类型降低成本
默认情况下,Elastic Beanstalk 环境是负载平衡的。 负载均衡器的成本很高。 为避免该成本,请将环境类型设置为“单个实例”,如 Amazon 文档中所述。 您还可以使用 CLI 和以下命令创建单实例环境: eb create -s |
1.5.2. 小结
这是访问 AWS 的最简单方法之一,但还有更多内容需要涵盖,例如如何将 Elastic Beanstalk 集成到任何 CI/CD 工具中,使用 Elastic Beanstalk Maven 插件而不是 CLI 等。 有一篇博客文章更详细地介绍了这些主题。
1.6. CloudCaptain 和 Amazon Web Services
CloudCaptain 的工作原理是将 Spring Boot 可执行 jar 或 war 转换为最小的 VM 映像,该映像可以原封不动地部署在 VirtualBox 或 AWS 上。 CloudCaptain 附带了 Spring Boot 的深度集成,并使用 Spring Boot 配置文件中的信息自动配置端口和运行状况检查 URL。 CloudCaptain 将此信息用于其生成的映像以及它预置的所有资源(实例、安全组、Elastic Load Balancer 等)。
创建 CloudCaptain 账户,将其连接到您的 AWS 账户,安装最新版本的 CloudCaptain 客户端,并确保应用程序已由 Maven 或 Gradle 构建(例如,通过使用),您可以使用类似于以下内容的命令将 Spring Boot 应用程序部署到 AWS:mvn clean package
$ boxfuse run myapp-1.0.jar -env=prod
有关更多选项,请参阅 boxfuse 运行
文档。
如果当前目录中存在 boxfuse.conf
文件,则考虑该文件。
默认情况下,CloudCaptain 会在启动时激活名为 Spring 的配置文件。
如果您的可执行 jar 或 war 包含 application-boxfuse.properties 文件,则 CloudCaptain 的配置基于它包含的属性。boxfuse |
此时,CloudCaptain 会为您的应用程序创建一个映像,上传该映像,并在 AWS 上配置和启动必要的资源,从而产生类似于以下示例的输出:
Fusing Image for myapp-1.0.jar ... Image fused in 00:06.838s (53937 K) -> axelfontaine/myapp:1.0 Creating axelfontaine/myapp ... Pushing axelfontaine/myapp:1.0 ... Verifying axelfontaine/myapp:1.0 ... Creating Elastic IP ... Mapping myapp-axelfontaine.boxfuse.io to 52.28.233.167 ... Waiting for AWS to create an AMI for axelfontaine/myapp:1.0 in eu-central-1 (this may take up to 50 seconds) ... AMI created in 00:23.557s -> ami-d23f38cf Creating security group boxfuse-sg_axelfontaine/myapp:1.0 ... Launching t2.micro instance of axelfontaine/myapp:1.0 (ami-d23f38cf) in eu-central-1 ... Instance launched in 00:30.306s -> i-92ef9f53 Waiting for AWS to boot Instance i-92ef9f53 and Payload to start at https://52.28.235.61/ ... Payload started in 00:29.266s -> https://52.28.235.61/ Remapping Elastic IP 52.28.233.167 to i-92ef9f53 ... Waiting 15s for AWS to complete Elastic IP Zero Downtime transition ... Deployment completed successfully. axelfontaine/myapp:1.0 is up and running at https://myapp-axelfontaine.boxfuse.io/
您的应用程序现在应该已在 AWS 上启动并运行。
请参阅有关在 EC2 上部署 Spring Boot 应用程序的博客文章以及 CloudCaptain Spring Boot 集成的文档,以开始使用 Maven 版本来运行应用程序。
1.7. Azure
本入门指南将指导你将 Spring Boot 应用程序部署到 Azure Spring Cloud 或 Azure 应用服务。
1.8. 谷歌云
Google Cloud 有几个选项可用于启动 Spring Boot 应用程序。 最容易上手的可能是 App Engine,但您也可以找到在具有 Container Engine 的容器中或使用 Compute Engine 在虚拟机上运行 Spring Boot 的方法。
要将第一个应用程序部署到 App Engine 标准环境,请按照本教程操作。
或者,App Engine Flex 要求您创建一个文件来描述您的应用程序所需的资源。
通常,您将此文件放入 ,它应类似于以下文件:app.yaml
src/main/appengine
service: "default"
runtime: "java17"
env: "flex"
handlers:
- url: "/.*"
script: "this field is required, but ignored"
manual_scaling:
instances: 1
health_check:
enable_health_check: false
env_variables:
ENCRYPT_KEY: "your_encryption_key_here"
您可以通过将项目 ID 添加到构建配置来部署应用程序(例如,使用 Maven 插件),如以下示例所示:
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>appengine-maven-plugin</artifactId>
<version>2.4.4</version>
<configuration>
<project>myproject</project>
</configuration>
</plugin>
然后部署(您需要先进行身份验证,否则构建失败)。mvn appengine:deploy
2. 安装 Spring Boot 应用程序
除了直接使用 Spring Boot 应用程序外,还可以将它们作为 或 Windows 服务运行。java -jar
systemd
init.d
2.1. 作为 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 Environment="JAVA_HOME=/path/to/java/home" ExecStart=${JAVA_HOME}/bin/java -jar /var/myapp/myapp.jar ExecStop=/bin/kill -15 $MAINPID SuccessExitStatus=143 [Install] WantedBy=multi-user.target
请记住更改应用程序的 、 、 和 字段。Description User Group Environment ExecStart |
该字段不声明 script action 命令,这意味着默认情况下使用该命令。ExecStart run |
运行应用程序的用户、PID 文件和控制台日志文件由其自身管理,因此必须使用 'service' 脚本中的相应字段进行配置。
有关更多详细信息,请参阅 Service Unit configuration 手册页。systemd
要将应用程序标记为在系统引导时自动启动,请使用以下命令:
$ systemctl enable myapp.service
运行 了解更多详情。man systemctl
2.2. 作为 init.d 服务安装(系统 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>
2.2.1. 保护 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
2.2.2. 自定义启动脚本
可以通过多种方式自定义 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 Gile
除 和 外,上一节中列出的设置可以使用文件进行配置。
该文件应位于 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 服务的准则。
3. 下一步要读什么
请参阅 Cloud Foundry、Heroku、OpenShift 和 Boxfuse 网站,了解有关 PaaS 可以提供的功能类型的更多信息。 这些只是最受欢迎的 Java PaaS 提供商中的四个。 由于 Spring Boot 非常适合基于云的部署,因此您也可以自由考虑其他提供商。
下一节将继续介绍 GraalVM 原生映像,或者您可以跳转到 Spring Boot CLI 或我们的构建工具插件。