例如，我担心没有开发人员的尽职调查，注册表中的最新Docker映像将无法在SCM中反映Dockerfile的当前状态，反之亦然。同样，我们必须始终可以追溯到注册表中任何映像的基础Dockerfile（我们制作的）。
#1 楼
我可以在这里找到答案。forums.docker.com功劳归于dmaze。 Docker在这一点上已经足够主流，任何基于云或本地安装的CI系统都可以做到。在Dockerfile中，使用LABEL记录构建的源。这可能包括来自分布式源代码管理（git，Mercurial）的提交哈希，分支名称（如果相关），任何发布标签（如果存在）以及可能的详细信息，例如最后一次提交的时间戳。 docker历史记录和docker inspect应该能够显示这些内容。
当docker push映像时，至少将它们推送两次，并使用提交哈希并将分支名称作为“版本”部分（码头） .io / mycorp / imagename：123abc7，quay.io/mycorp/imagename:dmaze-test）。如果可以使用发布标签，则CI系统也应使用这些标签推送图像。
当然，请确保Dockerfile致力于源代码控制，并尝试使用稳定的路径来获取任何外部文件
现在，您可以使用两种方式：给定一个任意提交，如果CI系统构建了它，则可以docker运行它构建的映像；如果有图像，则可以找到源历史记录中的确切位置，并进行git checkout或hg直至特定版本，然后docker自己构建一个几乎相同的副本。
#2 楼
如果您想在Docker和SCM之间实现完美的集成，GitLab提供了它自己的内置Docker注册表。这使得在构建管道中发布Docker映像变得轻而易举。GitLab Docker注册表的另一个大优点是，它为每个GitLab存储库支持多个Docker存储库。这使您可以为每个分支，每个提交，每个环境或您需要的任何内容创建一个新的Docker存储库。
我公司利用此功能，通过将我们的映像推送到基于该分支的存储库中，标记为他们的承诺。这是一个示例：
project-name/branch-name:commit-SHA 或者，如果您正在为一个特定的分支构建多个Docker映像（例如前端Angular应用程序，以及与之通信的后端API），则可以确定范围它甚至更像这样：
project-name/branch-name/api:commit-SHA project-name/branch-name/front-end:commit-SHA 用于范围定义的斜杠（/）数量没有限制。这使得在部署映像时很容易分辨出映像的确切提交。因此，我的公司几乎从未使用过通用的“最新”标签。我们更喜欢将映像部署在何处的特异性。
您仍然可以将相同的“多个docker repo”逻辑应用于任何Docker注册表。您必须查找特定系统的功能来动态创建新的存储库，以及与CI / CD管道集成的简便性。
评论
多次推送docker有什么区别吗？
–莫里茨
18年2月14日在23:23
不确定您的问题，但Docker注册表将跟踪映像的哈希值，因此，如果您多次推送docker映像（使用不同的标签），则将获得带有标签的多个``映像名称''，但它们都引用相同的哈希值。因此，除了存储新的映像名称外，不占用额外的空间。
–斯科特
18年2月15日在21:11