Docker to Rate Limit镜像拉取

在本博客的第1部分中，我们深入研究了存储在Docker Hub(世界上最大的容器注册中心)中的所有图像。我们这样做是为了让您更好地了解我们新的服务条款更新将如何影响使用Docker Hub管理其容器映像和CI/CD管道的开发团队。

这篇博客文章的第2部分深入探讨了容器图像拉取的速率限制。这也是作为我们更新的Docker服务条款(ToS)通信的一部分宣布的。我们详细介绍了将于2020年11月1日生效的Docker订阅计划的拉动费率限制：

Docker将拉取速率限制定义为对Docker Hub的清单请求数。Docker镜像拉取的速率限制基于请求镜像的用户的账户类型，而不是镜像所有者的账户类型。对于匿名(未经身份验证)用户，拉取率根据单个IP地址进行限制。

我们一直收到客户和社区关于容器图像层的问题。我们不会将图像层计算为拉动率限制的一部分。因为我们限制清单请求，所以此时与拉取相关的层(BLOB请求)的数量是不受限制的。这是一项基于社区反馈的更改，以使用户更加友好，因此用户不需要计算他们可能使用的每个图像上的图层。

在确定为什么需要速率限制以及如何应用这些限制时，我们花了大量时间分析从Docker Hub下载的图像。我们的发现证实，绝大多数Docker用户以正常工作流程预期的速度提取图像。然而，少数匿名用户带来了过大的影响。例如，Hub上大约30%的下载仅来自1%的匿名用户。

新的拉动限制是基于这一分析，这样我们的大多数用户都不会受到影响。这些限制旨在适应开发人员的正常使用情形-学习Docker、开发代码、构建映像等。

既然我们了解了影响和限制应该落在哪里，我们需要在技术层面上定义这些限制应该如何工作。将图像拉取限制到Docker注册表是复杂的。您在注册表规范中找不到Pull API-它不存在。事实上，图像拉取实际上是清单和BLOB API请求的组合，根据客户端状态和相关图像，这些请求以不同的模式完成。

例如，如果您已经拥有该镜像，Docker Engine客户端会发出清单请求，根据返回的清单发现它拥有所有引用的图层，然后停止。另一方面，如果您正在拉取支持多个体系结构的映像，则会发出清单请求，并返回每个支持的体系结构的映像清单列表。然后，Docker引擎将针对其运行的架构发出另一个特定的清单请求，并接收该映像中所有层的列表。最后，它将请求它缺少的每个层(BLOB)。

因此，图像拉取实际上是一个或两个清单请求，而零到无限的BLOB(层)请求。从历史上看，Docker监控的是基于斑点(层)的速率限制。这是因为BLOB与带宽使用关系最密切。然而，我们听取了社区的反馈，认为这很难跟踪，会导致不一致的体验(取决于您拉取的图像有多少层)，不鼓励良好的Dockerfile实践，并且对于那些只想在没有Docker图像和注册表专家的情况下完成工作的用户来说，这是不直观的。

因此，我们正在根据未来的清单请求进行速率限制。这样做的好处是更直接地与拉动相结合，便于用户理解。这里有一个小的权衡-如果你拉一张你已经有的图像，即使你不下载图层，这仍然是计入的。总体而言，我们希望这种速率限制方法既公平又方便。

我们将根据常见的用例随着时间的推移监控和调整这些限制，以确保这些限制适合每一层用户，特别是，我们永远不会阻止开发人员完成工作。

在接下来的几周里，请继续关注一篇关于根据这些变化配置CI和生产系统的博客文章。

最后，作为Docker对开源社区承诺的一部分，我们将在11月1日之前宣布新的开源计划的可用性。要申请开源计划，请在此处填写简短表格。

有关最近服务条款更改的更多信息，请参阅网站常见问题解答。

对于需要更高镜像拉取限制的用户，Docker还提供无限镜像拉取功能，作为Pro和Team计划的一项功能。请访问www.docker.com/ricing查看可用的计划。一如既往，我们欢迎您的问题和反馈，请发送电子邮件至[email protected]。