【发布时间】：2016-12-12 11:35:43
【问题描述】：
在推送上构建 Docker 映像的人 - 随着时间的推移，您如何管理不同的版本？
- 他们都有自己的标签吗？您是否根据 git 哈希进行标记？
- 您是否会在一段时间后删除旧图像？它们不是每个都占用大量空间 (1GB+) 吗？
【问题讨论】：
标签： docker
【发布时间】：2016-12-12 11:35:43
【问题描述】：
随着时间的推移，您如何管理不同的版本？
首先要注意的是标签不能随着时间的推移而被信任。它们不能保证引用相同的东西或继续存在，因此请使用 Dockerfile LABEL，它将保持一致并始终与图像一起存储。 label-schema.org 是一个很好的起点。
他们都有自己的标签吗？你是否根据 git hash 进行标记？
如果您需要一些独特的东西来引用每个构建，只需使用图像 sha256 sum。如果您想将额外的构建元数据附加到图像，请使用前面提到的 LABEL 并包含 git 哈希和您想要的任何版本控制系统。如果使用 sha256 sum 听起来很难，那么仍然需要标签来引用多个图像版本，因此您将需要一些系统。
Git 标签、日期时间、内部版本号都可以工作。每个都有其优点和缺点，具体取决于您的环境以及您试图将其结合为“发布”的内容。值得注意的是，Docker 镜像可能来自带有 git 哈希的 Dockerfile，但如果您在其他地方获取镜像 FROM，则从该 git 哈希构建的镜像将不会随着时间的推移产生一致的镜像。
一段时间后你会删除旧图像吗？
保留完全取决于您的软件/系统/公司要求或政策。我见过审计要求很高的环境，这会增加构建/发布保留时间，直至“我想在此构建上重新运行这些测试”级别。其他环境的审核很少，这往往会降低保留要求。有些地方甚至根本不尝试实施任何发布管理（这很糟糕）。对于您的特定环境，这里的某个人无法真正回答这个问题，尽管有最低要求，但坚持下去是个好主意。
基本要求是为每个存储的生产版本存储一个人工制品。出于历史目的，这通常是“永远的”。积极回顾一两个以上的版本是非常罕见的（同样这可能取决于您的应用程序），因此归档是一个好主意，并且很容易使用廉价存储/托管上的第二个注册表来完成，该注册表会推送所有内容的副本（即不在您珍贵的 ssd 上）。
我从未见过随着时间的推移保留所有开发版本的要求。保留通常遵循您的开发/发布周期。您很少需要访问当前版本 + 下一个版本的开发版本。只要记住标签+标签开发适当地构建所以清理很简单。 -dev -snapshot -alpha.0 随便。
它们不是每个都占用大量空间 (1GB+) 吗？
It's normally less than you think 但是是的，它们可以很大，因为在您的应用程序之上您有一个操作系统映像。这就是为什么很多人以alpine 开头的原因，因为它与大多数发行版相比很小，只要你没有与musl libc 不兼容的东西。
【讨论】：