CI/CD和部署的Docker实践

我是Docker的新手，读了一些关于它的文章

我读过许多文章，其中提到“对所有环境（dev/stage/production）使用相同的映像”和“CI/CD和部署的映像是不同的”

但我无法整合这两个建议，也找不到dockerfile的例子

这是不是意味着我必须制作下面两张docker的图片

(1) image for deployment
- application code and its dependencies
- there is no CMD 

(2) image for CI/CD
- use (1) as base image
- add extra for CI/CD

---

我认为你的困惑来自第4节：

部署映像应包含：

• 小型化/编译形式的应用程序代码及其运行时依赖项
• 没有别的了。真的没有别的了

第二类是用于CI/CD系统或 开发人员和可能包含：

• 原始形式的源代码（即未统一）
• 编译器/缩微器/Transpiler （等）

虽然许多开发人员认为这很自然，但我认为这不是一个很好的设置，它显示了反模式1，将容器视为VM

在我看来，在开发过程中，目标容器不应该包括编译器、测试框架等。它应该只包含编译后的代码和它的运行时，就像进入prod的容器一样

所有这些工具都属于一个不同的容器（我们称之为“实用工具”），特别是为了使构建和测试统一且可复制而创建的。该容器安装了构建所有容器或其广泛子集（例如，所有节点和Python容器）可能需要的所有工具。您在调用源目录时挂载它，它编译/缩小/打包代码，生成gRPC存根，运行测试套件，等等

您可以在本地和CI/CD中使用相同的实用程序容器。您的构建和测试管道独立于操作系统（在我们公司，开发人员在他们的桌面上运行Windows、macOS和Linux，但对于构建后端服务来说，这没有什么区别）。您永远不必处理不同“开发”映像之间编译器版本、测试框架版本、eslint配置等的差异

当然，您可以在prod和开发中以不同的方式使用编译后的代码运行相同的映像：例如，您可以公开用于连接调试器的端口，等等。但是它是从容器外部（轻）配置的，而不是不同的构建

---

因此，在我看来，不应该在开发、CI/CD和prod中使用相同的容器。在我为所有容器工作的公司中，有一家公司都有加密签名，您只能将从特定提交构建并通过测试的容器升级到QA/staging/prod，并在每次升级时检查签名。当然，将编译器留在这样一个容器中会是一个失礼。

这个问题似乎更适合您，您是否有一个指向“CI/CD映像和部署映像不同”文本的方便链接？这段引文似乎遗漏了一些重要的上下文，因为对我来说它毫无意义。@9000是的，在这里。哇，我明白了。非常感谢。