前段时间我接受了一家公司的采访，他们提到他们的应用程序是用Docker打包的。他们还说当修改应用程序时，他们不仅会提交代码而且会提交整个图像。因此，发布只是从git（？）推送提交。
我没有机会询问更多细节，所以我不确定他们的意思......
选项1：
他们实际上将Dockerfile放在源代码树的某个地方然后他们提交了它，然后一些脚本只会在正确的目录中复制已编译的应用程序（我们正在谈论java）。
选项2：
他们提交整个图像（？）。我不熟悉Docker镜像的结构，它们是二进制文件还是仅包含分发文件的大目录树（以及应用程序的配置等）。
或其他什么......我不太了解码头工人。
显然，我不想把这些资源放在图片中并在git中提交整个发行版似乎对我来说有点矫枉过正......
答案 0 :(得分：1)
我认为它介于选项1和2之间：
当团队中的任何开发人员推送代码时，某些CI / CD工具（如Jenkins）可能会使用Base Docker镜像创建Docker容器（可以直接拉出docker镜像或使用Dockefile创建镜像）并执行java编译那个容器。此时，如果构建了映像，则负责创建映像的Dockerfile可以git pull或ADD或使用Volume挂载，然后编译java项目。或者，如果基本图像已经存在基本环境设置，则可能已使用卷添加了Java源代码，或者使用引用基本图像的另一个Dockerfile并使用ADD或执行git pull创建一个新图像并最终创建容器，编译代码。此外，测试可能需要单独的data containers包含数据。现在相同的容器可以传递到其他环境，例如QA或Pre-prod用于单元测试和集成测试（完全取决于设计）。如果所有测试都通过，CI / CD工具可以提交容器来创建新图像，标记它们以便发布。现在使用相同的图像（使用该特定标记）在生产中部署容器。
现在，正如您所提到的，Dockerfile可能会在源代码树中的某处提交，也可能属于完全不同的repo，只负责部署。
Docker镜像可以绑定到构建管道并相应地标记，以便在必要时还原更改。
在版本中集成Docker的方法有很多种
您可以参考这些帖子来进一步调查人们如何在生产中使用Docker：
1. https://stackoverflow.com/a/18287169/2167517
2. Docker Container management in production environment
3. Creating a Docker UAT/Production image
我希望这在一定程度上帮助了你。这是一个简单的用例，我相信人们实际上在生产中使用了Docker的优雅设计。