jenkins – 用于持续集成/持续部署的Docker镜像版本控制

前端之家收集整理的这篇文章主要介绍了jenkins – 用于持续集成/持续部署的Docker镜像版本控制前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

我们使用两个众所周知的概念实现我们的持续集成和持续交付流程:Linux二进制包和Docker镜像.

大部分工作已经完成:我们从GitLab repo获取代码,编译它并放入存储在Aptly中的deb软件包,然后我们为我们拥有的每个服务创建Docker镜像并将图像推送到私有Docker Registry服务器.然后将这些图像滚动到测试环境.最后,我们启动服务并执行验收测试.这是一个连续的过程,每当有人将提交推送到origin / master时,它就会启动.

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

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

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

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

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

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

最佳答案
看起来您的问题已在该讨论链接中得到解答但是我只是注意到在Bleacher Report中我们从未将图像推送到未首先通过CI的docker hub(私有或托管).

>代码推了
> CircleCI创建标记的构建
>测试在标记容器内运行
>如果测试通过,CircleCI将标记的容器推送到集线器

Detailed explanation

猜你在找的Docker相关文章