macOS 容器机器

原文 ↗ Hacker News 讨论 ↗

Apple 的“容器机器”是什么

  • 基于 Apple 的 Containerization / Virtualization 框架；每个容器实际上都是自己的轻量级 Linux VM（micro-VM）。
  • 更接近 WSL2、toolbox/distrobox，或“通过 VM 实现的 LXC”，而不是经典的共享内核容器。
  • 在现有 container CLI 之上增加了持久化和宿主机文件系统挂载。
  • 宿主机挂载使用 virtiofs；默认 Linux 内核来自 Kata Containers。
  • 如果基础镜像包含 init 系统，则支持 systemd 和“真正的 Linux 服务”。

与 Docker/Podman/Colima/OrbStack 的比较

  • 旨在作为 Docker Desktop 单一大 VM 的原生替代方案；按容器划分的 VM 提高了隔离性和隐私性。
  • 仍然需要 Linux VM，因此并没有像一些人希望的那样消除 VM 层。
  • Colima/Podman/Lima 仍然可行，拥有更广泛的生态和 Docker Compose 支持。
  • OrbStack 经常受到称赞：基于 Rust 的自定义虚拟化、动态内存回收、优化的文件系统共享、USB/音频直通、隔离机器。
  • 几位评论者表示他们目前会继续使用 OrbStack/Colima；Apple 的工具感觉集成度较低，功能也没那么丰富。

性能、资源与文件系统行为

  • 内存默认设为宿主机 RAM 的一半，支持 ballooning 扩容但尚不能缩容；稀疏磁盘映像也不容易收缩。
  • 有人担心这会比传统容器更吃 RAM；也有人认为 micro-VM 仍然比完整 VM 轻量。
  • Apple 容器早期版本在包含大量小文件的工作负载（Node/Rust）上文件系统性能较慢；是否已完全解决尚不明确。
  • QEMU 被认为比 Apple 原生虚拟化慢，但 Lima 也可以使用原生框架。

平台支持与限制

  • 针对 Apple Silicon 和 macOS 26（“Tahoe”）进行了优化；在 macOS 15 上可用，但有网络限制，且没有计划进行回移植修复。
  • 底层虚拟化在 Intel 上也存在，但新功能将只面向 Apple Silicon 和更新的 macOS。
  • 仅支持 Linux guest；尽管对 macOS CI 和 “Darwin jails” 的需求很强，但不支持在容器中运行 macOS。
  • 虚拟化栈中的 Rosetta 允许 aarch64 Linux VM 运行 amd64 二进制文件；预计即使 mac 应用的 Rosetta 被移除，Linux 的 Rosetta 仍会保留。

用例与工作流

  • 主要目标：在 macOS 上构建本地 Linux 开发环境——数据库、后台服务、devcontainers 风格的设置。
  • 有人认为它很适合用作不受信任代码和 AI 编程代理的沙箱，是带有 VM 隔离的 sandbox-exec 的精神继任者。
  • 人们询问如何复现多服务 Docker Compose 设置；目前还没有一等公民的 Compose 方案，不过可以在 OCI 组件之上构建工具。
  • 也有人有兴趣把它用于 AOSP 构建、GPU/LLM 工作负载，以及作为像 WSL 那样更“隐形”的 Linux 层；GPU 直通以及除 Rosetta 之外的 x86 故事都还不清楚。

安全性、隔离与 UX 争论

  • 按 VM 划分的容器被认为比共享内核容器隔离更强，但也有人认为容器总体上并不是主要安全边界。
  • 默认自动挂载 $HOME 引发分歧：对大多数开发工作流来说很方便，但对追求严格供应链隔离的人来说并不理想。
  • 有人希望能方便地切换为不挂载宿主机，以及提供更细粒度的隔离选项。

缺失项与反复出现的愿望

  • 没有 Darwin namespaces / macOS 容器；许多人认为这是出于商业上的刻意选择，以保留 Mac 硬件在 CI 和构建集群中的销量。
  • Apple 方面没有提供官方桥接网络、类似 VPNKit/gVisor 的网络栈或 USB 直通；在这些方面第三方工具更领先。
  • 人们希望有更好的文档说明何时选择 Apple 的方案、Docker/Colima/OrbStack，以及对所有选项进行比较的基准测试。