Docker 镜像会改变吗？如何确保他们不这样做？

Question

Docker 的主要优点之一是可重复性。例如，我们可以准确指定哪些程序和库的安装方式和位置。

然而，我正在努力思考这个问题，但无法全神贯注。我对可重复性的理解是，如果您请求某个标签，您每次都会收到具有相同内容的相同图像。然而，这有两个问题：

• 即使我尝试尽可能彻底地指定一个版本，例如python:3.8.3，我似乎也无法保证它指向静态的不变图像？可以随时推送新版本。
• python:3.8.3python:3.8.3-buster是其所基于的 Debian Buster OS 映像的同义词。因此，即使 Python 没有改变，底层操作系统的某些包也可能会发生变化，这是正确的吗？我查看了官方 Dockerfile，它没有指定 Debian Buster 的特定版本或构建。

Answer 1

如果您依赖外部 docker 镜像，那么您的 Docker 镜像确实无法保证可重复性。解决方案是将 Python:3.8.3 镜像导入到您自己的 Docker 注册表中，理想情况下是一个可以防止覆盖标签（不变性）的 docker 注册表，例如Harbor。

但是，如果您的 Docker 映像比您导入的基础映像更难，那么可重复性就更难了。例如，如果您安装了一些 pip 软件包，并且其中一个 pip 软件包没有固定它们所依赖的软件包的版本，您仍然无法保证重建 Docker 映像会生成相同的映像。将这些 python 包托管在您自己的 pip 工件中也是这里的解决方案。

Answer 2

解决您的个人问题。

• 即使我尝试尽可能彻底地指定版本，例如 python:3.8.3，我似乎也无法保证它指向静态不变的图像？可以随时推送新版本。

我在对你的问题的评论中发布了这一点，但也在这里解决了它。大型包使用语义版本控制。为了使信任发挥作用，必须建立信任。这种版本控制方法为其他（有时是任意的）系统引入了信任和一致性。

我们相信，当他们上传时3.8.3，它将在未来尽可能保持不变。如果他们添加了另一个补丁，他们会上传3.8.4，如果他们添加了一个功能，他们会上传3.9.0，如果他们破坏了一个功能，他们会创建4.0.0。这可以确保您（用户）3.8.3无论何时何地都是一样的。

框架和操作系统经常向后移植补丁。PHP 以此而闻名。如果他们在 v7 中发现 v5 中存在的安全漏洞，他们将更新所有存在该漏洞的 v5 版本。虽然所有 v5 版本均从其原始发布版本更新，但功能保持不变。这很重要，这就是信任。

因此，除非您“利用”该安全漏洞来完成您需要做的事情，或者依赖于错误，否则您应该确信3.8.3应该始终使用 DockerHub。

NodeJS 就是一个很好的例子。他们将所有旧的已弃用版本保留在 Docker Hub 中以供存档。

我一直latest在我的所有工作和家庭项目中使用 Docker Hub 中的命名标签（NOT ），并且在部署后我从未遇到过因为“在我脚下”发生变化而导致项目崩溃的问题。事实上，就在上周，我在旧版本的 NodeJS（4 年前）上重建并更新了一些代码，这需要重新拉取，并且因为它是一个命名版本（而不是latest），所以它完全按照预期工作。

• python:3.8.3 是 python:3.8.3-buster 的同义词，指的是它所基于的 Debian Buster OS 映像。因此，即使 Python 没有改变，底层操作系统的某些包也可能会发生变化，这是正确的吗？我查看了官方 Dockerfile，它没有指定 Debian Buster 的特定版本或构建。

一旦子图像（python）是根据父图像（buster）构建的，它就是不可变的。例外情况是，如果子映像 (python) 是在以后重建的，并且选择使用父映像 (buster) 的不同版本。但这被认为是不好的、偷偷摸摸的并且破坏了容器的目的。我不知道有什么主要的软件包可以做到这一点。

这就像git push --force在更改一些提交后在存储库上执行 a 操作。这是非常糟糕的做法。

该系统是在信任的基础上设计和构建的，为了让它被使用、采用和发展，信任必须保持。请务必检查您要使用的任何容器的旧标签，并确保它们允许旧的已弃用标签继续存在。

因此，当您python:3.8.3今天或两年后下载时，它的功能应该完全相同。

例如，如果您docker pull python:2.7.8，然后docker inspect python:2.7.8您会发现它与 5 年前创建的容器相同。

        "Created": "2014-11-26T22:30:48.061850283Z",