Spring Boot的灵活打包选项在部署应用程序时提供了很多选择. 您可以将Spring Boot应用程序部署到各种云平台,容器映像 (例如Docker) 或虚拟机/真实机上.

本节介绍一些更常见的部署方案.

1. 打包成容器

如果从容器中运行应用程序,则可以使用可执行jar,但是将其爆炸并以其他方式运行通常也是一个优点. 某些PaaS实施也可能选择在运行存档之前将其解压缩. 例如,Cloud Foundry以这种方式运行. 运行解压缩存档的最简单方法是启动相应的启动器,如下所示:

$ jar -xf myapp.jar
$ java org.springframework.boot.loader.JarLauncher

实际上,这在启动时 (取决于jar的大小) 比从未爆炸的存档中运行要快一些. 在运行时,您不应期望有任何差异.

解压缩jar文件后,还可以通过使用其 "自然" 主方法 (而不是 JarLauncher) 运行应用程序来增加启动时间. 例如:

$ jar -xf myapp.jar
$ java -cp BOOT-INF/classes:BOOT-INF/lib/* com.example.MyApplication

还可以通过将依赖为与应用程序类和资源 (通常会更频繁地更改) 分离的一层复制到映像中来创建更有效的容器映像. 实现这一层分离的方法不止一种. 例如,使用 Dockerfile 可以用以下形式表示它:

FROM openjdk:8-jdk-alpine AS builder
WORKDIR target/dependency
ARG APPJAR=target/*.jar
COPY ${APPJAR} app.jar
RUN jar -xf ./app.jar

FROM openjdk:8-jre-alpine
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY --from=builder ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY --from=builder ${DEPENDENCY}/META-INF /app/META-INF
COPY --from=builder ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT ["java","-cp","app:app/lib/*","com.example.MyApplication"]

假设上述 Dockerfile 是当前目录,则可以使用 docker build. 生成您的docker映像,或者可以选择指定应用程序jar的路径,如以下示例所示:

docker build --build-arg APPJAR=path/to/myapp.jar .

2. 部署到云端

Spring Boot的可执行jar已为大多数流行的云PaaS (平台即服务) 提供商提供. 这些提供程序往往要求您 "自带容器". 他们管理应用程序流程 (不是专门用于Java应用程序) ,因此他们需要一个中间层,以使您的应用程序适应云中正在运行的流程的概念.

两家受欢迎的云提供商,Heroku和Cloud Foundry,采用了 “buildpack” 方法. buildpack将部署的代码包装在启动应用程序所需的任何内容中. 它可能是JDK,可能是对 Java,嵌入式Web服务器或成熟的应用程序服务器的调用. 一个buildpack是可插入的,但是理想情况下,您应该能够通过尽可能少的自定义来获得它. 这减少了您无法控制的功能的占用空间. 它使开发和生产环境之间的差异最小化.

理想情况下,您的应用程序像Spring Boot可执行jar一样,具有打包运行所需的一切.

在本节中,我们研究如何使在 “Getting Started” 部分中开发的简单应用程序启动并在云中运行.

2.1. Cloud Foundry

如果未指定其他构建包,Cloud Foundry将提供默认的构建包. Cloud Foundry Java buildpack 对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 JRE 1.8.0_121 from https://java-buildpack.cloudfoundry.org/openjdk/trusty/x86_64/openjdk-1.8.0_121.tar.gz (found in cache)
       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/ 上找到它.

2.1.1. 绑定到服务

默认情况下,有关正在运行的应用程序的元数据以及服务连接信息作为环境变量 (例如: $VCAP_SERVICES) 暴露给应用程序. 该架构决定是由于Cloud Foundry的多语言 (可以将任何语言和平台支持为 buildpack) 所决定的. 过程范围的环境变量与语言无关.

环境变量并非总是使用最简单的API,因此Spring Boot会自动提取它们并将数据平整为可通过Spring的 Environment 抽象访问的属性,如以下示例所示:

@Component
class MyBean implements EnvironmentAware {

    private String instanceId;

    @Override
    public void setEnvironment(Environment environment) {
        this.instanceId = environment.getProperty("vcap.application.instance_id");
    }

    // ...

}

所有Cloud Foundry属性均以 vcap 为前缀. 您可以使用 vcap 属性来访问应用程序信息 (例如,应用程序的公共URL) 和服务信息 (例如,数据库凭据) . 有关完整的详细信息,请参见 ‘CloudFoundryVcapEnvironmentPostProcessor’ Javadoc.

Java CFEnv 项目更适合诸如配置数据源之类的任务.

2.2. Heroku

Heroku i是另一个流行的PaaS平台. 要自定义Heroku构建,您需要提供一个 Procfile,该文件提供了部署应用程序所需的内容. Heroku为Java应用程序分配了一个要使用的 port ,然后确保可以路由到外部URI.

您必须配置您的应用程序以监听正确的端口. 以下示例显示了我们的入门REST应用程序的 Procfile:

web: java -Dserver.port=$PORT -jar target/demo-0.0.1-SNAPSHOT.jar

Spring Boot使 -D 参数成为可从Spring Environment 实例访问的属性. server.port 配置属性被馈送到嵌入式Tomcat,Jetty或Undertow实例,然后在启动时使用该端口. $PORT 环境变量是由Heroku PaaS分配给我们的.

这应该是您需要的一切. Heroku部署最常见的部署工作流程是 git push 将代码推送生产环境,如以下示例所示:

$ git push heroku master

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 1.8... done
-----> Installing Maven 3.3.1... 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 git@heroku.com:agile-sierra-1405.git
 * [new branch]      master -> master

您的应用程序现在应该已经在Heroku上启动并运行了. 有关更多详细信息,请参阅将Spring Boot 应用程序部署到 Heroku.

2.3. OpenShift

OpenShift 是Kubernetes容器编排平台的Red Hat公共 (和企业) 扩展. 与Kubernetes相似,OpenShift具有许多用于安装基于Spring Boot的应用程序的选项.

OpenShift提供了许多资源来描述如何部署Spring Boot应用程序,包括:

2.4. Amazon Web Services (AWS)

Amazon Web Services 提供了多种安装基于Spring Boot的应用程序的方式,既可以作为传统的Web应用程序 (war) ,也可以作为具有嵌入式Web服务器的可执行jar文件安装. 选项包括:

  • AWS Elastic Beanstalk

  • AWS Code Deploy

  • AWS OPS Works

  • AWS Cloud Formation

  • AWS Container Registry

每个都有不同的功能和定价模型. 在本文档中,我们仅描述最简单的选项: AWS Elastic Beanstalk.

2.4.1. AWS Elastic Beanstalk

如官方的 Elastic Beanstalk Java 指南 中所述,部署Java应用程序有两个主要选项. 您可以使用 “Tomcat Platform” 或 “Java SE platform”.

使用Tomcat平台

该选项适用于产生war文件的Spring Boot项目. 无需特殊配置. 您只需要遵循官方指南即可.

使用Java SE平台

此选项适用于产生jar文件并运行嵌入式Web容器的Spring Boot项目. Elastic Beanstalk环境在端口80上运行nginx实例来代理在端口 5000 上运行的实际应用程序. 要对其进行配置,请将以下行添加到 ·application.properties· 文件:

server.port=5000
上传二进制文件而不是源文件

默认情况下,Elastic Beanstalk上传源码并在AWS中进行编译. 但是,最好改为上传二进制文件. 为此,请在 .elasticbeanstalk/config.yml 文件中添加类似于以下内容的行:

deploy:
    artifact: target/demo-0.0.1-SNAPSHOT.jar
通过设置环境类型来降低成本

默认情况下,Elastic Beanstalk环境是负载平衡的. 负载均衡器的成本很高. 为避免该费用,请按照 Amazon文档中 的说明将环境类型设置为 “Single instance”. 您还可以使用CLI和以下命令来创建单实例环境:

eb create -s

2.4.2. 简介

这是使用AWS的最简单方法之一,但还有更多内容需要介绍,例如如何将 Elastic Beanstalk 集成到任何 CI/CD 工具中,如何使用Elastic Beanstalk Maven插件而不是CLI等等. 有一篇 博客文章 详细介绍了这些主题.

2.5. Boxfuse 和 Amazon Web Services

Boxfuse 的工作原理是将您的Spring Boot可执行jar或war变成一个最小的VM映像,该映像可以在VirtualBox或AWS上不变地部署. Boxfuse与Spring Boot进行了深度集成,并使用Spring Boot配置文件中的信息自动配置端口和运行状况检查URL. Boxfuse在生成的图像以及它提供的所有资源 (实例,安全组,弹性负载均衡器等) 中都利用了此信息.

创建 Boxfuse 帐户,将其连接到您的AWS帐户,安装Boxfuse Client的最新版本,并确保该应用程序已由Maven或Gradle构建 (通过使用例如 mvn clean package) 后,您可以 使用与以下类似的命令将您的Spring Boot应用程序部署到AWS:

$ boxfuse run myapp-1.0.jar -env=prod

有关更多选项,请参见 boxfuse run 文档. 如果当前目录中存在 boxfuse.conf 文件,则将其考虑.

默认情况下,Boxfuse 在启动时会激活一个名为 boxfuse 的Spring配置文件. 如果您的可执行jar或war包含 application-boxfuse.properties 文件,则 Boxfuse 的配置将基于其包含的属性.

此时,boxfuse 为您的应用程序创建一个映像,然后上载该映像,并在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应用程序 的博客文章以及 Boxfuse Spring Boot集成的文档 ,以开始使用Maven构建来运行该应用程序.

2.6. Google Cloud

Google Cloud有多个选项可用于启动Spring Boot应用程序. 最容易上手的可能是App Engine,但您也可以找到在Container Engine的容器中或Compute Engine的虚拟机上运行Spring Boot的方法.

要在App Engine中运行,您可以先在用户界面中创建一个项目,该项目将为您设置一个唯一的标识符,并还设置HTTP路由. 将Java应用程序添加到项目中,并将其保留为空,然后使用 Google Cloud SDK 从命令行或CI构建将Spring Boot应用程序推送到该插槽中.

App Engine Standard 要求您使用WAR包装. 请按照 以下步骤 将 App Engine标准应用程序部署到Google Cloud.

另外,App Engine Flex要求您创建一个 app.yaml 文件来描述您的应用程序所需的资源. 通常,您将此文件放在 src/main/appengine 中,它应类似于以下文件:

service: default

runtime: java
env: flex

runtime_config:
  jdk: openjdk8

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>
    <configuration>
        <project>myproject</project>
    </configuration>
</plugin>

然后使用 mvn appengine:deploy 进行部署 (如果您需要先进行身份验证,则构建会失败) .

3. 安装Spring Boot应用程序

除了使用 java -jar 运行Spring Boot应用程序之外,还可以为Unix系统制作完全可执行的应用程序. 完全可执行的jar可以像其他可执行二进制文件一样执行,也可以在 init.d 或 systemd 中注册. 这使得在普通生产环境中安装和管理Spring Boot应用程序变得非常容易.

完全可执行的jar通过将额外的脚本嵌入文件的开头来工作. 当前,某些工具不接受此格式,因此您可能无法始终使用此技术. 例如,jar -xf 可能在无提示的情况下无法提取出已完全可执行的jar或war. 建议仅当您打算直接执行jar或war时才使其完全可执行,而不是使用 java -jar 来运行它或将其部署到servlet容器中.
不能使zip64格式的jar文件完全可执行. 尝试这样做将导致直接或使用 java -jar 执行时将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配置:

bootJar {
    launchScript()
}

然后,您可以通过输入 ./my-application.jar (其中 my-application 是 artifacts 的名称) 来运行您的应用程序. 包含jar的目录用作应用程序的工作目录.

3.1. 支持的操作系统

默认脚本支持大多数Linux发行版,并已在CentOS和Ubuntu上进行了测试. 其他平台,例如OS X和FreeBSD,则需要使用自定义的 EmbeddedLaunchScript.

3.2. Unix/Linux 服务

通过使用 init.d 或 systemd,可以轻松地将Spring Boot应用程序作为 Unix/Linux 服务启动.

3.2.1. 作为 init.d 服务安装 (系统V)

如果您将Spring Boot的Maven或Gradle插件配置为生成完全可执行的jar,并且不使用自定义的 EmbeddedLaunchScript,则您的应用程序可以用作 init.d 服务. 为此,将jar链接到 init.d 以支持标准的 start, stop, restart, 和 status 命令.

该脚本支持以下功能:

  • 以拥有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 用户身份运行该应用程序.

为了减少应用程序的用户帐户被盗的机会,您应该考虑阻止它使用登录外壳程序. 例如,您可以将帐户的外壳程序设置为 /usr/sbin/nologin.

您还应该采取措施防止修改应用程序的jar文件. 首先,配置其权限,使其不能被写入,只能由其所有者读取或执行,如以下示例所示:

$ chmod 500 your-app.jar

其次,如果您的应用程序或运行该应用程序的帐户受到威胁,您还应采取措施限制损害. 如果攻击者确实获得了访问权限,则他们可以使jar文件可写并更改其内容. 防止这种情况发生的一种方法是使用 chattr 使其不可变,如以下示例所示:

$ sudo chattr +i your-app.jar

这将阻止任何用户 (包括root用户) 修改jar.

如果使用root来控制应用程序的服务,并且您使用 使用 .conf 文件 来自定义其启动,则root用户将读取并评估 .conf 文件. 应该相应地对其进行保护. 使用 chmod,以便文件只能由所有者读取,并使用 chown 使root用户成为所有者,如以下示例所示:

$ chmod 400 your-app.conf
$ sudo chown root:root your-app.conf

3.2.2. 作为 systemd 服务安装

systemd 是System V init系统的后继产品,现在被许多现代Linux发行版使用. 尽管您可以继续在 systemd 中使用 init.d 脚本,但也可以通过使用 systemd 的 ‘service’ 脚本来启动Spring Boot应用程序.

假设您在 /var/myapp 中安装了Spring Boot应用程序,要将Spring Boot应用程序安装为 systemd 服务,请创建一个名为 myapp.service 的脚本并将其放在 /etc/systemd/system 目录中. 以下脚本提供了一个示例:

[Unit]
Description=myapp
After=syslog.target

[Service]
User=myapp
ExecStart=/var/myapp/myapp.jar
SuccessExitStatus=143

[Install]
WantedBy=multi-user.target
切记更改应用程序的 Description, User 和 ExecStart 字段.
ExecStart 字段未声明脚本操作命令,这意味着默认情况下使用 run 命令.

请注意,与作为 init.d 服务运行时不同,运行应用程序的用户,PID文件和控制台日志文件由 systemd 本身管理,因此必须通过在 ‘service’ 脚本中使用适当的字段进行配置. 有关更多详细信息,请查阅 服务单元配置手册页 .

要将应用程序标记为在系统启动时自动启动,请使用以下命令:

$ systemctl enable myapp.service

有关更多详细信息,请参考 man systemctl.

3.2.3. 自定义启动脚本

由Maven或Gradle插件编写的默认嵌入式启动脚本可以通过多种方式进行自定义. 对于大多数人来说,使用默认脚本以及一些自定义设置通常就足够了. 如果发现无法自定义所需的内容,请使用 EmbeddedLaunchScript 选项完全编写自己的文件.

编写后自定义启动脚本

在将启动脚本写入jar文件时,自定义启动脚本的元素通常很有意义. 例如,init.d 脚本可以提供 “description”. 由于您已经预先了解了描述 (并且无需更改) ,因此在生成jar时也可以提供它.

要自定义书面元素,请使用Spring Boot Maven插件的 embeddedLaunchScriptProperties 选项或 Spring Boot Gradle插件的 launchScript 的 properties 属性.

默认脚本支持以下属性替换:

Name Description Gradle default Maven default

mode

The script mode.

auto

auto

initInfoProvides

The Provides section of “INIT INFO”

${task.baseName}

${project.artifactId}

initInfoRequiredStart

Required-Start section of “INIT INFO”.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoRequiredStop

Required-Stop section of “INIT INFO”.

$remote_fs $syslog $network

$remote_fs $syslog $network

initInfoDefaultStart

Default-Start section of “INIT INFO”.

2 3 4 5

2 3 4 5

initInfoDefaultStop

Default-Stop section of “INIT INFO”.

0 1 6

0 1 6

initInfoShortDescription

Short-Description section of “INIT INFO”.

Single-line version of ${project.description} (falling back to ${task.baseName})

${project.name}

initInfoDescription

Description section of “INIT INFO”.

${project.description} (falling back to ${task.baseName})

${project.description} (falling back to ${project.name})

initInfoChkconfig

chkconfig section of “INIT INFO”

2345 99 01

2345 99 01

confFolder

The default value for CONF_FOLDER

Folder containing the jar

Folder containing the jar

inlinedConfScript

Reference to a file script that should be inlined in the default launch script. This can be used to set environmental variables such as JAVA_OPTS before any external config files are loaded

logFolder

Default value for LOG_FOLDER. Only valid for an init.d service

logFilename

Default value for LOG_FILENAME. Only valid for an init.d service

pidFolder

Default value for PID_FOLDER. Only valid for an init.d service

pidFilename

Default value for the name of the PID file in PID_FOLDER. Only valid for an init.d service

useStartStopDaemon

Whether the start-stop-daemon command, when it’s available, should be used to control the process

true

true

stopWaitTime

Default value for STOP_WAIT_TIME in seconds. Only valid for an init.d service

60

60
运行时自定义脚本

对于在编写jar之后需要自定义脚本的项目,可以使用环境变量或配置文件.

默认脚本支持以下环境属性:

变量 描述

MODE

操作的 mode. 默认值取决于jar的构建方式,但通常是自动的 (这意味着它会通过检查 init.d 目录中的符号链接来尝试猜测它是否为初始化脚本) . 如果要在前台运行脚本,可以将其显式设置为服务,以便 stop|start|status|restart 命令可以运行或 run.

RUN_AS_USER

将用于运行应用程序的用户. 未设置时,将使用拥有jar文件的用户.

USE_START_STOP_DAEMON

是否可以使用 start-stop-daemon 命令来控制该过程. 默认为 true.

PID_FOLDER

pid文件夹的根名称 (默认为 /var/run) .

LOG_FOLDER

放置日志文件的文件夹的名称 (默认为 /var/log) .

CONF_FOLDER

从中读取.conf文件的文件夹的名称 (默认情况下与jar文件相同的文件夹) .

LOG_FILENAME

LOG_FOLDER 中的日志文件名 (默认为 <appname>.log) .

APP_NAME

应用程序的名称. 如果jar是从符号链接运行的,则脚本会猜测应用程序名称. 如果它不是符号链接,或者您要显式设置应用程序名称,则这将很有用.

RUN_ARGS

传递给程序 (Spring Boot应用程序) 的参数.

JAVA_HOME

默认情况下,使用 PATH 查找 Java 可执行文件的位置,但是如果 $JAVA_HOME/bin/java 中有可执行文件,则可以显式设置它.

JAVA_OPTS

启动JVM时传递给JVM的选项.

JARFILE

jar文件的显式位置,以防脚本用于启动实际上未嵌入的jar.

DEBUG

如果不为空,则在shell进程中设置 -x 标志,从而易于查看脚本中的逻辑.

STOP_WAIT_TIME

停止应用程序之前强制关闭的等待时间 (以秒为单位) (默认为 60 ) .
PID_FOLDER, LOG_FOLDER, 和 LOG_FILENAME 变量仅对 init.d 服务有效. 对于 systemd,通过使用 ‘service’ 脚本进行等效的自定义. 有关更多详细信息,请参见 服务单元配置手册页 .

除了 JARFILE 和 APP_NAME,可以使用 .conf文 件配置上一节中列出的设置. 该文件应位于jar文件的旁边,并且具有相同的名称,但后缀为 .conf 而不是 .jar. 例如,名为 /var/myapp/myapp.jar 的jar使用名为 /var/myapp/myapp.conf 的配置文件,如以下示例所示:

myapp.conf
JAVA_OPTS=-Xmx1024M
LOG_FOLDER=/custom/log/folder
如果您不喜欢将配置文件放在jar文件旁边,则可以设置 CONF_FOLDER 环境变量以自定义配置文件的位置.

要了解有关适当保护此文件的信息,请参阅保护init.d服务的准则.

3.3. Microsoft Windows 服务

可以使用 winsw 将Spring Boot应用程序作为Windows服务启动.

(一个单独维护的示例) 逐步说明了如何为Spring Boot应用程序创建Windows服务.

4. 下一步

请访问 Cloud Foundry, Heroku , OpenShift 和 Boxfuse 网站,以获取有关PaaS可以提供​​的各种功能的更多信息. 这些只是最受欢迎的Java PaaS提供程序中的四个. 由于Spring Boot非常适合基于云的部署,因此您也可以自由考虑其他提供商.

下一节将继续介绍 Spring Boot CLI,或者您可以继续阅读有关 构建工具插件 的信息.