docker - 随着时间的推移管理Docker镜像

Question

正在推推式构建Docker镜像的人们-随着时间的推移，您如何管理不同版本？

他们都有自己的标签吗？您是否根据git hash进行标记？

一段时间后您会删除旧图像吗？他们每个人都不会占用很多空间(超过1GB)吗？

Answer 1

how do you manage the different versions over time?

首先要注意的是，随着时间的推移，标签不能被信任。不保证它们引用相同的东西或继续存在，因此请使用Dockerfile LABEL，它们将保持一致并始终与镜像一起存储。 label-schema.org是一个很好的起点。

Do they all get their own tag? Do you tag based on the git hash?

如果您需要独特的东西来引用每个版本，只需使用图像sha256 sum。如果要将附加的构建元数据附加到镜像，请使用前面提到的 LABEL并包括git哈希和所需的任何版本控制系统。如果使用sha256 sum听起来很难，则仍需要标记来引用多个图像版本，因此您将需要一些系统。

Git标签，日期时间，内部版本号都可以使用。每个人都有自己的优点和缺点，这取决于您的环境以及您作为“发行版”试图结合的东西。值得注意的是，Docker镜像可能来自带有git哈希值的Dockerfile，但是如果您在其他地方提供 FROM图像，则从该git哈希值进行构建将无法生成一致的镜像。

Do you delete old images after some time?

保留时间完全取决于您的软件/系统/公司的要求或政策。我已经看到审计需求很高的环境，这会增加构建/发行版的保留时间，降低到“我想在此构建上重新运行这些测试”级别。其他环境的审计很少，这往往会降低保留要求。有些地方甚至根本不尝试实现任何发布管理(这很糟糕)。对于您所处的特定环境，这里的人真的不能回答这个问题，尽管有一些最低限度的建议，但必须遵循。

基本要求是每个已存储的生产版本都有人工制品。通常出于历史目的，这是“永远的”。主动回头查看一两个或多个发行版的情况很少见(同样，这可能取决于您的应用程序)，因此存档是个好主意，并且可以通过廉价存储/主机上的第二个注册表轻松实现，该注册表可以推送所有内容的副本(即而不是您宝贵的ssd)。

我从未见过要保持所有开发版本随时间推移的要求。保留通常遵循您的开发/发布周期。您很少需要从当前版本+下一个版本中访问开发版本。只需记住对LABEL + tag dev进行适当构建即可，因此清理很简单。 -dev -snapshot -alpha.0随便。

Don't they take up a lot of space (1GB+) each?

It's normally less than you think，但是它们可以很大，因为在您的应用程序顶部您有一个OS镜像。这就是为什么很多人开始使用 alpine的原因，因为与大多数发行版相比它很小，只要您没有与 musl libc不兼容的东西。