Docker映像版本用于持续集成/持续部署

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

大部分的工作已经完成了：我们从GitLab Aptly获取代码，编译它并把它放到Aptly存储的deb包中，然后我们为每个服务创buildDocker镜像，并将镜像推送到私有Docker Registry服务器。 之后，这些图像将滚动到testing环境。 最后我们启动服务并进行验收testing。 这是一个连续的过程，每次有人向提交origin/master推送提交时都会启动。

还有什么不清楚的是如何区分存储在Docker Registry中的稳定图像 ？

我们必须跟踪每个图像的状态，因为我们需要执行稳定服务器的定期更新。 很明显，某些版本（即图像版本）不能通过验收testing，必须标记为不可用，并在每次连续发送的迭代中将其过滤掉。

似乎没有这个function的默认实现：

1. 默认的图像repo/tag是一个普通的普通string，不能同时拥有版本号，build立date和质量保证标志。
2. Labels （ 1.6中介绍）可能是解决scheme的一个很好的起点，但我们无法find重新标记现有图像的机会（请注意，我们需要考虑QA的结果更新图像“元数据”） 。 没有可用的标签值查询图像的方法，但我们可能会包装Docker API。

那么将版本分配给Docker镜像的正确方法是什么？ QA相关信息如何存储？ 我们如何“突出”稳定的形象构build？ Jenkins CI特点可以用来达到这些目的吗？ 请分享你的经验。

UPD：过了一段时间，我不得不在Docker问题跟踪器中开始讨论 。 也许有人会觉得它有用。

Answer 1

看起来你的问题已经在讨论环节中得到了解答，但是我只是注意到，在Bleacher Report上，我们从来没有把图像推送到没有通过CI的docker集线器（私有或托pipe）。

• 代码推送
• CircleCI创build一个标记的构build
• testing在标签容器中运行
• 如果testing通过了CircleCI推送标签容器到集线器

详细的解释