docker compose up 是干什么的
docker compose up 按编排文件创建并启动整套服务：先处理依赖顺序，再创建网络与卷，然后逐个拉起容器。默认前台运行且会占用终端，服务器上使用后台参数；启动前重建镜像、等待健康检查通过、强制重建容器这些参数，决定了它既能当日常启动命令，也能当发布动作使用。
基本信息
| 基本用法 | docker compose up [选项] [服务名] |
|---|---|
| 后台运行 | 加上对应参数后后台运行，服务器场景必须使用 |
| 重建镜像 | 启动前重新构建，改动构建文件后常用 |
| 等待就绪 | 配合健康检查等待全部服务就绪再返回，便于脚本判断 |
| 强制重建 | 配置改动未被识别时，用它强制重建容器 |
| 指定服务 | 只对某个服务执行，用于单服务重启与更新 |
典型使用场景
- 首次启动：创建网络、卷与容器，把整套环境拉起来
- 发布更新：重建镜像后启动，完成一次小规模发布
- 流水线部署：配合等待就绪参数，让脚本能判断部署成功与否
- 单服务更新：只重启被改动的服务，减少无关服务的抖动
- 排查配置不生效：配置改了但行为没变时，用强制重建排除容器复用
- 本地验证健康检查：确认服务在预期时间内就绪
常用参数速查
| 参数 | 作用 | 使用注意 |
|---|---|---|
| -d | 后台运行 | 生产环境必用，前台运行会随终端断开而停止 |
| --build | 启动前重建镜像 | 改动构建文件后使用 |
| --wait | 等待服务就绪再返回 | 需要服务配置了健康检查 |
| --force-recreate | 强制重建容器 | 排查配置不生效时使用 |
| --pull always | 先拉取最新镜像 | 注意标签漂移带来的风险 |
| 服务名 | 只操作指定服务 | 缩小影响范围的常用做法 |
常用形态
常用形态
docker compose up -d --build # 后台启动并重建镜像
docker compose up -d --wait # 等所有服务就绪再返回
docker compose up -d --force-recreate web # 强制重建单个服务
docker compose ps # 确认启动结果
docker compose logs -f --tail=50 web # 校验服务日志
# 避免在服务器上不加后台参数直接启动不加后台参数会占住终端：中断键可能触发整体停止，服务器上务必使用后台方式，避免会话断开导致服务停摆。
改了环境变量直接启动常不生效：容器会被复用，行为仍是旧配置，此时需要强制重建才能让改动落地。
等待就绪依赖健康检查：服务没有配置健康检查时，等待参数只能判断容器是否运行，不能判断服务是否真的可用。
启动后要做校验：查看服务状态与日志确认没有异常退出，比只看命令返回成功可靠得多。
编排启动的常见问题
- 依赖关系按实际启动顺序配置，并配合健康检查等待就绪
- 环境变量改动后需要强制重建容器才会真正生效
- 启动后核对服务状态与日志，命令返回成功不代表服务可用
- 把编排文件纳入版本管理，手工改动容易与环境脱节
- 生产环境使用固定镜像版本，避免每次启动拉到不同内容
- 定期清理停止的容器与无用网络，减少资源占用
启动失败时先看依赖服务的状态：健康检查未通过会阻断依赖它的服务，逐层排查比一次看完全部日志更清楚。