Docker Compose 是什么：一条命令把多个容器一起拉起

Docker Compose 是一个用一份 YAML 文件定义并管理多个容器的工具，核心是你把“要起哪些服务、怎么连、数据怎么存”都写进配置，然后一条命令全部拉起或关停。你在本地搭开发环境时常遇到这样的麻烦：一个项目要跑数据库、缓存、后端三个容器，手动 docker run 三次还容易连错。本文用初学者能跟上的方式，讲清它到底是什么、一份 compose 文件怎么写、和单容器命令差在哪，以及依赖顺序和网络不通这些常见坑。看完你能用一份配置管起一整套本地服务。今天这篇文章，编程狮就把这块讲透。

Docker Compose 一图看懂：一条命令起多容器

一、Compose 到底是什么

用一句判断句给定义：Docker Compose 是用声明式配置文件批量编排多个容器的工具，它把多个 docker run 参数收敛成一份可读的 YAML，用一条命令统一启停。

打个比方，就像把“点三道菜”写进一张菜单，后厨一次性出齐；而不是你跑三次单点、还得自己摆桌。Compose 也是把多容器的一次性编排交给一份文件。

1.1 触发条件

当你需要同时跑多个互相依赖的容器时，Compose 最值得用。典型场景是本地开发环境、小型演示部署、测试联调，这些地方手工起多个容器既烦又易错。

⚠️ 注意：Compose 主打单机多容器，不是生产级集群编排。真要跨主机调度、自动扩缩，得上 Kubernetes。想系统学 Docker，可先过一遍 Docker 教程。

1.2 常见误解

有人认为“Compose 就是写脚本代替 docker run”。其实关键在于它用声明式配置管理依赖、网络和卷的生命周期，启停一体、可追溯，而不是一串命令的堆砌。这也是它和纯脚本的区别。

二、一份 compose 文件怎么写

最核心是三个块：services 定义容器、volumes 挂持久化数据、networks 连内网。

services:
  web:
    image: nginx:alpine
    ports: ["8080:80"]
    networks: [app-net]
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    volumes: ["db-data:/var/lib/postgresql/data"]
    networks: [app-net]
volumes:
  db-data:
networks:
  app-net:

上面这段做的是把 web 和 db 两个服务、一个数据卷、一个网络写进一份文件。预期结果（未在本机执行，依据 Docker 官方文档）是执行 docker compose up 后，两个容器按配置启动并处于同一内网，web 能直接通过服务名访问 db。

💡 小提示：容器间通信用服务名当主机名（如 db），不用记 IP；改了配置后 docker compose up -d 会按差异重建，比手敲命令省心。

compose 文件三块核心：services volumes networks

三、单容器与多容器差在哪

docker run 适合起单个容器试手；Compose 适合一份配置管一整套；Kubernetes 适合生产集群编排。

3.1 版本与适用边界

Compose 文件格式有 v2/v3 等版本，新项目直接用 v3 起步。适用边界是：本地和单机用 Compose 足够；要跨节点、高可用、自动恢复才上 K8s。想厘清容器与虚拟机的关系，可参考容器与虚拟机笔记。

3.2 失败的表现

失败通常有两种：一是服务起不来却找不到原因，说明配置缩进或依赖写错；二是数据重启后没了，说明没挂卷。两者都要靠 docker compose ps 和日志来定位，不能只看启动成功。

四、它解决什么痛点

它把“多容器协作”从手工流程变成可版本化的配置：启停一条命令、环境可复制、同事拉下来就能跑。边界上，Compose 不解决资源调度和跨机容灾，那是编排平台的事；它专注让单机多容器变简单。

怎么验证编排真的可用？你会先配置好 compose 文件，在本地运行 docker compose up，检查各服务是否进入 healthy 状态，验证 web 能否通过服务名访问 db。失败时要看容器日志定位是依赖顺序还是端口问题，把这套“一键部署”流程接进 CI 做一次冒烟测试，才能保证同事拉下来就能跑。冒烟测试通过，才代表这份编排真能在别人机器上跑起来。

⚠️ 边界提醒：Compose 默认不保证启动顺序，数据库没就绪后端就可能连失败。需要顺序时要加 depends_on 配合健康检查，而不是假设“先起的总能用”。

单容器与多容器对比：docker run compose k8s

五、落地时容易踩的坑

把 compose 文件提交进版本库是个好习惯：环境变更有迹可循，同事拉到的是同一份配置，避免“在我机器上能跑”的扯皮。配合 .env 文件管理密码和端口，别把敏感信息硬编码进 yaml。每次改动后跑一次 docker compose config 校验语法，能提前拦住缩进和字段错误。环境即代码的思想，正是 Compose 最值得团队采纳的地方。

现象：后端连不上数据库。原因：没等 db 就绪。修复：用 depends_on 加健康检查，或后端加重连逻辑。
现象：重启后数据没了。原因：数据写在容器层没挂卷。修复：把关键目录挂到 named volume，再 up。
现象：端口被占用起不来。原因：宿主机端口冲突。修复：改 ports 映射，或用 docker compose ps 查占用。

# 常用操作片段（非完整脚本）
docker compose up -d        # 后台启动全部服务
docker compose ps           # 查看各服务状态
docker compose down         # 停止并移除容器（数据卷保留）
# 预期 up 后服务就绪，down 不会删 named volume（未在本机执行）

总结

Docker Compose 是用一份 YAML 声明式管理多个容器的工具，把多个 docker run 收敛成统一启停的配置。落地记住三点：services、volumes、networks 三块覆盖“起什么、存哪、怎么连”；容器间用服务名互联、数据要挂卷才不丢；它专注单机多容器，跨机编排交给 Kubernetes。想系统理解 Docker，可补 Docker 网络笔记。

要点带走：

Compose 是声明式多容器编排，不是脚本替代品；
数据持久化必须挂 volume，否则重启即丢；
它管单机，生产跨机调度才上 K8s。

延伸学习

想把这块知识系统补齐，可以按这个顺序来：

先过一遍 Docker 实战教程，看更多编排示例；
想对比轻量方案，读 Podman 笔记；
动手前补 Docker 课程打牢基础。

常见问题

Q：Compose 和 Kubernetes 是什么关系？

A：不冲突，是不同层级。Compose 适合单机多容器的本地开发和小型部署，一条命令启停；Kubernetes 适合跨多台机器的生产编排，管调度、扩缩和容灾。很多团队本地用 Compose、上线用 K8s。

Q：为什么重启容器数据会丢？

A：因为没挂卷时数据写在容器可写层，容器被移除就清空。解决办法是把数据库目录等挂到 named volume 或宿主机目录，Compose 里用 volumes 声明，数据便独立于容器生命周期。

Q：depends_on 能保证数据库先就绪吗？

A：不能保证“就绪”，只保证启动顺序。数据库进程起了不等于能接受连接。稳妥做法是用 depends_on 配 condition: service_healthy 健康检查，或让应用侧加重连，而不是假设先起就能用。