Docker Cloud Sandboxes:跨笔记本与云的一致沙箱抽象
DataHot 速览
Docker 推出 Cloud Sandboxes,为在 Docker 托管基础设施上运行 AI 编码代理提供安全、托管的执行环境。该平台基于硬件强制的 microVM 隔离,提供一致的执行环境与统一 CLI 工作流,可用 sbx move 命令在本地与云端之间迁移沙箱。它是此前本地版 Docker Sandboxes 的演进,应对开发者并行运行多个长时程代理任务的需求;Kits v3 规范则将预配置沙箱打包为标准 OCI 镜像。
为什么值得关注:内容围绕 AI 编码代理的沙箱执行环境与开发者工作流,属于 AI 开发基础设施话题,未直接涉及数据平台、BI 或数据分析场景,故不推荐给数据从业者。
译文
AI 逐段翻译Docker Cloud Sandboxes 提供安全、托管的执行环境,用于在 Docker 管理的基础设施上运行 AI 编码代理。该平台基于硬件强制的 microVM 隔离构建,提供一致的执行环境和统一的 CLI 工作流,可将工作负载从本地机器无缝迁移到云端。
Docker Cloud Sandboxes 是 Docker Sandboxes 的演进,Docker 在今年早些时候推出了后者,以提供本地 microVM 环境,让编码代理能够自主且安全地运行。然而,Docker 表示,开发者越来越多地并行运行多个长时程任务,这产生了对本地机器之外的持久、可扩展执行环境的需求。
当代理以短时间突发方式工作时,问题是模型能否保持任务连贯。如今它们以小时为单位工作,问题就变成了这些小时在哪里发生。笔记本电脑是围绕一个人构建的。合上盖子它就休眠,使用电池时会降速,你移动时它会断开连接。
借助 Cloud Sandboxes,开发者只需一条命令即可在本地和云端执行之间移动沙箱,从而能够“一次运行十几个代理,每个运行五、十或 21 小时,而无需照看任何一个”。Cloud Sandboxes 使用与本地 Docker Sandboxes 相同的隔离模型,并通过相同的 CLI 进行管理。这使开发者能够在本地启动任务,然后在需要额外资源时将其迁移到云端,或者在当天离开前将任务移交给云端。另一个关键用例是将工作负载并行化到数十个任务上,每个任务都在自己的隔离云沙箱中运行。
要将沙箱从本地机器移动到 Docker 基础设施,或反之,你可以运行:
$ sbx move my-project --to cloud
该命令“捕获沙箱的文件系统并在另一端重新创建它,因此你的工作会随之延续”。
除了 Cloud Sandboxes,Docker 还发布了若干套件(kits),这些套件是根据 Docker Sandbox Kit Specification 定义的预配置、预构建沙箱。在最新的 Kits v3 规范中,Kits 不再被视为单独的工件,而是打包为标准 OCI 镜像。这使它们可以像任何其他 Docker 镜像一样使用,包括用于 build 和 pull,并可作为构建更复杂 Kits 的基础。
在评论这一公告时,Deutsche Bank 首席 DevOps 工程师 Florin Lungu 表示,他认为“有趣的是,这项创新允许在 microVM 环境中进行安全、自主的编码,从而增强了我们工作流的灵活性”。
然而,Reddit 用户 CircumspectCapybara 指出,沙箱化只解决了问题的一部分:“任何真正有用的代理工作负载都需要将其沙箱化代理连接到有限的外部服务”,以访问“它在现实生活中会实际调用的工具、真实库或工件,以及它可能尝试从 PyPI、Docker Hub 或 Hugging Face 拉取的东西”。即使代理仍被限制在沙箱内,这也会产生潜在的攻击面:“它们可以只与其被授予访问权限的有限服务通信,并通过与这些服务通信来破坏它们,同时仍留在沙箱内”。
最后,Hacker News 读者 ongedierte 呼应了这一担忧,认为“传统沙箱不会是正确的抽象”,并且“基于对象能力构建 harness,并能够精确限制代理可以以何种方式访问什么,将是未来的方向”。
这篇内容对你有用吗?
反馈只用于改善内容筛选,不等同于收藏