Docker标签版本控制的最佳做法是什么？

11

我最近将我们的CI服务器挂接到git commit上，以构建docker映像。

我们构建了大约8个不同的容器，每个容器都有自己的语言/框架。一些是节点并具有package.json，其他一些是不包含语义版本信息的python服务。

我的问题不是关于如何创建标签，而是关于创建标签的值。

如何确保每个标签对特定图像都有唯一的语义版本号？谁应该是跟踪/增加构建版本的权威？

docker continuous-integration versioning

— 杰克·墨菲
source

您当前创建标签的方法是什么？

— 030

听到看到你在问什么。您说的是“语义版本号”，它必须是人工分配的（我们的AI不够先进，无法确定提交的语义...）。但是随后您询问“增加构建版本”。那么，您实际上对什么感兴趣？您要确保东西只是“增加”（例如SCN /系统更改号或其他）吗？还是您对版本号的语义内容（即，版本是否具有不兼容的更改）感兴趣？

— AnoE

6

我会将您定向到我的帖子耦合 Docker 注册表和源代码管理，其中dmaze从官方forums.docker.com回答。提交哈希和分支名称或标签就足够了。

在您的Dockerfile中，使用LABEL记录构建的源。这可能包括来自分布式源代码管理（git，Mercurial）的提交哈希，分支名称（如果相关），任何发布标签（如果存在）以及可能的详细信息，例如最后一次提交的时间戳。码头工人历史记录和码头工人检查应该能够显示这些。

当您docker推送您的图像时，将它们至少推送两次，使用提交哈希并将分支名称作为“版本”部分（quay.io/mycorp/imagename:123abc7、quay.io/mycorp/imagename:dmaze-test））。如果可以使用发布标签，则CI系统也应使用这些标签推送图像。

我们目前正在使用分支名称/提交哈希的组合。对我们来说，这似乎足够了。时间戳虽然有用，但IMO只会增加混乱，因为它们不提供提交哈希不能提供的任何内容。

我同意030关于以下方面的意见：

谁应该是跟踪/增加构建版本的权威

CI负责100％负责维护此类事情，并在其他团队之间进行适当的沟通。

— 斯科特
source

1

如何确保每个标签对特定图像都有唯一的语义版本号？

可以创建一个由多个元素组成的标签，例如时间戳，git commit哈希和语义版本的组合。后者必须手动设置，而前两个可以自动设置。这样的标签如下所示：

20171015141729-58617f500f7efe236c7ba6a1dfdf37a478b4c878-0.1.4

该标签包含生成日期，提交和语义版本。如果一个docker映像正在生产中运行并且发现了一个bug，那么人们就会知道该产品的版本，内部代码，生成该映像的时间以及在什么情况下。

谁应该是跟踪/增加构建版本的权威？

我认为这应该是CI的责任，因为它能够自动执行流程，并且可以自动创建标签，因此这种工具是完成工作的正确工具。

— 030
source

1

我想您使用像Jenkins这样的CI / CD的DevOps工具之一，我建议采用以下方法，

如果您使用类似詹金斯的东西，

您可以对作业进行配置，以便可以使用Jenkins环境变量“ BUILD_ID”，当触发该作业将其标记到图像时，该变量将检索该作业的构建ID。这样，您可以对Docker映像进行版本控制。请检查以下示例。

例如：- sudo docker build -t <image_name>:<BUILD_ID>

因此，如果您的SCM具有类似标签的机制，则可以在基于作业的版本中或在JENKINS HOME_FOLDER中的版本ID的config.xml中检查相应版本ID中的标签。

— 特兹
source