用于持续集成/持续部署的 Docker 映像版本控制答案

【问题标题】：Docker images versioning for Continuous Integration / Continuous Deployment用于持续集成/持续部署的 Docker 映像版本控制
【发布时间】：2015-08-28 13:55:48
【问题描述】：

我们正在使用两个众所周知的概念来实施我们的持续集成和持续交付流程：Linux 二进制包和Docker 图像。

大部分工作已经完成：我们从GitLab repo 中获取代码，编译并放入存储在Aptly 中的deb 包中，然后为每个服务创建Docker 图像我们拥有并将图像推送到私有Docker Registry 服务器。之后，这些图像被滚动到测试环境。最后，我们启动服务并执行验收测试。这是一个持续的过程，每次有人将提交推送到origin/master 时都会开始。

目前尚不清楚的是如何区分稳定的镜像存储在 Docker Registry 中？

我们必须跟踪每个图像的状态，因为我们需要执行稳定服务器的定期更新。显然，某些版本（即图像的版本）不会通过验收测试，必须在每次持续交付的下一次迭代中标记为不可用并过滤掉。

似乎没有此功能的默认实现：

默认图像 repo/tag 是一个普通的纯字符串，不能同时包含版本号、构建日期和 QA 标记。
Labels（在 1.6 中引入）可能是解决方法的一个很好的起点，但我们无法找到重新标记现有图像的机会（请注意，我们需要更新图像“元数据”，考虑到QA 的结果）。没有可用的方法通过标签值查询图像，但我们可能可以包装 Docker API。

那么将版本分配给 Docker 映像的正确方法是什么？如何存储与 QA 相关的信息？我们如何“突出”稳定的图像构建？ Jenkins CI 的哪些功能可用于实现这些目的？请分享您的经验。

UPD: 过了一会儿，我不得不在 Docker 问题跟踪器中启动 discussion。可能有人会发现它也很有用。

【问题讨论】：

您应该使用在 github 上收集的输入回答您自己的问题并接受它。它肯定会帮助别人

标签： jenkins version-control docker continuous-deployment docker-registry

【解决方案1】：

看起来您的问题已在该讨论链接中得到解答，但我只想指出，在 Bleacher Report 中，我们从未将图像推送到未首先通过 CI 的 docker hub（私有或托管）。

代码推送
CircleCI 创建一个标记的构建
测试在标记容器内运行
如果测试通过，CircleCI 会将标记的容器推送到集线器

Detailed explanation

【讨论】：

感谢您的回答。不幸的是，CircleCI 不适用于我们，因为它是一个云解决方案，但我们需要在我们自己的设施上构建管道。
CircleCI 可以替换为 Jenkins，但不幸的是我没有详细的帖子:( 但是它的概念相同，Jenkins 监听 git commit 触发器，然后构建 docker 映像，运行它, 在其中进行测试，如果通过，则将其推送到注册表。