docker run vs docker compose:什么时候用哪个?

docker run 适合单容器快速启动,docker compose 适合多容器应用编排

对比

维度docker rundocker compose
使用场景 运行单个容器,快速测试或一次性任务 定义和运行多容器应用,管理服务依赖关系
配置方式 命令行参数,参数多时命令很长 YAML 文件声明式配置,可版本控制
服务依赖 需要手动管理启动顺序和网络连接 depends_on 自动管理依赖和启动顺序
网络管理 需要手动创建网络并指定 --network 自动创建共享网络,服务名即主机名
环境一致性 每次运行需要记住所有参数 配置文件确保每次启动环境一致
扩展性 单容器,扩展需要手动管理 支持 --scale 水平扩展服务实例
适合团队 个人快速验证,不便于分享配置 配置文件可提交到仓库,团队共享

使用场景

什么时候用 docker run

  • 快速测试一个镜像是否正常工作
  • 运行一次性任务(如数据迁移脚本)
  • 只需要单个容器的简单场景
  • 学习和实验 Docker 基础功能

什么时候用 docker compose

  • 应用由多个服务组成(Web + DB + Cache)
  • 需要团队共享一致的开发环境
  • 服务之间有依赖关系需要编排
  • 需要一键启动/停止整个应用栈
  • CI/CD 中需要可复现的测试环境

示例

mergeExample

# docker run 启动多个服务(繁琐)
docker network create myapp
docker run -d --name db --network myapp -e POSTGRES_PASSWORD=secret postgres:15
docker run -d --name redis --network myapp redis:7-alpine
docker run -d --name web --network myapp -p 8080:3000 -e DB_HOST=db -e REDIS_HOST=redis myapp:latest

rebaseExample

# docker compose 一键启动(简洁)
# compose.yml 定义好所有服务后:
docker compose up -d

# 一键停止清理
docker compose down

常见错误

用很长的 docker run 命令管理多容器应用,难以维护和复现
compose 文件中硬编码密码,应该用环境变量或 secrets
忘记 compose 自动创建网络,手动加 --network 反而出错
在生产环境直接用 docker compose,应该考虑 Kubernetes 或 Swarm

建议

日常开发建议:单容器快速测试用 docker run --rm,项目开发环境用 docker compose。把 compose.yml 提交到代码仓库,新成员 clone 后一键 docker compose up -d 即可启动完整开发环境。