Meet Containerization
Developer Tools 入门 0m

认识 Containerization

Meet Containerization

2025年6月9日

在 Apple 官方观看视频

一句话判断

Apple 用 Swift 写了一个 Linux 容器框架，每个容器跑在独立的轻量级 VM 里，sub-second 启动，没有 Docker Desktop 也能在 Mac 上跑容器了。

这场 Session 讲了什么

Containerization 是 Apple 开源的 Swift 框架，目标是在 macOS 上安全、私密、高性能地运行 Linux 容器。它不是 Docker 的 wrapper，而是从底层重新设计的方案。

核心架构：每个容器一个轻量级 VM

传统方案（Docker Desktop）是启动一个大 VM，里面跑所有容器。Containerization 的做法不同：每个容器在自己的轻量级 VM 里运行，但启动时间在亚秒级别。这带来几个好处：

  • 安全隔离级别等同于完整 VM
  • 每个容器有独立 IP，不需要端口映射
  • 目录挂载按容器粒度，只有请求的容器能访问
  • 没有容器运行时不分配任何资源

镜像管理

  • 提供 API 从 Registry 拉取镜像的 filesystem 和 configuration
  • 文件系统以 block device（EXT4 格式）暴露，性能优于文件级访问
  • Swift 包提供了直接从 Swift 格式化、创建目录结构、填充 EXT4 文件系统的能力

vminitd：Swift 写的 init 系统

  • VM 启动后的第一个进程，负责网络配置、文件系统挂载、进程管理
  • 关键点：没有 libc、没有动态库、没有 core utilities（没有 cd/cp/ls）
  • 使用 Swift Static Linux SDK + musl 编译为静态可执行文件，直接从 Mac 交叉编译
  • 极大地减少了攻击面

Container CLI 工具

  • 开源的命令行工具，基于 Containerization 框架构建
  • 包含 CLI + XPC services（Storage、Network、Runtime）
  • container image pull alpine:latest + container run -it alpine sh，几百毫秒进入 shell

值得深挖的点

vminitd 的「零依赖」编译策略：这是最技术亮点。vminitd 要在完全没有系统库的 VM 里运行，所以必须是完全静态链接的。Apple 用 Swift Static Linux SDK + musl（不是 glibc）实现了从 Mac 交叉编译 Linux 静态二进制。这展示了 Swift 在系统编程领域的能力——很多人还停留在「Swift 只能写 iOS app」的认知上。

每容器一个 VM 的 trade-off：好处是隔离性极强，但代价是内存开销。每个轻量 VM 都需要一定基础内存。如果你同时跑几十个容器，内存压力会比 Docker Desktop 大。但 Apple 的设计哲学是：如果没跑容器，零资源占用；跑的时候，隔离优先。

EXT4 从 Swift 直接操作：Containerization 包含了一个纯 Swift 实现的 EXT4 操作包，可以直接格式化、创建目录、填充文件系统。这意味着你不需要在 Mac 上安装任何 Linux 工具链就能构建容器镜像的文件系统层。对于开发自定义容器工具的人来说，这是非常有价值的底层能力。

代码片段

# 安装 Container CLI
# 从 GitHub releases 下载

# 拉取镜像
container image pull alpine:latest

# 运行交互式容器
container run -it alpine sh

# 在容器里验证隔离
uname -a   # 显示 Linux 环境
ps aux     # 只能看到自己的进程
// 使用 Containerization 框架（Swift）
import Containerization

// 从 registry 获取镜像
let image = try await Image.fetch(
    reference: "alpine:latest",
    from: "docker.io"
)

// 创建并启动容器
let config = ContainerConfiguration(from: image)
let container = try await Container.create(configuration: config)
try await container.start()

// 执行命令
let exec = try await container.exec(
    command: ["/bin/sh", "-c", "echo hello"],
    terminal: false
)

最佳实践

  1. 先用 Container CLI 跑通再考虑集成框架：CLI 工具足够覆盖大部分开发场景（本地测试、构建验证）。只有需要自定义容器管理工具时才需要直接用 Containerization 框架。
  2. 评估内存开销：如果你的工作流需要同时跑很多小容器（比如集成测试矩阵），要测试实际内存占用。每容器一个 VM 的模型在大量并发时可能比 Docker Desktop 更吃内存。
  3. 利用独立 IP 做网络调试：每个容器有独立 IP 意味着你可以直接用 IP 访问容器服务，不需要 -p 端口映射。这在本地开发多个互相关联的服务时非常方便。
  4. 关注 Swift Static Linux SDK：如果你想做类似 vminitd 这样的「零依赖 Linux 二进制」，这个 SDK 是关键工具。它还在快速迭代中，值得关注。
  5. 安全审计的角度：vminitd 没有 core utilities 意味着即使容器被攻破，攻击者能做的事情也极其有限。如果你对安全要求高，这个方案比共享 VM 内核的 Docker 更可靠。

还有什么值得关注

  • 项目完全开源在 GitHub（apple/containerization），包含示例项目和跨平台 Swift 包。
  • Apple-Hosted Background Assets（328 session 提到的 200GB 资源托管）的管理 API 也可以通过容器化工具链集成。
  • 如果你做 server-side Swift，Containerization 和 vminitd 展示的 Swift 系统编程能力会让你重新评估 Swift 在后端的潜力。
  • APAC（Apple Positional Audio Codec）的编码器可以在容器化环境中批量处理，适合媒体工作流。
开发工具