java - 关于 Nexus 工件和构建说明的 Dockerfile 最佳实践

Question

我对 Docker 有点陌生，我正在尝试了解有关 Dockerfile 中构建过程的一些最佳实践建议。

我知道对于传统的 JAVA 应用程序，我们通常会使用 maven 从 Nexus 存储库中提取依赖库，从 GIT 或其他 CM 中提取源代码，然后构建应用程序。最后，输出的 .war 文件将再次存储在 Nexus 存储库中标记的发布文件夹中，以便复制到不同的环境(dev/qa/production 等)。但是仍然存在的一个挑战是不同环境之间的不一致，我们正在尝试使用容器来解决这个问题 - 这意味着一旦它在容器中进行了测试，我们就可以将该容器插入管道到不同的环境，它们应该可以在没有任何环境的情况下工作问题，因为容器包含环境依赖项以及 Web 应用程序作为包所需的所有内容。

但我的问题是关于 Dockerfile。那么 Dockerfile 应该取代 Maven 的功能吗？它是否应该包含应用程序的完整构建说明？我知道我们仍然通过在 Dockerfile 中引用它们来从 GIT 和依赖库中提取源代码，但是输出 .war 文件在哪里？是否仍然需要将其存储在 Nexus 中？由于我们可以通过 OpenShift 等工具对 Docker 容器进行版本控制，并在必要时回滚，所以将输出 .war 文件存储在 Nexus 中的目的是什么。

我能想到的一种情况与修补有关。当操作系统/安全补丁可用时，我们会更新基础 Docker 镜像并重建应用程序特定的 Docker 镜像以应用补丁。但是在这种情况下，应用程序会发生什么？每次需要应用补丁时都需要重新构建应用程序吗？如果应用程序构建指令嵌入到 Dockerfile 中，并且我们必须重新构建应用程序容器镜像，那么应用程序是否也会自动重新构建？或者 Dockerfile 是否只能执行某些指令 - 如果没有代码更改或当你告诉它跳过等时跳过构建应用程序部分。)。 Dockerfile 是否应该引用应用程序 .war 文件的 Nexus 存储库，以便在 .war 文件没有更改的情况下，它不会重建？

我将不胜感激。

谢谢。

Answer 1

我会说在 Nexus 中单独对应用程序构建工件(war、jar 等)进行版本控制是一个好主意，而不是将应用程序构建过程作为 docker 构建的一部分进行。我们有一个类似的管道，我们这样做的方式是这样的:

从 SCM checkout 源代码

使用 Maven 构建并将构建工件上传到 Nexus 以进行版本控制

作为 docker 构建步骤

的一部分，在基础 Docker 镜像(即 openjdk)中注入(inject)构建的工件

将镜像推送到注册表

CD 启动并部署最新镜像

Should Dockerfile reference to a Nexus repository for the application .war file so in the case the .war file doesn't change, it doesn't rebuild?

是的，没错，您可以在 Dockerfile 中使用 curl 命令从 Nexus 下载工件，无需在每次更改 Dockerfile 时重新构建应用程序。