docker run vs docker compose:什么时候用哪个?
docker run 适合单容器快速启动,docker compose 适合多容器应用编排
对比
| 维度 | docker run | docker 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 即可启动完整开发环境。