容器映像版本控制的最佳实践

Question

我正在寻找关于容器映像版本控制的最佳实践的一些指导，尽管阅读了一些最佳实践指南，但它们留下了一些模糊性。

我理解大多数容器映像使用稳定的版本控制，当更新框架、包、库等内容时，版本标记将保持不变，但我不清楚这种策略如何确保从映像部署的容器是一致的。

如果我今天构建一个标记设置为v1.0.0的映像，然后下个月更新映像以包括对框架、包、库等的更新，但是应用程序保持不变，那么我对稳定版本控制策略的理解意味着新映像将保持标记设置为v1.0.0。

使用此策略，如何确保一致地部署相同版本的映像？开发人员、测试环境和生产人员都可以相信，他们使用的映像版本与标记仍然设置为v1.0.0相同，但是底层框架、包和库中的更改可能会导致不稳定，这是每个人都不知道的。如果有一个集群运行一个映像的多个容器实例，那么这种情况可能会更糟。

另一个方面是框架、包和库可能位于父映像中，并且应用程序映像本身没有任何变化。

虽然我可以在应用程序映像的标记中以及包含框架、包和库的任何父映像中包含一个版本号，但这似乎是一种巨大的维护开销，因为每当父映像由于父映像标记(例如from parent-image:v1.0.0-build123 )而更新父映像时，我就需要为应用程序映像创建一个新的dockerfile。

是否有更好的策略来解决这个问题，或者仅仅是接受使用相同的稳定版本标记的图像之间会有一些差异呢？目前我不使用Kubernetes，但这是我们将来可能使用的东西，我非常希望选择一种版本控制策略，它将对Kubernetes有效，并确保在部署在节点上的容器实例中不会有来自同一映像版本的“隐藏”差异。

Answer 1

首先，有几个要点：

1. 标签在大多数注册表中都是可变的，所以今天的v1可能与一个月前的v1不同。但是，客户端确实需要再次提取此标记才能看到更新。
2. 多个标记可能指向同一个图像。所以stable和v1可以指向相同的图像。
3. 指向摘要可以确保图像是不可变的，但是您将不会收到更新，如果该图像被取消标记，一些注册中心就可以将其删除，作为垃圾收集的一部分。

尽管如此，最佳实践取决于您打算如何使用图像。对于将来可以重建并接收安全更新的内容，您通常希望依赖一个可变但稳定的标记。当您没有办法用新的图像标记自动更新您的Dockerfile时，这一点尤为重要。但是，如果您控制构建管道的各个端，您可能希望依赖摘要来获得相对可重复的构建，并在基本映像管道完成时自动注入该摘要。

通常，停靠标记中的半标记是通过构建图像创建者有意不更改的持久标记来处理的。因此，当1.0.0在git中发布和标记时，该git标记不会更改，生成的图像是v1.0.0，并且它也不会被更改(通过策略)。有了推送多个标签的能力，同样的构建也会推动v1.0和v1。然后，在git中标记1.0.1时，构建图像v1.0.1，并修改v1.0和v1的标记以指向该新图像。

这种扩展策略允许其他人依赖于他们使用FROM base-image:v1的Dockerfile中所需的版本，这样他们就可以得到一些小的更新、错误修复和安全补丁，而不需要对他们的Dockerfile进行任何修改，他们只需要定期地重建和提取更新的基本映像。

当上游发生重大变化时，他们会在git中释放2.0.0，标记他们的图像v2.0.0、v2.0和v2。任何依赖于v1的人在更新他们的Dockerfile以使用新的主要版本之前，都不会受到这种急剧变化的影响。

Answer 2

确保部署一致映像的最稳定方法是使用摘要而不是标记。消化就像容器映像的git。这保证了，如果有人上传了一个新的图像，并使用现有的版本标记，不管是偶然的还是恶意的，您将继续拉出已知的好图像。缺点是摘要不方便用户使用。