09 - Compose 到底解决什么问题
上一章我们见过了 docker-compose 长什么样。这一章不抠语法，专门讲清楚它为什么会出现、解决了什么痛点——理解了”为什么”，你才知道什么时候该用它。
痛点：应用很少是”一个容器”
你前面跑通的 FastAPI 服务，是单个容器。但真实应用基本都不是单打独斗，它需要一堆”伙伴”：
- AI 后端服务（你的业务代码）
- 数据库（存用户、存数据）
- 向量数据库（做 RAG 检索）
- 缓存（Redis）
- 也许还有前端、消息队列……
如果全靠 docker run 一个个手动启动，你会面对：
- 命令又多又长：每个容器一条带着一堆
-p -v -e参数的命令，记不住也容易敲错。 - 要手动连网络：容器之间怎么互相找到对方？得手动配。
- 启动顺序难管：数据库还没起来，业务就连上去了，报错。
- 换台机器重来一遍：所有命令都要重新敲，团队协作时每个人环境还可能不一样。
一句话：多容器手动管理，又乱又容易错。
Compose 的核心思想：把”怎么跑”写进一个文件
docker-compose 做的事很简单：
把”要跑哪些容器、各自怎么配置、它们之间什么关系”全部写进一个
docker-compose.yml文件，然后一条命令全部拉起。
docker compose up -d # 一键启动全部
docker compose down # 一键停止清理它带来三个关键价值：
- 配置即代码：原本散落在一堆命令里的配置，变成一个可读、可版本管理的文件。新同事拿到项目，
up一下整套环境就起来了。 - 自动组网：Compose 里的服务可以直接用服务名互相访问（比如业务代码里写
http://vectordb:6333就能连到向量库），不用手动配网络。 - 一致可复现：同一个 yml，在你电脑、同事电脑、测试服务器上跑出来的是同一套环境。
一句话总结它的定位
docker run管”一个容器”，docker compose管”一组容器”。
它本质上是把你本来要敲的一堆 docker run 命令，整理成了一份清晰的”剧本”，让多容器应用在本地开发时变得简单、可复现。
注意我加粗的”本地开发”——这正是引出下一章的关键。Compose 很好用，但它有个重要的适用边界。
小结
- 真实应用通常是”业务 + 数据库 + 缓存 + ……”多个容器。
- 手动
docker run管多容器：命令乱、组网烦、顺序难控、难复现。 - Compose 把这一切写进一个 yml，一键启停、自动组网、环境可复现。
- 定位：多容器编排，尤其适合本地开发和测试环境。
下一章我们就来谈 Compose 的”边界”——为什么真实业务不会简单地用它把数据库也一起跑。
上一章 ← 08 - 下一步：docker-compose ｜ 下一章 → 10 - Compose 的局限：业务与数据要分开