asp.net空网站,广州番禺邮政编码,社交网站是怎么做的,wordpress怎么静态页面本文为官方文档直译版本。原文链接 部署 Spring Boot 应用中文文档 引言部署到云Cloud Foundry与服务绑定 KubernetesKubernetes 容器生命周期 HerokuOpenShift亚马逊网络服务#xff08;AWS#xff09;AWS Elastic Beanstalk使用 Tomcat 平台使用 Java SE 平台 总结 CloudCa… 本文为官方文档直译版本。原文链接 部署 Spring Boot 应用中文文档 引言部署到云Cloud Foundry与服务绑定 KubernetesKubernetes 容器生命周期 HerokuOpenShift亚马逊网络服务AWSAWS Elastic Beanstalk使用 Tomcat 平台使用 Java SE 平台 总结 CloudCaptain 和亚马逊网络服务Azure谷歌云 安装 Spring Boot 应用程序作为 systemd 服务安装作为 init.d 服务安装System Vinit.d 服务安全自定义启动脚本自定义已编写的启动脚本自定义运行时的脚本使用 Conf Gile Microsoft Windows 服务 高效部署解压可执行 JAR使用 JVM 提前处理使用 JVM 检查点和还原 引言
Spring Boot 灵活的打包选项为部署应用程序提供了大量选择。您可以将 Spring Boot 应用程序部署到各种云平台、虚拟机/实机或使其完全可在 Unix 系统上执行。 本节将介绍一些更常见的部署场景。
部署到云
Spring Boot 的可执行 jar 是现成的适用于大多数流行的云 PaaSPlatform-as-a-Service平台即服务提供商。这些提供商往往要求您 “自带容器”。它们管理应用程序进程而不是专门的 Java 应用程序因此需要一个中间层来使您的应用程序适应云计算的运行进程概念。 Heroku 和 Cloud Foundry 这两个流行的云提供商采用了 “buildpack构建包” 方法。构建包将您部署的代码包装成启动应用程序所需的任何东西。它可能是 JDK 和 Java 调用、嵌入式 Web 服务器或完整的应用服务器。构建包是可插拔的但在理想情况下你应该尽可能少地对其进行定制。这样可以减少不在你控制范围内的功能。它能最大限度地减少开发环境和生产环境之间的差异。 理想情况下您的应用程序就像一个 Spring Boot 可执行 jar里面打包了运行所需的一切。 在本节中我们将介绍如何在云中运行我们在 “入门” 部分开发的应用程序。
Cloud Foundry
Cloud Foundry 提供默认构建包如果未指定其他构建包这些构建包将发挥作用。Cloud Foundry Java 构建包非常支持 Spring 应用程序包括 Spring Boot。您可以部署独立的可执行 jar 应用程序以及传统的 .war 打包应用程序。 一旦您构建了应用程序例如使用 mvn clean package并安装了 cf 命令行工具请使用 cf push 命令部署您的应用程序并替换已编译 .jar 的路径。在推送应用程序之前请确保已登录 cf 命令行客户端。下面一行显示了使用 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 JREExpanding 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:MaxMetaspaceSize104857K -Xms681574K -XX:MetaspaceSize104857K
----- 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 ...
OKname requested state instances memory disk urls
...
acloudyspringtime started 1/1 512M 1G acloudyspringtime.cfapps.io
...一旦 Cloud Foundry 确认您的应用程序已部署您就可以在给出的 URI 中找到该应用程序。在前面的示例中您可以在 https://acloudyspringtime.cfapps.io/ 找到它。
与服务绑定
默认情况下有关运行应用程序的元数据以及服务连接信息将作为环境变量例如$VCAP_SERVICES暴露给应用程序。这一架构决定是由于 Cloud Foundry 的多语言性可作为构建包支持任何语言和平台。进程作用域环境变量与语言无关。 环境变量并不总是最简单的 API因此 Spring Boot 会自动提取它们并将数据扁平化为可通过 Spring 的Environment抽象访问的属性如下例所示
import org.springframework.context.EnvironmentAware;
import org.springframework.core.env.Environment;
import org.springframework.stereotype.Component;Component
public class MyBean implements EnvironmentAware {private String instanceId;Overridepublic void setEnvironment(Environment environment) {this.instanceId environment.getProperty(vcap.application.instance_id);}// ...}所有 Cloud Foundry 属性均以 vcap 为前缀。您可以使用 vcap 属性访问应用程序信息如应用程序的公共 URL和服务信息如数据库凭据。有关完整的详细信息请参阅 CloudFoundryVcapEnvironmentPostProcessor Javadoc。 Java CFEnv 项目更适合配置数据源等任务。 Kubernetes
Spring Boot 通过检查环境中的 *_SERVICE_HOST 和 “*_SERVICE_PORT” 变量自动检测 Kubernetes 部署环境。您可以使用 spring.main.cloud-platform 配置属性覆盖此检测。 Spring Boot 可以帮助你管理应用程序的状态并使用 Actuator 通过 HTTP Kubernetes Probes 输出。
Kubernetes 容器生命周期
当 Kubernetes 删除应用程序实例时关机过程会同时涉及多个子系统关机钩子、取消服务注册、从负载平衡器中移除实例…由于关机处理是并行发生的而且由于分布式系统的特性因此存在一个窗口在此期间流量可能会被路由到也已开始关机处理的 pod。 您可以在 preStop 处理程序中配置休眠执行以避免请求被路由到已开始关闭的 pod。睡眠时间应足够长以便新请求不再被路由到 pod其持续时间因部署而异。可以使用 pod 配置文件中的 PodSpec 对预停止处理程序进行如下配置
spec:containers:- name: example-containerimage: example-imagelifecycle:preStop:exec:command: [sh, -c, sleep 10]一旦预停止钩子完成SIGTERM 就会发送到容器然后开始优雅关机允许完成任何剩余的处理中请求。 当 Kubernetes 向 pod 发送 SIGTERM 信号时它会等待一段指定的时间称为终止宽限期默认为 30 秒。如果容器在宽限期后仍在运行它们就会被发送 SIGKILL 信号并被强制移除。如果 Pod 的关闭时间超过 30 秒可能是因为增加了 spring.lifecycle.timeout-per-shutdown-phase 的时间请确保通过设置 Pod YAML 中的 terminationGracePeriodSeconds 选项来增加终止宽限期。 Heroku
Heroku 是另一个流行的 PaaS 平台。要定制 Heroku 的构建您需要提供一个 Procfile它提供了部署应用程序所需的命令。Heroku 会为 Java 应用程序分配一个端口然后确保路由到外部 URI 的工作正常。 您必须将应用程序配置为监听正确的端口。下面的示例显示了 REST 应用程序的Procfile
web: java -Dserver.port$PORT -jar target/demo-0.0.1-SNAPSHOT.jarSpring Boot 将 -D 参数作为 Spring Environment 实例可访问的属性。server.port 配置属性会反馈给嵌入式 Tomcat、Jetty 或 Undertow 实例然后在启动时使用该端口。$PORT 环境变量由 Heroku PaaS 分配给我们。 这就是你所需要的一切。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 -DskipTeststrue 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 typesProcfile declares types - web----- Compressing... done, 70.4MB
----- Launching... done, v6https://agile-sierra-1405.herokuapp.com/ deployed to HerokuTo githeroku.com:agile-sierra-1405.git* [new branch] main - main现在您的应用程序应该可以在 Heroku 上运行了。有关详细信息请参阅将 Spring Boot 应用程序部署到 Heroku。
OpenShift
OpenShift 有许多资源介绍如何部署 Spring Boot 应用程序包括
使用 S2I 生成器架构指南在 Wildfly 上作为传统网络应用程序运行OpenShift Commons 简介
亚马逊网络服务AWS
Amazon Web Services 提供多种方式来安装基于 Spring Boot 的应用程序既可以安装为传统的 Web 应用程序 (war) 也可以安装为带有嵌入式 Web 服务器的可执行 jar 文件。这些选项包括
AWS Elastic BeanstalkAWS Code DeployAWS OPS WorksAWS Cloud FormationAWS Container Registry
每种方法都有不同的功能和定价模式。在本文中我们将介绍使用 AWS Elastic Beanstalk 的方法。
AWS Elastic Beanstalk
正如 Elastic Beanstalk Java 官方指南所述部署 Java 应用程序有两个主要选项。你可以使用 “Tomcat 平台” 或 “Java SE 平台”。
使用 Tomcat 平台
该选项适用于生成 war 文件的 Spring Boot 项目。无需特殊配置。只需遵循官方指南即可。
使用 Java SE 平台
该选项适用于生成 jar 文件并运行嵌入式 Web 容器的 Spring Boot 项目。Elastic Beanstalk 环境会在端口 80 上运行一个 nginx 实例以代理在端口 5000 上运行的实际应用程序。要对其进行配置请在 application.properties 文件中添加以下一行
server.port5000上传二进制文件而不是源代码 默认情况下Elastic Beanstalk 会上传源代码并在 AWS 中编译。不过最好还是上传二进制文件。为此请在.elasticbeanstalk/config.yml文件中添加类似以下内容的行 deploy:artifact: target/demo-0.0.1-SNAPSHOT.jar通过设置环境类型降低成本 默认情况下Elastic Beanstalk 环境是负载平衡的。负载平衡器的成本很高。要避免这一成本可将环境类型设置为 “单实例”如亚马逊文档中所述。你也可以使用 CLI 和以下命令创建单实例环境 eb create -s总结
这是访问AWS最简单的方法之一但还有更多内容需要涉及例如如何将Elastic Beanstalk集成到任何CI/CD工具中使用Elastic Beanstalk Maven插件而不是CLI等。有一篇博文详细介绍了这些主题。
CloudCaptain 和亚马逊网络服务
CloudCaptain 的工作原理是将您的 Spring Boot 可执行 jar 或 war 转换成最小的虚拟机映像该映像可在 VirtualBox 或 AWS 上部署且不会发生变化。CloudCaptain 与 Spring Boot 深度集成并使用 Spring Boot 配置文件中的信息自动配置端口和健康检查 URL。CloudCaptain 将这些信息用于生成镜像以及提供所有资源实例、安全组、弹性负载平衡器等。 创建 CloudCaptain 帐户、将其连接到 AWS 帐户、安装最新版本的 CloudCaptain Client 并确保应用程序已由 Maven 或 Gradle 构建例如使用 mvn clean package后您就可以使用类似以下命令将 Spring Boot 应用程序部署到 AWS
$ boxfuse run myapp-1.0.jar -envprod默认情况下CloudCaptain 会在启动时激活名为 boxfuse 的 Spring 配置文件。如果您的可执行 jar 或 war 中包含 application-boxfuse.properties 文件CloudCaptain 将根据其中包含的属性进行配置。 此时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 构建运行应用程序。
Azure
本入门指南将指导您将 Spring Boot 应用程序部署到 Azure Spring Cloud 或 Azure App Service。
谷歌云
Google Cloud 有多个可用于启动 Spring Boot 应用程序的选项。最容易上手的可能是 App Engine但您也可以通过 Container Engine 在容器中运行 Spring Boot或通过 Compute Engine 在虚拟机上运行 Spring Boot。 要在 App Engine 标准环境中运行您的第一个应用程序请参考本教程。 另外App Engine Flex 还要求你创建一个 app.yaml 文件来描述应用程序所需的资源。通常您可以将该文件放在 src/main/appengine 中它应该与下面的文件类似
service: defaultruntime: java17
env: flexhandlers:
- url: /.*script: this field is required, but ignoredmanual_scaling:instances: 1health_check:enable_health_check: falseenv_variables:ENCRYPT_KEY: your_encryption_key_here您可以在构建配置中添加项目 ID 来部署应用程序例如使用 Maven 插件如下例所示
plugingroupIdcom.google.cloud.tools/groupIdartifactIdappengine-maven-plugin/artifactIdversion2.4.4/versionconfigurationprojectmyproject/project/configuration
/plugin然后使用 mvn appengine:deploy 进行部署需要先进行身份验证否则会导致构建失败。
安装 Spring Boot 应用程序
除了直接使用 java -jar 运行 Spring Boot 应用程序外还可以将其作为 systemd、init.d 或 Windows 服务运行。
作为 systemd 服务安装
systemd 是 System V init 系统的后继者目前已被许多现代 Linux 发行版所采用。Spring Boot 应用程序可通过 systemd “服务” 脚本启动。 假设你在 /var/myapp 目录中将 Spring Boot 应用程序打包为 uber jar要将其安装为 systemd 服务需要创建名为 myapp.service 的脚本并将其放置在 /etc/systemd/system 目录中。下面的脚本提供了一个示例
[Unit]
Descriptionmyapp
Aftersyslog.target network.target[Service]
Usermyapp
GroupmyappEnvironmentJAVA_HOME/path/to/java/homeExecStart${JAVA_HOME}/bin/java -jar /var/myapp/myapp.jar
ExecStop/bin/kill -15 $MAINPID
SuccessExitStatus143[Install]
WantedBymulti-user.target请记住要为您的应用程序更改Description、User、Group、Environment和 ExecStart 字段。 ExecStart 字段没有声明脚本操作命令这意味着默认使用运行命令。 运行应用程序的用户、PID 文件和控制台日志文件由 systemd 本身管理因此必须在 “服务” 脚本中使用相应字段进行配置。详情请查阅服务单元配置手册。 要标记应用程序在系统启动时自动启动请使用以下命令
$ 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 文件无法完全执行。如果尝试这样做在直接执行或使用 java -jar 执行时jar 文件将被报告为损坏。包含一个或多个 zip64 格式嵌套 jar 的标准格式 jar 文件可以完全执行。 要使用 Maven 创建 “完全可执行” 的 jar请使用以下插件配置
plugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactIdconfigurationexecutabletrue/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 priorityinit.d 服务安全 以下是一套关于如何确保作为 init.d 服务运行的 Spring Boot 应用程序安全的指南。它并不打算详尽无遗地列出加固应用程序及其运行环境应采取的所有措施。 以根用户身份执行时如使用根用户启动 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为降低应用程序用户账户被入侵的几率应考虑阻止其使用 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 使根用户成为所有者
$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf自定义启动脚本
由 Maven 或 Gradle 插件编写的默认嵌入式启动脚本可以通过多种方式进行自定义。对于大多数人来说使用默认脚本并进行一些自定义通常就足够了。如果你发现自己无法自定义需要的内容可以使用 embeddedLaunchScript 选项完全编写自己的文件。
自定义已编写的启动脚本
在将启动脚本写入 jar 文件时自定义启动脚本的元素往往很有意义。例如init.d 脚本可以提供 “description”。既然你事先知道描述而且不需要更改那么不妨在生成 jar 时提供它。 要自定义写入的元素请使用 Spring Boot Maven 插件的 embeddedLaunchScriptProperties 选项或 Spring Boot Gradle 插件的 launchScript 的 properties 属性。 默认脚本支持以下属性替换
属性名称描述Gradle 默认值Maven 默认值mode脚本模式。autoautoinitInfoProvides”INIT INFO“的 Provides 部分${task.baseName}${project.artifactId}initInfoRequiredStart”INIT INFO“的 Required-Start 部分$remote_fs $syslog $network$remote_fs $syslog $networkinitInfoRequiredStop”INIT INFO“的 Required-Stop 部分$remote_fs $syslog $network$remote_fs $syslog $networkinitInfoDefaultStart”INIT INFO“的 Default-Start 部分2 3 4 52 3 4 5initInfoDefaultStop”INIT INFO“的 Default-Stop 部分0 1 60 1 6initInfoShortDescription”INIT INFO“的 Short-Description 部分${project.description} 的单行版本回退至 ${task.baseName}${project.name}initInfoDescription”INIT INFO“的 Short-Description 部分${project.description} 回退至 ${task.baseName}${project.description} 回退至 ${project.name}initInfoChkconfig”INIT INFO“的 chkconfig 部分2345 99 012345 99 01confFolder默认值为CONF_FOLDER包含 jar 的文件夹包含 jar 的文件夹inlinedConfScript默认启动脚本中应内联的文件脚本引用。它可用于在加载任何外部配置文件前设置环境变量如 JAVA_OPTS。logFolderLOG_FOLDER 的默认值。仅对 init.d 服务有效logFilenameLOG_FILENAME 的默认值。仅对 init.d 服务有效pidFolderPID_FOLDER 的默认值。仅对 init.d 服务有效pidFilenamePID_FOLDER 中 PID 文件名的默认值。仅对 init.d 服务有效useStartStopDaemon当start-stop-daemon进程命令可用时是否应使用该命令来控制进程truetruestopWaitTimeSTOP_WAIT_TIME 的默认值秒。仅对 init.d 服务有效6060
自定义运行时的脚本
对于写入 jar 后需要自定义的脚本项目可以使用环境变量或配置文件。 默认脚本支持以下环境属性
变量描述MODE运行 “模式”。默认值取决于 jar 的构建方式但通常是auto这意味着它会通过检查它是否是 init.d 目录中的一个符号链接来猜测它是否是一个启动脚本。你可以明确地将其设置为 service这样 stop#124;start#124;status#124;restart 命令就能正常工作如果你想在前台运行脚本也可以将其设置为 run。RUN_AS_USER用于运行应用程序的用户。未设置时将使用拥有 jar 文件的用户。USE_START_STOP_DAEMON当start-stop-daemon进程命令可用时是否应使用该命令来控制进程。默认为 true。PID_FOLDERpid 文件夹的根名称默认为 /var/run。LOG_FOLDER存放日志文件的文件夹名称默认为 /var/log。CONF_FOLDER读取 .conf 文件的文件夹名称默认情况下与 jar-file 文件夹相同。LOG_FILENAMELOG_FOLDER 中日志文件的名称默认为 appname.log。APP_NAME应用程序名称。如果 jar 是通过符号链接运行的脚本会猜测应用程序的名称。如果它不是一个符号链接或者你想明确设置应用程序名称这可能会很有用。RUN_ARGS传给程序Spring Boot 应用程序的参数。JAVA_HOMEjava 可执行文件的位置默认通过 PATH 查找但如果在 $JAVA_HOME/bin/java 处有可执行文件则可以明确设置。JAVA_OPTS启动 JVM 时传递给它的选项。JARFILEjar 文件的明确位置以防脚本被用于启动实际上未嵌入的 jar。DEBUG如果不为空则在 shell 进程中设置 -x 标志以便查看脚本中的逻辑。STOP_WAIT_TIME停止应用程序后强制关闭前的等待时间默认为 60 秒。 PID_FOLDER、LOG_FOLDER 和 LOG_FILENAME 变量仅对 init.d 服务有效。对于 systemd可使用 “service” 脚本进行相应的自定义设置。更多详情请参阅服务单元配置手册。 使用 Conf Gile
除 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 服务的指南。
Microsoft Windows 服务
可以使用 winsw 将 Spring Boot 应用程序作为 Windows 服务启动。 本文档单独维护的示例将逐步介绍如何为 Spring Boot 应用程序创建 Windows 服务。
高效部署
解压可执行 JAR
如果从容器中运行应用程序可以使用可执行 jar但将其解压缩并以另一种方式运行通常也有好处。某些 PaaS 实现也可能选择在运行前解压缩存档。例如Cloud Foundry 就是这样运行的。运行解压缩存档的一种方法是启动相应的启动器如下所示
$ jar -xf myapp.jar
$ java org.springframework.boot.loader.launch.JarLauncher实际上启动时的速度取决于 jar 的大小要比从未爆发的压缩包运行时稍快一些。启动后就不会有任何差别了。 解压缩 jar 文件后还可以通过使用 “自然” 主方法而不是 JarLauncher 运行应用程序来额外延长启动时间。例如
$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication在应用程序的主方法上使用 JarLauncher 还有一个好处那就是类路径顺序可以预测。jar 中包含一个 classpath.idx 文件JarLauncher 在构建类路径时会使用该文件。 使用 JVM 提前处理
使用 AOT 生成的初始化代码运行应用程序对启动时间非常有利。首先您需要确保构建的 jar 包含 AOT 生成的代码。 对于 Maven 而言这意味着您在构建时应使用 -Pnative 激活native配置文件
$ mvn -Pnative package对于 Gradle您需要确保您的构建包含 org.springframework.boot.aot 插件。 JAR 生成后运行时将 spring.aot.enabled 系统属性设置为 true。例如
$ java -Dspring.aot.enabledtrue -jar myapplication.jar........ Starting AOT-processed MyApplication ...要注意的是使用超前处理有其缺点。它意味着以下限制
类路径是固定的在构建时已完全定义应用程序中定义的Bean类在运行时不会改变这意味着 Spring Profile 注解和特定于配置文件的配置有其局限性。不支持在创建 Bean 时改变的属性例如ConditionalOnProperty 和 .enable 属性。
要了解有关超前处理的更多信息请参阅了解Spring超前处理部分。
使用 JVM 检查点和还原
Coordinated Restore at CheckpointCRaC是一个 OpenJDK 项目它定义了一个新的 Java API允许您在 HotSpot JVM 上检查点和还原应用程序。它基于在 Linux 上实现检查点/还原功能的 CRIU 项目。 其原理如下几乎像往常一样启动应用程序但使用的是支持 CRaC 的 JDK 版本如支持 CRaC 的 Bellsoft Liberica JDK 或支持 CRaC 的 Azul Zulu JDK。然后在某个时间点可能是在通过执行所有常用代码路径热身 JVM 的某些工作负载之后使用 API 调用、jcmd 命令、HTTP 端点或其他机制触发检查点。 然后运行中的 JVM 的内存表示包括其预热会被序列化到磁盘上这样就可以在稍后的时间点快速还原可能是在另一台具有类似操作系统和 CPU 架构的机器上。恢复后的进程保留了 HotSpot JVM 的所有功能包括运行时的进一步 JIT 优化。 基于 Spring Framework 提供的基础Spring Boot 支持检查点和恢复应用程序并在有限的范围内管理资源如套接字、文件和线程池的开箱即用生命周期。预计其他依赖项和处理此类资源的应用程序代码还需要额外的生命周期管理。 有关支持的两种模式按需检查点/还原运行中的应用程序 和 “启动时自动检查点/还原”、如何启用检查点和还原支持以及一些指南的更多详情请参阅 Spring Framework JVM 检查点还原支持文档。
