docker - 如何使用 Docker 发布？

Question

前段时间我采访了一家公司，他们提到他们的应用程序是用Docker打包的。他们还说，当修改应用程序时，他们不仅会提交代码，还会提交整个图像。因此，发布仅包含从 git (?) 推送提交。

我没有机会询问更多细节，所以我不确定他们的意思......

选项 1:

他们实际上在源代码树的某个地方放置了一个 Dockerfile，然后他们提交了它，然后一些脚本只会将编译后的应用程序复制到正确的目录中(我们谈论的是 java)。

选项 2:

他们提交了整个图像(？)。我不熟悉 Docker 镜像的结构，它们是二进制的还是只是带有分发文件的大目录树(加上应用程序的配置等...)。

或者别的……我对 docker 了解不够。

显然我不想将源代码放在图像中并且在 git 中提交整个发行版对我来说似乎有点过分...

Answer 1

我认为它介于选项 1 和选项 2 之间:
当团队中的任何开发人员推送代码时，诸如 Jenkins 之类的某种 CI/CD 工具可能会使用 Base Docker 镜像创建 Docker 容器(可能会直接拉取 docker 镜像或使用 Dockerfile 创建镜像)并在其上进行 java 编译那个容器。此时，如果镜像已构建，负责创建镜像的 Dockerfile 可能会执行 git pull 或 ADD 或使用 挂载Volume 然后编译java项目。或者，如果基础镜像已经存在并设置了基本环境，则可能已使用卷或使用另一个引用基础镜像并使用 ADD 或执行 git pull 以创建新图像并最终创建编译代码的容器。另外，分开data containers包含测试可能需要的数据。现在，相同 容器可能会在其他环境中传递，比如用于单元测试和集成测试的 QA 或预生产(完全取决于设计)。如果所有测试都通过，CI/CD 工具可能会提交容器以创建新图像，并标记它们以供发布。相同的图像(带有特定标签)现在用于在生产环境中部署容器。
现在，正如您提到的，Dockerfile 可能在源代码树中的某个地方提交，或者可能属于完全不同的 repo，只负责部署。
Docker 镜像可以绑定(bind)到构建管道并相应地标记，以便在必要时恢复更改。
有很多方法可以在发布中集成 Docker。
您可以引用这些帖子以进一步调查人们如何在生产中使用 Docker:
1. https://stackoverflow.com/a/18287169/2167517
2. Docker Container management in production environment
3. Creating a Docker UAT/Production image
我希望这在一定程度上帮助了你。这是一个简单的用例，我相信人们实际上在他们的生产中使用了很多优雅的 Docker 设计。