我是Docker的新手，并阅读了一些有关它的文章。
[我读了许多文章，说“在所有环境（开发/生产/生产）中使用相同的映像”和“用于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系统或开发人员，可能包含：
- 原始格式的源代码（即未缩小）
- 编译器/缩小器/编译器（等）
[虽然许多开发人员认为它很自然，但我认为这不是一个很好的设置，它显示了反模式1，将容器像VM一样对待。
在我看来，在开发过程中，目标容器应不是包括编译器，测试框架等。它仅应包含已编译的代码和运行时，就像要生产的容器一样。
所有这些工具都属于different容器（我们称其为“实用程序”），其创建目的是使构建和测试统一且可重现。该容器已经安装了构建所有容器或其广泛子集所需的所有工具（例如，所有Node和Python容器）。您在调用时挂载源目录，它会编译/缩小/打包代码，生成gRPC存根，运行测试套件等。
您可以在本地和CI / CD中使用相同的实用程序容器。您的构建和测试管道与操作系统无关（在我们公司中，开发人员在其台式机上运行Windows，macOS和Linux，但是对于构建后端服务而言，这没有什么区别）。您无需在不同的“开发”映像之间处理各种版本的编译器版本，测试框架版本，eslint配置等问题。
当然，您可以在生产和开发过程中，以不同的方式用编译后的代码run使用相同的图像：例如您可以公开端口以连接调试器等。但这是容器外部的（轻型）配置，而不是其他版本。
所以，在我看来，您应该在开发，CI / CD和产品上使用相同的容器。在我为所有容器工作的一家公司中，每个容器都有加密签名，并且您只能将由特定提交构建并通过测试的容器升级到QA /分阶段/生产，并在每次升级时检查签名。当然，将编译器留在这样的容器中将是一件令人遗憾的事情。