Docker Cloud Sandboxes Provide a Consistent Sandbox Abstraction Across Laptop and Cloud

Docker Cloud Sandboxes：在笔记本和云端之间提供一致的沙箱抽象

作者：Sergio De Simone · InfoQ 原文

摘要：Docker Cloud Sandboxes 是基于硬件强制微VM隔离的安全托管执行环境，允许AI编码代理在Docker基础设施上运行。它提供一致的执行环境和统一的CLI工作流，支持在本地和云端之间无缝迁移工作负载。开发者可通过一条命令将沙箱从本地移至云端，实现并行运行多个长时间任务。同时，Docker发布了基于OCI镜像的Kits规范，简化沙箱配置。评论指出沙箱化仅解决部分问题，代理仍需访问外部服务，可能带来安全风险。

Docker Cloud Sandboxes provide secure, hosted execution environments for running AI coding agents on Docker-managed infrastructure.

Docker Cloud Sandboxes 提供安全、托管的执行环境，用于在 Docker 管理的基础设施上运行 AI 编码代理。

Built on hardware-enforced microVM isolation, the platform provides a consistent execution environment and unified CLI workflows for seamlessly moving workloads from local machines to the cloud.

该平台基于硬件强制微VM隔离构建，提供一致的执行环境和统一的CLI工作流，支持将工作负载从本地机器无缝迁移到云端。

Docker Cloud Sandboxes are an evolution of Docker Sandboxes, which Docker introduced earlier this year to provide local microVM environments where coding agents could operate autonomously and safely.

Docker Cloud Sandboxes 是 Docker Sandboxes 的演进版本，后者于今年早些时候推出，旨在提供本地微VM环境，使编码代理能够自主、安全地运行。

However, developers are increasingly running multiple long-horizon tasks in parallel, says Docker, creating a need for persistent, scalable execution environments beyond the local machine.

然而，Docker 表示，开发者越来越多地并行运行多个长期任务，这产生了对本地机器之外持久、可扩展执行环境的需求。

When agents worked in short bursts, the question was whether the model could hold a task together.

当代理以短突发方式工作时，问题在于模型能否将任务整合在一起。

Now that they work in hours, the question is where those hours happen.

现在它们以小时为单位工作，问题在于这些小时发生在哪里。

A laptop is built around a person.

笔记本电脑是围绕人设计的。

It sleeps when the lid closes, slows down on battery, and disconnects when you move.

合上盖子时会休眠，使用电池时会降速，移动时会断开连接。

With Cloud Sandboxes developers can move a sandbox between local and cloud execution with one command, making it possible to "run a dozen agents at once, for five, ten, or 21 hours each, without watching any of them".

借助 Cloud Sandboxes，开发者可以通过一条命令在本地和云端执行之间移动沙箱，从而能够“一次运行十几个代理，每个运行五、十或二十一小时，无需监控任何一个”。

Cloud Sandboxes use the same isolation model as local Docker Sandboxes and are managed through the same CLI.

Cloud Sandboxes 使用与本地 Docker Sandboxes 相同的隔离模型，并通过相同的 CLI 进行管理。

This enables developers to start a task locally and then move it to the cloud when it requires additional resource, or hand off a task to the cloud before leaving for the day.

这使得开发者可以在本地启动任务，然后在需要额外资源时将其移至云端，或者在离开前将任务交给云端处理。

Another key use case is parallelizing workloads across dozens of tasks, with each task running in its own isolated cloud sandbox.

另一个关键用例是将工作负载并行化到数十个任务中，每个任务都在其自己的隔离云沙箱中运行。

To move a sandbox from your local machine to Docker infrastructure or vice versa, you run:

要将沙箱从本地机器移动到 Docker 基础设施，反之亦然，请运行：

$ sbx move my-project --to cloud

This command "captures the sandbox's filesystem and recreates it on the other side, so your work carries over".

该命令“捕获沙箱的文件系统并在另一端重新创建，因此你的工作会延续”。

Alongside Cloud Sandboxes, Docker is also releasing several kits, which are pre-configured, pre-built sandboxes defined according to the Docker Sandbox Kit Specification.

除了 Cloud Sandboxes，Docker 还发布了多个 kits，这些是根据 Docker Sandbox Kit 规范定义的预配置、预构建沙箱。

In the latest Kits v3 specification, Kits are no longer treated as a separate artifact but are instead packaged as standard OCI images.

在最新的 Kits v3 规范中，Kits 不再被视为独立工件，而是打包为标准 OCI 镜像。

This allows them to be used just like any other Docker image, including with build and pull, and to serve as a base for building more complex Kits.

这使得它们可以像任何其他 Docker 镜像一样使用，包括构建和拉取，并作为构建更复杂 Kits 的基础。

Commenting on the announcement, Deutsche Bank lead devops engineer Florin Lungu said he finds "it interesting that this innovation allows for safe, autonomous coding in microVM environments, enhancing flexibility in our workflows".

德意志银行首席 DevOps 工程师 Florin Lungu 在评论该公告时表示，他觉得“这项创新允许在微VM环境中进行安全、自主的编码，增强了我们工作流程的灵活性，这很有趣”。

However, Reddit user CircumspectCapybara pointed out that sandboxing addresses only part of the issue: "any remotely useful agent workload is going to need to connect their sandboxed agents to limited external services" to access "tools it would realistically call in real life, real libraries or artifacts and stuff it might try to pull down from PyPI or Docker Hub or Hugging Face".

然而，Reddit 用户 CircumspectCapybara 指出，沙箱化仅解决了部分问题：“任何稍微有用的代理工作负载都需要将其沙箱化代理连接到有限的外部服务”，以访问“它在现实生活中实际会调用的工具、真实的库或工件，以及它可能尝试从 PyPI、Docker Hub 或 Hugging Face 拉取的东西”。

This creates a potential attack surface even when the agent remains contained within the sandbox: "they can just talk to the narrow set of services they have been given access to and by talking to them break them while remaining inside the sandbox".

即使代理仍被限制在沙箱内，这也创造了潜在的攻击面：“它们可以只与已被授予访问权限的狭窄服务集通信，并通过与它们通信来破坏它们，同时仍留在沙箱内”。

As a final note, Hacker News reader ongedierte echoed this concern arguing that "traditional sandboxes are not going to be the correct abstraction" and that "building harnesses based on object capabilities and being able to limit exactly what an agent can access in what manner will be the way forward".

最后，Hacker News 读者 ongedierte 呼应了这一担忧，认为“传统的沙箱不是正确的抽象”，并且“基于对象能力构建约束，并能够精确限制代理以何种方式访问什么内容，将是未来的方向”。

阅读理解

1. What is the primary advantage of Docker Cloud Sandboxes over local Docker Sandboxes according to the article?

2. What concern did Reddit user CircumspectCapybara raise about sandboxed agents?

3. According to the article, how are Kits defined in the latest Kits v3 specification?

温故复习 →每日一句 →