Moby Project：Docker 背后的容器化积木

Moby 是 Docker 公司发起的开源项目，用来做软件容器化。

说白了，Docker 的底层就是 Moby。Docker 把自己的开源组件全部放进了这个仓库，然后围绕它搭出了商业化产品。

Moby 在 GitHub 上拿到了 71,671 个 Star，是容器领域最核心的基础设施之一。

Moby 提供了一整套组件：容器构建工具、镜像仓库、编排工具、运行时，这些都可以单独拿出来用。

你可以把它们想象成乐高积木。每一块积木都有明确定义的功能和 API，你可以按需组装，搭出自己的容器系统。想换掉其中某一块？没问题，模块化架构保证了大部分组件都可以被替换。

这种设计思路带来了很高的灵活度。小团队拿几个组件拼一拼就能跑起来，大厂也可以基于它做深度定制。

很多人会问：这项目跟 Docker 到底是什么关系？

直接说结论：Docker 用 Moby 作为上游。Docker Engine 里的开源部分，代码都从 Moby 这边出。Docker 每次发新版本，都会把改动推回 Moby。

但 Moby 不只属于 Docker。其他项目同样可以把 Moby 当上游来用，复用这些组件去搭建自己的容器平台。不管是哪家的项目，贡献者和维护者都受到同等对待。

不过，Moby 本身不提供商业支持。如果你需要企业级服务，Docker Desktop 和 Mirantis Container Runtime 是对应的商业产品。Moby 这边只做开源代码，由社区维护，走的是 best efforts 路线。

Moby 有四个核心原则：

模块化。 组件之间通过 API 协作，各自负责一块功能。想用构建工具就只引入构建工具，想用运行时就只引入运行时，不需要全盘照收。

自带配件但可替换。 Moby 自带的组件足够搭建一套完整的容器系统，但如果你有自己的偏好实现，随时可以替换。比如你可能更喜欢用 containerd 而不是默认的运行时，换掉就行。

可用的安全性。 默认配置就是安全的，不需要额外加固。这个原则在容器领域挺重要的，因为安全问题出了名的难补救。

面向开发者。 API 的设计目标是让开发者能用它构建工具。Moby 不是一个终端用户产品，它是给开发者用的底层组件。

Moby 的定位很明确：给工程师、集成者和容器爱好者用的。

你想改、想折腾、想实验、想基于容器搭系统，Moby 适合你。如果你只是想要一个开箱即用的商业容器方案，那直接用 Docker Desktop 就好。

Moby 的维护和发版都走社区模式，没有商业 SLA 保障。社区活跃，代码质量高，但使用它意味着你自己要有一定的技术能力来处理问题。

从 Docker v29（2025 年 11 月发布）开始，旧的 Go 模块路径 github.com/docker/docker 已经弃用，不会再更新。

新的公开模块有两个：

根模块 github.com/moby/moby/v2 用于构建基于 Moby 的容器引擎（比如 Docker Engine），它只产出二进制文件，不作为 Go 库来导入。

迁移很简单，把 import 路径里的 github.com/docker/docker 改成 github.com/moby/moby 就行。不过 v29 涉及不少 breaking API 变更（结构体调整、方法重命名、类型移动），升级前最好翻一下 release notes。

Moby 使用 Apache License 2.0 开源协议，可以自由使用和分发。不过根据美国相关法规，使用和转移可能受到某些限制，具体可以参考美国商务部的出口管制信息。

总体来看，Moby 是容器生态里绕不开的基础项目。不管你用不用 Docker，了解 Moby 的架构和组件都会帮你更好地理解容器技术的底层逻辑。71,000 多个 Star 不是白来的。

不管你用不用 Docker，了解 Moby 的架构和组件都会帮你更好地理解容器技术的底层逻辑。71,000 多个 Star 不是白来的。