Docker push需要很长时间

Question

我有一个使用Docker的部署设置，其工作方式如下：

1. 通过Dockerfile在我的开发机器上构建映像
2. 将映像推送到注册表（我尝试了Docker Hub和Quay.io）
3. 将此映像拉到部署服务器，然后重新启动容器。

我想尽快执行这些步骤，但是它们花费了非常长的时间。即使对于中等大小的映像（750MiB，包括标准ubuntu和朋友），在进行少量修改后，部署也需要17分钟。我优化了项目的顺序Dockerfile，因此实际上大部分时间都可以访问缓存的图像。这似乎没有什么不同。

罪魁祸首是docker push步骤。对于Docker Hub和Quay.io而言，推送图像都花费了不切实际的长时间。在一个简单的基准测试中，我连续执行了docker push两次，因此所有先前的映像都已经在注册表中。所以我只看到这些行：

...
bf84c1d841244f: Image already pushed, skipping
...

但是，如果我按时完成，性能会令人恐怖。当所有图像都已经在服务器上时，推送到Quay.io将需要3.5分钟！推送到Docker Hub大约需要12分钟！

显然有些地方出了问题，因为许多人在生产中使用Docker，所以这些时间与持续交付完全相反。

我怎样才能使运行更快？别人也看到这种表演吗？它与注册表服务有关，还是与本地计算机有关？

我在Mac OS X下使用Docker。

Answer 1

请注意：我运行自己的 docker 注册表，该注册表位于我发出“docker Push”命令的机器本地，但仍然需要大量时间。这绝对不是磁盘的 I/O 速率问题，因为它们由 SSD 支持（澄清一下，对于使用它们的任何其他设备来说，它们的性能约为 500+MB/秒）。但是，docker Push 命令似乎需要与我将其发送到远程站点一样长的时间。我认为还有一些超出“带宽”问题的问题正在发生。我怀疑，无论我的注册表是本地的，它仍然尝试使用 NIC 来传输数据（这似乎是有道理的，因为需要 URI 作为推送目的地，而注册表本身就是一个容器）。

话虽这么说，我可以将相同的文件复制到它们最终驻留在本地注册表中的位置，速度比推送命令快几个数量级。也许解决方案就是这样。然而，明确的一件事是，问题不在于带宽本身，而在于一般的数据路径。

无论如何，运行本地注册表不太可能（完全）解决OP的问题。当我刚刚开始调查时，我怀疑需要对 docker 进行代码更改才能解决此问题。我不认为这是一个错误，而是一个设计挑战。URI 和/或主机<->主机通信需要网络堆栈，即使源和目标是同一台机器/主机/容器也是如此。

Answer 2

因此，组织通常在本地网络上运行自己的注册表。这也使组织能够控制自己的数据并避免依赖外部服务。

您还会发现，Google Container Engine 和 Amazon Container Service 等云主机提供托管注册表，为用户提供快速的本地下载。