加入收藏 | 设为首页 | 会员中心 | 我要投稿 李大同 (https://www.lidatong.com.cn/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 综合聚焦 > 服务器 > 安全 > 正文

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

发布时间:2020-12-16 03:51:48 所属栏目:安全 来源:网络整理
导读:我们使用两个众所周知的概念实现我们的持续集成和持续交付流程:Linux二进制包和Docker镜像. 大部分工作已经完成:我们从GitLab repo获取代码,编译它并放入存储在Aptly中的deb软件包,然后我们为我们拥有的每个服务创建Docker镜像并将图像推送到私有Docker Re

我们使用两个众所周知的概念实现我们的持续集成和持续交付流程: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

(编辑:李大同)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    推荐文章
      热点阅读