Apple Container 与 Docker：Compose、网络及迁移指南

Apple Container 可以替代 Mac 开发流程中的一部分，但能运行同一个镜像，不代表所有 Docker 工具都能正常工作。迁移时真正需要回答的不是 Alpine 能否启动，而是更换运行时后，构建、服务发现、持久化数据、测试和编辑器能否继续正确协作。

本文评审的是 2026 年 9 月 9 日发布的 Apple Container 1.4.1，这是我们在 2026 年 9 月 28 日核查时最新的已发布版本，其中包含两项 Containerization 安全修复。以下示例依据对应版本的文档和源代码编写，并非在 Mac 上实际运行的性能测试。安装 CLI 并成功启动一次，不能证明整个开发环境已经迁移完成。

Apple Container 是什么，支持哪些 Mac？

Apple 的 container 是用 Swift 编写的开源命令行工具，用于构建镜像，并在 Mac 上通过轻量 Linux 虚拟机运行容器。Containerization 是底层 Swift 软件包，container 则是可以直接使用的 CLI。1.4.1 版本的 README 将 Apple 芯片 Mac 和 macOS 26 列为受支持的基础环境。旧版 macOS 的兼容性说明不等于相同的支持承诺，也不要把运行 Intel Linux 镜像理解为支持 Intel Mac。

该工具使用并生成 OCI 兼容镜像，因此可以在兼容的运行时和镜像仓库之间复用镜像，但仍需满足操作系统、CPU 架构和运行时要求。这并不保证 Docker API 兼容性。“原生 macOS 工具”指宿主端程序及其平台集成，并不是让 Linux 进程直接运行在 macOS 内核上。

Apple Container 与 Docker Desktop 的架构有什么不同？

对于常规 container run 工作负载，Apple 的技术概览说明每个容器使用独立的轻量 Linux 虚拟机。Mac 上的 CLI 通过 Apple 平台机制与 API 服务和辅助进程通信。Linux 内核和虚拟化层仍然存在，因此它不是“无需虚拟机”的容器实现。

Docker Desktop 的 VMM 文档也介绍了 macOS 上的 Linux 虚拟机后端，包括 Apple Virtualization Framework 和 Docker VMM。因此，“Docker 全靠模拟，Apple 全部原生执行”不是准确的比较。真正需要比较的是执行架构、隔离边界，以及运行时对外提供的工具接口。CPU 架构和所选后端同样会影响结果。

虚拟机边界可以帮助限制客户机被攻破后的影响，却无法保护你主动以可写方式挂载的宿主目录，也不会自动撤销转发给客户机的凭据。更完整的部署威胁模型可参考我们的AI 智能体 Linux 基础设施指南。本文聚焦 Mac 本地运行时迁移，不重复讨论整个平台的安全设计。

Apple Container 支持 Docker Compose 和 Docker API 吗？

不要将 Apple 核心 CLI 当成可以直接替换 Docker Engine 的 API 端点。我们审查的 1.4.1 命令注册代码包含容器、镜像、机器、卷、网络和系统命令，以及插件分发机制，但没有注册内置 Compose 命令。这描述的是该版本的核心 CLI，并不意味着第三方集成不可能存在。

Docker Compose通过 YAML 模型定义和管理多容器应用。替换几个 docker run 命令，与保留 Compose 应用的网络、健康检查、依赖条件、profiles 和清理行为，是两种不同规模的迁移。不要用 alias docker=container 掩盖区别：命令别名既不会补齐缺失的 API，也不会复现编排语义。

例如，Testcontainers for Java 要求运行时兼容 Docker API。通过 Apple Container 手动启动数据库，并不能证明 Testcontainers 能发现、创建、检查和清理该数据库。应保留测试流程已经支持的引擎，直到替代方案通过这些测试。

同样，VS Code 的 Docker 替代安装文档区分了 Docker 兼容命令行流程与其他容器引擎。需要核验具体 Dev Containers 扩展版本、运行时适配器、Features、挂载和 Compose 用法。终端能运行镜像，不等于编辑器的完整开发流程已经通过兼容性测试。

如何安装 Apple Container，同时保留现有运行时？

从上方链接的 release 下载已签名安装包，并按照 Apple 的说明安装。安装程序会请求管理员权限，以便将文件放入 /usr/local。使用这个安装包不需要自行编译 Swift 项目。试点期间请保留现有 Docker 环境及其数据。

先在 Mac 上检查操作系统和架构，再启动服务。在原生 Apple 芯片终端中，uname -m 应返回 arm64。Apple CLI 本身会拒绝在 Rosetta 下运行；这与翻译客户机内的 amd64 应用是不同的事情。

