第6章 整船编队：Docker Compose
第6章 · 整船编队：Docker Compose
章节摘要：本章跟着一条线走——把第 5 章手工组队的那支小船队，升级成一份声明文件管理的工程化编队：写法、起航、收港、扩编，一条命令完成。读完你能把任何多容器应用变成"一个文件 + 一条命令"的交付物。
一条主线
第 5 章末尾留了悬念：手工逐只起吊、逐条配网络的方式开始出错。错在哪？把第 5 章的组队过程复盘一下——建网络两条命令、数据库箱子带五个参数、应用箱子带四个参数、起吊顺序要人工保证、环境变量写错一个字母就是一次排障……每一步都正确，但整个流程不可复制：换台机器，你确定还能一字不差地重来一遍？
Compose 的答案是把"船队的全部事实"写进一份声明文件：有哪些服务、用什么镜像、配什么参数、接哪条航道、挂哪个仓库。然后整支编队的操作收敛成两条命令——起航（up）与收港（down）。本章主线就沿这份文件的写法与用法推进：
图 6-1：从手工逐吊到整队编排
沿途站点
6.1 Compose 简介与应用场景
编队的定位与边界：它解决单机多容器的声明式管理，不解决跨机调度（那是编排平台的领地）。这一站给出该用与不该用的判断标准。
6.2 Compose 文件结构与语法
核心手艺站：声明文件的骨架——服务、网络、卷三大块，逐字段讲透常用配置项。学完你能把第 5 章的手工命令完整翻译成声明文件。
6.3 Compose 常用命令
编队操典：起航、收港、扩缩、看日志、进箱子——所有手工命令都有对应的编队版。这一站还讲项目名的机制，它决定编队资源的命名与隔离。
6.4 服务通信、依赖与环境变量
编队的协调学：服务名即域名的落地、启动顺序与就绪检测（depends_on 与健康检查）、环境变量与配置文件的注入管理。这一站收官主线任务——把 Web 加数据库的船队写成一个文件交付。
四节的节奏是"先定性、再写文件、后操舵、终协调"：6.1 十分钟可读完，6.2 与 6.3 是动手主力，6.4 收官。时间紧也至少完成 6.2 的翻译练习——把第 5 章自己敲过的组队命令亲手翻成声明文件，翻译时对照命令历史逐条核对，漏一条参数起航后的行为就差一截。这一步走通，Compose 才真正属于你——顺带把第 5 章那串收尾命令也一并退役，收港一条 down 全包。
拐点与结论
本章最重要的认知转折在 6.2：Compose 文件不是命令的另一种写法，而是"期望状态"的声明。手工命令描述"动作"（起一只什么箱子），声明文件描述"事实"（编队应当长什么样）；引擎比对事实与现状，缺什么补什么、多什么删什么。理解了声明式思维，你与 Kubernetes 之间就只剩一层窗户纸——第 7 章会帮你捅破它。
第二个转折在 6.4："起来了"不等于"就绪了"。数据库容器进程在跑，但它的服务还没准备好接受连接；依赖顺序要靠健康检查而不是靠睡三秒。这是多容器应用最常见的翻车点，也是 Compose 相对手工方式的真正价值所在——它给了你就绪语义的表达工具。
本章的练习与前六章不同，重心从"敲命令"转向"改文件"：同一支编队，你会反复经历改声明、重跑 up、看引擎算差异的循环。这个循环正是声明式工作的日常手感，建议每一处修改都亲手验证引擎的反应，而不是只看书中输出。
本章落点一句话：一份声明文件承载船队全部事实，两条命令完成起航与收港，多容器应用从此成为可复制的交付物。
读完你应该
- 判断一个场景该不该用 Compose，并说明它与跨机编排的边界。
- 独立编写包含服务、网络、卷的完整声明文件，把手工命令无损翻译成声明。
- 用 up、down、ps、logs 操纵编队，解释项目名对资源命名的隔离作用。
- 用健康检查实现"数据库就绪后应用再起"的正确依赖顺序。
- 用环境变量与配置文件管理多环境（开发与测试）的差异，做到一个文件多环境复用。
下一章的接力
编队能一键起航了，但它还局限在一台机器上。下一章把视野推向航线深处：安全基线、CI/CD 流水线、部署与版本管理、故障排查，最后抵达自动化港区——Kubernetes 之门。