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

Question

我有多个环境。它们是调试、开发和产品。我想引用最新的 dev(最新)或 dev(1.1 版)或 prod(最新)的图像。我将如何标记构建和推送？

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

Answer 1

这是对我和我的团队最有效的方法，我推荐它:

我建议在所有环境中为每个项目创建一个存储库，这样更易​​于管理。特别是如果你有微服务，那么你的项目是由多个微服务组成的。为每个项目的每个环境管理一个 repo 很痛苦。

例如，我有一个用户 api。docker repo 是 users。 alpha、dev 和 beta 使用这个 repo。

我们在 CI/CD 服务中创建一个名为 $DOCKER_TAG 的环境变量，并在创建构建时设置它，如下所示:

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

其中 $BUILD_NUMBER 先前由触发 CI/CD 运行时正在运行的build设置。例如，当我们合并一个 PR 时，会触发一个构建，作为构建号。 1，所以 $BUILD_NUMBER: 1。

使用时生成的标签如下所示:20171612.1所以我们的docker镜像是:users:20171612.1

为什么是这种格式？

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

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

如果在具有特定标签的环境中存在错误，我们会提取此类标签，构建并排除故障并在该条件下重现问题。如果我们发现问题，我们在标签 20171612.1 中有内部版本号，因此我们知道内部版本号。 1有问题。我们检查我们的 CI/CD 服务，它告诉我们什么提交是最新的。我们从 git 检查提交哈希并调试并修复问题。例如，然后我们将其部署为修补程序。

如果您还没有 CI/CD，并且您正在手动执行此操作，只需手动设置该格式的标签(几乎可以按原样输入完整的字符串)，而不是构建号，使用提交简短的 git 哈希(如果您使用的是 git):

20170612.ed73d4f

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

您还可以为您的标记定义映射到代码版本的任何其他后缀，以便您轻松排除故障(例如，如果您正在使用这些标记，则映射到 git 标签)。

尝试一下，根据需要进行调整，然后做最适合您和您的团队的事情。有很多方法可以绕过标记。我们尝试了很多，到目前为止，这是我们最喜欢的一个。

希望对您有所帮助。