sw_vers -productVersion
uname -m
container --version
container system start
container system status
container run --rm docker.io/library/alpine:3.22 echo "container ready"

首次拉取镜像需要访问镜像仓库，启动阶段也可能需要准备 Linux 内核。如果这一步失败，应先检查系统状态和网络访问，而不是立即调试应用。使用已安装版本的帮助信息，不要直接照搬其他版本的参数。

Apple Container 能构建现有 Dockerfile 吗？

可以。1.4.1 命令参考说明 container build 使用 BuildKit，支持 Dockerfile，并可回退到 Containerfile。文档还列出了构建参数、目标阶段、密钥和平台选择。这里确认的是构建接口，而不是所有 Buildx 工作流和插件都能直接替换。

下面的示例创建一个最小本地 HTTP 服务。请在新目录中执行。为了便于阅读，示例使用镜像标签，而不是不可变的生产版本锁定；团队需要可重复的基线时，应改用审查过的镜像摘要。这里的 Python 服务仅用于本地冒烟测试，不是生产部署建议。

mkdir apple-container-demo
cd apple-container-demo
printf '%s\n' 'Apple Container is serving this page.' > index.html
cat > Dockerfile <<'EOF'
FROM docker.io/library/python:3.13-alpine
WORKDIR /srv
COPY index.html .
EXPOSE 8000
CMD ["python", "-m", "http.server", "8000", "--bind", "0.0.0.0"]
EOF
container build -t wavect/container-demo:local .
container run -d --name wavect-web --cpus 2 --memory 512M \
  --publish 127.0.0.1:8080:8000 wavect/container-demo:local
curl --fail http://127.0.0.1:8080/
container logs wavect-web

服务在客户机内部监听 0.0.0.0，这样转发流量才能到达它。Mac 端明确发布到 127.0.0.1，将这个转发监听端口限定在 IPv4 回环地址。它并没有定义通往虚拟机所有路径的完整防火墙策略。curl 成功只能证明宿主到容器的 HTTP 路径可用，不能证明容器间 DNS、数据库持久化或编辑器兼容性。

从 Docker 迁移后，为什么 localhost 的行为不同？

必须区分三个连接方向。Apple 的网络指南介绍了容器 IP、回环端口发布和 DNS 配置。应逐条测试，而不是在没有定位故障的情况下修改无关的防火墙设置。

需要带域名的容器名称时，把以下配置合并到 ~/.config/container/config.toml，保留其他已有设置。如果已经存在 [dns] 表，不要重复创建：

[dns]
domain = "test"

重启服务会影响正在运行的工作负载，应先停止它们或安排维护窗口。只有确定需要修改本机 DNS 时，才将该域注册到 macOS resolver：

container system stop
container system start
sudo container system dns create test

这两部分分别配置容器服务和 Mac 的解析器。Demo 再次运行后，名称为 wavect-web.test，客户机端口为 8000。所审查的指南明确提醒：自定义网络上的短主机名发现不能等同于 Compose 服务发现。默认网络可使用文档规定的带域名路径；自定义网络场景则可先检查容器 IP。

反向连接方面，Apple 的宿主集成指南提供了可选的 --localhost DNS 配置方法，但也提醒该方法会关闭 Private Relay，并且相应包过滤规则会在重启后消失。不要在团队脚本中悄悄将 host.docker.internal 替换为具有不同副作用的宿主网络修改。应与负责 Mac 和网络策略的人员共同确认。

Apple Container 的卷能像 Docker 卷一样保留数据吗？

Apple 支持命名卷、bind mount 和 tmpfs，但生命周期并不完全相同。1.4.1 卷指南介绍了基于稀疏文件系统镜像的命名卷，并指出 --rm 不会自动删除匿名卷。因此，容器消失不代表其所有数据也已消失。

下面的检查先向明确命名的卷写入文件，退出时删除第一个容器，再通过第二个容器的只读挂载读取该文件：

container volume create wavect-demo-data
container run --rm --volume wavect-demo-data:/data \
  docker.io/library/alpine:3.22 \
  sh -c 'printf "persistent\n" > /data/probe.txt'
container run --rm --volume wavect-demo-data:/data:ro \
  docker.io/library/alpine:3.22 cat /data/probe.txt

