6.3 Compose 常用命令
6.3 Compose 常用命令
本节摘要：编队操典——up 起航、down 收港、ps 瞭望、logs 调阅、exec 进入、build 造货。本节按值班场景组织命令，并讲透项目名机制：它决定编队资源的命名、隔离与"你在哪支编队里"的判断。
操典按场景背，不按字母序查
文件会写了，本节把它操练起来。Compose 命令集不大，难点从来不是记命令，而是在什么场景用什么组合、输出里的信息怎么读。本节按一次完整的值班周期组织：起航、瞭望、介入、变更、收港。
准备一个编队做演习场（沿用上一节的三服务文件）：
# 起航：声明文件所在目录执行，-d 后台起航 docker compose up -d # [+] Running 4/4 # Network web-fleet_default Created # Volume "web-fleet_db-data" Created # Container web-fleet-db-1 Healthy # Container web-fleet-web-1 Started # 注意输出顺序：网络与卷先建，数据库健康检查通过后，应用才起——依赖自动排
瞭望与介入：编队视角的观察位
第 4 章练的观察位在编队里都有对应版本，差别是视角从"单箱"变成"整队"：
# 编队名册：服务、状态、端口一目了然 docker compose ps # NAME SERVICE STATUS PORTS # web-fleet-web-1 web Up 3 minutes 0.0.0.0:8080->8000/tcp # web-fleet-db-1 db Up 3 minutes (healthy) 5432/tcp # web-fleet-cache-1 cache Up 3 minutes 6379/tcp # 整队日志：所有服务的输出混排（各自带服务名前缀） docker compose logs -f --tail 5 # web-1 | INFO: Application startup complete # db-1 | database system is ready to accept connections # cache-1 | Ready to accept connections # 只看某只箱子的日志 docker compose logs -f db # 进入编队中的某只箱子（服务名即目标，不用查容器编号） docker compose exec web sh # /app# env | grep DB_HOST # DB_HOST=db <- 服务名做主机名，6.4 节展开 # 单箱体检（stats 与 top 也都支持服务名定位） docker compose top db
整队日志的混排值得多说一句：排障时跨服务的时间线对齐经常是破案关键（应用报连接失败的同一秒，数据库日志说了什么），混排视图天然给了时间轴。嫌吵就加 --tail 限行，定向追查再切单服务视图。
变更与扩缩：声明式的日常
改了声明文件或装箱单之后，让编队"追上"新声明只需重跑 up——引擎比对现状与期望，只动该动的部分：
# 声明或代码变更后的标准动作：重建有变化的服务，无变化的原地不动 docker compose up -d --build # [+] Running 2/2 # Container web-fleet-cache-1 Running <- 没变的：不动 # Container web-fleet-web-1 Recreated <- 变了的：重建
这就是声明式的日常甜头：你永远只需重申期望，不必计算差异。与之配套的还有在线调参与临时扩容：
# 在线查看与调整资源（与 docker update 同源） docker compose up -d web --scale web=3 # 起三只 web 副本（名字尾号 -1 -2 -3），共用同一条编队航道 # 依赖容器名互联的服务要改走"服务名"互联（本就如此），扩容才不会断
扩容多副本是编队也能做的，但要想清楚边界：编队的扩容是单机内的多副本，端口与资源约束都在一台宿主机里解决；跨机器的水平扩展，还是那句话——第 7 章的自动化港区。
项目名：你在哪支编队里
同一台机器上可以同时跑多支编队，引擎靠项目名区分。默认项目名取声明文件所在目录名——这就是为什么第 6.1 节体验里资源都叫 fleet-hello-xxx。项目名带来命名隔离（两支编队的同名服务互不干扰），也带来一个新手坑：在错误的目录执行命令，操作的是另一支编队。显式指定项目名的两个场景：
# 场景一：同一份文件起两套环境（项目名隔离） docker compose -p fleet-dev up -d docker compose -p fleet-test up -d docker compose -p fleet-test ps # 只看测试编队 # 场景二：按服务操作时的定位 docker compose -p fleet-dev restart web
日常守则：一个目录一支编队，up、down 都在声明文件目录执行；临时多套环境用 -p 显式管理，用完即 down，不留影子编队。
收港：分层清理的讲究
down 也讲究层次——默认行为是停容器、删容器、删网络，保留卷（数据安全默认值）：
# 标准收港：容器与网络清走，卷保留（数据安全） docker compose down # 彻底清仓：连卷一起删（数据没了！确认过再敲） docker compose down -v # [+] Running 3/3 # Container web-fleet-web-1 Removed # Volume web-fleet_db-data Removed # Network web-fleet_default Removed
-v 参数是本节最危险的一个键：开发环境的测试数据可以随手清，指着它清生产数据卷之前，请回忆 5.3 节"清理前看清单"的警告。改了镜像想换版本，标准组合也顺带记下：改声明里的 image 标签，然后 up -d 滚动重建该服务——换版本就是改声明重申期望，没有额外动作。
收尾前把整个操典串成一张速查口径：起航 up、瞭望 ps 加 logs、介入 exec、变更 up --build、收港 down。这五个动词覆盖日常运维九成以上的场景；剩下的一成（配置校验 config、事件查看 events、镜像清理 image prune）用到时查 --help 即可——你已经在第 2 章学会了"查"，这里正是兑现的地方。
本节要点回顾
- 值班周期五动作：up 起航、ps 与 logs 瞭望、exec 介入、up --build 变更、down 收港。
- up 重跑即追平声明：引擎自动算差异，只重建有变化的服务——声明式的日常甜头。
- 编队命令用服务名定位目标，整队日志混排自带跨服务时间轴。
- 项目名默认取目录名，决定资源命名与隔离；多套环境用 -p 显式区分。
- down 默认保留卷，down -v 连卷删除——本节最危险的键，敲前确认。
命令操练完毕。下一节处理编队的协调学：就绪顺序、服务互联与环境配置管理。