Docker:为环境标记图像时的最佳做法是什么

Question

我有多个环境.它们是debug,dev和prod.我想通过最新的dev(最新)或dev(1.1版)或prod(最新版)来引用图像.我将如何标记构建和推送？

我的第一个想法是为每个环境debug,dev和prod创建单独的存储库.但我开始怀疑我是否可以只用一个存储库来做到这一点.如果它可能与一个容器有关,那么构建和推送时的语法是什么？

Answer 1

这对我和我的团队最有效,我推荐它:

我建议在所有环境中为每个项目设置一个repo,它更易于管理.特别是如果你有微服务,那么你的项目由多个微服务组成.每个项目每个env管理一个repo是一件痛苦的事.

例如,我有一个用户api.码头回购是users.这个回购用于alpha,dev和beta.

我们创建一个$DOCKER_TAG在我们的CI/CD服务中调用的env变量,并在创建构建时设置它,如下所示:

DOCKER_TAG: $(date +%Y%m%d).$BUILD_NUMBER =>这是在bash中.

凡$BUILD_NUMBER事先由编译正在运行时设置的CI/CD运行被触发.例如,当我们合并PR时,会触发构建,因为构建号.1,所以$BUILD_NUMBER: 1.

生成的标签在使用时看起来像这样:20171612.1 所以我们的docker镜像是:users:20171612.1

为什么这种格式？

• 它允许我们使用运行任务在不同环境中部署相同的标记.
• 它可以帮助我们跟踪创建图像的时间以及它所属的构建.
• 通过构建号,我们可以根据需要找到提交信息并将它们映射在一起,非常适合于故障排除.
• 它允许我们为每个项目使用相同的docker repo.
• 很高兴知道我们何时从标签本身创建了图像.

因此,当我们合并时,我们创建一个单独的构建.然后根据需要将该构建部署到不同的环境.我们不为每个环境创建独立的构建.我们会跟踪在哪里部署的内容.

如果在具有特定标记的环境中存在错误,我们会在此条件下提取此类标记,构建和解决问题并重现问题.如果我们发现问题,我们在标签中有内置编号,20171612.1因此我们知道构建编号.1有问题.我们检查我们的CI/CD服务,它告诉我们最新的提交.我们从git和debug中查看提交哈希并修复问题.然后我们将其部署为修补程序,例如.

如果您还没有CI/CD,并且您手动执行此操作,只需手动设置该格式的标记(几乎按原样键入完整字符串)而不是生成编号,请使用commit short git hash (如果你使用的是git):

20170612.ed73d4f

因此,您知道什么是最新的提交,以便您可以解决特定图像的问题,并映射回代码以根据需要创建修复.

您还可以为映射到代码版本的标记定义任何其他后缀,以便您可以轻松进行故障排除(例如,如果您使用git标记,则映射到git标记).

尝试一下,根据需要进行调整,并为您和您的团队做最好的事情.有很多方法可以解决标记问题.我们尝试了很多,到目前为止这是我们的最爱.

希望这有帮助.

Answer 2

有两种思想流派，稳定标记（更新单个标记）和唯一标记。各有优缺点。部署到自我修复集群时，稳定标签可能会造成不稳定，因为新节点可能会拉取新版本，而集群的其余部分正在运行稍旧的版本。唯一标记是部署的最佳实践。但是，要管理操作系统和框架修补的基本映像更新，您需要在 dockerfile 中的稳定标签上进行构建，并启用自动容器构建。有关视觉效果的更详细的演练，这里有一个帖子：https : //blogs.msdn.microsoft.com/stevelasker/2018/03/01/docker-tagging-best-practices-for-tagging-and-versioning-码头工人图像/