--- title: "Apple Container 与 Docker：Compose、网络及迁移指南" canonical: https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/ language: zh description: "Apple Container 1.4.1 能替代 Mac 上的 Docker 吗？核查 Compose、Docker API、localhost、持久化卷、amd64 镜像与本地 Kubernetes，并用实际验收清单决定是否迁移。" image: "https://wavect.io/img/blog/headers/header_apple-container-vs-docker-compose-migration.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 分钟 阅读 · 2026年9月28日 最近审核 2026年9月28日 [**下一篇**](/zh/blog/linux-for-ai-agents/) # Apple Container 与 Docker：Compose、网络及迁移指南 要点速览 Apple Container 是用 Swift 编写的 CLI，可在 Apple 芯片 Mac 上通过轻量虚拟机运行 Linux OCI 容器，受支持的基础环境为 macOS 26。1.4.1 支持镜像构建、命名卷、多平台流程、本地 Kubernetes 和持久化 Linux machine。OCI 兼容不等于 Docker API、Compose 或 Dev Containers 兼容。先试点一个工作负载，验证网络和数据恢复，再决定是否更换默认运行时。在全部必需集成通过之前，应保留现有方案。本文是文档评审，不是性能实测。 **Apple Container 可以替代 Mac 开发流程中的一部分，但能运行同一个镜像，不代表所有 Docker 工具都能正常工作。**迁移时真正需要回答的不是 Alpine 能否启动，而是更换运行时后，构建、服务发现、持久化数据、测试和编辑器能否继续正确协作。 本文评审的是 [2026 年 9 月 9 日发布的 Apple Container 1.4.1](https://github.com/apple/container/releases/tag/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](https://github.com/apple/container/blob/1.4.1/README.md) 将 Apple 芯片 Mac 和 macOS 26 列为受支持的基础环境。旧版 macOS 的兼容性说明不等于相同的支持承诺，也不要把运行 Intel Linux 镜像理解为支持 Intel Mac。 该工具使用并生成 OCI 兼容镜像，因此可以在兼容的运行时和镜像仓库之间复用镜像，但仍需满足操作系统、CPU 架构和运行时要求。这并不保证 Docker API 兼容性。“原生 macOS 工具”指宿主端程序及其平台集成，并不是让 Linux 进程直接运行在 macOS 内核上。 ## Apple Container 与 Docker Desktop 的架构有什么不同？ 对于常规 `container run` 工作负载，Apple 的 [技术概览](https://github.com/apple/container/blob/1.4.1/docs/technical-overview.md) 说明每个容器使用独立的轻量 Linux 虚拟机。Mac 上的 CLI 通过 Apple 平台机制与 API 服务和辅助进程通信。Linux 内核和虚拟化层仍然存在，因此它不是“无需虚拟机”的容器实现。 [Docker Desktop 的 VMM 文档](https://docs.docker.com/desktop/features/vmm/) 也介绍了 macOS 上的 Linux 虚拟机后端，包括 Apple Virtualization Framework 和 Docker VMM。因此，“Docker 全靠模拟，Apple 全部原生执行”不是准确的比较。真正需要比较的是执行架构、隔离边界，以及运行时对外提供的工具接口。CPU 架构和所选后端同样会影响结果。 虚拟机边界可以帮助限制客户机被攻破后的影响，却无法保护你主动以可写方式挂载的宿主目录，也不会自动撤销转发给客户机的凭据。更完整的部署威胁模型可参考我们的 [AI 智能体 Linux 基础设施指南](/zh/blog/linux-for-ai-agents/) 。本文聚焦 Mac 本地运行时迁移，不重复讨论整个平台的安全设计。 ## Apple Container 支持 Docker Compose 和 Docker API 吗？ **不要将 Apple 核心 CLI 当成可以直接替换 Docker Engine 的 API 端点。**我们审查的 [1.4.1 命令注册代码](https://github.com/apple/container/blob/1.4.1/Sources/ContainerCommands/Application.swift) 包含容器、镜像、机器、卷、网络和系统命令，以及插件分发机制，但没有注册内置 Compose 命令。这描述的是该版本的核心 CLI，并不意味着第三方集成不可能存在。 [Docker Compose](https://docs.docker.com/compose/) 通过 YAML 模型定义和管理多容器应用。替换几个 `docker run` 命令，与保留 Compose 应用的网络、健康检查、依赖条件、profiles 和清理行为，是两种不同规模的迁移。不要用 `alias docker=container` 掩盖区别：命令别名既不会补齐缺失的 API，也不会复现编排语义。 | 现有依赖 | 可能复用的部分 | 仍需验证的内容 | | --- | --- | --- | | Linux OCI 镜像 | 镜像与仓库格式。 | CPU 架构、内核功能、入口程序和应用行为。 | | Dockerfile | 构建 OCI 镜像的定义。 | 构建参数、密钥、挂载、目标阶段和缓存行为。 | | Compose 应用 | 各组件的镜像与应用配置。 | 选用的编排层，以及全部必需的 Compose 功能。 | | Docker socket 或 API 客户端 | 不能通过镜像兼容性确认。 | 明确受支持的引擎或适配器，以及实际集成测试。 | | Linux CI 与生产环境 | 可部署镜像仍可作为共同交付物。 | 在真实目标平台上的构建和应用测试。 | 例如， [Testcontainers for Java 要求运行时兼容 Docker API](https://java.testcontainers.org/supported_docker_environment/) 。通过 Apple Container 手动启动数据库，并不能证明 Testcontainers 能发现、创建、检查和清理该数据库。应保留测试流程已经支持的引擎，直到替代方案通过这些测试。 同样， [VS Code 的 Docker 替代安装文档](https://code.visualstudio.com/remote/advancedcontainers/docker-options) 区分了 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 命令参考](https://github.com/apple/container/blob/1.4.1/docs/command-reference.md) 说明 `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 的 [网络指南](https://github.com/apple/container/blob/1.4.1/docs/networking.md) 介绍了容器 IP、回环端口发布和 DNS 配置。应逐条测试，而不是在没有定位故障的情况下修改无关的防火墙设置。 | 连接方向 | 优先检查 | 常见错误假设 | | --- | --- | --- | | Mac 到容器 | 例如 `127.0.0.1:8080:8000` 的端口发布，或容器 IP。 | 仅有 `EXPOSE` 就会在宿主创建监听端口。 | | 容器到容器 | 网络归属和文档规定的带域名 DNS 名称。 | Compose 中的简短服务名会原样解析。 | | 容器到 Mac | 明确配置且可达的宿主端点。 | 客户机内的 `localhost` 就是 Mac。 | 需要带域名的容器名称时，把以下配置合并到 `~/.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 的 [宿主集成指南](https://github.com/apple/container/blob/1.4.1/docs/host-integration.md) 提供了可选的 `--localhost` DNS 配置方法，但也提醒该方法会关闭 Private Relay，并且相应包过滤规则会在重启后消失。不要在团队脚本中悄悄将 `host.docker.internal` 替换为具有不同副作用的宿主网络修改。应与负责 Mac 和网络策略的人员共同确认。 ## Apple Container 的卷能像 Docker 卷一样保留数据吗？ Apple 支持命名卷、bind mount 和 tmpfs，但生命周期并不完全相同。 [1.4.1 卷指南](https://github.com/apple/container/blob/1.4.1/docs/volumes.md) 介绍了基于稀疏文件系统镜像的命名卷，并指出 `--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 的 [多平台镜像指南](https://github.com/apple/container/blob/1.4.1/docs/multiplatform-images.md) 记录了同时构建 `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 流程](https://github.com/apple/container/blob/1.4.1/docs/kubernetes.md) ，可创建开发集群、加载本地镜像并使用 `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](https://github.com/apple/container/blob/1.4.1/docs/container-machine.md) ，用于提供持久化 Linux 环境，而不只是单个应用容器。其默认主目录集成允许写入。这种便利性与仅挂载必要目录的 `container run` 工作区具有不同的信任边界。不要把共享了主目录的 machine 交给不可信的编程智能体，同时宣称它与个人文件完全隔离。 ## Apple Container 比 Docker Desktop 更快、更省内存吗？ **本文没有证明任何普遍成立的性能优势。**Apple 的 [资源使用指南](https://github.com/apple/container/blob/1.4.1/docs/resource-usage.md) 介绍了每个容器的 CPU 和内存设置、独立的 builder 虚拟机及资源统计。配置的内存上限不等于当前实际驻留内存。技术概览还说明 memory ballooning 仅得到部分支持：Linux 客户机释放的内存不一定会归还给 macOS。 ``` container stats --no-stream container system df container builder stop ``` 只有构建完成后才停止 builder。应将包含镜像下载的冷启动与使用缓存镜像的热启动分别测量。比较时保持镜像摘要、CPU 架构、资源上限、挂载类型和负载一致。观察整个宿主进程组、macOS 内存压力与 swap，不要只看客户机内打印的一项数值。还应记录容器和 builder 停止后仍然占用的资源。 我们建议采用“获得经过验证的可用环境所需时间”作为决策指标，包括安装、镜像构建、应用就绪、测试完成以及重启后恢复。如果开发者随后要花更多时间修复 DNS 或工具兼容问题，空容器启动快一点并没有实际价值。 ## 常见迁移故障，应该先检查什么？ | 现象 | 优先检查项 | | --- | --- | | XPC 或服务连接错误 | 运行 `container system status`，启动服务并确认安装版本。 | | 镜像在运行，但 Mac 无法访问 HTTP | 检查应用日志、客户机监听地址和明确发布的端口。 | | 数据库可通过 IP 访问，但服务名不行 | 检查 DNS 域、网络归属，以及脚本是否依赖 Compose 短服务名。 | | Testcontainers 找不到运行时 | 检查所需 Docker API 端点。手动 `container run` 验证的是另一条路径。 | | 重建容器后数据丢失 | 检查命名卷与挂载目标，先停止操作，不要立即删除或清理资源。 | | Mac 内存压力持续偏高 | 检查 builder 与客户机 VM、宿主 swap，以及文档描述的内存回收限制。 | ## 团队什么时候适合迁移，什么时候应保留 Docker？ **先迁移一个可丢弃的服务或构建任务，不要直接在整个组织内卸载 Docker。**当目标设备是 Apple 芯片 Mac，且任务能够通过受支持的镜像、构建和容器命令完成时，Apple Container 值得试点。对于尚未通过 Compose、Docker API 或编辑器集成验收的工作流，保留现有运行时。开发者可以使用不同的本地工具，同时共享相同的 OCI 镜像和 CI 验收约定。 | 领域 | 需要取得的证据 | | --- | --- | | 构建与应用 | 相同源代码能够生成所需镜像；真实应用与测试通过。 | | 网络与存储 | 三个网络方向均可用；数据经受预期生命周期并可从备份恢复。 | | 开发工具集成 | 编辑器、调试器、测试框架和编排不依赖未记录的别名或人工修复。 | | 运维与回退 | 重启、VPN 变更、升级和清理都有负责人；可恢复先前环境。 | 不再需要 HTTP Demo 时，只停止并删除它的命名容器： ``` container stop wavect-web container delete wavect-web ``` 命名测试卷、构建出的镜像和可选 Kubernetes 集群是独立资源，应逐项检查，而不是执行全局清理。上面的命令均不会删除已有的 Docker 数据。 应用层验收可参考我们的 [软件 QA 检查清单](/zh/software-development-guide/software-qa-checklist-before-launch/) 。如果需要的是智能体执行服务，而不是 Mac CLI，请阅读单独的 [OpenSandbox 架构评审](/zh/blog/opensandbox-ai-agent-sandbox-review/) 。工具应服从实际工作负载和信任边界，而不是反过来。 ## Apple Container 迁移常见问题 ### Apple Container 能替代 Docker Desktop 吗？ 它可以替代 Apple 芯片 Mac 上受支持的本地构建与运行流程，但不能据此认定每个 Docker API 客户端、Compose 应用或编辑器集成都兼容。移除原运行时之前，应验证完整工作流。 ### Apple Container 内置 Docker Compose 吗？ 所评审的 1.4.1 核心命令注册代码没有 Compose 命令。插件或兼容层需要单独验证功能和生命周期；支持 OCI 镜像不等于支持 Compose。 ### Apple Container 可以配合 Testcontainers 使用吗？ Testcontainers for Java 需要 Docker API 兼容运行时。使用 Apple Container 手动启动同一镜像，并不证明创建、检查和清理资源所需的 API 已经可用。 ### 为什么 Apple 容器无法访问 Mac 的 localhost？ 容器内部的 localhost 指向客户机自身。宿主到容器的端口发布与容器到宿主的访问是两条不同路径。修改网络前，应审查 Apple 的宿主集成方案，以及 Private Relay 和重启方面的限制。 ### Apple Container 可以运行 x86 或 amd64 镜像吗？ 文档规定的 amd64 路径通过 Rosetta 在 Apple 芯片上翻译执行客户机应用。这不代表支持 Intel Mac，也不能替代生产 CPU 架构上的测试。 ### --rm 会删除 Apple Container 的卷吗？ 卷指南说明 --rm 不会自动删除匿名卷。命名卷同样具有独立生命周期。应主动检查存储，在清理前保留已验证的备份。 ### Apple Container 一定更快或更省内存吗？ 本文没有证明普遍优势。应比较相同镜像和负载，计入 builder 与客户机虚拟机，并观察宿主内存压力。所审查文档明确提到了内存归还方面的限制。 ### Apple Container 支持 Kubernetes 吗？ 1.4.1 文档包含 container k8s，可创建本地开发集群并加载镜像。这是独立工作流，不是 Docker Compose 或 Docker API 兼容性的证明。 ## 最终思考 Apple Container 是值得评估的本地运行时选择，但不能代替集成测试。保留可移植镜像，明确运行时特有的假设，只有构建、网络、数据恢复和开发工具都通过相同验收约定后，才变更团队默认环境。 架构与平台 ## 继续浏览此集群 对长期交付产生影响的框架、平台与系统设计选择。 [从核心文章开始**智慧城市软件架构：MQTT、LoRaWAN、Kubernetes 与 Terraform**](/zh/blog/smart-city-architecture-best-practices-2026/) - [Pake 网页转桌面应用：体积、PWA 对比与登录限制](/zh/blog/pake-website-to-desktop-app/) - [因斯布鲁克机场：软件、数字化与 AI 机会独立分析](/zh/blog/flughafen-innsbruck-software-ai-opportunity-map/) - [欧盟电池护照软件架构：面向 2027](/zh/blog/eu-battery-passport-software-architecture-2027/) - [欧盟《数据法》：连接产品 API 清单](/zh/blog/eu-data-act-connected-product-api-2026/) - [Cursor Origin 与 GitHub 对比：团队该迁移吗？](/zh/blog/cursor-origin-vs-github-code-hosting/) [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 14 分钟 阅读 · 2026年9月28日 最近审核 2026年9月28日 [**下一篇**](/zh/blog/linux-for-ai-agents/) ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/#webpage", "@type": "WebPage", "dateModified": "2026-09-28", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-09-28", "url": "https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Apple Container 是用 Swift 编写的 CLI，可在 Apple 芯片 Mac 上通过轻量虚拟机运行 Linux OCI 容器，受支持的基础环境为 macOS 26。1.4.1 支持镜像构建、命名卷、多平台流程、本地 Kubernetes 和持久化 Linux machine。OCI 兼容不等于 Docker API、Compose 或 Dev Containers 兼容。先试点一个工作负载，验证网络和数据恢复，再决定是否更换默认运行时。在全部必需集成通过之前，应保留现有方案。本文是文档评审，不是性能实测。", "articleBody": " 博客概览/交付与 QA/架构与平台 Apple Container 与 Docker：Compose、网络及迁移指南 要点速览 Apple Container 是用 Swift 编写的 CLI，可在 Apple 芯片 Mac 上通过轻量虚拟机运行 Linux OCI 容器，受支持的基础环境为 macOS 26。1.4.1 支持镜像构建、命名卷、多平台流程、本地 Kubernetes 和持久化 Linux machine。OCI 兼容不等于 Docker API、Compose 或 Dev Containers 兼容。先试点一个工作负载，验证网络和数据恢复，再决定是否更换默认运行时。在全部必需集成通过之前，应保留现有方案。本文是文档评审，不是性能实测。 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，也不会复现编排语义。 迁移到 Apple Container 时需要分别判断的兼容性 现有依赖可能复用的部分仍需验证的内容 Linux OCI 镜像镜像与仓库格式。CPU 架构、内核功能、入口程序和应用行为。 Dockerfile构建 OCI 镜像的定义。构建参数、密钥、挂载、目标阶段和缓存行为。 Compose 应用各组件的镜像与应用配置。选用的编排层，以及全部必需的 Compose 功能。 Docker socket 或 API 客户端不能通过镜像兼容性确认。明确受支持的引擎或适配器，以及实际集成测试。 Linux CI 与生产环境可部署镜像仍可作为共同交付物。在真实目标平台上的构建和应用测试。 例如，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 配置。应逐条测试，而不是在没有定位故障的情况下修改无关的防火墙设置。 需要独立验证的三条网络路径 连接方向优先检查常见错误假设 Mac 到容器例如 127.0.0.1:8080:8000 的端口发布，或容器 IP。仅有 EXPOSE 就会在宿主创建监听端口。 容器到容器网络归属和文档规定的带域名 DNS 名称。Compose 中的简短服务名会原样解析。 容器到 Mac明确配置且可达的宿主端点。客户机内的 localhost 就是 Mac。 需要带域名的容器名称时，把以下配置合并到 ~/.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 不会自动删除匿名卷", "articleSection": "平台工程", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "2026 年 9 月 9 日发布的 Apple Container 1.4.1", "url": "https://github.com/apple/container/releases/tag/1.4.1" }, { "@type": "WebPage", "name": "1.4.1 版本的 README", "url": "https://github.com/apple/container/blob/1.4.1/README.md" }, { "@type": "WebPage", "name": "技术概览", "url": "https://github.com/apple/container/blob/1.4.1/docs/technical-overview.md" }, { "@type": "WebPage", "name": "Docker Desktop 的 VMM 文档", "url": "https://docs.docker.com/desktop/features/vmm/" }, { "@type": "WebPage", "name": "1.4.1 命令注册代码", "url": "https://github.com/apple/container/blob/1.4.1/Sources/ContainerCommands/Application.swift" }, { "@type": "WebPage", "name": "Docker Compose", "url": "https://docs.docker.com/compose/" }, { "@type": "WebPage", "name": "Testcontainers for Java 要求运行时兼容 Docker API", "url": "https://java.testcontainers.org/supported_docker_environment/" }, { "@type": "WebPage", "name": "VS Code 的 Docker 替代安装文档", "url": "https://code.visualstudio.com/remote/advancedcontainers/docker-options" }, { "@type": "WebPage", "name": "1.4.1 命令参考", "url": "https://github.com/apple/container/blob/1.4.1/docs/command-reference.md" }, { "@type": "WebPage", "name": "网络指南", "url": "https://github.com/apple/container/blob/1.4.1/docs/networking.md" }, { "@type": "WebPage", "name": "宿主集成指南", "url": "https://github.com/apple/container/blob/1.4.1/docs/host-integration.md" }, { "@type": "WebPage", "name": "1.4.1 卷指南", "url": "https://github.com/apple/container/blob/1.4.1/docs/volumes.md" }, { "@type": "WebPage", "name": "多平台镜像指南", "url": "https://github.com/apple/container/blob/1.4.1/docs/multiplatform-images.md" }, { "@type": "WebPage", "name": "本地 Kubernetes 流程", "url": "https://github.com/apple/container/blob/1.4.1/docs/kubernetes.md" }, { "@type": "WebPage", "name": "container machine", "url": "https://github.com/apple/container/blob/1.4.1/docs/container-machine.md" }, { "@type": "WebPage", "name": "资源使用指南", "url": "https://github.com/apple/container/blob/1.4.1/docs/resource-usage.md" } ], "dateModified": "2026-09-28", "datePublished": "2026-09-28", "description": "Apple Container 是用 Swift 编写的 CLI，可在 Apple 芯片 Mac 上通过轻量虚拟机运行 Linux OCI 容器，受支持的基础环境为 macOS 26。1.4.1 支持镜像构建、命名卷、多平台流程、本地 Kubernetes 和持久化 Linux machine。OCI 兼容不等于 Docker API、Compose 或 Dev Containers 兼容。先试点一个工作负载，验证网络和数据恢复，再决定是否更换默认运行时。在全部必需集成通过之前，应保留现有方案。本文是文档评审，不是性能实测。", "headline": "Apple Container 与 Docker：Compose、网络及迁移指南", "image": "https://wavect.io/img/blog/headers/header_apple-container-vs-docker-compose-migration.svg", "inLanguage": "zh", "keywords": "Apple Container, Docker 迁移, macOS 开发", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/", "wordCount": 905 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/delivery-qa/", "name": "交付与 QA", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/architecture-platforms/", "name": "架构与平台", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/apple-container-vs-docker-compose-migration/", "name": "Apple Container 与 Docker：Compose、网络及迁移指南", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "它可以替代 Apple 芯片 Mac 上受支持的本地构建与运行流程，但不能据此认定每个 Docker API 客户端、Compose 应用或编辑器集成都兼容。移除原运行时之前，应验证完整工作流。" }, "name": "Apple Container 能替代 Docker Desktop 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "所评审的 1.4.1 核心命令注册代码没有 Compose 命令。插件或兼容层需要单独验证功能和生命周期；支持 OCI 镜像不等于支持 Compose。" }, "name": "Apple Container 内置 Docker Compose 吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Testcontainers for Java 需要 Docker API 兼容运行时。使用 Apple Container 手动启动同一镜像，并不证明创建、检查和清理资源所需的 API 已经可用。" }, "name": "Apple Container 可以配合 Testcontainers 使用吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "容器内部的 localhost 指向客户机自身。宿主到容器的端口发布与容器到宿主的访问是两条不同路径。修改网络前，应审查 Apple 的宿主集成方案，以及 Private Relay 和重启方面的限制。" }, "name": "为什么 Apple 容器无法访问 Mac 的 localhost？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "文档规定的 amd64 路径通过 Rosetta 在 Apple 芯片上翻译执行客户机应用。这不代表支持 Intel Mac，也不能替代生产 CPU 架构上的测试。" }, "name": "Apple Container 可以运行 x86 或 amd64 镜像吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "卷指南说明 --rm 不会自动删除匿名卷。命名卷同样具有独立生命周期。应主动检查存储，在清理前保留已验证的备份。" }, "name": "--rm 会删除 Apple Container 的卷吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "本文没有证明普遍优势。应比较相同镜像和负载，计入 builder 与客户机虚拟机，并观察宿主内存压力。所审查文档明确提到了内存归还方面的限制。" }, "name": "Apple Container 一定更快或更省内存吗？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "1.4.1 文档包含 container k8s，可创建本地开发集群并加载镜像。这是独立工作流，不是 Docker Compose 或 Docker API 兼容性的证明。" }, "name": "Apple Container 支持 Kubernetes 吗？" } ] } ```