共计 10719 个字符，预计需要花费 27 分钟才能阅读完成。
许多人应用容器来包装他们的 Spring Boot 应用程序，而构建容器并不是一件简略的事件。这是针对 Spring Boot 应用程序开发人员的指南，容器对于开发人员来说并不总是一个好的形象。它们迫使你去理解和思考低层次的问题。然而，有时可能会要求您创立或应用容器，因而理解构建块是值得的。在本指南中，咱们旨在向您展现如果您面临须要创立本人的容器的前景，您能够做出的一些抉择。
咱们假如您晓得如何创立和构建根本的 Spring Boot 应用程序。如果没有，请转到入门指南之一 ——例如，对于构建 REST 服务的指南。从那里复制代码并练习本指南中蕴含的一些想法。
还有一个对于 Docker 的入门指南，这也是一个很好的终点，但它没有涵盖咱们在此处介绍的抉择范畴或具体介绍它们。
一个根本的 Dockerfile
Spring Boot 应用程序很容易转换为可执行的 JAR 文件。所有的入门指南都是这样做的，你从 Spring Initializr 下载的每个应用程序都有一个构建步骤来创立一个可执行的 JAR。应用 Maven，你运行./mvnw install，应用 Gradle，你运行./gradlew build。运行该 JAR 的根本 Dockerfile 将如下所示，位于我的项目的顶层：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE
COPY ${JAR_FILE} app.jar
ENTRYPOINT [“java”,”-jar”,”/app.jar”]复制
JAR_FILE 您能够作为命令的一部分传入 docker（Maven 和 Gradle 不同）。对于 Maven，以下命令无效：
docker build –build-arg JAR_FILE=target/*.jar -t myorg/myapp . 复制
对于 Gradle，以下命令无效：
docker build –build-arg JAR_FILE=build/libs/*.jar -t myorg/myapp . 复制
一旦你抉择了一个构建零碎，你就不须要 ARG. 您能够对 JAR 地位进行硬编码。对于 Maven，如下所示：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY target/*.jar app.jar
ENTRYPOINT [“java”,”-jar”,”/app.jar”]复制
而后咱们能够应用以下命令构建镜像：
docker build -t myorg/myapp . 复制
而后咱们能够通过运行以下命令来运行它：
docker run -p 8080:8080 myorg/myapp 复制
输入相似于以下示例输入：
. _
/\ / ‘ _(_) _ \ \ \ \
(()\__ | ‘ | ‘_| | ‘_ / _` | \ \ \ \
\/ ___)| |_)| | | | | || (_| |) ) ) )
‘ |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.0.2.RELEASE)
Nov 06, 2018 2:45:16 PM org.springframework.boot.StartupInfoLogger logStarting
INFO: Starting Application v0.1.0 on b8469cdc9b87 with PID 1 (/app.jar started by root in /)
Nov 06, 2018 2:45:16 PM org.springframework.boot.SpringApplication logStartupProfileInfo
… 复制
如果你想在镜像外部四处寻找，你能够通过运行以下命令在其中关上一个 shell（留神根底镜像没有 bash）：
docker run -ti –entrypoint /bin/sh myorg/myapp 复制
输入相似于以下示例输入：
/ # ls
app.jar dev home media proc run srv tmp var
bin etc lib mnt root sbin sys usr
/ #
咱们在示例中应用的 alpine 根底容器没有 bash，所以这是一个 ashshell。它具备一些但不是全副的个性 bash。
如果你有一个正在运行的容器并且你想查看它，你能够通过运行 docker exec：
docker run –name myapp -ti –entrypoint /bin/sh myorg/myapp
docker exec -ti myapp /bin/sh
/ #复制
传递给命令 myapp 的地位在哪里。如果您没有应用，docker 会调配一个助记名称，您能够从. 您还能够应用容器的 SHA 标识符而不是名称。SHA 标识符在输入中也可见。–namedocker run–namedocker psdocker ps
入口点
应用 Dockerfile 的 exec 模式 ENTRYPOINT，以便没有外壳包装 Java 过程。长处是 java 过程响应 KILL 发送到容器的信号。实际上，这意味着（例如）如果您 docker run 在本地应用图像，则能够应用 CTRL-C. 如果命令行有点长，您能够 COPY 在运行之前将其提取到 shell 脚本中并放入映像中。以下示例显示了如何执行此操作：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
COPY run.sh .
COPY target/*.jar app.jar
ENTRYPOINT [“run.sh”]复制
请记住应用 exec java …启动 java 过程（以便它能够解决 KILL 信号）：
run.sh
!/bin/sh
exec java -jar /app.jar 复制
入口点的另一个乏味方面是您是否能够在运行时将环境变量注入 Java 过程。例如，假如您想要在运行时增加 Java 命令行选项。您能够尝试这样做：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT [“java”,”${JAVA_OPTS}”,”-jar”,”/app.jar”]复制
而后您能够尝试以下命令：
docker build -t myorg/myapp .
docker run -p 9000:9000 -e JAVA_OPTS=-Dserver.port=9000 myorg/myapp 复制
这失败了，因为 ${}替换须要一个外壳。exec 表单不应用 shell 来启动过程，因而不利用选项。您能够通过将入口点挪动到脚本（如 run.sh 后面显示的示例）或在入口点显式创立 shell 来解决此问题。以下示例显示了如何在入口点中创立 shell：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT [“sh”, “-c”, “java ${JAVA_OPTS} -jar /app.jar”]复制
而后，您能够通过运行以下命令来启动此应用程序：
docker run -p 8080:8080 -e “JAVA_OPTS=-Ddebug -Xmx128m” myorg/myapp 复制
该命令产生相似于以下的输入：
. _
/\ / ‘ _(_) _ \ \ \ \
(()\__ | ‘ | ‘_| | ‘_ / _` | \ \ \ \
\/ ___)| |_)| | | | | || (_| |) ) ) )
‘ |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.0.RELEASE)
…
2019-10-29 09:12:12.169 DEBUG 1 — [main] ConditionEvaluationReportLoggingListener :
============================
CONDITIONS EVALUATION REPORT
… 复制
（后面的输入显示了 Spring BootDEBUG 生成的残缺输入的一部分。）-Ddebug
将 anENTRYPOINT 与显式 shell 一起应用（如后面的示例所做的那样）意味着您能够将环境变量传递给 Java 命令。然而，到目前为止，您还不能为 Spring Boot 应用程序提供命令行参数。以下命令不会在端口 9000 上运行应用程序：
docker run -p 9000:9000 myorg/myapp –server.port=9000 复制
该命令产生以下输入，将端口显示为 8080 而不是 9000：
. _
/\ / ‘ _(_) _ \ \ \ \
(()\__ | ‘ | ‘_| | ‘_ / _` | \ \ \ \
\/ ___)| |_)| | | | | || (_| |) ) ) )
‘ |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.0.RELEASE)
…
2019-10-29 09:20:19.718 INFO 1 — [main] o.s.b.web.embedded.netty.NettyWebServer : Netty started on port(s): 8080 复制
它不起作用，因为 docker 命令（该 –server.port=9000 局部）被传递到入口点 (sh)，而不是它启动的 Java 过程。要解决此问题，您须要将命令行从以下增加 CMD 到 ENTRYPOINT：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG JAR_FILE=target/*.jar
COPY ${JAR_FILE} app.jar
ENTRYPOINT [“sh”, “-c”, “java ${JAVA_OPTS} -jar /app.jar ${0} ${@}”]复制
而后您能够运行雷同的命令并将端口设置为 9000：
$ docker run -p 9000:9000 myorg/myapp –server.port=9000 复制
如以下输入示例所示，端口的确设置为 9000：
. _
/\ / ‘ _(_) _ \ \ \ \
(()\__ | ‘ | ‘_| | ‘_ / _` | \ \ \ \
\/ ___)| |_)| | | | | || (_| |) ) ) )
‘ |____| .__|_| |_|_| |_\__, | / / / /
=========|_|==============|___/=/_/_/_/
:: Spring Boot :: (v2.2.0.RELEASE)
…
2019-10-29 09:30:19.751 INFO 1 — [main] o.s.b.web.embedded.netty.NettyWebServer : Netty started on port(s): 9000 复制
留神 ${0}“命令”（在这种状况下是第一个程序参数）和 ${@}“命令参数”（程序参数的其余部分）的应用。如果您应用脚本作为入口点，那么您不须要 ${0}（/app/run.sh 在后面的示例中）。以下列表显示了脚本文件中的正确命令：
run.sh
!/bin/sh
exec java ${JAVA_OPTS} -jar /app.jar ${@}复制
docker 配置到当初都非常简单，生成的镜像效率不是很高。docker 镜像有一个文件系统层，其中蕴含 fat JAR，咱们对利用程序代码所做的每一次更改都会更改该层，这可能是 10MB 或更多（对于某些应用程序甚至高达 50MB）。咱们能够通过将 JAR 拆分为多个层来改良这一点。
较小的图像
请留神，后面示例中的根本映像是 openjdk:8-jdk-alpine. 这些 alpine 图像小于 Dockerhubopenjdk 的规范库图像。您还能够通过应用标签而不是. 并非所有应用程序都应用 JRE（与 JDK 绝对），但大多数应用程序都能够。一些组织强制执行一个规定，即每个应用程序都必须应用 JRE，因为存在滥用某些 JDK 性能（例如编译）的危险。jrejdk
另一个能够让您取得更小的映像的技巧是应用 JLink，它与 OpenJDK 11 捆绑在一起。JLink 容许您从残缺 JDK 中的模块子集构建自定义 JRE 散发，因而您不须要 JRE 或 JDK 根底图像。原则上，这将使您取得比应用 openjdk 官网 docker 图像更小的总图像大小。在实践中，您（还）不能将 alpine 根底镜像与 JDK 11 一起应用，因而您对根底镜像的抉择是无限的，并且可能会导致最终镜像的大小更大。此外，您本人的根本映像中的自定义 JRE 不能在其余应用程序之间共享，因为它们须要不同的自定义。因而，您的所有应用程序可能都有较小的图像，但它们依然须要更长的工夫能力启动，因为它们没有从缓存 JRE 层中受害。
最初一点突出了图像构建者的一个十分重要的问题：指标不肯定总是尽可能地构建最小的图像。较小的图像通常是一个好主见，因为它们须要更少的工夫来上传和下载，但前提是它们中的所有图层都没有被缓存。现在，图像注册非常复杂，您很容易通过尝试奇妙地构建图像而失去这些性能的益处。如果您应用通用根底层，图像的总大小就不再那么重要了，而且随着注册核心和平台的倒退，它可能变得更不重要。话虽如此，尝试优化应用程序映像中的层依然很重要且有用。然而，
更好的 Dockerfile
因为 JAR 自身的打包形式，Spring Boot fat JAR 天然有“层”。如果咱们先解包，它曾经分为内部依赖和外部依赖。要在 docker 构建中一步实现此操作，咱们须要先解压缩 JAR。以下命令（保持应用 Maven，但 Gradle 版本十分类似）解压缩 Spring Boot fat JAR：
mkdir target/dependency
(cd target/dependency; jar -xf ../*.jar)
docker build -t myorg/myapp . 复制
而后咱们能够应用上面的 Dockerfile
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=target/dependency
COPY ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY ${DEPENDENCY}/META-INF /app/META-INF
COPY ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]复制
当初有三层，所有应用程序资源都在前面两层。如果应用程序依赖没有扭转，第一层（from BOOT-INF/lib）不须要扭转，所以构建更快，并且容器在运行时的启动也更快，只有根底层曾经被缓存。
咱们应用了一个硬编码的主应用程序类：hello.Application. 这对于您的应用程序可能有所不同。如果你违心，你能够用另一个参数化它 ARG。您还能够将 Spring Boot fat 复制 JarLauncher 到映像中并应用它来运行应用程序。它能够工作，您不须要指定主类，但启动时会慢一些。
Spring Boot 层索引
从 Spring Boot 2.3.0 开始，应用 Spring Boot Maven 或 Gradle 插件构建的 JAR 文件在 JAR 文件中蕴含层信息。该层信息依据应用程序构建之间更改的可能性来拆散应用程序的各个局部。这能够用来使 Docker 镜像层更加高效。
层信息可用于将 JAR 内容提取到每个层的目录中：
mkdir target/extracted
java -Djarmode=layertools -jar target/*.jar extract –destination target/extracted
docker build -t myorg/myapp . 复制
而后咱们能够应用以下内容 Dockerfile：
Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG EXTRACTED=/workspace/app/target/extracted
COPY ${EXTRACTED}/dependencies/ ./
COPY ${EXTRACTED}/spring-boot-loader/ ./
COPY ${EXTRACTED}/snapshot-dependencies/ ./
COPY ${EXTRACTED}/application/ ./
ENTRYPOINT [“java”,”org.springframework.boot.loader.JarLauncher”]
Spring Boot fatJarLauncher 是从 JAR 中提取到镜像中的，因而它能够用于启动应用程序，而无需对主应用程序类进行硬编码。
无关应用分层性能的更多信息，请参阅 Spring Boot 文档。
调整
如果您想尽快启动您的应用程序（大多数人都这样做），您可能会思考一些调整：
应用 spring-context-indexer（链接到文档）。它不会为小型应用程序减少太多，但每一点都有帮忙。
如果您负担得起，请不要应用执行器。
应用 Spring Boot 2.1（或更高版本）和 Spring 5.1（或更高版本）。
应用（通过命令行参数、零碎属性或其余办法）修复 Spring Boot 配置文件的地位。spring.config.location
通过设置来敞开 JMX（您可能不须要在容器中应用它）spring.jmx.enabled=false。
应用 -noverify. 还要思考 -XX:TieredStopAtLevel=1（这会在当前减慢 JIT 但会缩短启动工夫）。
应用 Java 8 的容器内存提醒：-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap. 在 Java 11 中，默认状况下这是主动的。
您的应用程序在运行时可能不须要残缺的 CPU，但它的确须要多个 CPU 能力尽快启动（至多两个，四个更好）。如果您不介意启动速度较慢，则能够将 CPU 限度在四个以下。如果您被迫从少于四个 CPU 开始，设置 可能会有所帮忙
-Dspring.backgroundpreinitializer.ignore=true，因为它能够避免 Spring Boot 创立一个它可能无奈应用的新线程（这实用于 Spring Boot 2.1.0 及更高版本）。
多阶段构建
A Better Dockerfile 中 Dockerfile 所示的假如假如胖 JAR 曾经在命令行上构建。您还能够通过应用多阶段构建并将后果从一个图像复制到另一个图像来在 docker 中执行该步骤。以下示例通过应用 Maven 来实现：
Dockerfile
FROM openjdk:8-jdk-alpine as build
WORKDIR /workspace/app
COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src
RUN ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]复制
第一个图像标记为 build，它用于运行 Maven、构建胖 JAR 并解压缩它。解包也能够由 Maven 或 Gradle 实现（这是入门指南中采纳的办法）。没有太大区别，只是必须编辑构建配置并增加插件。
请留神，源代码已分为四层。前面的层蕴含构建配置和应用程序的源代码，后面的层蕴含构建零碎自身（Maven 包装器）。这是一个小的优化，也意味着咱们不用将 target 目录复制到 docker 镜像，即便是用于构建的长期镜像。
RUN 每个源代码更改的构建都很慢，因为必须在第一局部从新创立 Maven 缓存。然而你有一个齐全独立的构建，只有他们有 docker，任何人都能够运行它来运行你的应用程序。这在某些环境中可能十分有用——例如，您须要与不理解 Java 的人共享您的代码。
试验性能
Docker 18.06 带有一些“实验性”个性，包含缓存构建依赖项的办法。要关上它们，您须要在守护过程 (dockerd) 中有一个标记，并在运行客户端时须要一个环境变量。而后你能够增加一个“神奇”的第一行到你的 Dockerfile：
Dockerfile
syntax=docker/dockerfile:experimental 复制
而后该 RUN 指令承受一个新标记：–mount. 以下清单显示了一个残缺示例：
Dockerfile
syntax=docker/dockerfile:experimental
FROM openjdk:8-jdk-alpine as build
WORKDIR /workspace/app
COPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src src
RUN –mount=type=cache,target=/root/.m2 ./mvnw install -DskipTests
RUN mkdir -p target/dependency && (cd target/dependency; jar -xf ../*.jar)
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/target/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]复制
而后你能够运行它：
DOCKER_BUILDKIT=1 docker build -t myorg/myapp . 复制
以下清单显示了示例输入：
…
=> /bin/sh -c ./mvnw install -DskipTests 5.7s
=> exporting to image 0.0s
=> => exporting layers 0.0s
=> => writing image sha256:3defa…
=> => naming to docker.io/myorg/myapp 复制
应用试验性功能，您会在管制台上取得不同的输入，但您能够看到，如果缓存是热的，当初 Maven 构建只需几秒钟而不是几分钟。
这个 Dockerfile 配置的 Gradle 版本十分类似：
Dockerfile
syntax=docker/dockerfile:experimental
FROM openjdk:8-jdk-alpine AS build
WORKDIR /workspace/app
COPY . /workspace/app
RUN –mount=type=cache,target=/root/.gradle ./gradlew clean build
RUN mkdir -p build/dependency && (cd build/dependency; jar -xf ../libs/*.jar)
FROM openjdk:8-jdk-alpine
VOLUME /tmp
ARG DEPENDENCY=/workspace/app/build/dependency
COPY –from=build ${DEPENDENCY}/BOOT-INF/lib /app/lib
COPY –from=build ${DEPENDENCY}/META-INF /app/META-INF
COPY –from=build ${DEPENDENCY}/BOOT-INF/classes /app
ENTRYPOINT [“java”,”-cp”,”app:app/lib/*”,”hello.Application”]
尽管这些性能处于试验阶段，但关上和敞开 buildkit 的选项取决于 docker 您应用的版本。查看您领有的版本的文档（后面显示的示例对于 docker18.0.6 是正确的）。
平安方面
就像在经典 VM 部署中一样，过程不应以 root 权限运行。相同，映像应蕴含运行应用程序的非 root 用户。
在 aDockerfile 中，您能够通过增加另一个增加（零碎）用户和组并将其设置为以后用户（而不是默认的 root）的层来实现此目标：
Dockerfile
FROM openjdk:8-jdk-alpine
RUN addgroup -S demo && adduser -S demo -G demo
USER demo
… 复制
如果有人设法冲破您的应用程序并在容器内运行系统命令，这种预防措施会限度他们的能力（遵循最小权限准则）。
一些进一步的 Dockerfile 命令只能以 root 身份运行，因而您可能必须将 USER 命令进一步向下挪动（例如，如果您打算在容器中装置更多包，它只能以 root 身份运行）。
对于其余办法，不应用 aDockerfile 可能更适宜。例如，在前面形容的 buildpack 办法中，大多数实现默认应用非 root 用户。
另一个思考因素是大多数应用程序在运行时可能不须要残缺的 JDK，因而一旦咱们进行了多阶段构建，咱们就能够平安地切换到 JRE 根底映像。因而，在后面显示的多阶段构建中，咱们能够将其用于最终的可运行映像：
Dockerfile
FROM openjdk:8-jre-alpine
… 复制
如前所述，这也节俭了映像中的一些空间，这些空间将被运行时不须要的工具占用。
文末备注：
Spring Boot Docker 起源：Spring 中国教育管理中心