Java docker文件。构建并测试还是只运行jar文件？

我在CI管道中考虑这一点，我应该首先构建并测试我的应用程序，结果应该是一个docker映像

我想知道使用构建环境在构建服务器上构建然后运行测试是否更常见。也许使用一个构建脚本。最后，将jar文件添加到使用COPY生成的Docker容器中，然后使用Entrypoint java-jar.jar。因此，保持Dockerfile非常小，并在容器外部进行测试和构建

有点像这样：

FROM openjdk:8-jre-alpine
CMD java ${JAVA_OPTS} -jar *.jar
COPY build/libs/*.jar .

或者，如果我应该将所有源代码添加到容器中，构建它，然后在容器中运行测试，然后让入口点（像以前一样）运行生成的jar文件？那么把所有东西都放在Dockerfile里？也许还要做一些清理，删除源代码

---

我想这并不一定是Java，同样的问题也适用于所有语言，你可以用所谓的build docker镜像来构建和测试应用程序，使用JDK和所有你需要的工具。当您完成并高兴时，您将jar／WAR作为一个工件提取到您的Ci/CD管道中，然后，当您认为它已准备好时，您就可以建立一个生产坞镜像并将工件放入内部，在那里您只有一个JRe/Tomcat（无论您只需要生产什么）-没有DEV工具，不编译任何工具-尽可能小、光滑、简单

因此，基本上每个应用程序都至少有2个图像，一个用于构建，一个用于在生产中运行。两者混合是非常糟糕的做法，迟早会导致问题

在主机上构建更糟糕，因为您没有以这种方式使用干净的环境，这或多或少是docker的一个关键优势，而且您无法轻松地在本地复制构建。

优化容器构建 历史上，为了创建不包含源代码（以及用于创建二进制文件的软件）的Docker映像，必须运行Docker两次，例如，请参阅

现在，Docker支持新的多阶段构建功能：

这使Docker能够使用包含构建工具的映像构建容器，但输出仅包含运行时依赖项的映像。下面的示例演示了这个概念，请注意jar是如何从第一个构建阶段的目标目录复制的

FROM maven:3.3-jdk-8-onbuild 

FROM java:8
COPY --from=0 /usr/src/app/target/demo-1.0-SNAPSHOT.jar /opt/demo.jar
CMD ["java","-jar","/opt/demo.jar"]

生成的映像不包含maven，只包含java和构建的jar

测试 假设我们不是在讨论单元测试（可以在本地运行），那么集成测试需要首先部署代码。本例中的答案在很大程度上取决于如何部署容器化Java应用程序

---

例如，如果您使用Kubernetes或Openshift，一个选项是在Maven中运行测试阶段之前使用部署代码。

为了解决这个问题，我借用了SoC（关注点分离）设计原则来自计算机科学，并决定采用两种docker image方法：一种用于构建/测试应用程序，另一种用于运行应用程序。将过程分开的另一个好处是减少意外行为的发生，这将简化维护和回归测试。

这是一个相当广泛的问题，我将对jar本身进行单元测试，然后在构建过程中对Docker映像进行集成测试