最后一个命令预期输出 persistent。这是建议执行的验收检查，不是我们在这里实测得到的结果。测试后卷仍然存在。数据库还需要通过真实客户端测试写入、正常关闭、重启和恢复。跨运行时迁移时，保持数据库版本一致，并采用数据库支持的备份与恢复流程。不能假设 Docker 管理的某个卷名称指向 Apple Container 中的同一份存储。

不要把卷清理当作常规排障步骤。Apple 文档警告，没有容器引用的卷及其内容会被立即删除。在验证恢复之前，应保留迁移备份。仅检查源代码时，优先使用范围小、只读的宿主挂载；只有确实需要写入的目录才授予写权限。

Apple Container 能运行 amd64 镜像并为 Linux 服务器构建吗？

Apple 的多平台镜像指南记录了同时构建 arm64 与 amd64 镜像的方法。在 Apple 芯片上，amd64 用户态程序通过 Rosetta 翻译执行。这既不会把 Mac 变成 Intel 宿主，也不能独立证明 x86 生产环境的兼容性。

container build --arch arm64 --arch amd64 \
  --tag wavect/container-demo:multi .
container run --rm --arch amd64 wavect/container-demo:multi uname -m

请在前面的 Demo 目录中执行这些命令，且翻译执行路径需要 Rosetta 可用。能执行 uname -m 只是架构冒烟测试，原生依赖、数据库扩展、系统调用和性能仍需真实工作负载验证。即使本地镜像成功构建，也应保留针对生产 CPU 架构的 CI 测试。

现在已经支持 Kubernetes 和持久化 Linux machine 了吗？

是的，所评审版本通过 container k8s 提供文档化的本地 Kubernetes 流程，可创建开发集群、加载本地镜像并使用 kubectl。因此，早期文章中“Apple Container 完全没有 Kubernetes 工作流”的说法已不适用于这一版本。

container k8s create --name wavect-local
container k8s list
kubectl --context wavect-local get nodes

这个可选示例需要安装 kubectl，并会创建本地集群。工具会修改 ~/.kube/config；请显式指定 context，避免与生产集群混淆。本地 Kubernetes 流程不会自动提供 Compose 实现或 Docker API 兼容性。

此外还有 container machine，用于提供持久化 Linux 环境，而不只是单个应用容器。其默认主目录集成允许写入。这种便利性与仅挂载必要目录的 container run 工作区具有不同的信任边界。不要把共享了主目录的 machine 交给不可信的编程智能体，同时宣称它与个人文件完全隔离。

Apple Container 比 Docker Desktop 更快、更省内存吗？

本文没有证明任何普遍成立的性能优势。Apple 的资源使用指南介绍了每个容器的 CPU 和内存设置、独立的 builder 虚拟机及资源统计。配置的内存上限不等于当前实际驻留内存。技术概览还说明 memory ballooning 仅得到部分支持：Linux 客户机释放的内存不一定会归还给 macOS。

container stats --no-stream
container system df
container builder stop

只有构建完成后才停止 builder。应将包含镜像下载的冷启动与使用缓存镜像的热启动分别测量。比较时保持镜像摘要、CPU 架构、资源上限、挂载类型和负载一致。观察整个宿主进程组、macOS 内存压力与 swap，不要只看客户机内打印的一项数值。还应记录容器和 builder 停止后仍然占用的资源。

我们建议采用“获得经过验证的可用环境所需时间”作为决策指标，包括安装、镜像构建、应用就绪、测试完成以及重启后恢复。如果开发者随后要花更多时间修复 DNS 或工具兼容问题，空容器启动快一点并没有实际价值。

常见迁移故障，应该先检查什么？

团队什么时候适合迁移，什么时候应保留 Docker？

先迁移一个可丢弃的服务或构建任务，不要直接在整个组织内卸载 Docker。当目标设备是 Apple 芯片 Mac，且任务能够通过受支持的镜像、构建和容器命令完成时，Apple Container 值得试点。对于尚未通过 Compose、Docker API 或编辑器集成验收的工作流，保留现有运行时。开发者可以使用不同的本地工具，同时共享相同的 OCI 镜像和 CI 验收约定。

不再需要 HTTP Demo 时，只停止并删除它的命名容器：

container stop wavect-web
container delete wavect-web

命名测试卷、构建出的镜像和可选 Kubernetes 集群是独立资源，应逐项检查，而不是执行全局清理。上面的命令均不会删除已有的 Docker 数据。

应用层验收可参考我们的软件 QA 检查清单。如果需要的是智能体执行服务，而不是 Mac CLI，请阅读单独的 OpenSandbox 架构评审。工具应服从实际工作负载和信任边界，而不是反过来。