使用了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命令lline选项的选项。您可以尝试执行以下操作：

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表单不使用外壳程序来启动进程，因此不会应用选项。您可以通过将入口点移动到脚本（如run.sh上面的示例），或在入口点中显式创建外壳来解决这个问题。例如：

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 Boot DEBUG生成的全部输出的一部分-Ddebug。）

ENTRYPOINT与上面的显式shell一起使用，意味着您可以将环境变量传递到java命令中，但是到目前为止，您还不能为Spring Boot应用程序提供命令行参数。此技巧无法在端口9000上运行应用程序：

$ docker run -p 9000:9000 myorg/myapp --server.port=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} ${@}"]

$ docker run -p 9000:9000 myorg/myapp --server.port=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映像只有一个文件系统层，其中包含胖子罐，我们对应用程序代码进行的每一次更改都会更改该层，该层可能为10MB或更大（某些应用程序甚至为50MB）。我们可以通过将JAR分为多个层来改善这一点。

请注意，以上示例中的基本图像为openjdk:8-jdk-alpine。这些alpine图像比Dockerhub的标准openjdk库图像小。尚无Java 11的正式高山图像（AdoptOpenJDK已有一段时间，但不再出现在其Dockerhub页面上）。您还可以使用“ jre”标签而不是“ jdk”在基本映像中节省大约20MB。并非所有的应用程序都可以与JRE一起使用（而不是JDK），但是大多数的应用程序都可以，并且确实有些组织会强制执行每个应用程序必须遵循的规则，因为存在滥用某些JDK功能（例如编译）的风险。

可以使您缩小图像的另一个技巧是使用JLink，它与OpenJDK 11捆绑在一起。JLink允许您从完整JDK中的模块子集构建自定义JRE分发，因此您不需要JRE或JDK在基本图像中。原则上，这将使您的总映像大小小于使用openjdk官方docker映像。实际上，您还无法使用alpine带有JDK 11的基本映像，因此您对基本映像的选择将受到限制，并且可能会导致最终映像尺寸更大。另外，您自己的基本映像中的自定义JRE无法在其他应用程序之间共享，因为它们将需要不同的自定义。因此，对于所有应用程序来说，它们可能都有较小的映像，但是启动它们仍需要更长的时间，因为它们无法从缓存JRE层中受益。

最后一点突出了图像构建者的一个真正重要的关注点：目标不一定总是要构建尽可能小的图像。通常，较小的图像是一个好主意，因为它们只需要较少的时间就可以上传和下载，但是前提是它们中的所有层都没有被缓存。如今，图像注册表非常复杂，通过尝试巧妙地构建图像，您很容易失去这些功能的优势。如果使用公共基础层，则图像的总大小将变得无关紧要，并且随着注册管理机构和平台的发展，图像的总大小可能会变得更小。话虽如此，尝试并优化我们的应用程序映像中的各层仍然很重要且有用，但是目标始终应该是将变化最快的东西放在最高层中，

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/appCOPY mvnw .
COPY .mvn .mvn
COPY pom.xml .
COPY src srcRUN --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/appCOPY . /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"]

在Spotify的Maven插件是一个受欢迎的选择。它要求应用程序开发人员编写a Dockerfile，然后docker为您运行，就像您在命令行上一样。docker image标签和其他内容有一些配置选项，但它使您的应用程序中的docker知识集中在Dockerfile，很多人都喜欢。

对于真正的基本用法，它无需额外配置即可直接使用：

$ mvn com.spotify:dockerfile-maven-plugin:build
...
[INFO] Building Docker context /home/dsyer/dev/demo/workspace/myapp
[INFO]
[INFO] Image will be built without a name
[INFO]
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 7.630 s
[INFO] Finished at: 2018-11-06T16:03:16+00:00
[INFO] Final Memory: 26M/595M
[INFO] ------------------------------------------------------------------------

这将构建一个匿名docker镜像。我们现在可以docker在命令行上用标记，或者使用Maven配置将其设置为repository。示例（不更改pom.xml）：

$ mvn com.spotify:dockerfile-maven-plugin:build -Ddockerfile.repository=myorg/myapp

或在pom.xml：

pom.xml

<build><plugins><plugin><groupId>com.spotify</groupId><artifactId>dockerfile-maven-plugin</artifactId><version>1.4.8</version><configuration><repository>myorg/${project.artifactId}</repository></configuration></plugin></plugins>
</build>

该真知晶球摇篮插件工作有Dockerfile，它也能产生一个Dockerfile适合你，然后它运行docker，如果你是在命令行中运行它。

首先，您需要将插件导入您的build.gradle：

build.gradle

buildscript {...dependencies {...classpath('gradle.plugin.com.palantir.gradle.docker:gradle-docker:0.13.0')}
}

然后最后应用插件并调用其任务：

build.gradle

