我们使用两个众所周知的概念实现我们的持续集成和持续交付流程：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.可能有人会发现它也很有用.
>代码推了
> CircleCI创建标记的构建
>测试在标记容器内运行
>如果测试通过,CircleCI将标记的容器推送到集线器
原文地址：https://www.jb51.cc/docker/436632.html
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
