ECS是否使用Docker层缓存来加速部署？

Question

想象一个典型的ECS场景：

1. 我部署使用MYIMAGE:1的任务定义1。
2. 稍后，我部署了使用MYIMAGE:2的任务定义2。

第二个部署与第一个EC2主机相同。因此，从理论上讲，ECS在从容器注册表中提取MYIMAGE:2时可以使用Docker层缓存(这可能会导致更快的拉出)。

但它是否在实践中使用过呢？有什么方法可以启用它吗？文件似乎没有提到这一点。

Answer 1

ecs-代理是否使用标准的码头拉力行为？

由于这个问题在上面的评论中得到了改进，我试图回答ecs-代理是否使用标准的码头拉力机制。

• 我们从AWS文档中了解到，配置参数称为ECS_IMAGE_PULL_BEHAVIOR。1
• AWS ECS使用实例上的ecs代理来管理容器.因为这个工具是开源的，所以我们必须做这个工作，并寻找能够提取图像的代码。它托管在GitHub上。2
• 如果我们搜索引入拉行为开关的PR，我们会发现以下内容：#1840。
• 从这里开始，我们看到发动机是起点。然后调用客户端，然后使用去码头项目发送创建请求。
• 我们可以从码头引擎API中看到这是一个标准的图像拉力。

结论

您可以自定义ECS码头拉行为，方法是告诉ecs代理何时应该发出拉请求，以及是否应该启用自动图像清理。当ecs试图从容器注册表中提取图像时，它使用标准的停靠程序"create“请求3。

最后，对接引擎请求从坞守护进程中提取标准图像。4.

如果您将ecs环境变量ECS_IMAGE_PULL_BEHAVIOR设置为首选缓存，MYIMAGE:1将在第一次使用时被完全提取。随后，同一个EC2实例执行一个坞拉检索MYIMAGE:2。

我试图弄清楚停靠守护进程中的PullImage是如何在引擎盖下工作的，但是我找不到任何有用的信息。我想它会对在MYIMAGE:1和MYIMAGE:2之间更改的层进行增量更新(如果MYIMAGE:1仍然可用--这需要自动图像清理才能关闭)，但我不能完全确认它.

码头商常见问题5说明如下：

版本控制。..。Docker还实现了增量上传和下载，类似于git拉，因此新版本的容器只能通过发送差异来传输。

参考文献

1

2

3.

4.

5

Answer 2

ecs在MYIMAGE上发出停靠拉命令:1.如果您的MYIMAGE:2具有相同的MYIMAGE:1层，那么对接者将使用本地可用的图像层，而只在MYIMAGE:2上只拉对接者拉动元数据，而不是实际层。

详细的医生。https://docs.docker.com/engine/reference/commandline/pull/