apply plugin: 'com.palantir.docker'group = 'myorg'bootJar {baseName = 'myapp'version =  '0.1.0'
}task unpack(type: Copy) {dependsOn bootJarfrom(zipTree(tasks.bootJar.outputs.files.singleFile))into("build/dependency")
}
docker {name "${project.group}/${bootJar.baseName}"copySpec.from(tasks.unpack.outputs).into("dependency")buildArgs(['DEPENDENCY': "dependency"])
}

在此示例中，我们选择将Spring Boot胖子罐解压缩到build目录中的特定位置，该目录是docker构建的根目录。然后，上面的多层（不是多阶段）Dockerfile将起作用。

Google有一个名为Jib的开源工具，它相对较新，但出于多种原因却很有趣。可能最有趣的事情是您不需要docker来运行它-它使用与您获得的输出相同的标准输出来构建映像，docker build但docker除非您要求使用否则不使用-因此它可以在没有docker的环境中工作已安装（在构建服务器中并不罕见）。您也不需要Dockerfile（无论如何都会被忽略），也不需要任何东西pom.xml来获得在Maven中构建的映像（Gradle要求您至少在中安装插件build.gradle）。

Jib的另一个有趣的功能是，它对层有看法，并且以与Dockerfile上面创建的多层略有不同的方式优化了它们。就像在胖子罐中一样，Jib将本地应用程序资源与依赖项分离开来，但它走得更远，而且还将快照依赖项放入一个单独的层中，因为它们更容易发生变化。有一些配置选项可用于进一步自定义布局。

Maven的示例（不更改pom.xml）：

$ mvn com.google.cloud.tools:jib-maven-plugin:build -Dimage=myorg/myapp

要运行上述命令，您将需要具有在myorg存储库前缀下推送到Dockerhub的权限。如果您docker在命令行上通过进行了身份验证，则可以在本地~/.docker配置中使用。您还可以在您的仓库中设置Maven“服务器”身份验证~/.m2/settings.xml（id存储库的身份很重要）：

settings.xml

    <server><id>registry.hub.docker.com</id><username>myorg</username><password>...</password></server>

还有其他选项，例如，您可以docker使用dockerBuild目标而不是来针对docker守护程序在本地构建（例如在命令行上运行）build。还支持其他容器注册表，对于每个容器注册表，您将需要通过docker或Maven设置来设置本地身份验证。

一旦将gradle插件放入，它就具有类似的功能build.gradle，例如

build.gradle

plugins {...id 'com.google.cloud.tools.jib' version '1.8.0'
}

或使用入门指南中使用的较旧样式：

build.gradle

buildscript {repositories {maven {url "https://plugins.gradle.org/m2/"}mavenCentral()}dependencies {classpath('org.springframework.boot:spring-boot-gradle-plugin:2.2.1.RELEASE')classpath('com.google.cloud.tools.jib:com.google.cloud.tools.jib.gradle.plugin:1.8.0')}
}

然后您可以用

$ ./gradlew jib --image=myorg/myapp

与Maven构建一样，如果您docker在命令行上使用进行了身份验证，则映像推送将从您的本地~/.docker配置进行身份验证。

Concourse是基于管道的自动化平台，可用于CI和CD。它在Pivotal内部大量使用，该项目的主要作者在那里工作。除CLI外，Concourse中的所有内容都是无状态的，并且所有内容都在容器中运行。由于运行容器是自动化管道的主要业务顺序，因此很好地支持创建容器。该泊坞窗图像资源负责保持你构建的输出状态更新，如果它是一个容器图像。

这是一个示例管道，为上面的示例构建一个docker映像，假设它位于github上，myorg/myapp并且Dockerfile在根目录下有一个，并且在以下位置有一个构建任务声明src/main/ci/build.yml：

resources:
- name: myapptype: gitsource:uri: https://github.com/myorg/myapp.git
- name: myapp-imagetype: docker-imagesource:email: {{docker-hub-email}}username: {{docker-hub-username}}password: {{docker-hub-password}}repository: myorg/myappjobs:
- name: mainplan:- task: buildfile: myapp/src/main/ci/build.yml- put: myapp-imageparams:build: myapp

管道的结构非常具有声明性：您可以定义“资源”（输入或输出或两者兼有）和“作业”（使用动作并将其应用于资源）。如果任何输入资源发生更改，则会触发新的构建。如果作业期间任何输出资源发生更改，则将对其进行更新。

可以在与应用程序源代码不同的位置定义管道。对于通用构建设置，任务声明也可以集中或外部化。如果这是滚动的方式，则可以将开发和自动化之间的关注点分离开。

Jenkins是另一种流行的自动化服务器。它具有广泛的功能，但在此处与其他自动化示例最接近的功能是管道功能。这是一个Jenkinsfile使用Maven构建Spring Boot项目，然后使用Dockerfile构建图像并将其推送到存储库的：

Jenkinsfile

node {checkout scmsh './mvnw -B -DskipTests clean package'docker.build("myorg/myapp").push()
}

对于需要在构建服务器中进行身份验证的（现实的）泊坞库，您可以使用将凭证添加到上述docker对象docker.withCredentials(…​)。